On Wed, Oct 22, 2008 at 02:04:52PM -0700, David Brownell wrote: > On Wednesday 22 October 2008, Anton Vorontsov wrote: > > > > > > The board info has another problem though. We can't remove it, thus > > > > we can't implement module_exit() for the 'OF glue'. > > That's not a problem. Why would you want to remove it? > > > > > And try to solve this problem... maybe then things will begin to > > > move forward. > > > > There is another problem: board infos are scanned at the controller > > registration time only. > > Right. Such board description data should be made available > early in boot. As a rule: before arch_initcall() finishes, > so that subsys_initcall() code can use the associated GPIOs. > > (It's fairly well acknowledged that init dependency handling > has a lot of problems. Until that's fixed ... for GPIOs, the > general advice is to make sure everything is available by > subsys_initcall time, so the subsystems which rely on GPIOs > to initialize -- power switches, resets, etc -- can initialize. > That can require i2c adapter drivers to use subsys_initcall, > for example.) > > > > So if we register the board infos after > > the controller registered, then nobody will probe the board infos. > > See above. If you're doing it right, there's no problem. > That is, scan the OF tables early. Just like PNP tables > get scanned early, for example.
Heh. If we don't want to be able to make the OF-parsing code be a module then there is no problem at all. I can use the bus notifiers. And it is most straightforward solution then. But I quite dislike to bloat the kernel image with maybe-never-used-on-this-board code. My aim was to make the OF-parsing part be a module too. Because in the long run we need the OF-parsing stuff for _every_ driver that needs platform data. It's quite expensive to have it always built-in, don't you think? -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev