linux-kernel - Re: [PATCH 3/3] arm64: dts: rockchip: Enable UART8 on rock-3b

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: <dc628e6e50239aac65a4424738000612@manjaro.org>
Date: Wed, 13 Nov 2024 11:38:37 +0100
From: Dragan Simic <dsimic@...jaro.org>
To: Tamás Szűcs <tszucs@...ux.com>
Cc: Jonas Karlman <jonas@...boo.se>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Heiko Stuebner <heiko@...ech.de>, FUKAUMI Naoki
 <naoki@...xa.com>, Chukun Pan <amadeus@....edu.cn>,
 devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] arm64: dts: rockchip: Enable UART8 on rock-3b

Hello Tamas,

On 2024-11-13 11:24, Tamás Szűcs wrote:
> On Wed, Nov 13, 2024 at 12:25 AM Dragan Simic <dsimic@...jaro.org> 
> wrote:
>> On 2024-11-12 22:04, Tamás Szűcs wrote:
>> > On Tue, Nov 12, 2024 at 4:07 PM Dragan Simic <dsimic@...jaro.org>
>> > wrote:
>> >> Please correct me if I'm wrong, but isn't this UART supposed to be
>> >> used for the Bluetooth part of an SDIO WiFi + Bluetooth module, in
>> >> form of a non-standard M.2 module that Radxa sells?
>> >
>> > UART8 is supposed to be used for any radio module connected to the M2E
>> > connector.
>> > It will typically be responsible for Bluetooth or BLE but it could be
>> > 802.15.4 or whatever. In any case, all wanting to use it will need the
>> > uart8 node enabled.
>> 
>> I see, but I'm still guessing what's the actual use of enabling the
>> UART8 when it will remain pretty much useless without the additional
>> DT configuration, such as in the WiFi+Bluetooth DT overlay that Jonas
>> sent a bit earlier?
> 
> The actual use is device enablement.

Hmm, I'll need to think more about how it fits together.

>> I think that the UART8 should be enabled together with something that
>> actually makes use of it, which in this case unfortunately cannot be
>> automatically detected and configured, so it belongs to a DT overlay.
>> I'll get back to this in my next response.
> 
> I agree, bluetooth blocks dedicated to specific modules should belong
> to DT overlays.
> 
>> >> With that in mind, I see very little sense in just enabling the UART,
>> >> without defining the entire Bluetooth interface, which AFAIK produces
>> >
>> > Defining a bluetooth node would hardwire idiosyncrasies of a given
>> > radio module's Bluetooth core. Sure you could add a sleep clock, all
>> > kind of sideband signals for wakeups, reset, power down, etc. But hey,
>> > some will use them, some won't. I think it's undesirable and
>> > unnecessary. You can hciattach from here and most will work just like
>> > that. Tighter integration or anything special, module specific on top
>> > should be handled individially, on a case-by-case basis. This is a dev
>> > board after all. I say trick of all trades.
>> >
>> >> nasty looking error messages in the kernel log when there's actually
>> >> nothing connected to the UART.
>> >
>> > My dmesg is clean as a whistle
>> > root@...k-3b:~# dmesg | grep -E 'fe6c0000|ttyS0'
>> > [    0.344818] fe6c0000.serial: ttyS0 at MMIO 0xfe6c0000 (irq = 26,
>> > base_baud = 1500000) is a 16550A
>> > What kind of nasty errors do you recall?
>> 
>> Those would be the kernel error messages produced with the Bluetooth
>> DT configuration in place, but with no SDIO module installed.
> 
> These are the kernel messages related to UART8 with the uart8 DT node
> enabled and an SDIO module installed.

Out of curiosity, what M.2 module are you testing it with?