Hi Orlando, >> So if this just affects two macs, why can't the fix be realized as a >> quirk that is only enabled on those two systems? Or are they impossible >> to detect clearly via DMI data or something like that? > > I think we should be able to quirk based off the acpi _CID "apple-uart-blth" > or _HID "BCM2E7C". Marcel suggested quirking based of the acpi table here > https://lore.kernel.org/linux-bluetooth/1D2217A9-EA73-4D93-8D0B-5BC2718D4788@xxxxxxxxxxxx/ > > This would catch some unaffected Macs, but they don't support the LE Read > Transmit Power command anyway (the affected macs were released after it > was added to the Bluetooth spec, while the unaffected Macs were released > before it was added to the spec, and thus don't support it). > > I'm not sure how to go about applying a quirk based off this, there are > quirks in drivers/bluetooth/hci_bcm.c (no_early_set_baudrate and > drive_rts_on_open), but they don't seem to be based off acpi ids. > > It might be simpler to make it ignore the Unknown Command error, like > in this patch https://lore.kernel.org/linux-bluetooth/CABBYNZLjSfcG_KqTEbL6NOSvHhA5-b1t_S=3FQP4=GwW21kuzg@xxxxxxxxxxxxxx/ > however that only applies on bluetooth-next and needed the status it > checks for to be -56, not 0x01. so we abstain from try-and-error sending of commands. The Bluetooth spec has a list of supported commands that a host can query for a reason. This is really broken behavior of the controller and needs to be pointed out as such. The question is just how we quirk it. Regards Marcel
