Re: Question of RFKILL for bluetooth, hci_core.c

[Marcel Holtmann <marcel@holtmann.org>]

Hi Zangfei,

> >> > first of all, please use linux-bluetooth mailing list and not the MCC
> >> > one.
> >> >
> >> >> We found you have submitted one patch adding rfkill for bluetoogh.
> >> >>
> >> >> commit 611b30f74b5d8ca036a9923b3bf6e0ee10a21a53
> >> >> Author: Marcel Holtmann <marcel@holtmann.org>
> >> >> Date:   Mon Jun 8 14:41:38 2009 +0200
> >> >>
> >> >>     Bluetooth: Add native RFKILL soft-switch support for all devices
> >> >>
> >> >>     With the re-write of the RFKILL subsystem it is now possible to easily
> >> >>     integrate RFKILL soft-switch support into the Bluetooth subsystem. All
> >> >>     Bluetooth devices will now get automatically RFKILL support.
> >> >>
> >> >>     Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> >> >>
> >> >> Question 1,
> >> >> Once hci_register_dev is called, the rfkill_alloc is called, the
> >> >> result is the rfkill number is increased one by one,  the application
> >> >> may not know which rfkill it is.
> >> >> For example, insmod bt.ko -> rfkill0, rmmod bt; insmod bt.ko->
> >> >> rfkill1, ~~ rfkill2, 3
> >> >> Same effect would happen when echo 0 > /sys/class/rfkill/rfkill0/state.
> >> >>
> >> >> The reason is rfkill_register would increase rfkill->idx.
> >> >> int __must_check rfkill_register(struct rfkill *rfkill)
> >> >> {
> >> >>         static unsigned long rfkill_no;
> >> >> ~~~
> >> >>         rfkill->idx = rfkill_no;
> >> >>         dev_set_name(dev, "rfkill%lu", rfkill_no);
> >> >>         rfkill_no++;
> >> >>
> >> >> ~~~
> >> >> }
> >> >>
> >> >> Quesiton 2.
> >> >> In fact, we have own rfkill to control power on and off, then
> >> >> currently both our own rfkill and bluetooth rfkill need to be enabled.
> >> >>
> >> >> I am not sure what's the purpose of the rfkill adding in
> >> >> hci_register_dev, just wander could we add one default state as
> >> >> enabled for such rfkill. Then we could ignore this rfkill, no matter
> >> >> the number is increased one by one.
> >> >
> >> > And second it is clearly the soft RFKILL switch. As usual a device can
> >> > also have a hard kill switch.
> >> >
> >> > The index numbers are irrelevant. If the RFKILL switch is assigned to a
> >> > device is will be a child of its parent, so it is easy to figure out
> >> > where it belong. In case of platform switches it is impossible anyway
> >> > and hence we have implemented CHANGE_ALL support.
> >> >
> >>
> >> Thanks for your explanation, however how to get hard kill switch.
> >> Ususally we enable wifi via "echo 1 > sys/class/rfkill/rfkill0/state",
> >> and enable bt via "echo 1 > sys/class/rfkill/rfkill1/state".
> >> This method highly depends on the indelx number.
> >
> > just use the rfkill utility. Using the sysfs is a bad idea.
> >
> >> Could you kindly share me how to set hard kill switch, which may
> >> irrelevant with the index number.
> >
> > You can not set hard states from software. They are meant for physical
> > RFKILL switches.
> >
> 
> For how to use rfkill utility?
> Do you mean rfkill tool.
> 
> $rfkill block bluetooth
> to stop Bluetooth and
> 
> $rfkill unblock bluetooth
> to resume Bluetooth.
> 
> If not, is there any example?
> I looking for example in kernel, and find many driver use rfkill_alloc
> just one time, for example in probe or _init, then the rfkill number
> would be keep same.

I am not really following your question here. What are you trying to
achieve?

Regards

Marcel