linux-kernel - Re: [PATCH] ASoC: mediatek: mt8188: add constraints for PCM

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: <fe35c2597040e84ac842696f72a5b3e5cd0f98ad.camel@mediatek.com>
Date:   Tue, 4 Jul 2023 02:01:28 +0000
From:   Trevor Wu (吳文良) <Trevor.Wu@...iatek.com>
To:     "angelogioacchino.delregno@...labora.com" 
        <angelogioacchino.delregno@...labora.com>,
        "broonie@...nel.org" <broonie@...nel.org>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "tiwai@...e.com" <tiwai@...e.com>,
        "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        "perex@...ex.cz" <perex@...ex.cz>,
        "alsa-devel@...a-project.org" <alsa-devel@...a-project.org>
Subject: Re: [PATCH] ASoC: mediatek: mt8188: add constraints for PCM

On Mon, 2023-07-03 at 14:27 +0200, AngeloGioacchino Del Regno wrote:
>  Il 30/06/23 13:00, Mark Brown ha scritto:
> > On Fri, Jun 30, 2023 at 05:29:23AM +0000, Trevor Wu (吳文良) wrote:
> >> On Thu, 2023-06-29 at 16:06 +0100, Mark Brown wrote:
> > 
> >>> This commit message isn't entirely clear.  The effect of the
> commit
> >>> is
> >>> to restrict the configurations supported when using a nau8825 but
> >>> it's
> >>> not clear what a nau8825 has to do with this or why we're doing
> this
> >>> in
> >>> general.  What exactly do you mean when saying that "only a
> limited
> >>> number of parameters are necessary" and what makes this the case?
> > 
> >> For instance, some userspace frameworks only support specific
> sampling
> >> rates such as 48kHz on Chromebook, making other parameters
> unnecessary.
> >> By restricting the configuration, unexpected usage can be
> prevented and
> >> the alsa_conformance_test process which checks all parameters
> provided
> >> by an ALSA driver can be sped up.
> > 
> > That's a userspace policy decision, we shouldn't be enforcing this
> in
> > the kernel - even for Chromebooks people can install other OSs on
> them
> > which may make different decisions, and it's always possible that
> the
> > ChromeOS people might change their mind later.  If they're only
> > interested in testing 48kHz and it's slowing things down
> unreasonably
> > to test more then they should just only test 48kHz rather than
> changing
> > the driver to work around it.
> > 
> >> Would it be more beneficial to establish the criteria as a general
> rule
> >> for this machine driver, while limiting the use of the machine
> driver
> >> solely to the Chromebook project? Or do you just suggest that I
> add
> >> more details in the commit messages?
> > 
> > I think we just shouldn't do this, it's policy for ChromeOS rather
> than
> > something that's actually needed.  If we were doing this it would
> need a
> > much clearer commit message and we should be restricting things to
> > Chromebooks only.
> 
> I agree with Mark. Except for me it's not a *should not* but a *shall
> not*.
> 
> Such other configurations are supported by the hardware and it is the
> driver's
> duty to support all of them - otherwise I deem the driver to be
> *incomplete*.
> It's then the userspace's duty to properly use the sound APIs and
> request the
> right sampling rate for specific usecases.
> 
> Chromebooks aren't special at all in this regard.
> 
> 

Thanks for your suggestion.
After the internal discussion, we decided to drop the patch.
On the other hand, I will send another patch using dpcm_merged_xxx to
report the actual capability of hardware.

Thanks,
Trevor