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: <4A37D0CD-FD4F-445A-87F8-19D65CB7FDB9@hewittfamily.org.uk>
Date: Sun, 20 Apr 2025 11:45:20 +0400
From: Christian Hewitt <christian@...ittfamily.org.uk>
To: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
Cc: linux-amlogic@...ts.infradead.org,
 linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org,
 jbrunet@...libre.com,
 neil.armstrong@...aro.org
Subject: Re: [PATCH 0/5] dts: amlogic: switch to the new PWM controller
 binding

> On 28 Dec 2024, at 1:25 am, Martin Blumenstingl <martin.blumenstingl@...glemail.com> wrote:
> 
> This series switches all Amlogic SoCs to use the new PWM controller
> binding. The main benefits of the new binding are:
> - the pwm controller driver now picks the best possible clock to
>  achieve the most accurate pwm output
> - board.dts don't have to know about the pwm clock inputs anymore (as
>  the driver picks the best one automatically)
> - new SoCs only need a new compatible string but no pwm-meson driver
>  changes, assuming only the clock inputs differ from older IP
>  revisions
> 
> This silences the following warning(s) at boot (for each pwm
> controller instance):
>  using obsolete compatible, please consider updating dt
> 
> I have tested this on two devices:
> - meson8b: odroidc1 (boots fine and cycling through all CPU
>  frequencies and thus voltages works fine)
> - meson-sm1: x96-air-gbit (boots and the rtw8822cs SDIO card is
>  detected, so the 32kHz clock for the SDIO card works)
> 
> Since I cannot test all devices I'm asking for this series to be
> applied so the Kernel CI board farm can help verify it works on all
> boards available there.

This series breaks Broadcom BT on the GXBB/GXM/G12B boards in my
current test rotation. I’m running Linux 6.14.2 with this series
backported for testing. This is generally what’s seen in dmesg:

VIM2:~ # dmesg | grep -i blue
[    8.659535] Bluetooth: Core ver 2.22
[    8.659681] NET: Registered PF_BLUETOOTH protocol family
[    8.659690] Bluetooth: HCI device and connection manager initialized
[    8.659712] Bluetooth: HCI socket layer initialized
[    8.659721] Bluetooth: L2CAP socket layer initialized
[    8.659742] Bluetooth: SCO socket layer initialized
[    8.724898] Bluetooth: HCI UART driver ver 2.3
[    8.724953] Bluetooth: HCI UART protocol H4 registered
[    8.725106] Bluetooth: HCI UART protocol Three-wire (H5) registered
[    8.725434] Bluetooth: HCI UART protocol Broadcom registered
[    8.725502] Bluetooth: HCI UART protocol QCA registered
[    8.725559] Bluetooth: HCI UART protocol AML registered
[    8.966727] Bluetooth: hci0: Frame reassembly failed (-84)
[    8.966772] Bluetooth: hci0: Frame reassembly failed (-84)
[   11.148157] Bluetooth: hci0: command 0xfc18 tx timeout
[   11.148383] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
[   11.148446] Bluetooth: hci0: Failed to set baudrate
[   13.281510] Bluetooth: hci0: command 0xfc18 tx timeout
[   13.281576] Bluetooth: hci0: BCM: Reset failed (-110)

This is also visible on a VIM3 board in kernelci (Linux 6.15.-rc2):

https://dashboard.kernelci.org/test/maestro%3A67fd3cda3328e043e96da230?l=true

[ 3.954267] Bluetooth: hci0: Frame reassembly failed (-84)
[ 4.040555] Bluetooth: hci0: Frame reassembly failed (-84)

(linux-firmware and thus kernelci is lacking Broadcom BT firmwares so
later messages that result from trying to load fw aren’t seen)

With the series reverted:

VIM2:~ # dmesg | grep -i blue
[    8.452570] Bluetooth: Core ver 2.22
[    8.452695] NET: Registered PF_BLUETOOTH protocol family
[    8.452703] Bluetooth: HCI device and connection manager initialized
[    8.452724] Bluetooth: HCI socket layer initialized
[    8.452735] Bluetooth: L2CAP socket layer initialized
[    8.452752] Bluetooth: SCO socket layer initialized
[    8.530077] Bluetooth: HCI UART driver ver 2.3
[    8.530113] Bluetooth: HCI UART protocol H4 registered
[    8.530387] Bluetooth: HCI UART protocol Three-wire (H5) registered
[    8.530902] Bluetooth: HCI UART protocol Broadcom registered
[    8.530983] Bluetooth: HCI UART protocol QCA registered
[    8.531037] Bluetooth: HCI UART protocol AML registered
[    8.917685] Bluetooth: hci0: BCM: chip id 101
[    8.918000] Bluetooth: hci0: BCM: features 0x2f
[    8.919526] Bluetooth: hci0: BCM4354A2
[    8.919560] Bluetooth: hci0: BCM4356A2 (001.003.015) build 0000
[    8.941837] Bluetooth: hci0: BCM4356A2 'brcm/BCM4356A2.hcd' Patch
[    9.831321] Bluetooth: hci0: BCM: features 0x2f
[    9.832884] Bluetooth: hci0: BCM4356 37.4MHz AMPAK AP6356-0055
[    9.832902] Bluetooth: hci0: BCM4356A2 (001.003.015) build 0266
[    9.856044] Bluetooth: MGMT ver 1.23

An SML544TW board (S905D) with a QCA9377 chip is not affected by the
changes so the scope appears to be limited to Broadcom BT.

I’ve also noticed that VIM3 and the SML5442TW have device-tree items
like max-speed, clocks, clock-names defined, but adding these to e.g.
a WeTek Play2 board or removing from VIM3 doesn’t change anything.

Christian


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ