linux-kernel - Re: [PATCH v2 2/2] arm64: dts: rockchip: Add FriendlyElec CM3588 NAS board

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: <4035271.e99z0qppnp@diego>
Date: Sun, 09 Jun 2024 18:05:49 +0200
From: Heiko Stübner <heiko@...ech.de>
To: linux-rockchip@...ts.infradead.org,
 Sebastian Reichel <sebastian.reichel@...labora.com>,
 Space Meyer <me@...-space.agency>, Sebastian Kropatsch <seb-dev@...l.de>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Jonas Karlman <jonas@...boo.se>,
 Dragan Simic <dsimic@...jaro.org>, devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject:
 Re: [PATCH v2 2/2] arm64: dts: rockchip: Add FriendlyElec CM3588 NAS board

Am Samstag, 8. Juni 2024, 19:22:01 CEST schrieb Sebastian Kropatsch:
> Hello,
> 
> Am 08.06.2024 um 16:38 schrieb Heiko Stuebner:
> > Am Donnerstag, 6. Juni 2024, 15:13:20 CEST schrieb Space Meyer:
> >> On 02.06.2024 22:20, Sebastian Kropatsch wrote:
> >>> Some RK3588 boards are still using this property, the following quote
> >>> is from rk3588-tiger-haikou.dts for example:
> >>>       &sdmmc {
> >>>           /* while the same pin, sdmmc_det does not detect card changes */
> >>>           cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
> >>>
> >>> I am unsure as to whether this comment from the quote might apply for
> >>> the CM3588 as well. Please let me know if you are able to tell :-)
> >>
> >> I don't quite understand this. However GPIO0_A4 *is* routed to the micro
> >> sd CD according to the NAS schematic, page 16 around A5.
> > 
> > for the actual sdmmc_det functionality ... possibly some pinconfig thing?
> > I.e. pull-whatever settings?
> 
> I have no idea. I just removed the "cd-gpios" line in v2 due to a
> suggestion by Jonas Karlman and then stumbled over this comment.
> So I'm not sure whether to include or not include this property
> for the CM3588 NAS since I don't know the consequences.
> Probably in the end it doesn't even matter :)
> 
> >>> +	vcc_3v3_pcie30: regulator-vcc-3v3-pcie30 {
> >>> +		compatible = "regulator-fixed";
> >>> +		regulator-name = "vcc_3v3_pcie30";
> >>> +		regulator-always-on;
> >>> +		regulator-boot-on;
> >>> +		regulator-min-microvolt = <3300000>;
> >>> +		regulator-max-microvolt = <3300000>;
> >>> +		vin-supply = <&vcc_5v0_sys>;
> >>> +	};
> >>
> >> These are 4 seperate regulators according to the schematic. However, as
> >> they are all fixed, idk if they should be split or kept like this.
> > 
> > personally, I really like the power-diagram to match schematics.
> > I.e. $debugfs/regulator/regulator_summary will produce a really nice
> > graph of all the system's regulators, so it's definitly nice if the
> > hirarchy matches. Also prevents head-scratching later on ;-)
> 
> These are indeed 4 different regulators according to the schematic.[1]
> But they don't have any pin to control them separately. I can
> duplicate them 4 times if that's the preferred practice.
> 
> But matching the schematics won't be possible either way, since
> e.g. there is only one single 5v regulator acc. to the schematic
> (vcc_5v0_sys), but vcc_5v0_host_20, vcc_5v0_host_30, vbus_5v0_typec
> and so on are needed since each device has a different control pin
> to enable its power. Or is there a better way to solve this while
> having only one 5v regulator node but still being able to set the
> control pins separately for the different USB ports?

The other option we often use is to define multiple phandles
for a regulator. For exactly that case where one gpio controls
a set of regulators.

So you have one regulator

vcc_5v0_host_20: vcc_5v0_host_30: vbus_5v0_typec: regulator-vcc-whatever {
	foo;
}

So in short there is not set rule, but more like a best-effort to get as
close to the schematics as possible. I.e. someone going from dt
to schematics should be able to just search for an identifier
(of course same for the other direction).


Heiko