linux-kernel - Re: [RFC PATCH v2 12/22] sound: usb: card: Introduce USB SND platform op callbacks

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]

Date:   Mon, 27 Feb 2023 18:59:32 -0800
From:   Wesley Cheng <quic_wcheng@...cinc.com>
To:     Greg KH <gregkh@...uxfoundation.org>
CC:     <srinivas.kandagatla@...aro.org>, <mathias.nyman@...el.com>,
        <perex@...ex.cz>, <lgirdwood@...il.com>, <andersson@...nel.org>,
        <krzysztof.kozlowski+dt@...aro.org>, <Thinh.Nguyen@...opsys.com>,
        <broonie@...nel.org>, <bgoswami@...cinc.com>, <tiwai@...e.com>,
        <robh+dt@...nel.org>, <agross@...nel.org>,
        <linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
        <alsa-devel@...a-project.org>, <devicetree@...r.kernel.org>,
        <linux-usb@...r.kernel.org>, <quic_jackp@...cinc.com>,
        <quic_plai@...cinc.com>
Subject: Re: [RFC PATCH v2 12/22] sound: usb: card: Introduce USB SND platform
 op callbacks

Hi Greg,

On 2/10/2023 2:49 PM, Wesley Cheng wrote:
> Hi Greg,
> 
> On 1/28/2023 5:28 AM, Greg KH wrote:
>> On Wed, Jan 25, 2023 at 07:14:14PM -0800, Wesley Cheng wrote:
>>> Allow for different platforms to be notified on USB SND 
>>> connect/disconnect
>>> seqeunces.  This allows for platform USB SND modules to properly 
>>> initialize
>>> and populate internal structures with references to the USB SND chip
>>> device.
>>>
>>> Signed-off-by: Wesley Cheng <quic_wcheng@...cinc.com>
>>> ---
>>>   sound/usb/card.c | 28 ++++++++++++++++++++++++++++
>>>   sound/usb/card.h | 20 ++++++++++++++++++++
>>>   2 files changed, 48 insertions(+)
>>>
>>> diff --git a/sound/usb/card.c b/sound/usb/card.c
>>> index 26268ffb8274..803230343c16 100644
>>> --- a/sound/usb/card.c
>>> +++ b/sound/usb/card.c
>>> @@ -117,6 +117,24 @@ MODULE_PARM_DESC(skip_validation, "Skip unit 
>>> descriptor validation (default: no)
>>>   static DEFINE_MUTEX(register_mutex);
>>>   static struct snd_usb_audio *usb_chip[SNDRV_CARDS];
>>>   static struct usb_driver usb_audio_driver;
>>> +static struct snd_usb_platform_ops *platform_ops;
>>
>> You can not have a single "platform_ops" pointer, this HAS to be
>> per-bus.
>>
> 
> Agreed.
> 

I looked at seeing how we could implement this at a per bus level, but 
the USB class driver model doesn't exactly have a good framework for 
supporting this.  Reason being is because, at the time of the USB SND 
class driver initialization, there is a big chance that there isn't a 
USB bus registered in the system, so the point of adding the operations 
is not clear.  However, we need to ensure that we've added the 
platform/driver operations before any USB SND devices are detected.

To add to the above, in case of OTG/DRD (dual role) designs, the USB 
HCD/bus isn't created until we move into the host role.  At that time, 
using DWC3 as an example, we will create the XHCI platform device, and 
probe the USB HCD, where a USB bus is created.

In general, we currently think this USB offload driver should co-exist 
with the USB SND class driver, which handles all devices connected 
across every bus.  We can add a check to the platform connect routine to 
ensure that there is a reference to the USB backend.  If so, then that 
particular USB bus/sysdev can be supported by the audio DSP.  That way, 
we do not falsely populate USB SND cards which are present on another 
USB bus/controller.

Thanks
Wesley Cheng