[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081022010347.GA7377@oksana.dev.rtsoft.ru>
Date: Wed, 22 Oct 2008 05:03:47 +0400
From: Anton Vorontsov <avorontsov@...mvista.com>
To: Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc: David Brownell <david-b@...bell.net>,
David Brownell <dbrownell@...rs.sourceforge.net>,
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 Wed, Oct 22, 2008 at 11:29:20AM +1100, Benjamin Herrenschmidt wrote:
>
> > But it doesn't work as a module (i.e. OF-specific bits should be
> > always in-kernel).
>
> Why not ?
If say "X" driver loads prior to bus-notifier module (where we fill
the platform data), then X.0 device will try to probe w/o platform
data and will fail. The only way to re-probe things is to rmmod X &&
insmod of_pdata_filler_X && insmod X. So things depend on the module
load order.
The obvious solution is to link the OF stuff into the module, but
this also won't work, since modules have only one entry (and exit)
point. So there is no way* to hook our OF helpers into the module.
* Well, there is one solution to this problem. We can implement
arch-specific init_module and cleanup_module entry/exit points,
where we can load/unload the OF hooks. This is quite easy, but
may look ugly. I could show the drafts.
--
Anton Vorontsov
email: cbouatmailru@...il.com
irc://irc.freenode.net/bd2
--
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