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

[Pan, Jacob jun]

>-----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
>Moorestown
>>>> 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
>please
>>>> tell me if the patch below works for you?
>>>
>>> Dmitry,
>>>
>>> This patch (in current mainline git) causes a problem when X86_MRST
>is
>>> enabled. CONFIG_SERIO_I8042 is no longer enabled when X86_MRST is
>enabled,
>>> and X86_MRST could be enabled when someone is trying to build a
>generic
>>> 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
>Moorestown
>> on generic images then, instead of playing with Kconfig, we need to
>adjust
>> 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
>patch).
>
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  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/