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.
On Tue, 8 May 2007 00:04:14 +0300
Ismail D?nmez <[email protected]> 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 <[email protected]>
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 <[email protected]>
Signed-off-by: Kumar Gala <[email protected]>
cc:ing authors, fti.
Kim
Kim Phillips wrote:
> On Tue, 8 May 2007 00:04:14 +0300
> Ismail D?nmez <[email protected]> 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 <[email protected]>
> 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
On Tue, May 08, 2007 at 03:11:52PM -0500, Timur Tabi wrote:
> Kim Phillips wrote:
> >On Tue, 8 May 2007 00:04:14 +0300
> >Ismail D?nmez <[email protected]> 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 <[email protected]>
> >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?
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 <[email protected]>
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 <[email protected]>
Signed-off-by: Roman Zippel <[email protected]>
Signed-off-by: Geert Uytterhoeven <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
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 <[email protected]>
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 <[email protected]>
Acked-by: Benjamin Herrenschmidt <[email protected]>
Signed-off-by: Paul Mackerras <[email protected]>
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
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
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
On Thu, May 10, 2007 at 05:39:29PM +0200, Johannes Berg wrote:
> 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.
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.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
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.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
On Fri, 11 May 2007, Simon Horman wrote:
> 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.
>
> --
> Horms
> H: http://www.vergenet.net/~horms/
> W: http://www.valinux.co.jp/en/
>
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.
On May 10, 2007, at 8:25 PM, Simon Horman wrote:
> 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.
It really seems like the kconfig shouldn't complain if the depends
isnt satisfied.
- k
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/
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
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.
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
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?
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?
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
From: Simon Horman <[email protected]>
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 <[email protected]>
Signed-off-by: Simon Horman <[email protected]>
---
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.
On Thu, May 10, 2007 at 08:47:05PM -0500, Kumar Gala wrote:
> On Fri, 11 May 2007, Simon Horman wrote:
>
> > 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.
> >
> > --
> > Horms
> > H: http://www.vergenet.net/~horms/
> > W: http://www.valinux.co.jp/en/
> >
>
> Try this patch:
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:
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
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.
On Fri, May 11, 2007 at 01:45:37PM +0200, Johannes Berg wrote:
> 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.
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
--
Horms
H: http://www.vergenet.net/~horms/
W: http://www.valinux.co.jp/en/
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
On Mon, 14 May 2007, Johannes Berg wrote:
> 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
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
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
On May 14, 2007, at 11:25 AM, Johannes Berg wrote:
> 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
Was my patch ok, if so I'll push it up through my git tree to paul?
- k
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
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.
- k
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