bluetooth: hci: spi: 0xFF is a valid payload length

[JordanYates]

A payload size of 0xFF is valid and should not be a reason to keep looping for more headers. The complete reqiurement is now:

header_slave[STATUS_HEADER_READY] == READY_NOW &&
header_slave[STATUS_HEADER_TOREAD] > 0

This fixes events being dropped when the payload size is 255.

[Thalley]

@JordanYates did you figure out why there was a check for 0xff?

I'm wondering if it is related to this

(void)memset(&txmsg, 0xFF, SPI_MAX_MSG_LEN);

[JordanYates]

@JordanYates did you figure out why there was a check for 0xff?

I'm wondering if it is related to this

(void)memset(&txmsg, 0xFF, SPI_MAX_MSG_LEN);

It's been there since the driver was added 7 years ago, so I'll take my best guess.

The purpose of the check if to validate that the controller is ready to send the payload, and if not, check again.
If the controller is not ready, the line state, and hence the received data, will be 0x00 or 0xFF, depending on the controller SPI slave implementation.
The original condition did not include header_slave[STATUS_HEADER_READY] == READY_NOW.
The original check was probably trying to check against the idle line state, but missed the simplest solution of checking header_slave[STATUS_HEADER_READY] == READY_NOW.