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

[Pavel Skripkin]

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@xxxxxxxxx>
> > > ---
> > >   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