--- Begin Message ---
- To: Wesley Cheng <quic_wcheng@xxxxxxxxxxx>, srinivas.kandagatla@xxxxxxxxxx, mathias.nyman@xxxxxxxxx, perex@xxxxxxxx, broonie@xxxxxxxxxx, lgirdwood@xxxxxxxxx, krzysztof.kozlowski+dt@xxxxxxxxxx, agross@xxxxxxxxxx, Thinh.Nguyen@xxxxxxxxxxxx, bgoswami@xxxxxxxxxxx, andersson@xxxxxxxxxx, robh+dt@xxxxxxxxxx, gregkh@xxxxxxxxxxxxxxxxxxx, tiwai@xxxxxxxx
- Subject: Re: [PATCH v3 09/28] sound: usb: card: Introduce USB SND platform op callbacks
- From: Oliver Neukum <oneukum@xxxxxxxx>
- Date: Thu, 9 Mar 2023 12:16:59 +0100
- Cc: linux-kernel@xxxxxxxxxxxxxxx, linux-arm-msm@xxxxxxxxxxxxxxx, alsa-devel@xxxxxxxxxxxxxxxx, devicetree@xxxxxxxxxxxxxxx, linux-usb@xxxxxxxxxxxxxxx, quic_jackp@xxxxxxxxxxx, quic_plai@xxxxxxxxxxx
- In-reply-to: <20230308235751.495-10-quic_wcheng@quicinc.com>
- References: <20230308235751.495-1-quic_wcheng@quicinc.com> <20230308235751.495-10-quic_wcheng@quicinc.com>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0
On 09.03.23 00:57, 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@xxxxxxxxxxx> --- sound/usb/card.c | 36 ++++++++++++++++++++++++++++++++++++ sound/usb/card.h | 20 ++++++++++++++++++++ 2 files changed, 56 insertions(+) diff --git a/sound/usb/card.c b/sound/usb/card.c index 26268ffb8274..9bcbaa0c0a55 100644 --- a/sound/usb/card.c +++ b/sound/usb/card.c @@ -117,6 +117,30 @@ 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; + +int snd_usb_register_platform_ops(struct snd_usb_platform_ops *ops) +{ + if (platform_ops) + return -EEXIST; + + mutex_lock(®ister_mutex); + platform_ops = ops; + mutex_unlock(®ister_mutex);This looks _highly_ suspicious. Why does the assignment need a lock, but the check does not? Regards Oliver
--- End Message ---
