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

Kconfig warnings on latest GIT

9 views
Skip to first unread message

Ismail Dönmez

unread,
May 7, 2007, 5:10:08 PM5/7/07
to
Hi,

Following Kconfig warnings shows up with latest GIT :

drivers/net/Kconfig:2279:warning: 'select' used by config symbol 'UCC_GETH'
refers to undefined symbol 'UCC_FAST'

drivers/input/keyboard/Kconfig:170:warning: 'select' used by config
symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'

drivers/input/mouse/Kconfig:161:warning: 'select' used by config
symbol 'MOUSE_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'

Regards,
ismail

--
Le mieux est l'ennemi du bien.
-
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/

Kim Phillips

unread,
May 8, 2007, 3:40:11 PM5/8/07
to
On Tue, 8 May 2007 00:04:14 +0300
Ismail Dönmez <ism...@pardus.org.tr> wrote:

>
> drivers/net/Kconfig:2279:warning: 'select' used by config symbol 'UCC_GETH'
> refers to undefined symbol 'UCC_FAST'

looks like this introduces the error:

commit 7d776cb596994219584257eb5956b87628e5deaf
Author: Timur Tabi <ti...@freescale.com>
Date: Mon Mar 12 15:40:27 2007 -0500

[POWERPC] QE: automatically select QE options

Change the Kconfig files so that the Freescale QE options are automatically
selected if a QE device is selected. Previously, you'd need to manually
select UCC_FAST if you want any "fast" UCC devices, such as Gigabit Ethernet
Now, the QE Gigabit Ethernet option is always available if the device has a
QE, and UCC_FAST is automatically enabled. A side-effect is that the
"QE Options" menu no longer exists.

Signed-off-by: Timur Tabi <ti...@freescale.com>
Signed-off-by: Kumar Gala <ga...@kernel.crashing.org>

cc:ing authors, fti.

Kim

Timur Tabi

unread,
May 8, 2007, 4:20:10 PM5/8/07
to
Kim Phillips wrote:
> On Tue, 8 May 2007 00:04:14 +0300
> Ismail Dönmez <ism...@pardus.org.tr> wrote:
>
>> drivers/net/Kconfig:2279:warning: 'select' used by config symbol 'UCC_GETH'
>> refers to undefined symbol 'UCC_FAST'
>
> looks like this introduces the error:
>
> commit 7d776cb596994219584257eb5956b87628e5deaf
> Author: Timur Tabi <ti...@freescale.com>
> Date: Mon Mar 12 15:40:27 2007 -0500
>
> [POWERPC] QE: automatically select QE options

I have a dilemma, so I need help fixing this bug.

This particular patch is necessary because without it, selecting support for the QE is too
complicated.

Background: The QUICC Engine (QE) is a microcontroller on some Freescale CPUs that can
mimic a wide variety of devices. It has multiple controllers (called UCCs), and each one
can be an ethernet device, or a UART, or an HDLC thingy, etc. There's a QE library and a
bunch of other support code in the arch/powerpc directory, so the QE is a powerpc-specific
device. However, all of the drivers that use it are located in drivers/xxx.

This isn't a new problem. The common solution is to define some intermediate Kconfig
option, like UCC_FAST_TEMP in the driver's Kconfig. Selecting UCC_FAST will then also set
UCC_FAST_TEMP. The device driver then depends on UCC_FAST_TEMP.

There's also a UCC_SLOW option with the same problem.

The dillema is that there is no single device driver class that depends on UCC_FAST.
Currently, there's only one that uses UCC_FAST: the ucc_geth driver. But I'm also working
on a UART driver.

So my question is: in which Kconfig do I define "UCC_FAST_TEMP" and "UCC_SLOW_TEMP"? At
first I thought, just put it in drivers/Kconfig, but that Kconfig does nothing but
including other Kconfigs. I believe that if I submit a patch that adds "UCC_FAST_TEMP"
and "UCC_SLOW_TEMP" to drivers/Kconfig, it will be rejected. Either that, or I'll spend
six weeks trying to persuade everyone that it's a good idea.

Does anyone have any suggestions on how I can fix this?

--
Timur Tabi
Linux Kernel Developer @ Freescale

Simon Horman

unread,
May 10, 2007, 1:20:07 AM5/10/07
to

That does seem like a reasonable suggestion, and one that
would probably work well with the other similar problems
that have been introduced sice 2.6.21.

drivers/input/keyboard/Kconfig:170:warning: 'select' used by config symbol 'KEYBOARD_ATARI' refer to undefined symbol 'ATARI_KBD_CORE'
drivers/input/mouse/Kconfig:102:warning: 'select' used by config symbol 'MOUSE_ATARI' refer to undefined symbol 'ATARI_KBD_CORE'

Which seem to be introduced by:

commit c04cb856e20a8bf68762d60737b84328c1ab5900
Author: Michael Schmitz <sch...@opal.biophys.uni-duesseldorf.de>
Date: Tue May 1 22:32:38 2007 +0200

m68k: Atari keyboard and mouse support.

Atari keyboard and mouse support.
(reformating and Kconfig fixes by Roman Zippel)

Signed-off-by: Michael Schmitz <sch...@debian.org>
Signed-off-by: Roman Zippel <zip...@linux-m68k.org>
Signed-off-by: Geert Uytterhoeven <ge...@linux-m68k.org>
Signed-off-by: Linus Torvalds <torv...@linux-foundation.org>

drivers/macintosh/Kconfig:112:warning: 'select' used by config symbol 'PMAC_APM_EMU' refer to undefined symbol 'SYS_SUPPORTS_APM_EMULATION'

Which seems to have been introduced by:

commit b302887854d6f0c6f9fc3f1080535e7c1bd53134
Author: Johannes Berg <joha...@sipsolutions.net>
Date: Tue Mar 20 05:18:02 2007 +1100

[POWERPC] apm_emu: Use generic apm-emulation

This patch removes a huge amount of code that is now in common code
in drivers/char/apm-emulation.c

Signed-off-by: Johannes Berg <joha...@sipsolutions.net>
Acked-by: Benjamin Herrenschmidt <be...@kernel.crashing.org>
Signed-off-by: Paul Mackerras <pau...@samba.org>

--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/

Johannes Berg

unread,
May 10, 2007, 11:40:12 AM5/10/07
to
On Thu, 2007-05-10 at 14:10 +0900, Simon Horman wrote:

> drivers/macintosh/Kconfig:112:warning: 'select' used by config symbol 'PMAC_APM_EMU' refer to undefined symbol 'SYS_SUPPORTS_APM_EMULATION'

Argh. Is that with ARCH=ppc? I keep forgetting that it still exists,
sorry.

johannes

signature.asc

Timur Tabi

unread,
May 10, 2007, 1:00:13 PM5/10/07
to
Simon Horman wrote:

>> So my question is: in which Kconfig do I define "UCC_FAST_TEMP" and
>> "UCC_SLOW_TEMP"? At first I thought, just put it in drivers/Kconfig, but that
>> Kconfig does nothing but including other Kconfigs. I believe that if I submit
>> a patch that adds "UCC_FAST_TEMP" and "UCC_SLOW_TEMP" to drivers/Kconfig, it
>> will be rejected. Either that, or I'll spend six weeks trying to persuade
>> everyone that it's a good idea.
>>
>> Does anyone have any suggestions on how I can fix this?
>
> That does seem like a reasonable suggestion, and one that
> would probably work well with the other similar problems
> that have been introduced sice 2.6.21.

Looks like the fix is simpler than I thought. Instead of having

UCC_GETH
select UCC_FAST

I need to do

UCC_FAST
default y if UCC_GETH

I'll have a patch that fixes this out later today.

I chose the first method because I wanted each individual UCC device driver to select
UCC_FAST or UCC_SLOW as appropriate, so that I wouldn't have to update
arch/powerpc/sysdev/qe_lib/Kconfig every time we add a new UCC driver. Oh well.

--
Timur Tabi
Linux Kernel Developer @ Freescale

Simon Horman

unread,
May 10, 2007, 9:30:14 PM5/10/07
to

Actually, it was with ARCH=ia64. I have a feeling that you can get
it to show up quite easily with anything other than ARCH=powerpc.

Simon Horman

unread,
May 10, 2007, 9:30:16 PM5/10/07
to
On Thu, May 10, 2007 at 11:56:48AM -0500, Timur Tabi wrote:
> Simon Horman wrote:
>
> >>So my question is: in which Kconfig do I define "UCC_FAST_TEMP" and
> >>"UCC_SLOW_TEMP"? At first I thought, just put it in drivers/Kconfig, but
> >>that Kconfig does nothing but including other Kconfigs. I believe that if I
> >>submit a patch that adds "UCC_FAST_TEMP" and "UCC_SLOW_TEMP" to
> >>drivers/Kconfig, it will be rejected. Either that, or I'll spend six weeks
> >>trying to persuade everyone that it's a good idea.
> >>
> >>Does anyone have any suggestions on how I can fix this?
> >That does seem like a reasonable suggestion, and one that
> >would probably work well with the other similar problems
> >that have been introduced sice 2.6.21.
>
> Looks like the fix is simpler than I thought. Instead of having
>
> UCC_GETH
> select UCC_FAST
>
> I need to do
>
> UCC_FAST
> default y if UCC_GETH

I pondered something like that, but I couldn't get it quite right :(

> I'll have a patch that fixes this out later today.
>
> I chose the first method because I wanted each individual UCC device
> driver to select UCC_FAST or UCC_SLOW as appropriate, so that I
> wouldn't have to update arch/powerpc/sysdev/qe_lib/Kconfig every time
> we add a new UCC driver. Oh well.

--

-

Kumar Gala

unread,
May 10, 2007, 9:50:06 PM5/10/07
to

Try this patch:

diff --git a/arch/powerpc/sysdev/qe_lib/Kconfig b/arch/powerpc/sysdev/qe_lib/Kconfig
index 887739f..5de7aba 100644
--- a/arch/powerpc/sysdev/qe_lib/Kconfig
+++ b/arch/powerpc/sysdev/qe_lib/Kconfig
@@ -12,6 +12,7 @@ config UCC_SLOW

config UCC_FAST
bool
+ default y if UCC_GETH
default n
select UCC
help
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index fa489b1..b159c6c 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2276,7 +2276,6 @@ config GFAR_NAPI
config UCC_GETH
tristate "Freescale QE Gigabit Ethernet"
depends on QUICC_ENGINE
- select UCC_FAST
help
This driver supports the Gigabit Ethernet mode of the QUICC Engine,
which is available on some Freescale SOCs.

Kumar Gala

unread,
May 10, 2007, 10:00:12 PM5/10/07
to

It really seems like the kconfig shouldn't complain if the depends
isnt satisfied.

- k

Simon Horman

unread,
May 10, 2007, 10:10:07 PM5/10/07
to
On Thu, May 10, 2007 at 08:47:05PM -0500, Kumar Gala wrote:
> Try this patch:

That certainly resolves the problem for me.
I'll see about doing something like that for the similar
Kconfig problems that I see.

-

Kumar Gala

unread,
May 10, 2007, 10:20:09 PM5/10/07
to
On Fri, 11 May 2007, Simon Horman wrote:

> On Thu, May 10, 2007 at 08:47:05PM -0500, Kumar Gala wrote:
> > Try this patch:
>
> That certainly resolves the problem for me.
> I'll see about doing something like that for the similar
> Kconfig problems that I see.
>
> --
> Horms
> H: http://www.vergenet.net/~horms/
> W: http://www.valinux.co.jp/en/
>

I've got a similar fix for SYS_SUPPORTS_APM_EMULATION already. I'll push
both of these to Paul. If you can put something in place for the
Atari/68k and send it to Geert that would be good (feeling a little lazy
right now :)

I'm still not happy about this fix. I'd like to get Sam's feeling on if
we can fixup kconfig not to warn if the dependency isn't meet. I think
the select is valid, and would prefer to fix this properly before we paper
tape over it.

- k

Simon Horman

unread,
May 10, 2007, 10:30:05 PM5/10/07
to
On Thu, May 10, 2007 at 09:13:34PM -0500, Kumar Gala wrote:
> On Fri, 11 May 2007, Simon Horman wrote:
>
> > On Thu, May 10, 2007 at 08:47:05PM -0500, Kumar Gala wrote:
> > > Try this patch:
> >
> > That certainly resolves the problem for me.
> > I'll see about doing something like that for the similar
> > Kconfig problems that I see.
>
> I've got a similar fix for SYS_SUPPORTS_APM_EMULATION already. I'll push
> both of these to Paul. If you can put something in place for the
> Atari/68k and send it to Geert that would be good (feeling a little lazy
> right now :)
>
> I'm still not happy about this fix. I'd like to get Sam's feeling on if
> we can fixup kconfig not to warn if the dependency isn't meet. I think
> the select is valid, and would prefer to fix this properly before we paper
> tape over it.

I agree. I had thought a little about a kconfig fix. Though I'm
wondering if removing the warning will lead to oodles of dangling
symbols and invalid checks over time.

In any case, I'll look into the Atari problem. At least that way
there will be some patches to add to the discussion.

-

Timur Tabi

unread,
May 10, 2007, 10:40:07 PM5/10/07
to
Simon Horman wrote:

> I agree. I had thought a little about a kconfig fix. Though I'm
> wondering if removing the warning will lead to oodles of dangling
> symbols and invalid checks over time.

I'm pretty sure it will. Perhaps we need to have a lint for Kconfig?

Simon Horman

unread,
May 10, 2007, 11:10:06 PM5/10/07
to
On Fri, May 11, 2007 at 11:27:22AM +0900, Simon Horman wrote:
> On Thu, May 10, 2007 at 09:13:34PM -0500, Kumar Gala wrote:
> > On Fri, 11 May 2007, Simon Horman wrote:
> >
> > > On Thu, May 10, 2007 at 08:47:05PM -0500, Kumar Gala wrote:
> > > > Try this patch:
> > >
> > > That certainly resolves the problem for me.
> > > I'll see about doing something like that for the similar
> > > Kconfig problems that I see.
> >
> > I've got a similar fix for SYS_SUPPORTS_APM_EMULATION already. I'll push
> > both of these to Paul. If you can put something in place for the
> > Atari/68k and send it to Geert that would be good (feeling a little lazy
> > right now :)
> >
> > I'm still not happy about this fix. I'd like to get Sam's feeling on if
> > we can fixup kconfig not to warn if the dependency isn't meet. I think
> > the select is valid, and would prefer to fix this properly before we paper
> > tape over it.
>
> I agree. I had thought a little about a kconfig fix. Though I'm
> wondering if removing the warning will lead to oodles of dangling
> symbols and invalid checks over time.
>
> In any case, I'll look into the Atari problem. At least that way
> there will be some patches to add to the discussion.

The fix below seems to work for the ATARI problem.
Do you want me to submit it properly, do you want to
submit it along with the other patches, or do you think
we should sit on things for a bit?

From: Simon Horman <ho...@verge.net.au>
Subject: [PATCH] [IA64] ATARI_KBD_CORE only exists on m68k

ATARI_KBD_CORE doesn't exist on architectures other than m68k,
which causes the following warnings:

drivers/input/keyboard/Kconfig:170:warning: 'select' used by config symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
drivers/input/mouse/Kconfig:181:warning: 'select' used by config symbol 'MOUSE_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'

By reversing the Kconfig logic, the same results should occur on
m68k as the current code, but the warnings go away on other platforms.

Cc: Kumar Gala <ga...@kernel.crashing.org>
Signed-off-by: Simon Horman <ho...@verge.net.au>

---
arch/m68k/Kconfig | 1 +
drivers/input/keyboard/Kconfig | 1 -
drivers/input/mouse/Kconfig | 1 -
3 files changed, 1 insertion(+), 2 deletions(-)

Index: linux-2.6/arch/m68k/Kconfig
===================================================================
--- linux-2.6.orig/arch/m68k/Kconfig 2007-05-11 11:37:25.000000000 +0900
+++ linux-2.6/arch/m68k/Kconfig 2007-05-11 11:42:48.000000000 +0900
@@ -410,6 +410,7 @@ config STRAM_PROC
Say Y here to report ST-RAM usage statistics in /proc/stram.

config ATARI_KBD_CORE
+ default y if KEYBOARD_ATARI || MOUSE_ATARI
bool

config HEARTBEAT
Index: linux-2.6/drivers/input/keyboard/Kconfig
===================================================================
--- linux-2.6.orig/drivers/input/keyboard/Kconfig 2007-05-11 11:37:25.000000000 +0900
+++ linux-2.6/drivers/input/keyboard/Kconfig 2007-05-11 11:42:53.000000000 +0900
@@ -167,7 +167,6 @@ config KEYBOARD_AMIGA
config KEYBOARD_ATARI
tristate "Atari keyboard"
depends on ATARI
- select ATARI_KBD_CORE
help
Say Y here if you are running Linux on any Atari and have a keyboard
attached.
Index: linux-2.6/drivers/input/mouse/Kconfig
===================================================================
--- linux-2.6.orig/drivers/input/mouse/Kconfig 2007-05-11 11:40:32.000000000 +0900
+++ linux-2.6/drivers/input/mouse/Kconfig 2007-05-11 11:42:58.000000000 +0900
@@ -178,7 +178,6 @@ config MOUSE_AMIGA
config MOUSE_ATARI
tristate "Atari mouse"
depends on ATARI
- select ATARI_KBD_CORE
help
Say Y here if you have an Atari and want its native mouse
supported by the kernel.

Russell King

unread,
May 11, 2007, 3:50:08 AM5/11/07
to
On Thu, May 10, 2007 at 08:47:05PM -0500, Kumar Gala wrote:

You might also want to fix the other stupidity with this. See my message
on this very subject ("select is evil: another reason" from May 9th on lkml.)

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:

Johannes Berg

unread,
May 11, 2007, 7:50:08 AM5/11/07
to
On Fri, 2007-05-11 at 10:22 +0900, Simon Horman wrote:

> Actually, it was with ARCH=ia64. I have a feeling that you can get
> it to show up quite easily with anything other than ARCH=powerpc.

Ick, I didn't know that drivers/macintosh was now included for all
arches! Hmm. That's a bit of a problem.

I could do

config PMAC_APM_EMU
tristate "APM emulation"
depends on SYS_SUPPORTS_APM_EMULATION
select APM_EMULATION
depends on ADB_PMU && PM

and then

config SYS_SUPPORTS_APM_EMULATION
bool
default y
depends on PPC_PMAC

I'll have to run test that.

johannes

signature.asc

Timur Tabi

unread,
May 11, 2007, 8:40:07 AM5/11/07
to
Russell King wrote:

> You might also want to fix the other stupidity with this. See my message
> on this very subject ("select is evil: another reason" from May 9th on lkml.)

I submitted a patch yesterday which includes both fixes. Apparently, it's already in the -mm tree.

Simon Horman

unread,
May 13, 2007, 9:40:08 PM5/13/07
to

Hi Johannes,

I don't think that this is quite right, or at least it isn't quite the
same as before. I think that was is below will toggle
SYS_SUPPORTS_APM_EMULATION when PMAC_APM_EMU is selected,
which I think is what you want. Is it also neccessary to
add a dependancy on PPC_PMAC to PMAC_APM_EMU ?

config PMAC_APM_EMU
tristate "APM emulation"

select APM_EMULATION
depends on ADB_PMU && PM

config SYS_SUPPORTS_APM_EMULATION
bool
default y if PMAC_APM_EMU

Johannes Berg

unread,
May 14, 2007, 9:00:14 AM5/14/07
to
Simon,

> I don't think that this is quite right, or at least it isn't quite the
> same as before.

Yeah, I think you're right.

> I think that was is below will toggle
> SYS_SUPPORTS_APM_EMULATION when PMAC_APM_EMU is selected,
> which I think is what you want. Is it also neccessary to
> add a dependancy on PPC_PMAC to PMAC_APM_EMU ?

No, it depends on ADB_PMU which depends on PPC_PMAC.

> config PMAC_APM_EMU
> tristate "APM emulation"
> select APM_EMULATION
> depends on ADB_PMU && PM
>
> config SYS_SUPPORTS_APM_EMULATION
> bool
> default y if PMAC_APM_EMU

I still have to try it, I haven't been yet seen Kumar's fix that he said
he'd done.

johannes

signature.asc

Kumar Gala

unread,
May 14, 2007, 10:30:15 AM5/14/07
to

this was my fix which looks pretty much the same.

- k

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index ccc5410..af70799 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -118,6 +118,7 @@ config GENERIC_BUG
depends on BUG

config SYS_SUPPORTS_APM_EMULATION
+ default y if PMAC_APM_EMU
bool

config DEFAULT_UIMAGE
diff --git a/drivers/macintosh/Kconfig b/drivers/macintosh/Kconfig
index 58926da..f44c94a 100644
--- a/drivers/macintosh/Kconfig
+++ b/drivers/macintosh/Kconfig
@@ -113,7 +113,6 @@ config PMAC_SMU

config PMAC_APM_EMU
tristate "APM emulation"

- select SYS_SUPPORTS_APM_EMULATION


select APM_EMULATION
depends on ADB_PMU && PM

-

Johannes Berg

unread,
May 14, 2007, 12:30:09 PM5/14/07
to
On Mon, 2007-05-14 at 09:24 -0500, Kumar Gala wrote:

> this was my fix which looks pretty much the same.

[...]

Great, thanks.

johannes

signature.asc

Kumar Gala

unread,
May 23, 2007, 8:40:10 AM5/23/07
to

Was my patch ok, if so I'll push it up through my git tree to paul?

- k

Johannes Berg

unread,
May 23, 2007, 10:00:17 AM5/23/07
to
On Wed, 2007-05-23 at 07:37 -0500, Kumar Gala wrote:

> Was my patch ok, if so I'll push it up through my git tree to paul?

Yeah, looks fine to me, or will the ARCH=ppc folks then scream and want
that added to the Kconfig there as well?

johannes

signature.asc

Kumar Gala

unread,
May 23, 2007, 10:20:08 AM5/23/07
to

I can't imagine they will since pmac is only supported in ARCH=powerpc.

Johannes Berg

unread,
May 23, 2007, 10:30:11 AM5/23/07
to
On Wed, 2007-05-23 at 09:14 -0500, Kumar Gala wrote:
> On Wed, 23 May 2007, Johannes Berg wrote:
>
> > On Wed, 2007-05-23 at 07:37 -0500, Kumar Gala wrote:
> >
> > > Was my patch ok, if so I'll push it up through my git tree to paul?
> >
> > Yeah, looks fine to me, or will the ARCH=ppc folks then scream and want
> > that added to the Kconfig there as well?
>
> I can't imagine they will since pmac is only supported in ARCH=powerpc.

Oh right, that was the point of not mentioning
SYS_SUPPORTS_APM_EMULATION any more in the drivers/macintosh/Kconfig

johannes

signature.asc
0 new messages