[Cc: +Guenter to get a Chromium person in the loop]
Dear Kiran,
Thank you for your reply.
Am 28.06.24 um 11:37 schrieb K, Kiran:
[…]
Am 27.06.24 um 03:03 schrieb K, Kiran:
-----Original Message-----
From: Paul Menzel <pmenzel@xxxxxxxxxxxxx>
Sent: Wednesday, June 26, 2024 5:56 PM
[…]
Am 26.06.24 um 11:28 schrieb Kiran K:
BRI (Bluetooth Radio Interface) traffic from CNVr to CNVi was found
causing cross talk step errors to WiFi. As a workaround, driver
needs to reduce the drive strength of BRI. During *setup*, driver
reads the drive strength value from efi variable and passes it to
the controller via vendor specific command with opcode 0xfc0a.
I am still surprised this is done via an EFI variable. Could you
please add a reference to section in the UEFI(?) specification?
Hopefully that explains who is supposed to set the variable.
"UefiCnvCommonDSBR" efi variable would be created by OEMs.
Isn’t that approach fundamentally broken? How do the OEMs know, what
variable to set. It needs to be standardized somewhere (name and allowed
values). Also, there are non-UEFI firmwares, like coreboot based, used, for
example, with Google Chromebooks. Lastly, users can manipulate UEFI
variables to my knowledge.
Intel shares the information about the UEFI variables to customers
(via confidential documents). OEMs may modify these variables based
on the platform / re-work / BT NIC etc. Also these variables are
locked in BIOS, so I believe its not possible to modify these values
later.
For non-UEFI firmwares, driver would fetch the data from BIOS from
ACPI table.
Why can’t ACPI tables be used for all? I strongly oppose to add such an
undocumented feature to the Linux kernel. Intel should oppose the
current practice.
Currently we don’t have requirement to support coreboot.
I would submit patches for the same if it comes in future :)
Kind regards,
Paul
