lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YaXmt1WJqRy4pOss@kroah.com>
Date:   Tue, 30 Nov 2021 09:54:15 +0100
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Aditya Garg <gargaditya08@...e.com>
Cc:     Marcel Holtmann <marcel@...tmann.org>,
        Thorsten Leemhuis <regressions@...mhuis.info>,
        Orlando Chamberlain <redecorating@...tonmail.com>,
        Daniel Winkler <danielwinkler@...gle.com>,
        Johan Hedberg <johan.hedberg@...el.com>,
        "linux-bluetooth@...r.kernel.org" <linux-bluetooth@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Luiz Augusto von Dentz <luiz.dentz@...il.com>,
        "regressions@...ts.linux.dev" <regressions@...ts.linux.dev>,
        "sonnysasaka@...omium.org" <sonnysasaka@...omium.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH v6 2/2] btbcm: disable read tx power for affected Macs
 with the T2 Security chip

On Tue, Nov 30, 2021 at 08:45:44AM +0000, Aditya Garg wrote:
> 
> 
> > On 29-Nov-2021, at 7:30 PM, Aditya Garg <gargaditya08@...e.com> wrote:
> > 
> > From: Aditya Garg <gargaditya08@...e.com>
> > 
> > Some Macs with the T2 security chip had Bluetooth not working.
> > To fix it we add DMI based quirks to disable querying of LE Tx power.
> > 
> > Signed-off-by: Aditya Garg <gargaditya08@...e.com>
> > Reported-by: Orlando Chamberlain <redecorating@...tonmail.com>
> > Link:
> > https://lore.kernel.org/r/4970a940-211b-25d6-edab-21a815313954@protonmail.com
> > Fixes: 7c395ea521e6 ("Bluetooth: Query LE tx power on startup")
> > ---
> > drivers/bluetooth/btbcm.c | 40 +++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 40 insertions(+)
> > 
> > diff --git a/drivers/bluetooth/btbcm.c b/drivers/bluetooth/btbcm.c
> > index e4182acee488c5..40f7c9c5cf0a5a 100644
> > --- a/drivers/bluetooth/btbcm.c
> > +++ b/drivers/bluetooth/btbcm.c
> > @@ -8,6 +8,7 @@
> > 
> > #include <linux/module.h>
> > #include <linux/firmware.h>
> > +#include <linux/dmi.h>
> > #include <asm/unaligned.h>
> > 
> > #include <net/bluetooth/bluetooth.h>
> > @@ -343,9 +344,44 @@ static struct sk_buff *btbcm_read_usb_product(struct hci_dev *hdev)
> > 	return skb;
> > }
> > 
> > +static const struct dmi_system_id disable_broken_read_transmit_power[] = {
> > +	{
> > +		 .matches = {
> > +			DMI_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
> > +			DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,1"),
> > +		},
> > +	},
> > +	{
> > +		 .matches = {
> > +			DMI_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
> > +			DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,2"),
> > +		},
> > +	},
> > +	{
> > +		 .matches = {
> > +			DMI_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
> > +			DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro16,4"),
> > +		},
> > +	},
> > +	{
> > +		 .matches = {
> > +			DMI_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
> > +			DMI_MATCH(DMI_PRODUCT_NAME, "iMac20,1"),
> > +		},
> > +	},
> > +	{
> > +		 .matches = {
> > +			DMI_MATCH(DMI_BOARD_VENDOR, "Apple Inc."),
> > +			DMI_MATCH(DMI_PRODUCT_NAME, "iMac20,2"),
> > +		},
> > +	},
> > +	{ }
> > +};
> > +
> > static int btbcm_read_info(struct hci_dev *hdev)
> > {
> > 	struct sk_buff *skb;
> > +	const struct dmi_system_id;
> > 
> > 	/* Read Verbose Config Version Info */
> > 	skb = btbcm_read_verbose_config(hdev);
> > @@ -363,6 +399,10 @@ static int btbcm_read_info(struct hci_dev *hdev)
> > 	bt_dev_info(hdev, "BCM: features 0x%2.2x", skb->data[1]);
> > 	kfree_skb(skb);
> > 
> > +	/* Read DMI and disable broken Read LE Min/Max Tx Power */
> > +	if (dmi_first_match(disable_broken_read_transmit_power))
> > +		set_bit(HCI_QUIRK_BROKEN_READ_TRANSMIT_POWER, &hdev->quirks);
> > +
> > 	return 0;
> > }
> > 
> May I know whether this is fine or not.

Please realize that maintainers have lots and lots of patches to review.
If after 2 weeks of no response, it is fine to resend the patch again.

If you wish to help out with the maintainer's review load, please feel
free to review patches on the relevant mailing list to help lighten that
load such that your patch can be reviewed quicker.

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ