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
