Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

linux-next: mfd tree build failure

0 views
Skip to first unread message

Stephen Rothwell

unread,
Nov 22, 2009, 10:40:02 PM11/22/09
to
Hi Samuel,

Today's linux-next build (x86_64 allmodconfig) failed like this:

drivers/power/pcf50633-charger.c: In function 'pcf50633_mbc_get_usb_online_status':
drivers/power/pcf50633-charger.c:147: error: 'struct pcf50633' has no member named 'mbc_pdev'

Caused by commit 4c2e3bacc050f0ebf884954bb007616c162564cd ("mfd: pcf50633
- fix error handling during probe") from the mfd tree interacting with
commit c329795052aa339850a45fab649ab97a36905136 ("pcf50633: Query charger
status directly") from the battery tree.

I have applied the following merge fixup patch and can carry it as
necessary.

From: Stephen Rothwell <s...@canb.auug.org.au>
Date: Mon, 23 Nov 2009 14:31:43 +1100
Subject: [PATCH] mfd: fix pcf50633-charger.c for fallout from merge

Signed-off-by: Stephen Rothwell <s...@canb.auug.org.au>
---
drivers/power/pcf50633-charger.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/power/pcf50633-charger.c b/drivers/power/pcf50633-charger.c
index d4a3e77..4e535bb 100644
--- a/drivers/power/pcf50633-charger.c
+++ b/drivers/power/pcf50633-charger.c
@@ -144,7 +144,8 @@ EXPORT_SYMBOL_GPL(pcf50633_mbc_get_status);

int pcf50633_mbc_get_usb_online_status(struct pcf50633 *pcf)
{
- struct pcf50633_mbc *mbc = platform_get_drvdata(pcf->mbc_pdev);
+ struct pcf50633_mbc *mbc =
+ platform_get_drvdata(pcf->pdevs[PCF50633_PDEV_ADC_IDX]);

if (!mbc)
return 0;
--
1.6.5.3

--
Cheers,
Stephen Rothwell s...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Stephen Rothwell

unread,
Nov 22, 2009, 10:50:01 PM11/22/09
to
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.

Stephen Rothwell

unread,
Nov 22, 2009, 11:10:01 PM11/22/09
to
Hi Samuel,

On Mon, 23 Nov 2009 14:41:03 +1100 Stephen Rothwell <s...@canb.auug.org.au> 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.

Samuel Ortiz

unread,
Nov 23, 2009, 7:30:02 AM11/23/09
to
Hi Dmitry,

On Mon, Nov 23, 2009 at 02:35:03PM +1100, Stephen Rothwell wrote:
> Hi Samuel,
>
> Today's linux-next build (x86_64 allmodconfig) failed like this:
>
> drivers/power/pcf50633-charger.c: In function 'pcf50633_mbc_get_usb_online_status':
> drivers/power/pcf50633-charger.c:147: error: 'struct pcf50633' has no member named 'mbc_pdev'
>
> Caused by commit 4c2e3bacc050f0ebf884954bb007616c162564cd ("mfd: pcf50633
> - fix error handling during probe") from the mfd tree interacting with
> commit c329795052aa339850a45fab649ab97a36905136 ("pcf50633: Query charger
> status directly") from the battery tree.

Could we split the above fix so that we get back to the:

struct platform_device *rtc_pdev;
struct platform_device *mbc_pdev;
struct platform_device *adc_pdev;
struct platform_device *input_pdev;
struct platform_device *regulator_pdev[PCF50633_NUM_REGULATORS];

structure ? We can move to the index based structure after the next merge
window. That would make my life easier in terms of tree dependencies.
If you dont have time to do this change, I'll do it some time this week.

Thanks in advance.

Cheers,
Samuel.

--
Intel Open Source Technology Centre
http://oss.intel.com/

Samuel Ortiz

unread,
Nov 23, 2009, 7:30:02 AM11/23/09
to
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 <s...@canb.auug.org.au> 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 s...@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/

--

Mark Brown

unread,
Nov 23, 2009, 8:20:03 AM11/23/09
to
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.

Samuel Ortiz

unread,
Nov 23, 2009, 9:50:02 AM11/23/09
to
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/

Mark Brown

unread,
Nov 23, 2009, 10:30:02 AM11/23/09
to
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).

Dmitry Torokhov

unread,
Nov 23, 2009, 11:40:02 AM11/23/09
to
Hi Samuel,

On Mon, Nov 23, 2009 at 01:26:07PM +0100, Samuel Ortiz wrote:
> Hi Dmitry,
>
> On Mon, Nov 23, 2009 at 02:35:03PM +1100, Stephen Rothwell wrote:
> > Hi Samuel,
> >
> > Today's linux-next build (x86_64 allmodconfig) failed like this:
> >
> > drivers/power/pcf50633-charger.c: In function 'pcf50633_mbc_get_usb_online_status':
> > drivers/power/pcf50633-charger.c:147: error: 'struct pcf50633' has no member named 'mbc_pdev'
> >
> > Caused by commit 4c2e3bacc050f0ebf884954bb007616c162564cd ("mfd: pcf50633
> > - fix error handling during probe") from the mfd tree interacting with
> > commit c329795052aa339850a45fab649ab97a36905136 ("pcf50633: Query charger
> > status directly") from the battery tree.
> Could we split the above fix so that we get back to the:
>
> struct platform_device *rtc_pdev;
> struct platform_device *mbc_pdev;
> struct platform_device *adc_pdev;
> struct platform_device *input_pdev;
> struct platform_device *regulator_pdev[PCF50633_NUM_REGULATORS];
>
> structure ? We can move to the index based structure after the next merge
> window. That would make my life easier in terms of tree dependencies.
> If you dont have time to do this change, I'll do it some time this week.
>

Please feel free to drop or reschedule the patch as you see fit. I don't
have any problem if it will go in later.

Thanks.

--
Dmitry

Samuel Ortiz

unread,
Nov 24, 2009, 6:40:02 PM11/24/09
to
Hi Dmitry

On Mon, Nov 23, 2009 at 08:32:11AM -0800, Dmitry Torokhov wrote:
> > Could we split the above fix so that we get back to the:
> >
> > struct platform_device *rtc_pdev;
> > struct platform_device *mbc_pdev;
> > struct platform_device *adc_pdev;
> > struct platform_device *input_pdev;
> > struct platform_device *regulator_pdev[PCF50633_NUM_REGULATORS];
> >
> > structure ? We can move to the index based structure after the next merge
> > window. That would make my life easier in terms of tree dependencies.
> > If you dont have time to do this change, I'll do it some time this week.
> >
>
> Please feel free to drop or reschedule the patch as you see fit. I don't
> have any problem if it will go in later.

Yes, I'll requeue your patchset after the next merge window is closed.
Thanks for your understanding.

Cheers,
Samuel.

--
Intel Open Source Technology Centre
http://oss.intel.com/

0 new messages