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 14:30:28 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Mario Limonciello <superm1@...ntu.com>,
	Matthew Garrett <mjg@...hat.com>
Cc:	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

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
--
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/