linux-kernel - RE: [PATCH v6] ASoC: Intel: kbl_rt5663_rt5514_max98927: Fix kabylake_ssp

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]

Date:   Thu, 16 Jul 2020 18:04:13 +0000
From:   "N, Harshapriya" <harshapriya.n@...el.com>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
        "broonie@...nel.org" <broonie@...nel.org>
CC:     "lma@...ihalf.com" <lma@...ihalf.com>,
        "yang.jie@...ux.intel.com" <yang.jie@...ux.intel.com>,
        "liam.r.girdwood@...ux.intel.com" <liam.r.girdwood@...ux.intel.com>,
        "rad@...ihalf.com" <rad@...ihalf.com>,
        "zwisler@...gle.com" <zwisler@...gle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "M R, Sathya Prakash" <sathya.prakash.m.r@...el.com>,
        "brndt@...gle.com" <brndt@...gle.com>,
        "mw@...ihalf.com" <mw@...ihalf.com>,
        "levinale@...omium.org" <levinale@...omium.org>,
        "Gopal, Vamshi Krishna" <vamshi.krishna.gopal@...el.com>
Subject: RE: [PATCH v6] ASoC: Intel: kbl_rt5663_rt5514_max98927: Fix
 kabylake_ssp_fixup function

> 
> 
> 
> > diff --git a/sound/soc/intel/boards/kbl_rt5663_rt5514_max98927.c
> > b/sound/soc/intel/boards/kbl_rt5663_rt5514_max98927.c
> > index 584e4f9cedc2..b261b1c466a8 100644
> > --- a/sound/soc/intel/boards/kbl_rt5663_rt5514_max98927.c
> > +++ b/sound/soc/intel/boards/kbl_rt5663_rt5514_max98927.c
> > @@ -379,22 +379,30 @@ static int kabylake_ssp_fixup(struct
> snd_soc_pcm_runtime *rtd,
> >   	struct snd_interval *chan = hw_param_interval(params,
> >   			SNDRV_PCM_HW_PARAM_CHANNELS);
> >   	struct snd_mask *fmt = hw_param_mask(params,
> SNDRV_PCM_HW_PARAM_FORMAT);
> > -	struct snd_soc_dpcm *dpcm = container_of(
> > -			params, struct snd_soc_dpcm, hw_params);
> > -	struct snd_soc_dai_link *fe_dai_link = dpcm->fe->dai_link;
> > -	struct snd_soc_dai_link *be_dai_link = dpcm->be->dai_link;
> > +	struct snd_soc_dpcm *dpcm, *rtd_dpcm;
> > +
> > +	/*
> > +	 * This macro will be called for playback stream
> > +	 */
> > +	for_each_dpcm_fe(rtd, SNDRV_PCM_STREAM_PLAYBACK, dpcm)
> > +		rtd_dpcm = dpcm;
> > +	/*
> > +	 * This macro will be called for capture stream
> > +	 */
> > +	for_each_dpcm_fe(rtd, SNDRV_PCM_STREAM_CAPTURE, dpcm)
> > +		rtd_dpcm = dpcm;
> 
> is the assumption that both of those loops return the same pointer?
no only one loop will enter based on the direction of the stream
If it’s a playback stream, the dpcm[1] will be empty
If it’s a capture stream, the dpcm[0] will be empty

> If yes, why not stop for the first non-NULL dpcm value?
> Also wondering if you are using a loop because there's no other helper
> available?
yes. I did not find any other helper function so I took the loop.