Received-SPF: pass (google.com: domain of linux-wireless+bounces-5699-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <ff3b97d0-118c-42b3-be0b-47cfcf06ab74@gmail.com>
Date: Sun, 31 Mar 2024 21:48:39 +0300
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v3 11/12] wifi: rtlwifi: Add rtl8192du/sw.{c,h}
To: Ping-Ke Shih <pkshih@realtek.com>, "kvalo@kernel.org" <kvalo@kernel.org>
Cc: "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
 "Larry.Finger@lwfinger.net" <Larry.Finger@lwfinger.net>,
 "s.l-h@gmx.de" <s.l-h@gmx.de>, "chewitt@libreelec.tv" <chewitt@libreelec.tv>
References: <7f4b3309-1580-48f3-9426-29f1eb4052fd@gmail.com>
 <2eb79c8c-cf2c-4696-b958-e8d961628e17@gmail.com>
 <f86a40493745a53ff73083f87b3e8fae215eac77.camel@realtek.com>
 <66565618-3638-47e5-afe5-3530214da0c9@gmail.com> <87ttkrzf1m.fsf@kernel.org>
 <5696990a-4450-4d92-bbda-1d9ca3a9a619@gmail.com>
 <4672072ef782ae1200886a190c740e0f3ccec2c8.camel@realtek.com>
 <7873dee1-46a8-48a7-9059-bc300ac98c23@gmail.com>
 <1f8ebed6a04a4fbebf33b0a3edc2f50b@realtek.com>
Content-Language: en-US
From: Bitterblue Smith <rtl8821cerfe2@gmail.com>
In-Reply-To: <1f8ebed6a04a4fbebf33b0a3edc2f50b@realtek.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 29/03/2024 02:34, Ping-Ke Shih wrote:
> 
>> I got another idea: if we have a guarantee that the two USB
>> interfaces are probed one at a time, then we can move the global
>> things into struct rtl_priv. The first probe call will allocate
>> the arrays and initialise the mutexes. The second probe call
>> will obtain those from the first struct rtl_priv:
>>
>> int rtl_usb_probe(struct usb_interface *intf, ...) {
>>         udev = interface_to_usbdev(intf);
>>         struct ieee80211_hw *first_hw = usb_get_intfdata(udev->actconfig->interface[0]);
>>         struct rtl_priv *first_rtlpriv = rtl_priv(first_hw);
>>
> 
> Could it have racing when obtaining mutexes from second probe? 
> Should we need a lock to ensure the sequence? 
> 
> When driver is going to down, how can mutexes get free safely?
> 
> It seems like we still need another global lock to ensure that. 
> 

I asked linux-usb and they said the two interfaces are probed
and disconnected one at a time, so it should be fine without
another mutex:

https://lore.kernel.org/linux-usb/2024032907-smokeless-imperial-f3f9@gregkh/