On Mon, Apr 21, 2008 at 08:58:09AM -0600, Grant Likely wrote: > On Mon, Apr 21, 2008 at 8:49 AM, Anton Vorontsov > <[EMAIL PROTECTED]> wrote: > > > > Should this really be a arch_initcall()? Would it be better for > > > > platforms needing it to call it explicitly from one of the platform's > > > > machine_arch_initcall()? Otherwise it gets called for all platforms > > > > in a multiplatform kernel. > > > > > > Ok, I'll place it into qe_reset(). > > > > Ugh, no, I can't. qe_reset() is called too early. And I don't like > > having every QE board file to call this through machine_arch_initcall... > > Hmm, what to do.. well, is this thaat bad to call this for every > > platform?.. > > Its not great. It has a boot time impact for every platform compiled > into the kernel. The problem gets worse every time another block of > code uses this method. Personally I prefer platform code calling it > explicitly. > > Making it an of_platform device would also eliminate that problem, but > you'd need a method to synchronize the driver with its users. > > I'm not going to raise a big stink about it, but the issue should not > be ignored.
Heh.. how QE GPIO is different from FSL GTM then? Should I call fsl_gtm_init() from the board file too? For the every board? I do believe that years later someone will show up with something like this: From: J. Random Hacker Subject: [POWERPC] cleanup board initialization code This patch removes vast amount of machine_arch_initcall()s that were used to solely initialize some hardware, like this: qe_add_gpio_chips(); fsl_gtm_init(); fsl_spi_init(); ... So, instead of calling this stuff from the board files, we implement own arch_initcalls for these functions. This causes negligible run-time overhead for the boards that aren't using that hardware, but this overhead isn't measurable anyway. Also, this patch shrinks .text size a bit, and produces nice looking diffstat. 12 file changed, 6 insertions(+), 140 deletions(-) -- 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