[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5674cfb0-fabe-4b58-98fd-8479c4d3ff79@riscstar.com>
Date: Mon, 12 May 2025 11:27:25 -0500
From: Alex Elder <elder@...cstar.com>
To: Philipp Zabel <p.zabel@...gutronix.de>, Yixun Lan <dlan@...too.org>
Cc: robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
mturquette@...libre.com, sboyd@...nel.org, paul.walmsley@...ive.com,
palmer@...belt.com, aou@...s.berkeley.edu, alex@...ti.fr, heylenay@....org,
inochiama@...look.com, guodong@...cstar.com, devicetree@...r.kernel.org,
linux-clk@...r.kernel.org, spacemit@...ts.linux.dev,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 3/6] clk: spacemit: set up reset auxiliary devices
On 5/12/25 10:46 AM, Philipp Zabel wrote:
>>> so I'd assume the underlying device doesn't really care the id?
>>> but with different order of registration, it will result random id for the device
>> These things are identified in DTS files by their index values
>> defined in "spacemit,k1-syscon.h". If there is a need for the
>> assigned device ID to be consistent, I'm not aware of it. Can
>> you think of one? I think all that matters is that they're
>> unique, and this ensures that (for up to 2^32 PMICs).
> If there are multiple reset controllers and the driver can be unbound,
> it's trivial to provoke a collision by keeping one device bound and
> unbinding/binding the second one until next_id wraps.
> This could be fixed by using ida_alloc/free to manage the id.
>
> regards
> Philipp
OK thank you. I'll put together v9 of this series and will use
an IDA to set the device ID. Thanks again for the explanation.
-Alex
Powered by blists - more mailing lists