Question of RFKILL for bluetooth, hci_core.c

Question of RFKILL for bluetooth, hci_core.c

[zhangfei gao]

Hi, Marcel

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.

Thanks
Zhangfei

Re: Question of RFKILL for bluetooth, hci_core.c

[Marcel Holtmann]

Hi Zhangfei,

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.

Regards

Marcel

Re: Question of RFKILL for bluetooth, hci_core.c

[zhangfei gao]

Hi, Marcel



On Sat, May 29, 2010 at 6:57 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Zhangfei,
>
> 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.

Could you kindly share me how to set hard kill switch, which may
irrelevant with the index number.

> Regards
>
> Marcel
>
>
>

Re: Question of RFKILL for bluetooth, hci_core.c

[Marcel Holtmann]

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.

Regards

Marcel

Re: Question of RFKILL for bluetooth, hci_core.c

[zhangfei gao]

hi, Marcel



On Wed, Jun 2, 2010 at 4:00 AM, Marcel Holtmann <marcel@holtmann.org> 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@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.

> Regards
>
> Marcel
>
>
>

Re: Question of RFKILL for bluetooth, hci_core.c

[Marcel Holtmann]

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

Re: Question of RFKILL for bluetooth, hci_core.c

[zhangfei gao]

Hi, Marcel

On Wed, Jun 9, 2010 at 4:40 AM, Marcel Holtmann <marcel@holtmann.org> 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@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


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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>