linux-kernel - Re: [PATCH 3/3] ARM: dts: amlogic: Add TCU Fernsehfee 3.0

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: <CAFBinCDgn30H13hfkEsfyzSjO-HJ-XpAUwSwimBk7VPpKyNKMw@mail.gmail.com>
Date: Sun, 6 Apr 2025 22:36:18 +0200
From: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To: J. Neuschäfer <j.ne@...teo.net>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, 
	Conor Dooley <conor+dt@...nel.org>, Neil Armstrong <neil.armstrong@...aro.org>, 
	Jerome Brunet <jbrunet@...libre.com>, Kevin Hilman <khilman@...libre.com>, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-amlogic@...ts.infradead.org
Subject: Re: [PATCH 3/3] ARM: dts: amlogic: Add TCU Fernsehfee 3.0

On Tue, Apr 1, 2025 at 3:00 PM J. Neuschäfer <j.ne@...teo.net> wrote:
>
> On Sun, Mar 30, 2025 at 11:10:28PM +0200, Martin Blumenstingl wrote:
> > Thanks for your patch!
> >
> > On Sun, Mar 23, 2025 at 1:38 PM J. Neuschäfer via B4 Relay
> > <devnull+j.ne.posteo.net@...nel.org> wrote:
> > [...]
> > > +               eth_phy0: ethernet-phy@0 {
> > > +                       /* IC Plus IP101A (0x02430c54) */
> > > +                       reg = <0>;
> > Does reg = <1> also work on your board?
> > 0 is the broadcast address. It's unfortunately something that we still
> > have incorrect in a lot of .dts files.
>
> Unfortunately not. I tried addresses 1 to 31 without success, which
> seems strange; my guess was that the PHY should respond to one of them.
> I get this error:
>
> # ip l set eth0 up
> [    6.806847] meson6-dwmac c9410000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
> [    6.810609] meson6-dwmac c9410000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19)
Thanks for testing. Let's keep it at zero then.

> >
> > [...]
> > > +&i2c_AO {
> > > +       status = "okay";
> > > +       pinctrl-0 = <&i2c_ao_pins>;
> > > +       pinctrl-names = "default";
> > > +
> > > +       pmic@32 {
> > > +               compatible = "ricoh,rn5t618";
> > > +               reg = <0x32>;
> > > +               system-power-controller;
> > Here I'm a bit surprised:
> > Aren't some of the outputs used to drive VCCK (CPU power rail) and
> > VDDEE (everything else power rail, which also powers the GPU)?
>
> Unfortunately I don't have schematics and I wasn't able to trace the
> connections on the board because they're so tiny. So it's quite possible that
> you're right, but I can't be sure.
>
> Are there voltage sensors in the Meson8 SoC that I could use to establishs the
> relation between PMIC outputs and SoC supplies?
There aren't any sensors (that I'm aware of). But you can check
/sys/kernel/debug/regulator/regulator_summary and compare the values
with the ones from arch/arm/boot/dts/amlogic/meson8m2-mxiii-plus.dts
Also the vendor u-boot and kernel logs may provide some information.

> >
> > [...]
> > > +&usb1 {
> > > +       status = "okay";
> > > +       dr_mode = "host";
> > > +       /*
> > > +        * This bus features a Realtek RTL8188 2.4GHz WiFi module, with a
> > > +        * 3.3V supply voltage that must be enabled before use.
> > > +        */
> > > +       vbus-supply = <&wifi_3v3>;
> > If you want to go for perfection then you can use
> > Documentation/devicetree/bindings/sound/xmos,xvf3500.yaml as
> > reference.
> > It's also an "onboard" USB device which requires toggling a GPIO and regulators.
> > The driver side is super easy to manage as it's generic (meaning: it
> > parses any GPIO and regulator as long as the USB ID is registered):
> > drivers/usb/misc/onboard_usb_dev.c
>
> I considered using onboard_usb_dev, but then came to the conclusion that
> I don't need it because I don't need reset sequencing, only power.
>
> > That way you can just describe the RTL8188 on the USB bus and assign
> > it's vd33-supply without having to (ab)use vbus-supply of the USB
> > controller.
>
> This does sound reasonable. I'll reconsider the onboard_usb_dev
> approach.
Thank you for the onboard usb device patches (for those who are curious: [0])!


[0] https://lore.kernel.org/lkml/20250403-rtl-onboard-v1-0-10ca9a6a4ee0@posteo.net/