linux-kernel - Re: [PATCH v2 8/8] ASoC: qcom: apq8096: add kcontrols to set PCM rate

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: <f88d21773f47f5a543a17ad07d66f9b7@serbinski.com>
Date:   Mon, 10 Feb 2020 15:00:55 -0500
From:   Adam Serbinski <adam@...binski.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Srini Kandagatla <srinivas.kandagatla@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Andy Gross <agross@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Liam Girdwood <lgirdwood@...il.com>,
        Patrick Lai <plai@...eaurora.org>,
        Banajit Goswami <bgoswami@...eaurora.org>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>, alsa-devel@...a-project.org,
        linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 8/8] ASoC: qcom: apq8096: add kcontrols to set PCM rate

On 2020-02-10 13:26, Mark Brown wrote:
> On Mon, Feb 10, 2020 at 10:45:16AM -0500, Adam Serbinski wrote:
>> On 2020-02-10 08:36, Mark Brown wrote:
> 
>> > This would seem like an excellent thing to put in the driver for the
>> > baseband or bluetooth.
> 
>> The value that must be set to this control is not available to the 
>> bluetooth
>> driver. It originates from the bluetooth stack in userspace, typically
>> either blueZ or fluoride, as a result of a negotiation between the two
>> devices participating in the HFP call.
> 
> To repeat my comment on another patch in the series there should still
> be some representation of the DAI for this device in the kernel.

Respectfully, I'm not sure I understand what it is that you are 
suggesting.

Is it your intention to suggest that instead of adding controls to the 
machine driver, I should instead write a codec driver to contain those 
controls?

Or is it your intention to suggest that something within the kernel is 
already aware of the rate to be set, and it is that which should set the 
rate rather than a control?