linux-kernel - Re: 2.6.32 -mm merge plans

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]

Message-ID: <a26097d80818626d3fdb4ba668cc115b.squirrel@www.hardeman.nu>
Date:	Wed, 16 Sep 2009 10:33:39 +0200 (CEST)
From:	David Härdeman <david@...deman.nu>
To:	"Andrew Morton" <akpm@...ux-foundation.org>
Cc:	"Dmitry Torokhov" <dmitry.torokhov@...il.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	"Bjorn Helgaas" <bjorn.helgaas@...com>
Subject: Re: 2.6.32 -mm merge plans

On Wed, September 16, 2009 06:14, Andrew Morton wrote:
> On Tue, 15 Sep 2009 20:46:50 -0700 Dmitry Torokhov
> <dmitry.torokhov@...il.com> wrote:
>>>
>>> input-add-a-shutdown-method-to-pnp-drivers.patch
>>
>> This should go through PNP tree (do we have one?).
>
> Not really.  Bjorn heeps an eye on pnp.  Sometimes merges through acpi,
> sometimes through -mm.
>
> I'll merge it I guess, but where is the corresponding change to the
> winbond driver?

I posted the most recent version of my patch, which is based on the pnp
layer rather than the acpi layer and which addresses every single comment
I've gotten so far, to linux-input, linux-kernel, Dmitry and you.

It's archived here (among other places):
http://www.spinics.net/lists/linux-input/msg04396.html

I assumed that Dmitry would be the logical person to push the patch
upstream and he indicated some hesitation if the driver would change its
mode of operation completely in a later revision (if the input subsystem
grows IR capabilities that is), see the relevant parts at the end of:

http://www.spinics.net/lists/linux-input/msg04395.html

I don't think these fears are reason enough to block the driver from
inclusion, if the input subsystem grows additional IR capabilities any and
all IR drivers will have to change accordingly and the IR capabilities
will serve to support additional functionality rather than providing a
drastic change to existing functionality.

-- 
David Härdeman

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