[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTimuPK8+uV6tZ6GmFx0tp64pAUajrt2dpwOzx_n-@mail.gmail.com>
Date: Thu, 7 Oct 2010 16:33:14 -0500
From: Mario Limonciello <superm1@...ntu.com>
To: Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc: Matthew Garrett <mjg@...hat.com>,
Keng-Yu Lin <keng-yu.lin@...onical.com>, len.brown@...el.com,
alan-jenkins@...fmail.co.uk, platform-driver-x86@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] dell-laptop: Add hwswitch_only module parameter
Hi Dmitry:
On Thu, Oct 7, 2010 at 16:30, Dmitry Torokhov <dmitry.torokhov@...il.com> 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@...hat.com> 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@...il.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists