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: <639b4e3a-3f68-4fba-aa33-c46dcb6fc88f@linaro.org>
Date: Fri, 24 Jan 2025 17:48:03 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Markus Schneider-Pargmann <msp@...libre.com>
Cc: Lee Jones <lee@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Siddharth Vadapalli <s-vadapalli@...com>,
 Nishanth Menon <nm@...com>, Vignesh Raghavendra <vigneshr@...com>,
 Tero Kristo <kristo@...nel.org>, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 2/5] dt-bindings: mfd: syscon: Add ti,am62-ddr-pmctrl

On 24/01/2025 17:05, Markus Schneider-Pargmann wrote:
> Hi Krzysztof,
> 
> On Fri, Jan 24, 2025 at 09:22:54AM +0100, Krzysztof Kozlowski wrote:
>> On Fri, Jan 24, 2025 at 09:19:49AM +0100, Krzysztof Kozlowski wrote:
>>> On Wed, Jan 22, 2025 at 11:24:33AM +0100, Markus Schneider-Pargmann wrote:
>>>> Add compatible for ti,am62-ddr-pmctrl to the list. There is a DDR pmctrl
>>>> register in the wkup-conf register space of am62a and am62p. This
>>>> register controls DDR power management.
>>>>
>>>> Signed-off-by: Markus Schneider-Pargmann <msp@...libre.com>
>>>> ---
>>>>  Documentation/devicetree/bindings/mfd/syscon.yaml | 2 ++
>>>>  1 file changed, 2 insertions(+)
>>>
>>> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>>
>> 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.
> 
> Do I understand you correctly that the whole register range of the
> wkup_conf node as seen in arch/arm64/boot/dts/ti/k3-am62a-wakeup.dtsi
> should be considered a single syscon device?

I don't have the datasheets (and not my task to actually check this),
but you should probably follow datasheet. I assume it describes what is
the device, more or less.

I assume entire wkup_conf is considered a device.

> 
> Unfortunately wkup_conf is modeled as a simple-bus with currently 5
> subnodes defined of which 4 of them consist of a single register. Most
> of them are syscon as well. So I think I can't change the simple-bus
> back to syscon.

Huh... Maybe TI folks will help us understand why such design was chosen.

> 
> For the DDR pmctrl, this really only consist of a single register, the
> registers surrounding this pmctrl are not related as far as I can tell.

DDR pmctrl does not fit definition of syscon then. Syscon is a
*collection* of miscellaneous registers. Most likely the entire block is
that collection and someone decided - oh but I want syscon per each
register. Awesome. And then what if someone wants two registers, but
there are spread apart and in the middle is someone else?

| ddr pmctrl 1 | something else | ddr pmctrl 2 |

Two syscons?

And what if you have three registers? What if four? You see where it is
getting at?


> 
> What do you suggest how I can solve this?

I have no clue how the device actually looks like, so tricky to give
answer, but I could imagine total node rework, calling everything
syscon+mfd. This would still be backwards compatible.

Or adding one new block covering remaining parts of the device, so at
least people stop adding 1000 new syscons per each register, because
there will be just one.

Best regards,
Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ