[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200810221452.46786.david-b@pacbell.net>
Date: Wed, 22 Oct 2008 14:52:46 -0700
From: David Brownell <david-b@...bell.net>
To: avorontsov@...mvista.com
Cc: benh@...nel.crashing.org, linux-kernel@...r.kernel.org,
linuxppc-dev@...abs.org, i2c@...sensors.org,
Jean Delvare <khali@...ux-fr.org>,
David Miller <davem@...emloft.net>
Subject: Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls
On Wednesday 22 October 2008, Anton Vorontsov wrote:
> >
> > > 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.
So have it live in the __init text section. If you're
building a kernel with support for several boards, you
know it's necessarily going to be larger than it would
be if only one board were supported. But you can shrink
kernel size by judicious use of __init sections..
> 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?
If it's discarded early, after translating the data from
OF format into what the drivers need, there will be no
RAM footprint.
- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists