linux-kernel - Re: [RFC PATCH 1/2] soundwire: add support for static port mapping

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] [day] [month] [year] [list]

Message-ID: <caaca3cb-77b2-7137-3319-b0af887f563e@linaro.org>
Date:   Mon, 22 Feb 2021 13:40:52 +0000
From:   Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To:     Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>,
        Vinod Koul <vkoul@...nel.org>
Cc:     alsa-devel@...a-project.org, gregkh@...uxfoundation.org,
        linux-kernel@...r.kernel.org, sanyog.r.kale@...el.com,
        yung-chuan.liao@...ux.intel.com
Subject: Re: [RFC PATCH 1/2] soundwire: add support for static port mapping



On 19/02/2021 19:52, Pierre-Louis Bossart wrote:
> 
> 
>>>>> It seems you are in a different solution-space, where the codec driver
>>>>> needs to notify the master of which ports it needs to use?
>>>> Correct! As Codec is the place where we have mixer controls ant it can
>>>> clearly tell which master ports should be used for that particular
>>>> configuration.
>>> And that should come from firmware (DT etc) and driver should pass on
>>> this info
>>
>> Are you okay with the patch as it is, provided this information is 
>> populated from DT?
> 
> I am fine with the direction at a high-level. The premise for SoundWire 
> is that the bus is simple enough that it can be used in different 
> contexts and architectures, so if Qualcomm need something that differs 
> from what is needed for Intel we are really not in a position to object.
> 
> That said, I could use more explanations on how the mapping is defined: 
> I don't think we have the same definition of 'static port mapping'. For 
> SDCA integration, we plan to have a static mapping in some sort of ACPI 
> table that will describe which port on the Manager side is connected to 
> which ports on Peripheral XYZ. That's static as in set in stone in 
> platform firmware. I understand the reference to DT settings as the same 
> idea.

Yes, we are talking about the same static mapping here!

> 
> But if the mapping depends on the value of mixer controls as you 
> describe it, then it's not static and defined by DT settings, but 
> run-time defined.
I think there is some miss understanding here, the mapping is static but 
the port selection is based on the mixer controls!

> 
> Also maybe we'd want to have a more opaque way of passing the 
> information, maybe with a stream private data or a callback, instead of 
> hard-coding fields that are only used by Qualcomm.

Let me try the callback way and see how it will endup!

thanks,
srini

> 
>