Hi Dmitry: On Thu, Oct 7, 2010 at 16:30, Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx> wrote: > On Thu, Oct 07, 2010 at 03:53:37PM -0500, Mario Limonciello wrote: >> Hi Matthew: >> >> On Thu, Oct 7, 2010 at 15:50, Matthew Garrett <mjg@xxxxxxxxxx> wrote: >> > On Thu, Oct 07, 2010 at 03:49:05PM -0500, Mario Limonciello wrote: >> >> Hi Matthew: >> >> > Is the kernel able to unblock it under those circumstances? >> >> >> >> Manually running rfkill unblock will unblock it in this broken >> >> firmware scenario in question. >> > >> > So the issue is in the firmware's response to the keystroke? Ok. I'd >> > rather have a DMI list of the broken machines than a module parameter. >> >> Yes the issue is the firmware's response to the keystroke. The >> intention here is to individual submit machines in future patches as >> they're discovered. The parameter's primary purpose is to assist in >> building the list. If someone reports a bug with these symptoms, they >> can add the parameter to their kernel command line, and report if it >> helps them. If it helps, their machine can be added to the DMI table. >> > > Mario, Matthew, > > Since the fix is not essential for boot purposes can we keep module > parameter only (without adding DMI entries) and push the task of > properly setting the module parmeter to udev? > > We have this strategy for bunch of input stuff (force release, keymap) > and I think it works better than dding more and more DMI quirks into > kernel itself. > > Thanks. > > -- > Dmitry > I think this is a fair alternative. A majority of the machines will work properly as is - no parameter, and the few in between that don't can have entries added to udev then. It's even easier for users to diagnose and submit feedback when they're modifying a udev conffile. -- Mario Limonciello superm1@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
