Comment 12 for bug 1903048

On Tue, Nov 10, 2020 at 03:12:30PM -0000, Sebastien Bacher wrote:
>Thanks for the work but it there any work to upstream those changes? I'm
>not happy to carry a sleep(1) hack in our package unless there is a
>strong reason and we are working on a way to replace it by a better
>solution

The changes come from the Pi Foundation originally (though I've tidied
them up a tiny bit). They're not interested in upstreaming them
themselves, though they expressed no objections to my attempting to do
so when I raised the question.

I realize I'll probably have a bit of a battle on my hands with
something like the patch involving sleep(1), but I would note that the
sleep(1) hack is in the hciattach_bcm43xx module so it is not something
that would be applied to every single Bluetooth module, only to those
compatible with the BCM43xx line.

While 1 second is obviously a suspiciously round number for the delay, I
would further note that it's immediately after a firmware load over the
controlling UART and that that UART can (in certain configurations) be
the Pi's mini-UART which has some (minimal) buffering, but lacks any
hardware flow control. Finally, these patches were also intended to work
on the relatively slow, single core Pi Zero.

Obviously we don't support the Zero, and thus it's possible *we* might
be able to either do away with that sleep, or at least reduce the delay
required, but given this is one-off initialization, and the delay is all
of 1 second, I'm not convinced it's worth investing the time required to
figure out the minimum. Also, I would assume in the interests of
upstreaming the patch, the delay should be as widely applicable as
possible.

Anyway, I'll upstream what I can and we'll have to carry whatever's left
over.