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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y/X5Po7Ieao3svBm@kroah.com>
Date:   Wed, 22 Feb 2023 12:15:10 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Святослав Ригель 
        <clamor95@...il.com>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        Jaroslav Kysela <perex@...ex.cz>,
        Takashi Iwai <tiwai@...e.com>,
        Maxim Schwalm <maxim.schwalm@...il.com>,
        Dmitry Osipenko <digetx@...il.com>, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, alsa-devel@...a-project.org,
        linux-tegra@...r.kernel.org, linux-staging@...ts.linux.dev
Subject: Re: [PATCH v1 09/10] staging: dsp: add support for Fortemedia FM34NE
 DSP

On Wed, Feb 22, 2023 at 11:39:59AM +0200, Святослав Ригель wrote:
> 
> 
> 22 лютого 2023 р. 11:21:02 GMT+02:00, Greg Kroah-Hartman <gregkh@...uxfoundation.org> написав(-ла):
> >On Wed, Feb 22, 2023 at 10:19:47AM +0200, Svyatoslav Ryhel wrote:
> >> вт, 21 лют. 2023 р. о 21:27 Greg Kroah-Hartman
> >> <gregkh@...uxfoundation.org> пише:
> >> >
> >> > On Tue, Feb 21, 2023 at 08:32:10PM +0200, Svyatoslav Ryhel wrote:
> >> > > FM34NE is digital sound processing chip used for active
> >> > > noise suppression mainly on ASUS Transformers.
> >> > >
> >> > > Signed-off-by: Svyatoslav Ryhel <clamor95@...il.com>
> >> > > ---
> >> > >  drivers/staging/Kconfig          |   2 +
> >> > >  drivers/staging/Makefile         |   1 +
> >> > >  drivers/staging/dsp/Kconfig      |   7 +
> >> > >  drivers/staging/dsp/Makefile     |   2 +
> >> > >  drivers/staging/dsp/dsp-fm34ne.c | 364 +++++++++++++
> >> > >  drivers/staging/dsp/dsp-fm34ne.h | 845 +++++++++++++++++++++++++++++++
> >> > >  6 files changed, 1221 insertions(+)
> >> > >  create mode 100644 drivers/staging/dsp/Kconfig
> >> > >  create mode 100644 drivers/staging/dsp/Makefile
> >> > >  create mode 100644 drivers/staging/dsp/dsp-fm34ne.c
> >> > >  create mode 100644 drivers/staging/dsp/dsp-fm34ne.h
> >> >
> >> >
> >> > Sorry, but why is this going into drivers/staging/ at all?  What is
> >> > needed to be done to get this out of staging?  Why not do that work
> >> > right now?  At the least, we need a TODO file in the directory that
> >> > lists what needs to be done and who is responsible for it.
> >> 
> >> Because this driver sets up fm34 and switches it to bypass mode allowing
> >> sound to work on the device. There is no dsp framework in kernel which could
> >> be called to operate dsp from the actual sound codec. (If there is, I
> >> would be glad
> >> if you show me). Fm34 must be active only on DMIC use, all other cases require
> >> it to be in bypass.
> >
> >That does not explain at all why this needs to go into drivers/staging/
> >and not the normal portion of the kernel.  Why this specific location?
> >What is wrong with it that requires it to go here?
> 
> It is not fully functional and does not perform its main function
> (noise cancellation) because it has to be called only for DMIC. Same
> time it is essential to be set so that audio could work on device.

But why does that mean it should go to drivers/staging/?  That's not
what staging is for (broken code).

> Once there is such a framework in kernel, which allows to control dsp
> from, I assume, asoc machine driver, this driver can be moved wherever
> it should be. Currently I can not tell where it should be since I
> haven't seen dsp drivers like this in kernel.

Then work to create that, don't dump stuff in drivers/staging/ for no
valid reason.

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ