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]

Date: Sat, 8 Jun 2024 19:22:01 +0200
From: Sebastian Kropatsch <seb-dev@...l.de>
To: Heiko Stuebner <heiko@...ech.de>, linux-rockchip@...ts.infradead.org,
 Sebastian Reichel <sebastian.reichel@...labora.com>,
 Space Meyer <me@...-space.agency>
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

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?

Cheers,
Sebastian

[1] 
https://wiki.friendlyelec.com/wiki/images/1/15/CM3588_NAS_SDK_2309_SCH.PDF