On 10/2/07, Benjamin Herrenschmidt <[EMAIL PROTECTED]> 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. [EMAIL PROTECTED] (403) 399-0195 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
