linux-kernel - Re: [PATCH 0/5] dts: amlogic: switch to the new PWM controller binding

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] [day] [month] [year] [list]
Message-ID: <CAFBinCC7HrT_fD0zYudtj10SNiajwq-OSC7ceeoNrz2neChptg@mail.gmail.com>
Date: Sun, 20 Apr 2025 18:53:04 +0200
From: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To: Christian Hewitt <christian@...ittfamily.org.uk>
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 Sun, Apr 20, 2025 at 9:45 AM Christian Hewitt
<christian@...ittfamily.org.uk> wrote:
>
> > 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.
Thanks for reporting this - a fix has been submitted here: [0]


[0] https://lore.kernel.org/linux-amlogic/20250420164801.330505-1-martin.blumenstingl@googlemail.com/T/#t