[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ad9e375e-fe4f-b4bd-aebd-26f5f0a6317b@linux.intel.com>
Date: Thu, 26 Jan 2023 10:22:56 -0600
From: Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To: Wesley Cheng <quic_wcheng@...cinc.com>,
srinivas.kandagatla@...aro.org, mathias.nyman@...el.com,
perex@...ex.cz, lgirdwood@...il.com, andersson@...nel.org,
krzysztof.kozlowski+dt@...aro.org, gregkh@...uxfoundation.org,
Thinh.Nguyen@...opsys.com, broonie@...nel.org,
bgoswami@...cinc.com, tiwai@...e.com, robh+dt@...nel.org,
agross@...nel.org
Cc: devicetree@...r.kernel.org, alsa-devel@...a-project.org,
linux-arm-msm@...r.kernel.org, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org, quic_jackp@...cinc.com,
quic_plai@...cinc.com
Subject: Re: [RFC PATCH v2 00/22] Introduce QC USB SND audio offloading
support
This version has lots of improvements, but I am concerned
about hard-coded ops/callbacks that look racy and assume dependencies
between driver probes. How does this work if the probe is delayed on one
side for some reason? What happens is a driver is 'blacklisted' and
manually added later? The code has to deal with this sort of known unknowns.
I also still have a bit of heartburn with the notion that there would be
a completely separate card with all the control for volume/mute/etc
having to be duplicated.
It's still a lot of good work so thanks for sharing and pushing for this
capability.
Powered by blists - more mailing lists