Re: [PATCH] ASoC: ak4458: Check reset status after deassert

["Alvin Šipraga" <alvin.sipraga@analog.com>]

On Sat, Oct 10, 2026 at 04:40:58PM +0800, shengjiu.wang@oss.nxp.com wrote:
> From: Shengjiu Wang <shengjiu.wang@nxp.com>
> 
> The reset line of the ak4458 can be shared, for example when two ak4458
> devices use the same reset GPIO. In that case the two codecs may call
> reset_control_deassert() concurrently from their runtime resume paths.
> 
> Only the first caller performs the actual hardware deassert, which may
> sleep (for example a GPIO-expander based reset controller). A second
> caller merely increments the shared deassert count and returns
> immediately, so it can continue while the first caller's .deassert() has
> not finished releasing the line yet, leaving the device still in reset.

This seems like something that should be fixed in the reset controller
framework. In fact the issue you describe seems to contradict the
documentation of reset_control_deassert():

/**
 * reset_control_deassert - deasserts the reset line
 * @rstc: reset controller
 *
 * After calling this function, the reset is guaranteed to be deasserted.

^ (1) seems not to be the case as you have found

 * Consumers must not use reset_control_reset on shared reset lines when
 * reset_control_(de)assert has been used.

^ (2) isn't this rule also being broken in the suspend/resume path of
      this driver?

 *
 * If rstc is NULL it is an optional reset and the function will just
 * return 0.
 */
int reset_control_deassert(struct reset_control *rstc)
...


(1) being fixed in the framework would solve your problem.

But (2) seems a bit more intractable. Shared reset GPIOs have always
been a pain... I wonder if there is a better approach?

Kind regards,
Alvin