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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <VI1PR0401MB2272061C958E91FCAA239EB892E20@VI1PR0401MB2272.eurprd04.prod.outlook.com>
Date:   Tue, 17 Nov 2020 18:17:36 +0000
From:   Viorel Suman <viorel.suman@....com>
To:     Mark Brown <broonie@...nel.org>,
        "Viorel Suman (OSS)" <viorel.suman@....nxp.com>
CC:     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 12:20:36AM +0200, Viorel Suman (OSS) wrote:
> 
> >  static void ak4458_power_off(struct ak4458_priv *ak4458)  {
> > -	if (ak4458->reset_gpiod) {
> > -		gpiod_set_value_cansleep(ak4458->reset_gpiod, 0);
> > -		usleep_range(1000, 2000);
> > +	if (ak4458->reset) {
> > +		reset_control_assert(ak4458->reset);
> > +		msleep(20);
> 
> We should really leave the support for doing this via GPIO in place for backwards
> compatibility I think, we could mark it as deprecated in the binding document.
> Otherwise this makes sense to me and solves a real problem we have with the
> handling of resets so we should look into doing this for new bindings.
> 
> 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);
==========

/Viorel