linux-kernel - Re: [PATCH 2/2] 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251224114848-GYA1993014@gentoo.org>
Date: Wed, 24 Dec 2025 19:48:48 +0800
From: Yixun Lan <dlan@...too.org>
To: Philipp Zabel <p.zabel@...gutronix.de>
Cc: Stephen Boyd <sboyd@...nel.org>,
	Michael Turquette <mturquette@...libre.com>,
	Alex Elder <elder@...cstar.com>, Guodong Xu <guodong@...cstar.com>,
	Inochi Amaoto <inochiama@...il.com>, Yao Zi <me@...ao.cc>,
	linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org,
	linux-riscv@...ts.infradead.org, spacemit@...ts.linux.dev
Subject: Re: [PATCH 2/2] reset: spacemit: fix auxiliary device id

Hi Philipp Zabel,

I'd like to see your preference for this issue, see my comment below

On 10:59 Sat 20 Dec     , Yixun Lan wrote:
> Hi Yao,
> 
> On 02:40 Sat 20 Dec     , Yao Zi wrote:
> > On Sat, Dec 20, 2025 at 09:11:20AM +0800, Yixun Lan wrote:
> > > Due to the auxiliary register procedure moved to ccu common module,
> > > the auxiliary device id need to be adjusted, otherwise reset driver
> > > will fail to probe.
> > 
> > Does it mean the reset driver fails to probe with only PATCH 1 in the
> > series applied? If so these two patches should probably be merged, or we
> > will get unfunctional commits.
> yes, it will fail with only patch 1
> 
> and no, I do not want to combine them together as they belong to
> different subsystem. it shouldn't be a problem if they are accepted in
> same merge window, or if people too picky to worry bisectable breakage,
> then I would ask reset/clock maintainer an ack instead to make it go
> via clock tree in one combined PR
> 
I'd consider above approach is less optimal, would it ok if I create an
immutable tag for this single patch, and send it to you? so can be shared
by both clock and reset subsystem.. eventually reset driver should go via
reset tree, and I also know Guodong is working on new reset driver to
add support for incoming K3 SoC, which means potential conflicts or
extra dependency..

-- 
Yixun Lan (dlan)