linux-kernel - Re: [alsa-devel][PATCH 1/3] SoC: fsl

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: <20150121060702.GB3275@Alpha>
Date:	Tue, 20 Jan 2015 22:07:03 -0800
From:	Nicolin Chen <nicoleotsuka@...il.com>
To:	Zidan Wang <zidan.wang@...escale.com>
Cc:	timur@...i.org, Xiubo.Lee@...il.com, lgirdwood@...il.com,
	broonie@...nel.org, perex@...ex.cz, tiwai@...e.de,
	alsa-devel@...a-project.org, linuxppc-dev@...ts.ozlabs.org,
	linux-kernel@...r.kernel.org
Subject: Re: [alsa-devel][PATCH 1/3] SoC: fsl_sai: add sai master mode support

On Tue, Jan 20, 2015 at 08:21:18PM +0800, Zidan Wang wrote:
> +static int fsl_sai_set_bclk(struct snd_soc_dai *dai, bool tx, u32 freq)

> +	if ((tx && sai->synchronous[TX]) || (!tx && !sai->synchronous[RX])) {
> +		regmap_update_bits(sai->regmap, FSL_SAI_RCR2,
> +			FSL_SAI_CR2_MSEL_MASK, FSL_SAI_CR2_MSEL(sai->mclk_id));
> +		regmap_update_bits(sai->regmap, FSL_SAI_RCR2,
> +			FSL_SAI_CR2_DIV_MASK, savediv - 1);

Hmm...the case should be a bit more complicated here IMO.

"tx && sai->synchronous[TX]" means the playback in synchronous
mode (TX following RX). What if the recording has been already
activated with an MSEL setting at this point? Then the playback
stream, as a secondary stream, will overwrite MSEL of the first
stream -- Record. Same would happen to the DIV configuration.

> @@ -297,6 +368,24 @@ static int fsl_sai_hw_params(struct snd_pcm_substream *substream,
>  	unsigned int channels = params_channels(params);
>  	u32 word_width = snd_pcm_format_width(params_format(params));
>  	u32 val_cr4 = 0, val_cr5 = 0;
> +	int ret;
> +
> +	if (!sai->is_slave_mode) {
> +		ret = fsl_sai_set_bclk(cpu_dai, tx,
> +			2 * word_width * params_rate(params));
> +		if (ret)
> +			return ret;
> +
> +		/* Do not enable the clock if it is already enabled */

It actually doesn't matter to enable the clock again since it
purely increaes its count. But we do need a protection for MSEL
overwritten issue resulted from the fsl_sai_set_bclk() call.

> @@ -133,10 +135,13 @@ struct fsl_sai {
>  	struct clk *mclk_clk[FSL_SAI_MCLK_MAX];
>  
>  	bool is_lsb_first;
> +	bool is_slave_mode;
>  	bool is_dsp_mode;
>  	bool sai_on_imx;
>  	bool synchronous[2];
>  
> +	unsigned int mclk_id;
> +	unsigned int mclk_streams;

Besides, I doubt that only one property of mclk_id can content
Asynchronous Mode -- TX and RX can fetch their clocks from
different MCLK sources.

Nicolin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/