linux-kernel - RE: [RFC PATCH] ASoC: ak4458: use reset control instead of reset gpio

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

Date:   Thu, 19 Nov 2020 16:22:42 +0000
From:   Viorel Suman <viorel.suman@....com>
To:     Mark Brown <broonie@...nel.org>
CC:     "Viorel Suman (OSS)" <viorel.suman@....nxp.com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
        "S.j. Wang" <shengjiu.wang@....com>,
        Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        Peter Ujfalusi <peter.ujfalusi@...com>,
        Lee Jones <lee.jones@...aro.org>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC PATCH] ASoC: ak4458: use reset control instead of reset gpio

> On Tue, Nov 17, 2020 at 06:17:36PM +0000, Viorel Suman wrote:
> > > On Tue, Nov 17, 2020 at 12:20:36AM +0200, Viorel Suman (OSS) wrote:
> 
> > > One thing I'm not clear on is if there's some way to ensure that we
> > > don't have different instances of the device resetting each other without
> them noticing?
> > > Shouldn't be an issue in practice for the use here.
> 
> > The way to ensure that we don't have different instances of the device
> > resetting each other is to rely on the way the "shared" reset is handled by
> reset API:
> > ==========
> > +	ak4458->reset = devm_reset_control_get_optional_shared(ak4458-
> >dev, NULL);
> > +	if (IS_ERR(ak4458->reset))
> > +		return PTR_ERR(ak4458->reset);
> > ==========
> 
> Flip side of that then, how do we know when a reset has actually happened?

I don't see how this can be achieved - I'd imagine some "shared" reset
framework notification mechanism calling back all "listeners" in the moment
the assert/deassert actually happened, there is no such mechanism currently
implemented.

In this specific case the GPIO purpose is to just to power on/off all codecs.
In my view with this approach it's enough to know that all codecs will be
powered on the first _deassert_ call and will be powered off on the last
_assert_ call.

/Viorel