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. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to bluez in Ubuntu. https://bugs.launchpad.net/bugs/1903048 Title: [SRU] Bluetooth won't activate on the pi 400 Status in bluez package in Ubuntu: Fix Released Status in bluez source package in Hirsute: Fix Released Bug description: [Impact] Without these patches, Bluetooth is inoperable on the recently released Raspberry Pi 400. [Test Case] * Boot the Ubuntu Desktop for Pi image on a Pi 400. * Start the Settings application and switch to the Bluetooth tab * Verify that Bluetooth is not enabled and attempting to activate it fails * sudo add-apt-repository ppa:waveform/pi-bluetooth * sudo apt update * sudo apt install bluez * sudo reboot * Start the Settings application and switch to the Bluetooth tab * Verify that Bluetooth is active and that Bluetooth devices (e.g. mice, mobile phones, headphones, etc.) can connect and operate correctly [Regression Potential] Extremely low (on groovy in particular, this has the same version of bluez as hirsute). The only significant risk is to non-Pi platforms or dongles which also use the Broadcom 43xx (or Cypress 305) chips for Bluetooth which might be inadvertently affected by these patches. [Original Description] The new Pi 400 has a slightly different Wifi/BT chip to the Pi4. Whilst wifi works happily, Bluetooth fails to operate. This doesn't appear to be an issue with either the firmware (the latest versions from upstream Raspbian have been tried), or the kernel (a known-good raspi kernel has been tested under Ubuntu), but with Bluez itself. Specifically, tracing the initialization with btmon on Raspbian and Ubuntu, the stack consistently fails when attempting to "Set Default PHY" on the latter. Curiously, under Ubuntu the adapter also appears to lack a MAC address. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1903048/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp