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: <2024120523-rifling-skipping-234c@gregkh>
Date: Thu, 5 Dec 2024 07:50:24 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Wesley Cheng <quic_wcheng@...cinc.com>
Cc: Cezary Rojewski <cezary.rojewski@...el.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@...ux.dev>,
	Takashi Iwai <tiwai@...e.de>, srinivas.kandagatla@...aro.org,
	mathias.nyman@...el.com, perex@...ex.cz, conor+dt@...nel.org,
	dmitry.torokhov@...il.com, corbet@....net, broonie@...nel.org,
	lgirdwood@...il.com, krzk+dt@...nel.org, Thinh.Nguyen@...opsys.com,
	tiwai@...e.com, robh@...nel.org, linux-kernel@...r.kernel.org,
	devicetree@...r.kernel.org, linux-sound@...r.kernel.org,
	linux-usb@...r.kernel.org, linux-input@...r.kernel.org,
	linux-arm-msm@...r.kernel.org, linux-doc@...r.kernel.org
Subject: Re: [PATCH v30 00/30] Introduce QC USB SND audio offloading support

On Wed, Dec 04, 2024 at 05:15:02PM -0800, Wesley Cheng wrote:
> 
> On 12/4/2024 1:14 PM, Cezary Rojewski wrote:
> > On 2024-12-03 5:57 PM, Greg KH wrote:
> >> On Tue, Dec 03, 2024 at 05:17:48PM +0100, Cezary Rojewski wrote:
> >>> On 2024-12-01 4:14 AM, Pierre-Louis Bossart wrote:
> >>>> Sorry to chime in late, I only look at email occasionally.
> >
> > ...
> >
> >>>>> I believe Amadeusz was still against having the two card design, and wants the routing to automatically happen when playback happens on the sound card created by the USB SND layer.  However, even with that kind of implementation, the major pieces brought in by this series should still be relevant, ie soc-usb and the vendor offload driver.  The only thing that would really change is adding a path from the USB SND PCM ops to interact with the ASoC entities.  Complexity-wise, this would obviously have a good amount of changes to the USB SND/ASoC core drivers.  Some things I can think of that we'd need to introduce:
> >>>>
> >>>> The notion of two cards was agreed inside Intel as far back as 2018, when Rakesh first looked at USB offload.
> >>>
> >>>
> >>> Well, I believe a lot has changed since then, not sure if USB Audio Offload
> >>> (UAOL) was even stable on the Windows solution back then. Obviously we want
> >>> to incorporate what we have learned during all that time into our solution
> >>> before it lands on upstream.
> >>
> >> Great, can you help review this series please?
> >
> > Hi Greg,
> >
> > This series is large and I'd suggest to split it up, what I touched on in my recent reply [1]. Please correct me if I'm wrong, but you mostly care about drivers/usb/* part. If so, the existing set could be split into USB-changes series, ALSA/ASoC-framework series and a third, holding bulk of QCOM-specific patches. Me and my team care mostly about the sound/* part and we don't hold much expertise in USB. I believe Mathias covers this part well though.
> >
> 
> I'm fine to split this into 3 different series if that helps with the reviews.  I was always under the impression that when we upstream things, we need to have an end to end use case within the same series, so that folks get the full picture.  I've gotten feedback where people were confused they couldn't find/follow the code flow, albeit those series were much much smaller.  If Greg is ok with it, I can split it up and have a link reference to the other series.

Yes, a full patch series is best as adding infrastructure in a
stand-alone series that no one uses isn't going to work well.

> I was able to reorganize the list a bit to what you recommended.  So the current layout is xHCI changes first, followed by the USB ALSA and ASoC changes, and lastly the QCOM/vendor specific modifications.

That sounds reasonable, hopefully it lets others review it easier.

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ