Re: [PATCH 2/2] staging: r8188eu: Make some clean-ups in usbctrl_vendorreq()

[Pavel Skripkin <paskripkin@gmail.com>]

On 8/24/21 6:15 PM, Fabio M. De Francesco wrote:
> On Tuesday, August 24, 2021 4:39:51 PM CEST Pavel Skripkin wrote:
>> On 8/24/21 5:28 PM, Fabio M. De Francesco wrote:
>> > After replacing usb_control_msg() with the new usb_control_msg_recv() and
>> > usb_control_msg_send() API of USB Core, remove camelcase from the pIo_buf
>> > variable that is passed as argument to the new API and remove the initial
>> > 'p' (that probably stands for "pointer") from the same pIo_buf and from
>> > the pintfhdl and pdata arguments of usbctrl_vendorreq().
>> > 
>> > Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
>> > ---
>> >   drivers/staging/r8188eu/hal/usb_ops_linux.c | 22 ++++++++++-----------
>> >   1 file changed, 11 insertions(+), 11 deletions(-)
>> > 
>> 
>> I cannot apply this one on top of the first one:
>> 
>> error: patch failed: drivers/staging/r8188eu/hal/usb_ops_linux.c:33
>> error: drivers/staging/r8188eu/hal/usb_ops_linux.c: patch does not apply
>> 
>> With regards,
>> Pavel Skripkin
> 

I found the problem:

>  	mutex_lock(&dvobjpriv->usb_vendor_req_mutex);
>  
>  	/*  Acquire IO memory for vendorreq */
> -	pIo_buf = dvobjpriv->usb_vendor_req_buf;
> +	io_buf = dvobjpriv->usb_vendor_req_buf;


I don't know from where mutex_lock() comes from. In staging-next I have

_enter_critical_mutex(&dvobjpriv->usb_vendor_req_mutex, NULL);

instead of

mutex_lock(&dvobjpriv->usb_vendor_req_mutex);




With regards,
Pavel Skripkin