linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: "Grant Likely" <grant.likely@secretlab.ca>
To: "Sergei Shtylyov" <sshtylyov@ru.mvista.com>
Cc: linuxppc-dev@ozlabs.org, Pavel Kiryukhin <pkiryukhin@ru.mvista.com>
Subject: Re: [PATCH] booting-without-of: add Xilinx uart 16550.
Date: Fri, 15 Feb 2008 12:33:38 -0700	[thread overview]
Message-ID: <fa686aa40802151133l2a76d101pcd827b3d41af6609@mail.gmail.com> (raw)
In-Reply-To: <47B5E4B2.4050705@ru.mvista.com>

On Fri, Feb 15, 2008 at 12:14 PM, Sergei Shtylyov
<sshtylyov@ru.mvista.com> wrote:
> Grant Likely wrote:
>  > The registers are not at the same location, therefore it is not compatible.
>
>  > However, the *driver* can be easily made compatible with the devices.
>  > We just teach the driver to bind against both "ns16550" and whatever
>  > value is chosen for these reg-shifted devices.  Not a big deal.
>
>     You're going to "teach" 8250.c? Good luck. :-)

:-P

As you already know, 8250.c already knows how to handle reg shifts.
But that is not what this conversation is about.

>     IMO we can only teach a glue layer which "passes" UARTs to 8250.c via
>  platform devices.

That's right.  This discussion is only about the device tree binding.
It is not about the core driver.

>  > compatible also covers bus binding when it is a memory mapped device.
>  > Otherwise you need another node between the bus and the ns16550 type
>  > device that does translation from the wide stride (regshift=2) to the
>  > ns16550 register definitions (regshift=0).
>
>     The chip can be connected to the bus (via chip select circuitry) in
>  different ways, therefore we need a "glue" node for that circuitry?

I'm not arguing that we want a glue node.  What I'm arguing is that
"compatible=ns16550" has a very specific meaning that has become a
defacto standard over the years.  To add a new interpretation of that
meaning is problematic.  Instead, if reg shift is needed then use a
different value for compatible.

It's not like we're talking about something that is hard to do.  It is
simply being explicit in the device tree layout.  Historically
"ns16550" means no reg shift, so don't use it for devices that have a
reg shift.

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

  reply	other threads:[~2008-02-15 19:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-15 13:40 [PATCH] booting-without-of: add Xilinx uart 16550 Pavel Kiryukhin
2008-02-15 17:08 ` Stephen Neuendorffer
2008-02-15 17:41   ` Pavel Kiryukhin
2008-02-15 17:46     ` Stephen Neuendorffer
2008-02-15 18:34 ` Milton Miller
2008-02-15 18:38 ` Grant Likely
2008-02-15 18:56   ` Sergei Shtylyov
2008-02-15 19:02     ` Grant Likely
2008-02-15 19:14       ` Sergei Shtylyov
2008-02-15 19:33         ` Grant Likely [this message]
2008-02-15 21:40     ` Stephen Neuendorffer
2008-02-18 19:47       ` Sergei Shtylyov

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=fa686aa40802151133l2a76d101pcd827b3d41af6609@mail.gmail.com \
    --to=grant.likely@secretlab.ca \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=pkiryukhin@ru.mvista.com \
    --cc=sshtylyov@ru.mvista.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).