linux-kernel - Re: [PATCH] dell-laptop: Add hwswitch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/