> 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. 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. Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
