linux-kernel - Re: [PATCH 15/15] rfkill: document rw rfkill switches and clarify input subsystem interactions (v2)

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, 29 May 2008 18:16:21 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Ivo van Doorn <ivdoorn@...il.com>, linux-kernel@...r.kernel.org,
	Thomas Renninger <trenn@...e.de>
Subject: Re: [PATCH 15/15] rfkill: document rw rfkill switches and clarify
	input subsystem interactions (v2)

On Thu, 29 May 2008, Dmitry Torokhov wrote:
> I wonder why thinkpad_acpi has to go through Len, it seems to live
> in drivers/misc... Does it depend on some other ACPI changes that
> are not in mainline/-mm yet? If it not I'd probably bombard Andrew
> with it.

No, the patches in question don't depend on anything at all other than
thinkpad-acpi itself.  If there were no thinkpad-acpi patches "in
flight" in need to get to mainline soon, there would be no problem at
all... but at least one of them clashes with the SW_RFKILL_ALL patch.

thinkpad-acpi merges through Len Brown because that's probably the best
subsystem for it to be tied to right now.  It uses various other
subsystems, like the input layer, hwmon, LEDs and rfkill, but it makes
extremely heavy use of the ACPI subsystem to actually *do* something.

But patches to thinkpad-acpi do not HAVE to always go through Len, as
they never modify anything in ACPI proper.

> Alternatively SW_RFKILL_ALL can be brought in through wireless three
> or I can add it to my "for_linus" branch that I want Linus to pull
> soon.

I would be thankful if you could merge the input layer SW_RFKILL_ALL
patch ASAP through your for_linus branch, as that's probably the fastest
way to get the whole rfkill stack in its way to the linux-next tree.

The SW_RFKILL_ALL patch is the only real dependency of the rfkill
patches on anything.  If that gets merged now, I can immediately send
the rfkill stack to wireless-dev AND respin the two thinkpad-acpi
patches that are pending on Len's hands to apply without issues on top
of a tree that already had SW_RADIO renamed.

I will send the SW_RFKILL_ALL patch in a version that applies on top of
Linus git tree to you in a few moments.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
--
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/