[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <859a4fc2-45f5-4d72-9727-7979e4c15bd5@kernel.org>
Date: Sat, 12 Apr 2025 12:04:33 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Bryan Brattlof <bb@...com>
Cc: Nishanth Menon <nm@...com>, Vignesh Raghavendra <vigneshr@...com>,
Tero Kristo <kristo@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, linux-arm-kernel@...ts.infradead.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 2/3] arm64: dts: ti: k3-am62l: add initial
infrastructure
On 11/04/2025 20:26, Bryan Brattlof wrote:
>>> +
>>> + usb0_phy_ctrl: syscon@...00 {
>>> + compatible = "ti,am62-usb-phy-ctrl", "syscon";
>>> + reg = <0x45000 0x4>;
>>> + bootph-all;
>>> + };
>>> +
>>> + usb1_phy_ctrl: syscon@...04 {
>>> + compatible = "ti,am62-usb-phy-ctrl", "syscon";
>>> + reg = <0x45004 0x4>;
>>
>> No, you do not get syscon per register. The entire point of syscon is to
>> collect ALL registers. Your device is the syscon, not a register.
>>
>
> My understanding from [0] was that we would need to break this up into
> smaller syscon nodes because the alternative would be to mark the entire
> region as a syscon and every other node using it would need to use it's
> base + offset which was kinda undesirable especially for the small
> number of drivers that need data from this region.
>
> a-device {
> clocks = <&epwm_tbclk 0>;
Hm? That's how you use the syscon, so how it can be undesirable?
Anyway, one register is not a device, so no device node per register.
In the link you provided I was repeating the same, so you got same
review in multiple places.
Best regards,
Krzysztof
Powered by blists - more mailing lists