linux-kernel - Re: [PATCH v4 18/32] sound: usb: Introduce QC USB SND offloading support

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: <87msziyhtt.wl-tiwai@suse.de>
Date:   Wed, 26 Jul 2023 14:31:58 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     Wesley Cheng <quic_wcheng@...cinc.com>
Cc:     <agross@...nel.org>, <andersson@...nel.org>, <robh+dt@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <conor+dt@...nel.org>,
        <catalin.marinas@....com>, <will@...nel.org>,
        <mathias.nyman@...el.com>, <gregkh@...uxfoundation.org>,
        <lgirdwood@...il.com>, <broonie@...nel.org>, <perex@...ex.cz>,
        <tiwai@...e.com>, <srinivas.kandagatla@...aro.org>,
        <bgoswami@...cinc.com>, <Thinh.Nguyen@...opsys.com>,
        <linux-arm-msm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-usb@...r.kernel.org>, <alsa-devel@...a-project.org>,
        <quic_jackp@...cinc.com>, <pierre-louis.bossart@...ux.intel.com>,
        <oneukum@...e.com>, <albertccwang@...gle.com>,
        <o-takashi@...amocchi.jp>
Subject: Re: [PATCH v4 18/32] sound: usb: Introduce QC USB SND offloading support

On Wed, 26 Jul 2023 00:59:57 +0200,
Wesley Cheng wrote:
> 
> >> +static int enable_audio_stream(struct snd_usb_substream *subs,
> >> +				snd_pcm_format_t pcm_format,
> >> +				unsigned int channels, unsigned int cur_rate,
> >> +				int datainterval)
> >> +{
> > 
> > ... this implementation, I wonder whether it'd be better to modify and
> > export  snd_usb_hw_params() snd snd_usb_hw_free() to fit with qcom
> > driver.  Then you can avoid lots of open code.
> > 
> 
> I think the problem is that snd_usb_hw_params assumes that we've
> already done a PCM open on the PCM device created by USB SND.
> However, with the offload path, we don't reference the USB PCM device,
> but the one created by the platform sound card.  Hence, I don't have
> access to the snd_pcm_substream.
> 
> I attempted to derive snd_pcm_substream from snd_usb_substream, but
> since PCM open isn't run, it doesn't provide a valid structure.
> 
> What do you think about adding a wrapper to snd_usb_hw_params?  Have a
> version that will take in snd_usb_substream, and another that is
> registered to hw_params().

Yes, that's what I had in mind, too.

> > In general, if you see a direct use of chip->mutex, it can be often
> > done better in a different form.  The use of an internal lock or such
> > from an external driver is always fragile and error-prone.
> > 
> > Also, the current open-code misses the potential race against the
> > disconnection during the operation.  In snd-usb-audio, it protects
> > with snd_usb_lock_shutdown() and snd_usb_unlock_shutdown() pairs.
> > 
> 
> I agree...I think then the best approach would be something like the
> above, ie:
> 
> int snd_usb_hw_params(struct snd_pcm_substream *substream,
> 			     struct snd_pcm_hw_params *hw_params)
> {
> 	struct snd_usb_substream *subs = substream->runtime->private_data;
> 
> 	snd_usb_ep_attach(subs, hw_params);
> ...
> 
> int snd_usb_ep_attach(...)
> {
> 	//implementation of current code in snd_usb_hw_params()
> }
> EXPORT_SYMBOL(snd_usb_ep_attach);

Yes, exactly something like that ;)


thanks,

Takashi