Re: [PATCH] Bluetooth: silence a dmesg error message in hci_request.c

[Gix, Brian]

Hi  Mateusz,

On Thu, 2022-11-17 at 22:27 +0100, Mateusz Jończyk wrote:
> W dniu 17.11.2022 o 21:34, Gix, Brian pisze:
> > On Wed, 2022-11-16 at 21:28 +0100, Mateusz Jończyk wrote:
> > > On kernel 6.1-rcX, I have been getting the following dmesg error
> > > message
> > > on every boot, resume from suspend and rfkill unblock of the
> > > Bluetooth
> > > device:
> > > 
> > >         Bluetooth: hci0: HCI_REQ-0xfcf0
> > > 
> > This has a patch that fixes the usage of the deprecated HCI_REQ
> > mechanism rather than hiding the fact it is being called, as in
> > this
> > case.
> > 
> > I am still waiting for someone to give me a "Tested-By:" tag to
> > patch:
> > 
> > [PATCH 1/1] Bluetooth: Convert MSFT filter HCI cmd to hci_sync
> > 
> > Which will also stop the dmesg error. If you could try that patch,
> > and
> > resend it to the list with a Tested-By tag, it can be applied.
> 
> Hello,
> 
> I did not receive this patch, as I was not on the CC list; I was not
> aware of it. I will test it shortly.
> 
> Any guidelines how I should test this functionality? I have a Sony
> Xperia 10 i4113
> mobile phone with LineageOS 19.1 / Android 12L, which according to
> the spec supports
> Bluetooth 5.0. Quick Google search tells me that I should do things
> like 
> 
>         hcitool lescan
> 

Whatever you were running that produced the

"Bluetooth: hci0: HCI_REQ-0xfcf0"

error in the dmesg log should be sufficient to determine that the error
log is no longer happening. The HCI call is necessary on some
platforms, so the absense of other negative behavior should be
sufficient to verify that the call is still being made.  The code flow
itself has not changed, and new coding enforces the HCI command
sequence, so that it is more deterministric than it was with
hci_request. The hci_request mechanism was an asyncronous request.

> to discover the phone, then use gatttool to list the services, etc.
> 
> Greetings,
> 
> Mateusz
>