linux-kernel - Re: [PATCH] rfkill: clarify usage of rfkill_force_state() and rfkill->get

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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 18 Sep 2008 19:40:24 +0200
From:	Ivo van Doorn <ivdoorn@...il.com>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	John Linville <linville@...driver.com>,
	linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org,
	Larry Finger <Larry.Finger@...inger.net>
Subject: Re: [PATCH] rfkill: clarify usage of rfkill_force_state() and rfkill->get_state()

On Thursday 18 September 2008, Henrique de Moraes Holschuh wrote:
> On Thu, 18 Sep 2008, Ivo van Doorn wrote:
> > On Thursday 18 September 2008, Henrique de Moraes Holschuh wrote:
> > > rfkill_force_state() is used to update the rfkill core's idea of what is
> > > really happening RIGHT NOW to the transmitter hardware in a PUSH model.
> > > 
> > > rfkill->get_state() does the same, in a PULL model.
> > > 
> > > Neither of them change the real hardware radio state through a call to
> > > rfkill->toggle_radio() or anything of the sort, so they must deal with the
> > > real, current state of the hardware.
> > > 
> > > Change some documentation to make that more clear (I hope).
> > > 
> > > Signed-off-by: Henrique de Moraes Holschuh <hmh@....eng.br>
> > > Cc: Ivo van Doorn <IvDoorn@...il.com>
> > 
> > See my other mail I just send out.
> 
> I did, and just replied to it.
> 
> But only now do I think I realised what you meant:  That even if the driver
> tries to keep set txpower off separate from rfkill, if it uses the hardware
> soft-rfkill bit to implement both, it cannot use that to feed information to
> rfkill_force_state() directly.
> 
> Argh.

Indeed, you need to differentiate between RFKILL and RADIO states.

> > But I don't quite agree on this change of rfkill event interpretation.
> 
> Well, there is no intended change in interpretation, but I don't know how to
> word it in a way that means "the real current hardware state as far as
> rfkill is concerned".

Well my interpretation is that rfkill events and thus rfkill_force_state() calls
should be done for RFKILL state changes only. And RADIO state should be
ignored since they don't matter for rfkill.

> Because suppose it is a driver doing txpower off AND software rfkill using
> the *same* hardware bit (a sigle software rfkill bit).
>
> Now it must do something like this in pseudo-code:
> 
> 	1. if (the bit is disabled (i.e. SW rfkill is NOT ACTIVE)) {
> 		rfkill-SW-status = disabled;
> 	   }  else if (the bit is enabled (i.e. SW rfkill is ACTIVE)) {
> 		if (tx power off is NOT ACTIVE)
> 			rfkill-SW-status = enabled;
> 		else
> 			rfkill-SW-status = whatever the user asked
> 	   }
> 
> THEN, it should use rfkill-sw-status, along with the hw rfkill line status,
> to synthesize the state it must pass to rfkill_force_status().
> 
> ICK.  Of course, if the driver has another way to implement txpower off that
> does not clash with sw rfkill, the above is unneeded.
> 
> How would you put that into words for the rfkill documentation?

The driver is required to keep track of the userspace configuration settings,
when rfkill sends BLOCK to driver it should disable the radio, when rfkill
send UNBLOCK to the driver it should restore to the userspace configuration
settings (which can either be an enabled or disabled radio).

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