Re: [PATCH] rfkill: core: add custom rfkill switch

Re: [PATCH] rfkill: core: add custom rfkill switch

[Pavan Savoy]

--- On Fri, 26/3/10, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Subject: Re: [PATCH] rfkill: core: add custom rfkill switch
> To: "Johannes Berg" <johannes@sipsolutions.net>
> Cc: "Pavan Savoy" <pavan_savoy@yahoo.co.in>
> Date: Friday, 26 March, 2010, 12:28 PM
> On Thu, Mar 25, 2010 at 11:39:10PM
> -0700, Johannes Berg wrote:
> > On Thu, 2010-03-25 at 23:23 -0700, Dmitry Torokhov
> wrote:
> > 
> > > > I do have an actual driver it's just that
> all 3 cores are controlled
> > > > by 1 chip_enable and individual cores are
> powered up down by s/w
> > > > commands.
> > > > 
> > > 
> > > Hmm, so the main portion of the driver needs to
> count the number of
> > > active users across rfkill interfaces 
> before powering down the chip. I
> > > do not quite understand what the issue is
> here...
> > 
> > He also wants to (ab)use rfkill to signal to userspace
> what the value of
> > that counter is ...
> > 
> 
> Well, this one is easy - just say 'No' ;)
> 
> -- 
> Dmitry

Well, Almost, I don't want to signal the user-space about the counter.
Have a look @ http://lkml.org/lkml/2010/3/24/303

See the kernel space (bluetooth driver) would register itself, to my line discipline driver, when someone does a 'hciconfig hci0 up' which is essentially BT-On.

So, now from my ldisc driver (which intends to mux BT/FM and GPS over UART), I need to signal a user-space daemon to open the TTY device, set the baud rate and install the ldisc - So I can make use of it.

To notify that user-space daemon, I had planned to use /dev/rfkill.
However, now with BT application also toggling the rfkill switch by writing to sysfs entry - is causing a bit of confusion to my user-space daemon.

Although I now use hard/soft members of struct rfkill_event now to differentiate the 2 events (1 auto generated, another from BT app) - This patch would make it a bit more proper.




      The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/

Re: [PATCH] rfkill: core: add custom rfkill switch

[Johannes Berg]

On Fri, 2010-03-26 at 21:43 +0530, Pavan Savoy wrote:

> Well, Almost, I don't want to signal the user-space about the counter.
> Have a look @ http://lkml.org/lkml/2010/3/24/303
> 
> See the kernel space (bluetooth driver) would register itself, to my line discipline driver, when someone does a 'hciconfig hci0 up' which is essentially BT-On.
> 
> So, now from my ldisc driver (which intends to mux BT/FM and GPS over UART), I need to signal a user-space daemon to open the TTY device, set the baud rate and install the ldisc - So I can make use of it.
> 
> To notify that user-space daemon, I had planned to use /dev/rfkill.
> However, now with BT application also toggling the rfkill switch by writing to sysfs entry - is causing a bit of confusion to my user-space daemon.
> 
> Although I now use hard/soft members of struct rfkill_event now to differentiate the 2 events (1 auto generated, another from BT app) - This patch would make it a bit more proper.

No. The proper way would be to either have your driver manage the UART
instead of userspace, or have your driver have its own userspace
interface. rfkill has nothing to do with it.

johannes

rfkill switch state during suspend?

[Pavan Savoy]

Hi,

I remember in 2.6.29, the rfkill switch state during suspend was set to SOFT_BLOCKED by calling the toggle_radio of rfkill drivers.

What happens now ? 2.6.32+ ... ?

This previously posed a problems to drivers which mapped their chip enable GPIOs to the rfkill entries, because on suspend, the gpio was pulled low because of the SOFT_BLOCKED state.

A couple of lines regarding same in Documentation/rfkill.txt would be ideal too.

Thanks in advance.
Pavan Savoy.


--- On Fri, 26/3/10, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Subject: Re: [PATCH] rfkill: core: add custom rfkill switch
> To: "Johannes Berg" <johannes@sipsolutions.net>
> Cc: "Pavan Savoy" <pavan_savoy@yahoo.co.in>
> Date: Friday, 26 March, 2010, 12:28 PM
> On Thu, Mar 25, 2010 at 11:39:10PM
> -0700, Johannes Berg wrote:
> > On Thu, 2010-03-25 at 23:23 -0700, Dmitry Torokhov
> wrote:
> > 
> > > > I do have an actual driver it's just that
> all 3 cores are controlled
> > > > by 1 chip_enable and individual cores are
> powered up down by s/w
> > > > commands.
> > > > 
> > > 
> > > Hmm, so the main portion of the driver needs to
> count the number of
> > > active users across rfkill interfaces 
> before powering down the chip. I
> > > do not quite understand what the issue is
> here...
> > 
> > He also wants to (ab)use rfkill to signal to userspace
> what the value of
> > that counter is ...
> > 
> 
> Well, this one is easy - just say 'No' ;)
> 
> -- 
> Dmitry
>