[PATCH v3] tty: serial: add Freescale lpuart driver support

Jin Zhengxiong-R64188 R64188 at freescale.com
Sun May 26 21:27:04 EDT 2013


> On Wed, May 22, 2013 at 08:59:20AM +0000, Jin Zhengxiong-R64188 wrote:
> > [Jason Jin-R64188] For the lpuart itself, I do not think it will have
> different version IP.
> 
> You can never tell in 5 or 10 years.  Also no major version doesn't
> necessarily mean no minor updates or revise.
> 
> > The general name is sufficient and soc related name can introduce the
> minor difference. If the there are update version, we can name it
> lpuart2.0 or something like that.
> >
> 
> Yeah, if IP designers name it lpuart2.0, it surely works.  But from my
> experience on IMX, hardware guys are not always properly updating IP name.
> Then the version 2.0 becomes a versioning given by software people which
> is improper to be used in compatible string.
> 
[Jason Jin-R64188] We had some internal discussion on this. For the lpuart itself, as we cannot get the version information at run time from the version register and lpuart is not publicly versioned, we agree to use the SoC name for lpuart. 
However, if the version information can be got from the register at run time, or the version was publicly versioned. the general name still useful than the SoC name. 
on the other side, the SoC itself may also have new versions, So the SoC name is also not a perfect solution.

> >
> 
> Think about it from "compatibility" point of view.  It does not cause
> confusion but just help understand the compatible history.  Saying the
> same IP is reused on LS-1 SoC, I do not see a problem with putting the
> following compatible into LS-1 <soc>.dtsi under UART node, to tell that
> the UART block on LS-1 is completely compatible with the one used on
> MVF600.
> 
>   compatible = "fsl,ls1-uart", "fsl,mvf600-uart";
> 
[Jason Jin-R64188] We'll leverage this compatible strings for compatible history. Thanks.
By the way, we'll change the SoC name from mvf600 to vf610 to align the description in the document. 




More information about the linux-arm-kernel mailing list