linux-kernel - Re: [PATCH v3 4/4] reset: spacemit: fix auxiliary device id

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] [day] [month] [year] [list]

Message-ID: <20260108122413-GYB4052@gentoo.org>
Date: Thu, 8 Jan 2026 20:24:13 +0800
From: Yixun Lan <dlan@...too.org>
To: Philipp Zabel <p.zabel@...gutronix.de>
Cc: Alex Elder <elder@...cstar.com>, Stephen Boyd <sboyd@...nel.org>,
	Michael Turquette <mturquette@...libre.com>,
	Guodong Xu <guodong@...cstar.com>,
	Inochi Amaoto <inochiama@...il.com>, linux-kernel@...r.kernel.org,
	linux-clk@...r.kernel.org, linux-riscv@...ts.infradead.org,
	spacemit@...ts.linux.dev
Subject: Re: [PATCH v3 4/4] reset: spacemit: fix auxiliary device id

Hi Philipp,

On 12:07 Thu 08 Jan     , Philipp Zabel wrote:
> On Di, 2026-01-06 at 08:43 -0600, Alex Elder wrote:
> > On 1/3/26 1:26 AM, Yixun Lan wrote:
> > > Due to the auxiliary register procedure moved to ccu common module where
> > > the module name changed to spacemit_ccu, then the reset auxiliary device
> > > register id also need to be adjusted in order to prepare for adding new
> > > K3 reset driver, otherwise two reset drivers will claim to support same
> > > "compatible" auxiliary device.
> > > 
> > > Signed-off-by: Yixun Lan <dlan@...too.org>
> > 
> > This would ideally be merged with the previous patch.  Maybe
> > Philipp can negotiate with Stephen to have that happen.
> > 
> > Reviewed-by: Alex Elder <elder@...cstar.com>
> > 
> > > ---
> > >   drivers/reset/reset-spacemit.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/reset/reset-spacemit.c b/drivers/reset/reset-spacemit.c
> > > index e1272aff28f7..cc7fd1f8750d 100644
> > > --- a/drivers/reset/reset-spacemit.c
> > > +++ b/drivers/reset/reset-spacemit.c
> > > @@ -278,7 +278,7 @@ static int spacemit_reset_probe(struct auxiliary_device *adev,
> > >   
> > >   #define K1_AUX_DEV_ID(_unit) \
> > >   	{ \
> > > -		.name = "spacemit_ccu_k1." #_unit "-reset", \
> > > +		.name = "spacemit_ccu.k1-" #_unit "-reset", \
> > >   		.driver_data = (kernel_ulong_t)&k1_ ## _unit ## _reset_data, \
> > >   	}
> > >   
> 
> Acked-by: Philipp Zabel <p.zabel@...gutronix.de>
> 
thanks

> to be merged via the clock tree.
> 
ok, got!

and, here is my plan, I will prepare an immutable tag for the patch 4 -
the change to reset driver ID, and merge it with the whole series,
then send them along via clock tree.

the tag would be useful if follow-up K3 reset patch[1] need to be merged, since
both will change the reset driver, and with the tag, patch 4 can be pulled into
both clock and reset subsystem, future reset patches can commit on top of it.
even there is no price to pay if above doesn't happen.


> Note that the commits for both patches 2 and 3 will fail to probe the
> reset driver when bisecting.
> If you don't want do merge the corresponding changes to K1_AUX_DEV_ID()
> into those two patches, to make this series (runtime) bisectable, you
no, I do not want to merge changes K1_AUX_DEV_ID() into patch 2/3

> should add a warning to both their commit messages that the reset
> driver will be adapted in the following patch 4.
ok, I will send a new version and add a warning message

> 
> regards
> Philipp

Link: https://lore.kernel.org/all/20251229-k3-reset-v1-0-eda0747bded3@riscstar.com/ [1]

-- 
Yixun Lan (dlan)