rfkill: core: add custom rfkill switch
in [Kernel]
|
Prev: sched: Remove remaining USER_SCHED code
Next: [PATCH] free_early_partial() should permit start == end
From: Pavan Savoy on 26 Mar 2010 12:20 --- On Fri, 26/3/10, Dmitry Torokhov <dmitry.torokhov(a)gmail.com> wrote: > From: Dmitry Torokhov <dmitry.torokhov(a)gmail.com> > Subject: Re: [PATCH] rfkill: core: add custom rfkill switch > To: "Johannes Berg" <johannes(a)sipsolutions.net> > Cc: "Pavan Savoy" <pavan_savoy(a)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/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Johannes Berg on 26 Mar 2010 13:20
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |