hi, Marcel
On Wed, Jun 2, 2010 at 4:00 AM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote:
> 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@xxxxxxxxxxxx>
>> >> 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@xxxxxxxxxxxx>
>> >>
>> >> 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.
> Regards
>
> Marcel
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
