RE: problem: Re: [PATCH] input: fixup X86_MRST selects

From: Pan, Jacob jun
Date: Mon Jun 28 2010 - 17:12:12 EST

>-----Original Message-----
>From: Randy Dunlap [mailto:randy.dunlap@xxxxxxxxxx]
>Sent: Monday, June 28, 2010 1:24 PM
>To: Dmitry Torokhov
>Cc: Stephen Rothwell; Pan, Jacob jun; linux-next@xxxxxxxxxxxxxxx; LKML;
>linux-input@xxxxxxxxxxxxxxx; akpm; chuck.lever@xxxxxxxxxx
>Subject: Re: problem: Re: [PATCH] input: fixup X86_MRST selects
>On 06/28/10 13:18, Dmitry Torokhov wrote:
>> On Monday, June 28, 2010 12:03:44 pm Randy Dunlap wrote:
>>> On 06/10/10 12:04, Dmitry Torokhov wrote:
>>>> On Wednesday, June 09, 2010 03:42:08 pm Randy Dunlap wrote:
>>>>> On 06/09/10 15:40, Dmitry Torokhov wrote:
>>>>>> On Wednesday, June 09, 2010 03:29:21 pm Randy Dunlap wrote:
>>>>>>> +++ linux-next-20100609/drivers/input/keyboard/Kconfig
>>>>>>> @@ -70,9 +70,10 @@ config KEYBOARD_ATARI
>>>>>>> config KEYBOARD_ATKBD
>>>>>>> tristate "AT keyboard" if EMBEDDED || !X86
>>>>>>> + depends on !X86 || (X86 && !X86_MRST)
>>>>>> Should it be simply 'depends on !X86_MRST' and then we could kill
>>>>>> '!X86_MRST' conditionals in selects?
>>>>> Duh, that sounds good, yes.
>>>> Actually, I do not think this is a correct approach. While
>>>> does not have i8042 theoretically it is possible to add AT-style
>>>> keyboard by other means (however unlikely it is) so we should not be
>>>> disabling it.
>>>> We should, however, disallow i8042 from being selected. Could you
>>>> tell me if the patch below works for you?
>>> Dmitry,
>>> This patch (in current mainline git) causes a problem when X86_MRST
>>> enabled. CONFIG_SERIO_I8042 is no longer enabled when X86_MRST is
>>> and X86_MRST could be enabled when someone is trying to build a
>>> kernel.
>> Randy,
>> Looking at arch/x86/kernel/mrst.c I am not sure if generic kernel will
>> work well witbh X86_MRST set. However if we supposed to support
>> on generic images then, instead of playing with Kconfig, we need to
>> i8042_platform_init() to abort on Moorestown.
>OK. Until something else is done, you might want to revert this patch
>and just live with the build errors (that caused me to send the original
We do intend to maintain binary compatibility between generic kernel and Moorestown.
I guess the challenge is not having enumeration of i8042 pass to the driver. Do you
prefer abort i8042_platform_init() based on #define CONFIG_X86_MRST? It is no safe
to probe HW on Moorestown, unfortunately.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at