linux-kernel - Re: [PATCH 1/1] ASoC: codecs: max98090: Allow dsp

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: <0ada8334-4006-438f-8461-5c4c8e13f65d@inbox.ru>
Date:   Wed, 21 Jun 2023 17:28:41 +0300
From:   Maxim Kochetkov <fido_max@...ox.ru>
To:     Mark Brown <broonie@...nel.org>
Cc:     alsa-devel@...a-project.org, Liam Girdwood <lgirdwood@...il.com>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        Benjamin Mugnier <benjamin.mugnier@...s.st.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Uwe Kleine-König <u.kleine-koenig@...gutronix.de>,
        Claudiu Beznea <claudiu.beznea@...rochip.com>,
        Charles Keepax <ckeepax@...nsource.cirrus.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] ASoC: codecs: max98090: Allow dsp_a mode



On 21.06.2023 17:01, Mark Brown wrote:
> On Wed, Jun 21, 2023 at 04:55:18PM +0300, Maxim Kochetkov wrote:
>> On 21.06.2023 16:18, Mark Brown wrote:
> 
>>> I'm saying there should be some interlock between these two settings, if
>>> nothing else setting DSP A mode should force TDM mode with automatically
>>> configured slot sizes.
> 
>> At this time there is no any interlock for TDM mode in MAX98090 driver. We
> 
> Yes, that's the problem I am identifying.  The driver allows TDM mode to
> be configured independently of the DAI format but the two are related.

But DSP_A mode is just bit/frame format. It is just compatible with TDM.

> 
>> can specify dai-tdm-slot-* properties in DT and .set_tdm_slot() will be
>> called to setup TDM mode. And SND_SOC_DAIFMT cannot affect it. I checked
>> other codecs drivers: most of them performs TDM setup this way. So why do we
>> need such interlock right now?
> 
> A lot of devices support TDM modes with other DAI formats, or allow the
> mode that is required for TDM to be configured even without doing TDM
> setup.  Some always configure TDM like I'm suggesting, with the explicit
> TDM configuration just being an override.  Some are just buggy and
> nobody noticed.  The issue is that the driver will claim to have
> configured DSP A mode but actually done something else unless the user
> also configures TDM.

Yep. But we have to specify TDM parameters (slot masks, slot width, etc) 
any way. Because there is no default TDM configuration like I2S and so. 
And pure DSP_A/B mode just have no sense.

Anyway. What do you suggest? Should I perform some refactoring for the 
driver? Should I move M98090_REG_TDM_FORMAT/M98090_REG_TDM_CONTROL 
registers setup to the max98090_dai_set_fmt()?