<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/bluetooth/hci_bcm.c, branch v6.11</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>Bluetooth: hci_bcm: Limit bcm43455 baudrate to 2000000</title>
<updated>2024-05-14T14:51:05+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2024-04-06T13:51:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=51931c55e02659a8f6ce0edc37f1dcb6540abc03'/>
<id>51931c55e02659a8f6ce0edc37f1dcb6540abc03</id>
<content type='text'>
Like the bcm43430a0 the bcm43455 BT does not support the 0xfc45 command
to set the UART clock to 48 MHz and because of this it does not work
at 4000000 baud.

These chips are found on ACPI/x86 devices where the operating baudrate
does not come from the firmware but is hardcoded at 4000000, which does
not work.

Make the driver_data for the "BCM2EA4" ACPI HID which is used for
the bcm43455 BT point to bcm43430_device_data which limits the baudrate
to 2000000.

Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Like the bcm43430a0 the bcm43455 BT does not support the 0xfc45 command
to set the UART clock to 48 MHz and because of this it does not work
at 4000000 baud.

These chips are found on ACPI/x86 devices where the operating baudrate
does not come from the firmware but is hardcoded at 4000000, which does
not work.

Make the driver_data for the "BCM2EA4" ACPI HID which is used for
the bcm43455 BT point to bcm43430_device_data which limits the baudrate
to 2000000.

Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: hci_bcm: Convert to platform remove callback returning void</title>
<updated>2024-05-14T14:51:03+00:00</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@pengutronix.de</email>
</author>
<published>2024-03-11T21:49:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=536a0ad609d9e424a36aa47a110dc39189aaec78'/>
<id>536a0ad609d9e424a36aa47a110dc39189aaec78</id>
<content type='text'>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The .remove() callback for a platform driver returns an int which makes
many driver authors wrongly assume it's possible to do error handling by
returning an error code. However the value returned is ignored (apart
from emitting a warning) and this typically results in resource leaks.

To improve here there is a quest to make the remove callback return
void. In the first step of this quest all drivers are converted to
.remove_new(), which already returns void. Eventually after all drivers
are converted, .remove_new() will be renamed to .remove().

Trivially convert this driver from always returning zero in the remove
callback to the void returning variant.

Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: hci_bcm: do not mark valid bd_addr as invalid</title>
<updated>2023-06-29T17:52:08+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>johan+linaro@kernel.org</email>
</author>
<published>2023-06-02T08:19:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=56b7f325db139c9255b1eb1d1e741576d5f8fa34'/>
<id>56b7f325db139c9255b1eb1d1e741576d5f8fa34</id>
<content type='text'>
A recent commit restored the original (and still documented) semantics
for the HCI_QUIRK_USE_BDADDR_PROPERTY quirk so that the device address
is considered invalid unless an address is provided by firmware.

This specifically means that this flag must only be set for devices with
invalid addresses, but the Broadcom driver has so far been setting this
flag unconditionally.

Fortunately the driver already checks for invalid addresses during setup
and sets the HCI_QUIRK_INVALID_BDADDR flag. Use this flag to indicate
when the address can be overridden by firmware (long term, this should
probably just always be allowed).

Fixes: 6945795bc81a ("Bluetooth: fix use-bdaddr-property quirk")
Reported-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Link: https://lore.kernel.org/lkml/ecef83c8-497f-4011-607b-a63c24764867@samsung.com
Signed-off-by: Johan Hovold &lt;johan+linaro@kernel.org&gt;
Tested-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
A recent commit restored the original (and still documented) semantics
for the HCI_QUIRK_USE_BDADDR_PROPERTY quirk so that the device address
is considered invalid unless an address is provided by firmware.

This specifically means that this flag must only be set for devices with
invalid addresses, but the Broadcom driver has so far been setting this
flag unconditionally.

Fortunately the driver already checks for invalid addresses during setup
and sets the HCI_QUIRK_INVALID_BDADDR flag. Use this flag to indicate
when the address can be overridden by firmware (long term, this should
probably just always be allowed).

Fixes: 6945795bc81a ("Bluetooth: fix use-bdaddr-property quirk")
Reported-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Link: https://lore.kernel.org/lkml/ecef83c8-497f-4011-607b-a63c24764867@samsung.com
Signed-off-by: Johan Hovold &lt;johan+linaro@kernel.org&gt;
Tested-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: hci_bcm: Add Acer Iconia One 7 B1-750 to the bcm_broken_irq_dmi_table</title>
<updated>2023-04-24T05:01:00+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2023-03-31T21:11:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=09df5a91e620a2d21f7f410938e5e28364fae0bf'/>
<id>09df5a91e620a2d21f7f410938e5e28364fae0bf</id>
<content type='text'>
The DSDT for the Acer Iconia One 7 B1-750 models (which share
the same mainboard) specifies a IOAPIC IRQ for the HCI -&gt; host IRQ but
this is not correct.

Like the Asus TF103C these tablets use pin 17 of the INT33FC:02 GPIO
controller for the IRQ and this pin is _not_ configured in direct IRQ
mode by the firmware.

Add a DMI match for this, re-using the Asus TF103C gpiod_lookup_table,
to fix bluetooth not working on these tablets.

Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The DSDT for the Acer Iconia One 7 B1-750 models (which share
the same mainboard) specifies a IOAPIC IRQ for the HCI -&gt; host IRQ but
this is not correct.

Like the Asus TF103C these tablets use pin 17 of the INT33FC:02 GPIO
controller for the IRQ and this pin is _not_ configured in direct IRQ
mode by the firmware.

Add a DMI match for this, re-using the Asus TF103C gpiod_lookup_table,
to fix bluetooth not working on these tablets.

Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: hci_bcm: Add Lenovo Yoga Tablet 2 830 / 1050 to the bcm_broken_irq_dmi_table</title>
<updated>2023-04-24T05:00:46+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2023-03-31T21:11:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9a09460274d311466b44743c281c81f36c3e4df4'/>
<id>9a09460274d311466b44743c281c81f36c3e4df4</id>
<content type='text'>
The DSDT for the Lenovo Yoga Tablet 2 830 / 1050 models (which share
the same mainboard) specifies a IOAPIC IRQ for the HCI -&gt; host IRQ but
this is not correct.

Like the Asus TF103C these tablets use pin 17 of the INT33FC:02 GPIO
controller for the IRQ and this pin is _not_ configured in direct IRQ
mode by the firmware.

Add a DMI match for this, re-using the Asus TF103C gpiod_lookup_table,
to fix bluetooth not working on these tablets.

Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The DSDT for the Lenovo Yoga Tablet 2 830 / 1050 models (which share
the same mainboard) specifies a IOAPIC IRQ for the HCI -&gt; host IRQ but
this is not correct.

Like the Asus TF103C these tablets use pin 17 of the INT33FC:02 GPIO
controller for the IRQ and this pin is _not_ configured in direct IRQ
mode by the firmware.

Add a DMI match for this, re-using the Asus TF103C gpiod_lookup_table,
to fix bluetooth not working on these tablets.

Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: hci_bcm: Limit bcm43430a0 / bcm43430a1 baudrate to 2000000</title>
<updated>2023-04-24T05:00:32+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2023-03-31T21:11:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ce439473acdf0a3aecbda616a0f92973ab1c2e52'/>
<id>ce439473acdf0a3aecbda616a0f92973ab1c2e52</id>
<content type='text'>
The bcm43430a0 and bcm43430a1 BT does not support the 0xfc45 command
to set the UART clock to 48 MHz and it also does not work at 4000000
baud without this command as some newer models do.

These chips are found on ACPI/x86 devices where the operating baudrate
does not come from the firmware but is hardcoded at 4000000, which does
not work.

Add a max_baudrate value to struct bcm_device_data and set this
to 2000000 on all known ACPI hardware-ids for the bcm43430a0
and the bcm43430a1.

Note this also adds the BCM2E9F ACPI HID which was missing until now.

Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The bcm43430a0 and bcm43430a1 BT does not support the 0xfc45 command
to set the UART clock to 48 MHz and it also does not work at 4000000
baud without this command as some newer models do.

These chips are found on ACPI/x86 devices where the operating baudrate
does not come from the firmware but is hardcoded at 4000000, which does
not work.

Add a max_baudrate value to struct bcm_device_data and set this
to 2000000 on all known ACPI hardware-ids for the bcm43430a0
and the bcm43430a1.

Note this also adds the BCM2E9F ACPI HID which was missing until now.

Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: hci_bcm: Add CYW4373A0 support</title>
<updated>2022-12-12T22:19:24+00:00</updated>
<author>
<name>Marek Vasut</name>
<email>marex@denx.de</email>
</author>
<published>2022-11-02T16:47:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=02d056a3404e20245a69dcb4022a0930085fc5ec'/>
<id>02d056a3404e20245a69dcb4022a0930085fc5ec</id>
<content type='text'>
CYW4373A0 is a Wi-Fi + Bluetooth combo device from Cypress.
This chip is present e.g. on muRata 2AE module.

This chip has additional quirk where the HCI command 0xfc45, used on
older chips to switch UART clock from 24 MHz to 48 MHz, to support
baudrates over 3 Mbdps, is no longer recognized by this newer chip.
This newer chip can configure the 4 Mbdps baudrate without the need
to issue HCI command 0xfc45, so add flag to indicate this and do not
issue the command on this chip to avoid failure to set 4 Mbdps baud
rate.

It is not clear whether there is a way to determine which chip does
and which chip does not support the HCI command 0xfc45, other than
trial and error.

Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
CYW4373A0 is a Wi-Fi + Bluetooth combo device from Cypress.
This chip is present e.g. on muRata 2AE module.

This chip has additional quirk where the HCI command 0xfc45, used on
older chips to switch UART clock from 24 MHz to 48 MHz, to support
baudrates over 3 Mbdps, is no longer recognized by this newer chip.
This newer chip can configure the 4 Mbdps baudrate without the need
to issue HCI command 0xfc45, so add flag to indicate this and do not
issue the command on this chip to avoid failure to set 4 Mbdps baud
rate.

It is not clear whether there is a way to determine which chip does
and which chip does not support the HCI command 0xfc45, other than
trial and error.

Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: hci_bcm: Increase host baudrate for CYW55572 in autobaud mode</title>
<updated>2022-07-22T00:12:22+00:00</updated>
<author>
<name>Hakan Jansson</name>
<email>hakan.jansson@infineon.com</email>
</author>
<published>2022-06-30T12:53:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=46459cb6d4e63066e227a496ae8af35ba8c0b23b'/>
<id>46459cb6d4e63066e227a496ae8af35ba8c0b23b</id>
<content type='text'>
Add device specific data for max baudrate in autobaud mode. This allows the
host to use a baudrate higher than "init speed" when loading FW in autobaud
mode.

The device specific max baudrate in autobaud mode for CYW55572 is set to
921600 bps. Devices without device specific max baudrate in autobaud mode
will use init speed as before. If no device specific init speed has been
specified, it will default to the bcm_proto default 115200 bps.

The increased baud rate improves FW load time. The exact load time will
depend on the specific system and FW being used. As a rough indication,
the FW load time dropped from ~9s @ 115.2kbps to ~1.7s @ 921.6kbps in one
test.

Signed-off-by: Hakan Jansson &lt;hakan.jansson@infineon.com&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add device specific data for max baudrate in autobaud mode. This allows the
host to use a baudrate higher than "init speed" when loading FW in autobaud
mode.

The device specific max baudrate in autobaud mode for CYW55572 is set to
921600 bps. Devices without device specific max baudrate in autobaud mode
will use init speed as before. If no device specific init speed has been
specified, it will default to the bcm_proto default 115200 bps.

The increased baud rate improves FW load time. The exact load time will
depend on the specific system and FW being used. As a rough indication,
the FW load time dropped from ~9s @ 115.2kbps to ~1.7s @ 921.6kbps in one
test.

Signed-off-by: Hakan Jansson &lt;hakan.jansson@infineon.com&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: hci_bcm: Prevent early baudrate setting in autobaud mode</title>
<updated>2022-07-22T00:12:09+00:00</updated>
<author>
<name>Hakan Jansson</name>
<email>hakan.jansson@infineon.com</email>
</author>
<published>2022-06-30T12:45:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9baee415460e602686500d825a86436daa27ac8a'/>
<id>9baee415460e602686500d825a86436daa27ac8a</id>
<content type='text'>
Always prevent trying to set device baudrate before calling setup() when
using autobaud mode.

This was previously happening for devices which had device specific data
with member no_early_set_baudrate set to 0.

Signed-off-by: Hakan Jansson &lt;hakan.jansson@infineon.com&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Always prevent trying to set device baudrate before calling setup() when
using autobaud mode.

This was previously happening for devices which had device specific data
with member no_early_set_baudrate set to 0.

Signed-off-by: Hakan Jansson &lt;hakan.jansson@infineon.com&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Bluetooth: hci_bcm: Add DT compatible for CYW55572</title>
<updated>2022-07-22T00:11:56+00:00</updated>
<author>
<name>Hakan Jansson</name>
<email>hakan.jansson@infineon.com</email>
</author>
<published>2022-06-30T12:45:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f8cad62002a7699fd05a23b558b980b5a77defe0'/>
<id>f8cad62002a7699fd05a23b558b980b5a77defe0</id>
<content type='text'>
CYW55572 is a Wi-Fi + Bluetooth combo device from Infineon.

Signed-off-by: Hakan Jansson &lt;hakan.jansson@infineon.com&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
CYW55572 is a Wi-Fi + Bluetooth combo device from Infineon.

Signed-off-by: Hakan Jansson &lt;hakan.jansson@infineon.com&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Signed-off-by: Luiz Augusto von Dentz &lt;luiz.von.dentz@intel.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
