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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 8 Nov 2019 07:08:53 +0100
From:   Marcel Holtmann <marcel@...tmann.org>
To:     Abhishek Pandit-Subedi <abhishekpandit@...omium.org>
Cc:     Johan Hedberg <johan.hedberg@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        linux-bluetooth@...r.kernel.org, dianders@...omium.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 1/4] Bluetooth: hci_bcm: Disallow set_baudrate for
 BCM4354

Hi Abhishek,

> Without updating the patchram, the BCM4354 does not support a higher
> operating speed. The normal bcm_setup follows the correct order
> (init_speed, patchram and then oper_speed) but the serdev driver will
> set the operating speed before calling the hu->setup function. Thus,
> for the BCM4354, disallow setting the operating speed before patchram.
> 
> Signed-off-by: Abhishek Pandit-Subedi <abhishekpandit@...omium.org>
> ---
> 
> Changes in v2: None
> 
> drivers/bluetooth/hci_bcm.c | 25 +++++++++++++++++++++++--
> 1 file changed, 23 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/bluetooth/hci_bcm.c b/drivers/bluetooth/hci_bcm.c
> index 0f851c0dde7f..2114df607cb3 100644
> --- a/drivers/bluetooth/hci_bcm.c
> +++ b/drivers/bluetooth/hci_bcm.c
> @@ -1167,7 +1167,7 @@ static int bcm_remove(struct platform_device *pdev)
> 	return 0;
> }
> 
> -static const struct hci_uart_proto bcm_proto = {
> +static struct hci_uart_proto bcm_proto = {
> 	.id		= HCI_UART_BCM,
> 	.name		= "Broadcom",
> 	.manufacturer	= 15,
> @@ -1371,6 +1371,24 @@ static struct platform_driver bcm_driver = {
> 	},
> };
> 
> +#define BCM_QUIRK_DISALLOW_SET_BAUDRATE (1 << 0)
> +const u32 disallow_set_baudrate = BCM_QUIRK_DISALLOW_SET_BAUDRATE;
> +
> +static int bcm_check_disallow_set_baudrate(struct serdev_device *serdev)
> +{
> +	const u32 *quirks = device_get_match_data(&serdev->dev);
> +
> +	if (quirks) {
> +		/* BCM4354 can't run at full speed before patchram. Disallow
> +		 * externally setting operating speed.
> +		 */
> +		if (*quirks & BCM_QUIRK_DISALLOW_SET_BAUDRATE)
> +			return 1;
> +	}
> +
> +	return 0;
> +}
> +
> static int bcm_serdev_probe(struct serdev_device *serdev)
> {
> 	struct bcm_device *bcmdev;
> @@ -1408,6 +1426,9 @@ static int bcm_serdev_probe(struct serdev_device *serdev)
> 	if (err)
> 		dev_err(&serdev->dev, "Failed to power down\n");
> 
> +	if (bcm_check_disallow_set_baudrate(serdev))
> +		bcm_proto.set_baudrate = NULL;
> +

this change is not allowed since bcm_proto is on purpose const.

> 	return hci_uart_register_device(&bcmdev->serdev_hu, &bcm_proto);
> }
> 
> @@ -1424,7 +1445,7 @@ static const struct of_device_id bcm_bluetooth_of_match[] = {
> 	{ .compatible = "brcm,bcm4345c5" },
> 	{ .compatible = "brcm,bcm4330-bt" },
> 	{ .compatible = "brcm,bcm43438-bt" },
> -	{ .compatible = "brcm,bcm43540-bt" },
> +	{ .compatible = "brcm,bcm43540-bt", .data = &disallow_set_baudrate },
> 	{ },
> };
> MODULE_DEVICE_TABLE(of, bcm_bluetooth_of_match);

So I would prefer if we do this in a more generic from that will make this easy to extend in the future. Similar to what hci_qca.c does actually with defining a separate struct for the module differences.

struct bcm_device_data (
	bool no_early_oper_speed;
};

static const struct bcm_device_data bcm43540_device {
	.no_early_oper_speed = true,
};

static const struct of_device_id bcm_bluetooth_of_match[] = {
	..
	{ .compatible = "brcm,bcm43540-bt", .data = &bcm43540_device },
	( },
};

And then load the struct in serdev probe as pointer and check its existence and add the struct bcm_device_data to struct bcm_device so it can be referenced when you change the baudrate.

Regards

Marcel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ