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: <CA+Gksr+E-tZe4sKVNa8zpATwdTW_DiOQxOf_Jujf5SURzhSPSg@mail.gmail.com>
Date: Wed, 13 Nov 2024 11:24:28 +0100
From: Tamás Szűcs <tszucs@...ux.com>
To: Dragan Simic <dsimic@...jaro.org>
Cc: Tamás Szűcs <tszucs@...ux.com>, 
	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

Hi Dragan,

On Wed, Nov 13, 2024 at 12:25 AM Dragan Simic <dsimic@...jaro.org> wrote:
>
> Hello Tamas,
>
> 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.

>
> 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.