linux-kernel - Re: [PATCH] soundwire: stream: only change state if needed

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]

Date:   Fri, 20 Mar 2020 09:33:36 -0500
From:   Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:     Vinod Koul <vkoul@...nel.org>
Cc:     alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
        tiwai@...e.de, broonie@...nel.org, gregkh@...uxfoundation.org,
        jank@...ence.com, srinivas.kandagatla@...aro.org,
        slawomir.blauciak@...el.com,
        Bard liao <yung-chuan.liao@...ux.intel.com>,
        Rander Wang <rander.wang@...ux.intel.com>,
        Ranjani Sridharan <ranjani.sridharan@...ux.intel.com>,
        Hui Wang <hui.wang@...onical.com>,
        Sanyog Kale <sanyog.r.kale@...el.com>
Subject: Re: [PATCH] soundwire: stream: only change state if needed

On 3/20/20 9:15 AM, Vinod Koul wrote:
> On 17-03-20, 05:51, Pierre-Louis Bossart wrote:
>> In a multi-cpu DAI context, the stream routines may be called from
>> multiple DAI callbacks. Make sure the stream state only changes for
>> the first call, and don't return error messages if the target state is
>> already reached.
> 
> For stream-apis we have documented explicitly in Documentation/driver-api/soundwire/stream.rst
> 
> "Bus implements below API for allocate a stream which needs to be called once
> per stream. From ASoC DPCM framework, this stream state maybe linked to
> .startup() operation.
> 
> .. code-block:: c
> 
>    int sdw_alloc_stream(char * stream_name); "
> 
> This is documented for all stream-apis.
> 
> This can be resolved by moving the calling of these APIs from
> master-dais/slave-dais to machine-dais. They are unique in the card.

this change is about prepare/enable/disable/deprepare, not allocation or 
startup.

I see no reason to burden the machine driver with all these steps. It's 
not because QCOM needs this transition that everyone does.

As discussed earlier, QCOM cannot use this functionality because the 
prepare/enable and disable/deprepare are done in the hw_params and 
hw_free respectively. This was never the intended use, but Intel let it 
happen so I'd like you to return the favor. This change has no impact 
for QCOM and simplifies the Intel solution, so why would you object?

Seriously, your replies on all Intel contributions make me wonder if 
this is the QCOM/Linaro SoundWire subsystem, or if we are going to find 
common ground to deal with vastly different underlying architectures?