Created attachment 5814 [details]
dmesg when booting with atkbd built in

Created attachment 5815 [details]
dmesg when booting with atkbd as module

Created attachment 5816 [details]
diff dmesg-atkbd-built-in.txt dmesg-atkbd-as-module.txt

Created attachment 5817 [details]
.config used for 2.6.13-rc6 compilation (of course atkbd changes)

I don't think that the following config is allowed:

#
# Hardware I/O ports
#
CONFIG_SERIO=m
CONFIG_SERIO_I8042=y

Did you edit your .config by hand?

Unfortunately, his .config is allowed by the rules in the Kconfig file.

I'll attach a patch for this bug.

I think I see where the problem is, but the fix I had in mind doesn't work due
to the following that looks like a kconfig bug:


config FOO
        tristate
        default m

config BAR
        tristate
        default y
        depends on FOO


CONFIG_FOO=m
CONFIG_BAR=y

And a second kconfig bug involved in this issue:

config FOO
        tristate
        default m
        select BAR

config BAR
        tristate
        default y


CONFIG_FOO=m
CONFIG_BAR=m


A select mustn't _lower_ the value of the select'ed variable.

kconfig issues aside I still don't quite understand how the kernel could 
possibly link if serio is a module and i8042 which uses serio interface is 
built in. 

The kernel could link because i8042 was built as if it was included statically,
but it was not linked into the kernel.

drivers/Makefile contains:
  obj-$(CONFIG_SERIO)             += input/serio/

With CONFIG_SERIO=m and CONFIG_SERIO_I8042=y, the build system doesn't go into
input/serio/ when linking the kernel.

Looking deeper into this issue, it seems the two kconfig problems I've described
are the complete problem, and the SERIO* dependencies seem to be correct.

I use "make menuconfig" and "make oldconfig" sequences only, no direct editing
of ".config" was done.

I can't seem to directly change the SERIO and SERIO_I8042 settings.  These are
determined by my other choices.

If you want me to try something (such as recompiling and booting with other
settings), feel free to ask.

@Erik:
That's not required.
The two kconfig issues I've described should cover the problems leading to your
problem.

The first example is not a bug, the dependency simply enables the default and
the symbol will have the value of the default. Change it into this to get the
intended result:

config BAR
        tristate
        default FOO

I have to look closer into the second example, you get into unspecified area
here, but it sort of makes sense. :)

The real world example resulting in this bug is:

<--  snip  -->

if SERIO

config SERIO_I8042
        tristate "i8042 PC Keyboard controller" if EMBEDDED || !X86
        default y
        depends on !PARISC && (!ARM || ARCH_SHARK || FOOTBRIDGE_HOST) && !M68K
...

<--  snip  -->

If me must in this case duplicate all dependencies (including SERIO) in the
default line, this will be very error-prone (your proposed alternative solution
doesn't work in the case when the question is user-visible).

My first example works as I'd intuitively expect it if the question is
user-visible, but it doesn't work if it isn't user-visible.
That is _very_ confusing, especially here where the question might or might not
be user-visible.

Documentation/kbuild/kconfig-language.txt says:
"normal dependencies reduce the upper limit of a symbol"

Could kconfig please follow this specification in all cases (with the exception
of select's)?

Let me try to make it clearer:

If I modify my first example making BAR user-visible:

config FOO
        tristate
        default m

config BAR
        tristate "bar"
        default y
        depends on FOO

"make oldconfig" asks me:
  bar (BAR) [M/n] (NEW)

This is exactly the semantics I'd expect:
- maximum "m"
- default "m"

Why is the semantics different if the variable is not user-visible?

It does follow the spec, you missed the "(see below)" part.
Dependencies define the visibility of a default or prompt and the input range,
they don't have any influence on the value of a default. This is a design
decision I'm not going to discuss in this context.

In this case you don't need to duplicate the complete dependencies, you only
need to change it to SERIO.

That the duplication of dependencies except for SERIO is not required in this
case is only true because we are in the special case where all other symbols are
booleans.

You said in your last comment "dependencies [...] don't have any influence on
the value of a default". This is not true in your current implementation. If you
look at my example from Comment 16, dependencies _do_ change the default value
if a question is user-visible.

From a user's point of view, dependencies have a different semantics depending
on whether a variable is user-visible or not. That's bad. And even worse in
cases where a variable might or might not be user-visible like in the
SERIO_I8042 case.

Yes, we can always workaround this kconfig "feature". But this problem will bite
us again and again and I don't see the big gain from your design decision.

It looks like you guys found a solution, in the recent git tree dependencies look right.
Is that correct? The bug can be closed then.
Thanks.

Closing the bug, works as designed.
If there are still concerns about configuration issues please reopen.