Hi, Marcel
On Wed, Jun 9, 2010 at 4:40 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.
>
> I am not really following your question here. What are you trying to
> achieve?
>
> Regards
>
> Marcel
Thanks for your help.
The rfkill tool give a good example of how to block or unblock to all
rfkill with the same type, and it is better than sysfs since it has
nothing to do with the rfkill number.
http://wireless.kernel.org/en/users/Documentation/rfkill
Thanks
>
>
> --
> 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
>
--
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
