linux-kernel - Re: [ath5k-devel] [PATCH] ath5k: added initial RFKILL support

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] [day] [month] [year] [list]

Message-ID: <9b2b86520905300826q3eeab9cdjf575d98c7aca9ad2@mail.gmail.com>
Date:	Sat, 30 May 2009 16:26:13 +0100
From:	Alan Jenkins <sourcejedi.lkml@...glemail.com>
To:	Johannes Berg <johannes@...solutions.net>
Cc:	Tobias Doerffel <tobias.doerffel@...il.com>,
	Jiri Slaby <jirislaby@...il.com>, ath5k-devel@...ts.ath5k.org,
	linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [ath5k-devel] [PATCH] ath5k: added initial RFKILL support

On 5/30/09, Johannes Berg <johannes@...solutions.net> wrote:
> On Sat, 2009-05-30 at 00:33 +0200, Tobias Doerffel wrote:
>
>> > Could you try to work against v11
>> > of my rfkill patch, or better even against the cfg80211 rfkill instead?
>> I didn't look at both of them yet. However I think we first should try to
>> get
>> current rfkill support into mainline as fast as possible. Improvements and
>>
>> adaptations to reworked rfkill framework can follow.
>
> No other comments from me -- but since the v11 of the rfkill rewrite
> will certainly hit the tree before your patch (it's almost in) you
> _will_ have to work against it. I'll also try to make the cfg80211
> rfkill hit the tree very soon for reasons I'll explain elsewhere -- you
> would be better off working against that because then your rfkill code
> is very very very simple and doesn't need to do much at all.
>
> johannes

Btw, I believe the new rfkill core behaviour should avoid the concern
I raised about the EeePC.

Reminder: the eeepc-laptop implements platform rfkill on the original
model(s) by hotplugging the entire ath5k device.  If you boot with it
in the blocked state, the old rfkill core would "lock in" that state
as the default.  If you then hotplug the ath5k device _and it comes up
with an rfkill device of it's own_, my concern is that the new rfkill
device would be initialized to a blocked state.  It would be
impossible to enable the wireless.

The new core removes this idea of a separate "default" state, so it
can't have this problem.

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