回复: [PATCH v6 2/2] hwrng: starfive: rework clk/reset teardown order for JHB100

[Lianfeng Ouyang]

> -----邮件原件-----
> 发件人: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
> 发送时间: 2026年7月30日 15:15
> 收件人: Lianfeng Ouyang <lianfeng.ouyang@xxxxxxxxxxxxxxxx>
> 抄送: Olivia Mackall <olivia@xxxxxxxxxxx>; Rob Herring <robh@xxxxxxxxxx>;
> Krzysztof Kozlowski <krzk+dt@xxxxxxxxxx>; Conor Dooley
> <conor+dt@xxxxxxxxxx>; Philipp Zabel <p.zabel@xxxxxxxxxxxxxx>;
> linux-crypto@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx;
> linux-kernel@xxxxxxxxxxxxxxx
> 主题: Re: [PATCH v6 2/2] hwrng: starfive: rework clk/reset teardown order for
> JHB100
> 
> On Thu, Jul 23, 2026 at 03:52:06PM +0800, lianfeng.ouyang wrote:
> >
> > +	if (!wait && !mutex_trylock(&trng->lock))
> > +		return -EAGAIN;
> > +
> > +	mutex_lock(&trng->lock);
> 
> Did you actually test this? If mutex_trylock succeeds wouldn't
> the subsequent mutex_lock immediately dead-lock?

sorry, you're absolutely right — this is a bug. mutex_trylock() already acquires 
the lock on success, so the subsequent mutex_lock() would self-deadlock on the 
same execution flow (kernel mutexes are non-recursive). The change was small 
enough that I didn't run a test , but that's no excuse for missing it in review.

I will fix by making the two paths mutually exclusive:
if (!wait) {
	if (!mutex_trylock(&trng->lock))
		return -EAGAIN;
} else {
	mutex_lock(&trng->lock);
}

> Something's wrong with your patches and Sashiko couldn't apply
> them at all:
> 
> https://sashiko.dev/#/patchset/20260723075206.3032-1-lianfeng.ouyang%40st
> arfivetech.com
> 
> Thanks,

It seems that this website did not provide a reason for failed to apply. 
It was possible before v4 version. Is this error related to my code?

> --
> Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Best Regards,
Lianfeng Ouyang