why scan_disable during hciops_power_off

why scan_disable during hciops_power_off

[Pavan Savoy]

when hciops gets a set_powered with powered=0, then hciops_power_off is called.
However in here we write the SCAN_ENABLE (=0) to the device and then
do the HCIDEVDOWN...

so couple of questions,
1. are there controllers there which even after doing hci0 down,
allows other devices to be scanned?
for those what do hci0 down mean ? radio not switched off ?

2. what happens to the response? in case hci0 down is considered as
say close of UART?
There is a case I have a combo chip, and I need to keep UART opened,
because someone else is using the UART, and then
I do this power_off, the hci0 interface is down, and bluetooth just
dumps down the scan_disable and quits, but the response
which comes from the device has no takers....

so shouldn't hciops use a hci_send_req before HCIDEVDOWN ?

regards,
Pavan

Re: why scan_disable during hciops_power_off

[Luiz Augusto von Dentz]

Hi,

On Tue, Jan 25, 2011 at 3:12 PM, Pavan Savoy <pavan_savoy@sify.com> wrote:
> when hciops gets a set_powered with powered=0, then hciops_power_off is called.
> However in here we write the SCAN_ENABLE (=0) to the device and then
> do the HCIDEVDOWN...
>
> so couple of questions,
> 1. are there controllers there which even after doing hci0 down,
> allows other devices to be scanned?
> for those what do hci0 down mean ? radio not switched off ?

Good point, perhaps this is driver dependent, so we do it just be safe guard.

> 2. what happens to the response? in case hci0 down is considered as
> say close of UART?
> There is a case I have a combo chip, and I need to keep UART opened,
> because someone else is using the UART, and then
> I do this power_off, the hci0 interface is down, and bluetooth just
> dumps down the scan_disable and quits, but the response
> which comes from the device has no takers....
>
> so shouldn't hciops use a hci_send_req before HCIDEVDOWN ?

It should and Im almost sure we do send it before, if we do sent it
latter than it is probably a bug.


-- 
Luiz Augusto von Dentz
Computer Engineer

Re: why scan_disable during hciops_power_off

[Pavan Savoy]

On Tue, Jan 25, 2011 at 8:57 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi,
>
> On Tue, Jan 25, 2011 at 3:12 PM, Pavan Savoy <pavan_savoy@sify.com> wrote:
>> when hciops gets a set_powered with powered=0, then hciops_power_off is called.
>> However in here we write the SCAN_ENABLE (=0) to the device and then
>> do the HCIDEVDOWN...
>>
>> so couple of questions,
>> 1. are there controllers there which even after doing hci0 down,
>> allows other devices to be scanned?
>> for those what do hci0 down mean ? radio not switched off ?
>
> Good point, perhaps this is driver dependent, so we do it just be safe guard.

I hope all devices and drivers out there consider the hci0 down as the
radio OFF,
I don't think there is a reason for it to be otherwise....
so why the safe-guard ?

>> 2. what happens to the response? in case hci0 down is considered as
>> say close of UART?
>> There is a case I have a combo chip, and I need to keep UART opened,
>> because someone else is using the UART, and then
>> I do this power_off, the hci0 interface is down, and bluetooth just
>> dumps down the scan_disable and quits, but the response
>> which comes from the device has no takers....
>>
>> so shouldn't hciops use a hci_send_req before HCIDEVDOWN ?
>
> It should and Im almost sure we do send it before, if we do sent it
> latter than it is probably a bug.

we do send it before, but don't really care about the response.
I was mentioning here use of hci_send_req instead of hci_send_cmd
before HCIDEVDOWN, so
that the function waits for response and finishes up work before the DEVDOWN....

>
> --
> Luiz Augusto von Dentz
> Computer Engineer
>

Re: why scan_disable during hciops_power_off

[Johan Hedberg]

Hi,

On Tue, Jan 25, 2011, Pavan Savoy wrote:
> >> 1. are there controllers there which even after doing hci0 down,
> >> allows other devices to be scanned?
> >> for those what do hci0 down mean ? radio not switched off ?
> >
> > Good point, perhaps this is driver dependent, so we do it just be safe guard.
> 
> I hope all devices and drivers out there consider the hci0 down as the
> radio OFF,
> I don't think there is a reason for it to be otherwise....
> so why the safe-guard ?

IIRC Marcel added this due to paranoia with the non-connectable GAP test
case with the BITE tester. The test kept failing even though the device
was in DOWN state.

Johan

Re: why scan_disable during hciops_power_off

[Marcel Holtmann]

Hi Johan,

> > >> 1. are there controllers there which even after doing hci0 down,
> > >> allows other devices to be scanned?
> > >> for those what do hci0 down mean ? radio not switched off ?
> > >
> > > Good point, perhaps this is driver dependent, so we do it just be safe guard.
> > 
> > I hope all devices and drivers out there consider the hci0 down as the
> > radio OFF,
> > I don't think there is a reason for it to be otherwise....
> > so why the safe-guard ?
> 
> IIRC Marcel added this due to paranoia with the non-connectable GAP test
> case with the BITE tester. The test kept failing even though the device
> was in DOWN state.

we also had the case where we considered non-connectable as off when the
HCI devdown was not working properly. However this is a long time ago
and has been fixed properly. So we might can remove this now.

Regards

Marcel

Re: why scan_disable during hciops_power_off

[Pavan Savoy]

On Tue, Jan 25, 2011 at 9:41 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Johan,
>
>> > >> 1. are there controllers there which even after doing hci0 down,
>> > >> allows other devices to be scanned?
>> > >> for those what do hci0 down mean ? radio not switched off ?
>> > >
>> > > Good point, perhaps this is driver dependent, so we do it just be safe guard.
>> >
>> > I hope all devices and drivers out there consider the hci0 down as the
>> > radio OFF,
>> > I don't think there is a reason for it to be otherwise....
>> > so why the safe-guard ?
>>
>> IIRC Marcel added this due to paranoia with the non-connectable GAP test
>> case with the BITE tester. The test kept failing even though the device
>> was in DOWN state.
>
> we also had the case where we considered non-connectable as off when the
> HCI devdown was not working properly. However this is a long time ago
> and has been fixed properly. So we might can remove this now.

Oo...
I want to send the patch, I want to send the patch ..
Can I please .....


> Regards
>
> Marcel
>
>
>

Re: why scan_disable during hciops_power_off

[Pavan Savoy]

On Tue, Jan 25, 2011 at 9:47 PM, Pavan Savoy <pavan_savoy@sify.com> wrote:
> On Tue, Jan 25, 2011 at 9:41 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
>> Hi Johan,
>>
>>> > >> 1. are there controllers there which even after doing hci0 down,
>>> > >> allows other devices to be scanned?
>>> > >> for those what do hci0 down mean ? radio not switched off ?
>>> > >
>>> > > Good point, perhaps this is driver dependent, so we do it just be safe guard.
>>> >
>>> > I hope all devices and drivers out there consider the hci0 down as the
>>> > radio OFF,
>>> > I don't think there is a reason for it to be otherwise....
>>> > so why the safe-guard ?
>>>
>>> IIRC Marcel added this due to paranoia with the non-connectable GAP test
>>> case with the BITE tester. The test kept failing even though the device
>>> was in DOWN state.
>>
>> we also had the case where we considered non-connectable as off when the
>> HCI devdown was not working properly. However this is a long time ago
>> and has been fixed properly. So we might can remove this now.
>
> Oo...
> I want to send the patch, I want to send the patch ..
> Can I please .....

i've posted the patch..

>
>> Regards
>>
>> Marcel
>>
>>
>>
>