Hi Stefan,
Stefan Roese sr@denx.de writes:
Hmm. Seems reasonable, especially if this structure will be used for all drivers. But is this the case?
It's a mess right now. Some cpu-specific drivers are under the drivers directory (like the fsl drivers/qe/* for example) and some in the cpu directories. We should move those drivers from time to time to the drivers directory. But this will take quite a while.
If we have a consense with this location for the drivers, then at least we should start with moving *new* drivers directly into the "correct" place.
Yes, definitely. Now we only need to agree on where this is :-)
I still feel uncomfortable about placing a cpu dependant host controller driver in a generic driver directory. Will such a driver be maintained mainly by the USB Custodian or the respective Architecture Custodian? I would assume the latter.
This depends on the driver. If it's for example the ppc4xx ethernet driver it should be handled by the architecture custodian, but if it's the usb-ohci driver then it should be handled by the usb custodian. Most drivers will be handled (as they are right now) by the architecture custodian.
Yes, agreed.
But I see your point. By moving those cpu-specific files into the drivers directory, the architecture custodians need to maintain files distributed all over the drivers directory and not specifically in the cpu/xxx directory. I never thought of this before.
This is why I favor the old way of storing cpu dependant drivers in the appropriate cpu directory. This makes the responsibility clear and allows to cleanly seperate arch and generic code. Isn't this similar to linux where cpu dependant drivers are found in "arch/cpu/"?
Also, this is doesn't prohibit the cleaning up of "drivers" by adding subsystem subdirectories for net, usb etc.
What do you think?
Best Regards
Markus Klotzbücher
-- DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany