Re: [PATCH 2 6/7] Uartlite: Add of-platform-bus binding

["Grant Likely" <grant.likely@secretlab.ca>]

On 10/2/07, Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > My opinion is that since it is driver-specific code anyway, then it
> > belongs with the driver.  Plus a driver writer for ARM doesn't need to
> > write them.  It's the powerpc or microblaze developer who will do it.
> > If the driver maintainer doesn't want the binding in the main driver
> > .c file, then the binding can easily be in an additional .c file
> > without needing to add a constructor.  (Kind of like how many USB host
> > controllers are managed)
>
> The main advantage is that it keeps the OF specific code localized to a
> single function, whether that function lives in the driver or the arch
> code, it makes it self contained and easier to deal with by the driver
> author.
>
> Having multiple device types on which the driver can attach is a pain
> from a driver standpoint. It needs multiple
> probe/remove/suspend/resume/shutdown hooks etc... it's a bigger
> maintainance burden in the long run.

For many drivers, I think that is already the case.  USB OHCI is a
prime example where there are both PCI and platform_bus bindings among
others.  It seems to me that the bus binding effectively translates
down to "where do I go to get the needed information".  I think it
results in less of a maintenance burden to explicitly separate bus
binding from device setup as opposed to adding constructor code.

> The important thing however, with the constructor approach is to try as
> much as possible to keep the proper tree structure, and thus, try to
> find a way to instanciate the devices with proper parent/child
> relationship so that ordering for things like suspend/resume operations
> is maintained.

I'm not sure I follow.  Example?

Thanks,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195