Thread (17 messages) flat view 17 messages, 3 authors, 2011-03-18

Re: [RFC PATCH 1/2] serial: 8250: Add a notifier chain for driver registration.

From: Grant Likely <hidden>
Date: 2011-03-17 20:32:00
Also in: linux-devicetree, lkml

On Thu, Mar 17, 2011 at 01:13:06PM -0700, David Daney wrote:
On 03/17/2011 12:31 PM, Grant Likely wrote:
quoted
On Thu, Mar 17, 2011 at 07:24:41PM +0000, Alan Cox wrote:
quoted
quoted
quoted
If we did that, serial8250_probe() would automatically do the right thing.
Take a look at the way arch/powerpc/platforms/512x/pdm360ng.c uses a
notifier for amending a platform_device with additional data..
I tend to view arch specific embedded code as rather like very dubious
parties. What goes on in other peoples' house out of sight is none of my
business.

The 8250 however is core code so it should keep its clothers on and behave
in a manner befitting its status.

What part of the problem can't be solved by doing it properly using the
device registration interfaces we have today ?
Device registration isn't the problem.  The problem is supplying
machine-specific callbacks from the board support code to the
drivers.  When devices are sourced from a device tree, it is easy to
get data about the device out of the tree, but it is really hard to
get callback pointers.  To make it all work without this fiddling
about, the octeon serial_{in,out} implementation would need to be
rolled into of_serial.c (which FWIW, I have absolutely no problem
with).
The only problem I have with that is that it ends up moving chip
specific erratum workarounds into drivers/tty/serial instead of
arch/mips/cavium-octeon.

I will think about this more.
arch/mips/cavium-octeon/serial.c appears to be void of any
chip-specific errata at the moment.  :-)

g.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help