From: Krzysztof Kozlowski <krzk@kernel.org>
To: Bryan Brattlof <bb@ti.com>
Cc: Nishanth Menon <nm@ti.com>, Vignesh Raghavendra <vigneshr@ti.com>,
Tero Kristo <kristo@kernel.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/3] arm64: dts: ti: k3-am62l: add initial infrastructure
Date: Thu, 17 Apr 2025 07:39:47 +0200 [thread overview]
Message-ID: <f189ec8e-88fc-491f-8552-e1e5d0b7cde7@kernel.org> (raw)
In-Reply-To: <20250416144202.4bmm566iqaz6adzo@bryanbrattlof.com>
On 16/04/2025 16:42, Bryan Brattlof wrote:
> On April 12, 2025 thus sayeth Krzysztof Kozlowski:
>> On 11/04/2025 20:26, Bryan Brattlof wrote:
>>>>> +
>>>>> + usb0_phy_ctrl: syscon@45000 {
>>>>> + compatible = "ti,am62-usb-phy-ctrl", "syscon";
>>>>> + reg = <0x45000 0x4>;
>>>>> + bootph-all;
>>>>> + };
>>>>> +
>>>>> + usb1_phy_ctrl: syscon@45004 {
>>>>> + 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.
>>
>
> Interesting. The way I read that thread was the opposite and it's why we
> did this for the 62, 62A, and 62P devices. I mainly say it's unfortunate
Really? What was unclear here:
https://lore.kernel.org/lkml/20250124-able-beagle-of-prowess-f5eb7a@krzk-bin/
Un-acked, I missed the point that you really speak in commit msg about
register and you really treat one register is a device. I assumed you
only need that register from this device, but no. That obviously is not
what this device is. Device is not a single register among 10000 others.
IOW, You do not have 10000 devices there.
NAK
> because if we have a block of miscellaneous registers there's no clear
> guidance on how big or small that range can or should be and we still
> need to encode the offset to that exact register.
>
> By labeling each register we at least have the opportunity to describe
> each register and if they are even used.
Repeated many times: no device nodes per clock (also TI invention), no
device nodes per register. This is not an opportunity. This is just not
desired.
Best regards,
Krzysztof
next prev parent reply other threads:[~2025-04-17 5:39 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-07 15:34 [PATCH v4 0/3] arm64: dts: ti: introduce basic support for the AM62L Bryan Brattlof
2025-04-07 15:34 ` [PATCH v4 1/3] dt-bindings: arm: ti: Add binding for AM62L SoCs Bryan Brattlof
2025-04-07 15:34 ` [PATCH v4 2/3] arm64: dts: ti: k3-am62l: add initial infrastructure Bryan Brattlof
2025-04-07 17:46 ` Nishanth Menon
2025-04-07 21:34 ` Bryan Brattlof
2025-04-07 18:09 ` Andrew Davis
2025-04-07 21:35 ` Bryan Brattlof
2025-04-09 7:17 ` krzk
2025-04-11 18:26 ` Bryan Brattlof
2025-04-12 10:04 ` Krzysztof Kozlowski
2025-04-16 14:42 ` Bryan Brattlof
2025-04-17 5:39 ` Krzysztof Kozlowski [this message]
2025-04-07 15:34 ` [PATCH v4 3/3] arm64: dts: ti: k3-am62l: add initial reference board file Bryan Brattlof
2025-04-08 1:47 ` [PATCH v4 0/3] arm64: dts: ti: introduce basic support for the AM62L Rob Herring (Arm)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f189ec8e-88fc-491f-8552-e1e5d0b7cde7@kernel.org \
--to=krzk@kernel.org \
--cc=bb@ti.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=kristo@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nm@ti.com \
--cc=robh@kernel.org \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox