>-----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-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
