Hi Paul, >Subject: Re: [PATCH v3] Bluetooth: btintel: Allow lowering of drive strength of >BRI > >Dear Kiran, > > >Thank you for your reply. > >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. Currently we don’t have requirement to support core boot. I would submit patches for the same if it comes in future :) > > >Kind regards, > >Paul Thanks, Kiran
