linux-kernel - Re: [PATCH 2/5] arm64: dts: rockchip: Fix regulators, gmac and naming on NanoPi R6C/R6S

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: Thu, 20 Jun 2024 23:48:08 +0200
From: Sebastian Kropatsch <seb-dev@...l.de>
To: Heiko Stübner <heiko@...ech.de>
Cc: linux-rockchip@...ts.infradead.org, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/5] arm64: dts: rockchip: Fix regulators, gmac and naming
 on NanoPi R6C/R6S

Hello,

Am 20.06.2024 um 20:39 schrieb Heiko Stübner:
> Am Mittwoch, 12. Juni 2024, 22:48:11 CEST schrieb Sebastian Kropatsch:
>> Fix the alphabetical ordering in some nodes and rename some regulators
>> and pins to match the schematics [1][2] as well as to adhere to
>> preferred naming schemes.
> 
> General rule of thumb, when you need an "and" in your subject or a list
> like the above - you definitly want to split the change into multiple
> commits.

Thanks for the advice! I wasn't sure and didn't want to spam the list.
Also, my email provider only allows a limited number of emails to be
sent every day (series with 5 patches, with 9 recipients = 45 emails
sent). So I might have to send the patch series by spanning the
different patches over multiple days.

If anyone knows an email provider which is better suited for this kind
of open source work/mailing lists and is also privacy respecting, please
let me know :)

I will definitely split these changes into separate commits.

>> In addition to that:
>> * vcc_3v3_sd_s0: Fix voltage to be 3.3V
>> * vcc3v3_pcie:
>>      - Move to NanoPi R6C, this power switch is not available on R6S
>>      - Fix vin-supply (is vcc_5v0 per schematics)
>>      - Add gpios/pincrtl to enable power
> 
> this defnitly needs its own patch
> 
>> * vcc5v0_usb: Remove this regulator since according to the schematics,
> 
> this too
> 
>> * vcc5v0_host_20 and vcc5v0_usb_otg0 are directly powered by vcc_5v0
> 
> this could be grouped together with the 3.3v change
> 
>> * gmac1: Add rx_delay of 0 (no delay since phy-mode = "rgmii-rxid")
> 
> with rxid mode, why is the rx_delay needed at all?
> Shouldn't this just work without the property?

In theory yes, but with the property missing, you'll get a warning
message in dmesg which says:

	Can not read property: rx_delay.
	Set rx_delay to 0x10

So it will set the rx_delay to a value which is not 0, even if rxid
mode is selected. I guess this is something which can be fixed in the
driver, but that may be beyond my abilities.
Setting the rx_delay to 0 gets rid of this warning, so it seems to
be a viable workaround.

>> * rgmii_phy1: Add phy-supply as seen in schematics
> 
> separate patch
> 
>> * pcie2*:
>>      - Add pinctrl reset pins
>>      - Update vpcie3v3-supply to match the schematics
> 
> separate patch
> 
>> * sdhci: Add vmmc-supply and vqmmc-supply
> 
> separate patch
> 

Thanks,
Sebastian