netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: Rob Herring <robherring2@gmail.com>
Cc: Shawn Guo <shawn.guo@freescale.com>,
	patches@linaro.org, netdev@vger.kernel.org,
	devicetree-discuss@lists.ozlabs.org,
	Jason Liu <jason.hui@linaro.org>,
	linux-kernel@vger.kernel.org,
	Jeremy Kerr <jeremy.kerr@canonical.com>,
	Sascha Hauer <s.hauer@pengutronix.de>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 1/3] serial/imx: add device tree support
Date: Sun, 19 Jun 2011 12:44:34 -0600	[thread overview]
Message-ID: <BANLkTi=Ur1+FAHd2J_KGZgtuGTHrrtBb_g@mail.gmail.com> (raw)
In-Reply-To: <4DFE129E.1010800@gmail.com>

On Sun, Jun 19, 2011 at 9:15 AM, Rob Herring <robherring2@gmail.com> wrote:
> On 06/19/2011 10:05 AM, Grant Likely wrote:
>> On Sun, Jun 19, 2011 at 1:30 AM, Shawn Guo <shawn.guo@freescale.com> wrote:
>>> On Sat, Jun 18, 2011 at 10:19:34AM -0600, Grant Likely wrote:
>>>> On Sat, Jun 18, 2011 at 11:19:12PM +0800, Shawn Guo wrote:
>>>>> It adds device tree data parsing support for imx tty/serial driver.
>>>>>
>>>>> Signed-off-by: Jeremy Kerr <jeremy.kerr@canonical.com>
>>>>> Signed-off-by: Jason Liu <jason.hui@linaro.org>
>>>>> Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
>>>>> Cc: Sascha Hauer <s.hauer@pengutronix.de>
>>>>> ---
>>>>>  .../bindings/tty/serial/fsl-imx-uart.txt           |   21 +++++
>>>>>  drivers/tty/serial/imx.c                           |   81 +++++++++++++++++---
>>>>>  2 files changed, 92 insertions(+), 10 deletions(-)
>>>>>  create mode 100644 Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
>>>>> new file mode 100644
>>>>> index 0000000..7648e17
>>>>> --- /dev/null
>>>>> +++ b/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
>>>>> @@ -0,0 +1,21 @@
>>>>> +* Freescale i.MX Universal Asynchronous Receiver/Transmitter (UART)
>>>>> +
>>>>> +Required properties:
>>>>> +- compatible : should be "fsl,<soc>-uart", "fsl,imx-uart"
>>>>
>>>> I'd make this "fsl,<soc>-uart", "fsl,imx51-uart"
>>>>
>>>> It's better to anchor these things on real silicon, or a real ip block
>>>> specification rather than something pseudo-generic.  Subsequent chips,
>>>> like the imx53, should simply claim compatibility with the older
>>>> fsl,imx51-uart.
>>>
>>> It is a real IP block on all imx silicons (except imx23 and imx28
>>> which are known as former stmp).
>>>
>>>>
>>>> (in essence, "fsl,imx51-uart" becomes the generic string without the
>>>> downside of having no obvious recourse when new silicon shows up that
>>>> is an imx part, but isn't compatible with the imx51 uart.
>>>>
>>> In this case, should imx1 the ancestor of imx family than imx51
>>> becomes part of that generic string?  Claiming uart of imx1, imx21
>>> and imx31 (senior than imx51) compatible with the imx51 uart seems
>>> odd to me.
>>>
>>> That said, IMO, "fsl,imx-uart" stands a real IP block specification
>>> here and can be a perfect generic compatibility string to tell the
>>> recourse of any imx silicon using this IP.
>>
>> Yes, but which /version/ of the IP block?  Hardware designers are
>> notorious for changing hardware designs for newer silicon, sometimes
>> to add features, sometimes to fix bugs.  While I understand the
>> temptation to boil a compatible value down to a nice clean generic
>> string, doing so only works in a perfect world.  In the real world,
>> you still need to have some information about the specific
>> implementation.  I prefer this specifying it to the SoC name, but I've
>> been known to be convinced that specifying it to the ip-block name &
>> version in certain circumstances, like for IP blocks in an FPGA, or
>> some of the Freescale powerpc pXXXX SoCs which actually had an IP
>> block swapped out midway through the life of the chip.
>>
>
> There are definitely uart changes along the way with each generation.
>
>> Besides, encoding an soc or ip block version into the 'generic'
>> compatible values is not just good practice, it has *zero downside*.
>> That's the beauty of the compatible property semantics.  Any node can
>> claim compatibility with an existing device.  If no existing device
>> fits correctly, then the node simple does not claim compatibility.
>> Drivers can bind to any number of compatible strings, so it would be
>> just fine for the of_match_table list to include both "fsl,imx-21" and
>> "fsl,imx-51" (assuming that is the appropriate solution in this case).
>>
>
> Don't you need uart or serial in here somewhere.

you are of course correct.  The examples should be "fsl,imx21-uart" &
"fsl,imx51-uart".  I was just writing too quickly.

g.

  reply	other threads:[~2011-06-19 18:44 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-18 15:19 [PATCH 0/3] Add basic device support for imx51 babbage Shawn Guo
     [not found] ` <1308410354-21387-1-git-send-email-shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2011-06-18 15:19   ` [PATCH 1/3] serial/imx: add device tree support Shawn Guo
     [not found]     ` <1308410354-21387-2-git-send-email-shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2011-06-18 16:19       ` Grant Likely
2011-06-19  7:02         ` Wolfram Sang
2011-06-19  7:30         ` Shawn Guo
2011-06-19 15:05           ` Grant Likely
2011-06-19 15:15             ` Rob Herring
2011-06-19 18:44               ` Grant Likely [this message]
2011-06-21 13:55           ` Shawn Guo
2011-06-21 18:32             ` Mitch Bradley
2011-06-21 18:42               ` Grant Likely
2011-06-21 18:53                 ` Russell King - ARM Linux
2011-06-21 19:02                   ` Grant Likely
     [not found]                 ` <BANLkTiny9xDwiUww9Ys+jQZ0SHdQATABUA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-06-21 19:04                   ` Mitch Bradley
2011-06-21 19:13             ` Grant Likely
     [not found]               ` <BANLkTim4vunTm1176MRw3pqRZnunu4=9jg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-06-21 19:35                 ` Mitch Bradley
2011-06-21 19:38                   ` Grant Likely
2011-06-21 22:08                     ` Mitch Bradley
2011-06-21 22:33                       ` Grant Likely
     [not found]                         ` <BANLkTikBUo3jO=R0amkdxU1V3QMJoOUkEw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-06-21 22:52                           ` Segher Boessenkool
     [not found]                             ` <ba379b3b42f1659f4f6649c78b8bb1b2-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2011-06-21 22:58                               ` Grant Likely
2011-06-22 15:33                 ` Shawn Guo
2011-06-22 15:52                   ` Grant Likely
     [not found]                     ` <BANLkTimsk2eWKPi2hnHbaAn-vSMKmdYsGQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-06-23  0:12                       ` Shawn Guo
     [not found]                         ` <20110623001234.GB25799-+NayF8gZjK2ctlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2011-06-23  3:35                           ` Grant Likely
2011-06-23 18:38               ` Shawn Guo
2011-06-23 23:11                 ` Grant Likely
     [not found]                   ` <BANLkTi=8Mks6T85WnEyihmB21U1j7reHrQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-06-24  3:49                     ` Shawn Guo
     [not found]                       ` <20110624034859.GB19188-+NayF8gZjK2ctlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
2011-06-24  4:05                         ` Grant Likely
2011-06-18 16:21     ` Arnd Bergmann
     [not found]       ` <201106181821.46574.arnd-r2nGTMty4D4@public.gmane.org>
2011-06-18 16:26         ` Grant Likely
     [not found]           ` <20110618162655.GK8195-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2011-06-18 18:11             ` Arnd Bergmann
2011-06-19  7:41           ` Shawn Guo
2011-06-19  7:40         ` Shawn Guo
2011-06-18 15:19   ` [PATCH 2/3] net/fec: " Shawn Guo
2011-06-18 16:22     ` Grant Likely
     [not found]       ` <20110618162220.GI8195-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2011-06-19  7:46         ` Shawn Guo
     [not found]     ` <1308410354-21387-3-git-send-email-shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2011-06-18 18:27       ` Arnd Bergmann
     [not found]         ` <201106182027.22974.arnd-r2nGTMty4D4@public.gmane.org>
2011-06-19  0:24           ` Grant Likely
2011-06-19  7:55         ` Shawn Guo
2011-06-19 11:39     ` Greg Ungerer
2011-06-19 12:11       ` Arnd Bergmann
2011-06-19 15:09         ` Rob Herring
2011-06-19 18:43           ` Grant Likely
2011-06-20  0:05         ` Greg Ungerer
2011-06-18 15:19   ` [PATCH 3/3] ARM: mx5: add basic device tree support for imx51 babbage Shawn Guo
     [not found]     ` <1308410354-21387-4-git-send-email-shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2011-06-18 16:24       ` Grant Likely
2011-06-18 16:29   ` [PATCH 0/3] Add basic device " Grant Likely

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='BANLkTi=Ur1+FAHd2J_KGZgtuGTHrrtBb_g@mail.gmail.com' \
    --to=grant.likely@secretlab.ca \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=jason.hui@linaro.org \
    --cc=jeremy.kerr@canonical.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=patches@linaro.org \
    --cc=robherring2@gmail.com \
    --cc=s.hauer@pengutronix.de \
    --cc=shawn.guo@freescale.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).