Re: [bluetooth] linux-3.x regression (bisected)

[Marcel Holtmann <marcel@holtmann.org>]

Hi Rene,

> > < HCI Command: Read Local Extended Features (0x04|0x0004) plen 1
> >       page 1
> > > HCI Event: Command Complete (0x0e) plen 14
> >       Read Local Extended Features (0x04|0x0004) ncmd 1
> >       status 0x00 page 0 max 0
> >       Features: 0xff 0xfe 0xff 0x7e 0x98 0x19 0x00 0x80
> >
> > And this is correct. Page 0 is the same as local features. Storing this
> > as page 1 is the issue here. We request page 1, but we are getting page
> > 0 instead. So yes, the controller is broken, but not as broken as it
> > gets us false information.
> 
> By the way, while the bluetooth (2.0) spec seems to consist of a 1230 
> page document that I am most certainly not going to study ...
> 
> ... I couldn't help noticing that the HCI_Read_Local_Extended_Features 
> command is in fact specified to return "The highest features page number 
> which contains non-zero bits for the local device", and if I look at the 
> above, it seems to indeed return max=0.
> 
> Is it as such not in fact the case that the dongle is spec-compliant, 
> whereas it's the linux code that neglects to check that return value in 
> order to make sure that it requested a valid page?

the Linux code indeed is broken for not checking the returned page, but
it is broken for different reasons.

However the expected result from the dongle would be an error code and
not just returning page 0 instead.

And the max value just tells you about the max page value. So that the
host does not have to go ahead and read 255 pages before realizing that
there is nothing there.

Regards

Marcel