Hi Samuel,
Today's linux-next build (x86_64 allmodconfig) failed like this:
ERROR: "irq_to_desc" [drivers/mfd/wm831x.ko] undefined!
ERROR: "handle_edge_irq" [drivers/mfd/wm831x.ko] undefined!
ERROR: "set_irq_chip_and_handler" [drivers/mfd/wm831x.ko] undefined!
ERROR: "set_irq_noprobe" [drivers/mfd/wm831x.ko] undefined!
Probably caused by commit 8fc686c7369173519817f0cfbb2df9a3671d5b8d ("mfd:
Move WM831x to generic IRQ"). Maybe a Kconfig dependency is missing?
I have used the mfd tree from next-20091120 for today.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Hi Samuel,
On Mon, 23 Nov 2009 14:41:03 +1100 Stephen Rothwell <[email protected]> wrote:
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> ERROR: "irq_to_desc" [drivers/mfd/wm831x.ko] undefined!
> ERROR: "handle_edge_irq" [drivers/mfd/wm831x.ko] undefined!
> ERROR: "set_irq_chip_and_handler" [drivers/mfd/wm831x.ko] undefined!
> ERROR: "set_irq_noprobe" [drivers/mfd/wm831x.ko] undefined!
>
> Probably caused by commit 8fc686c7369173519817f0cfbb2df9a3671d5b8d ("mfd:
> Move WM831x to generic IRQ"). Maybe a Kconfig dependency is missing?
It actually looks as though set_irq_chip_and_handler (at least) is not
exported to modules.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Hi Stephen,
On Mon, Nov 23, 2009 at 03:03:46PM +1100, Stephen Rothwell wrote:
> Hi Samuel,
>
> On Mon, 23 Nov 2009 14:41:03 +1100 Stephen Rothwell <[email protected]> wrote:
> >
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> >
> > ERROR: "irq_to_desc" [drivers/mfd/wm831x.ko] undefined!
> > ERROR: "handle_edge_irq" [drivers/mfd/wm831x.ko] undefined!
> > ERROR: "set_irq_chip_and_handler" [drivers/mfd/wm831x.ko] undefined!
> > ERROR: "set_irq_noprobe" [drivers/mfd/wm831x.ko] undefined!
> >
> > Probably caused by commit 8fc686c7369173519817f0cfbb2df9a3671d5b8d ("mfd:
> > Move WM831x to generic IRQ"). Maybe a Kconfig dependency is missing?
>
> It actually looks as though set_irq_chip_and_handler (at least) is not
> exported to modules.
True. Mark, I think we should get those symbols exported, unless you have a
better idea ? Having wm831x as a boolean choice from Kconfig doesnt sound too
god to me.
Cheers,
Samuel.
> --
> Cheers,
> Stephen Rothwell [email protected]
> http://www.canb.auug.org.au/~sfr/
--
Intel Open Source Technology Centre
http://oss.intel.com/
On Mon, Nov 23, 2009 at 01:29:04PM +0100, Samuel Ortiz wrote:
> True. Mark, I think we should get those symbols exported, unless you have a
> better idea ? Having wm831x as a boolean choice from Kconfig doesnt sound too
> god to me.
I don't see getting them exported flying, especially not in the
timeframe we've got for the merge window. Keeping them non-exported has
been a deliberate decision on the part of the genirq maintainers. I'll
send a patch making it built in.
Given the typical applications for these parts building the driver in
isn't the end of the world - there's a reasonable chance it'll be forced
built in for other reasons due to device-specific configuration.
On Mon, Nov 23, 2009 at 01:11:13PM +0000, Mark Brown wrote:
> On Mon, Nov 23, 2009 at 01:29:04PM +0100, Samuel Ortiz wrote:
>
> > True. Mark, I think we should get those symbols exported, unless you have a
> > better idea ? Having wm831x as a boolean choice from Kconfig doesnt sound too
> > god to me.
>
> I don't see getting them exported flying, especially not in the
> timeframe we've got for the merge window. Keeping them non-exported has
> been a deliberate decision on the part of the genirq maintainers.
Out of curiosity, what's the reasoning behind thatdecision ?
> I'll send a patch making it built in.
Thanks, patch applied.
Cheers,
Samuel.
> Given the typical applications for these parts building the driver in
> isn't the end of the world - there's a reasonable chance it'll be forced
> built in for other reasons due to device-specific configuration.
--
Intel Open Source Technology Centre
http://oss.intel.com/
On Mon, Nov 23, 2009 at 03:44:14PM +0100, Samuel Ortiz wrote:
> On Mon, Nov 23, 2009 at 01:11:13PM +0000, Mark Brown wrote:
> > I don't see getting them exported flying, especially not in the
> > timeframe we've got for the merge window. Keeping them non-exported has
> > been a deliberate decision on the part of the genirq maintainers.
> Out of curiosity, what's the reasoning behind thatdecision ?
Unless you're actually implementing an interrupt controller those APIs
should never be called and people should be using flags on request_irq()
or similar. Driver authors have been awfully fond of bypassing those
APIs, but this prevents them doing so.
None of this is really a practical issue unless you implement an IRQ
controller in a driver and that's very rare (or has been up until now).