All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To: Phillip Potter <phil@philpotter.co.uk>
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"open list:STAGING SUBSYSTEM" <linux-staging@lists.linux.dev>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Pavel Skripkin <paskripkin@gmail.com>
Subject: Re: [PATCH 1/2] staging: r8188eu: Use usb_control_msg_recv/send() in usbctrl_vendorreq()
Date: Tue, 24 Aug 2021 03:38:03 +0200	[thread overview]
Message-ID: <1815496.OexNakQ7IY@localhost.localdomain> (raw)
In-Reply-To: <15825589.4VbMHeJK9p@localhost.localdomain>

On Tuesday, August 24, 2021 2:31:11 AM CEST Fabio M. De Francesco wrote:
> On Tuesday, August 24, 2021 2:08:49 AM CEST Phillip Potter wrote:
> > On Mon, 23 Aug 2021 at 23:38, Fabio M. De Francesco
> > <fmdefrancesco@gmail.com> wrote:
> > >
> > > Replace usb_control_msg() with the new usb_control_msg_recv() and
> > > usb_control_msg_send() API of USB Core in usbctrl_vendorreq().
> > >
> > > Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > Signed-off-by: Fabio M. De Francesco <fmdefrancesco@gmail.com>
> > > ---
> > >
> > > Thanks to Pavel Skripkin <paskripkin@gmail.com> for his review of the
> > > RFC patch.
> > >
> > > drivers/staging/r8188eu/hal/usb_ops_linux.c | 25 ++++++++++-----------
> > > 1 file changed, 12 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/drivers/staging/r8188eu/hal/usb_ops_linux.c b/drivers/staging/r8188eu/hal/usb_ops_linux.c
> > > index a93d5cfe4635..6f51660b967a 100644
> > > --- a/drivers/staging/r8188eu/hal/usb_ops_linux.c
> > > +++ b/drivers/staging/r8188eu/hal/usb_ops_linux.c
> > > @@ -15,9 +15,8 @@ static int usbctrl_vendorreq(struct intf_hdl *pintfhdl, u16 value, void *pdata,
> > >         struct adapter  *adapt = pintfhdl->padapter;
> > >         struct dvobj_priv  *dvobjpriv = adapter_to_dvobj(adapt);
> > >         struct usb_device *udev = dvobjpriv->pusbdev;
> > > -       unsigned int pipe;
> > > +       u8 pipe;
> > >         int status = 0;
> > > -       u8 reqtype;
> > >         u8 *pIo_buf;
> > >         int vendorreq_times = 0;
> > >
> > > @@ -44,22 +43,22 @@ static int usbctrl_vendorreq(struct intf_hdl *pintfhdl, u16 value, void *pdata,
> > >         }
> > >
> > >         while (++vendorreq_times <= MAX_USBCTRL_VENDORREQ_TIMES) {
> > > -               memset(pIo_buf, 0, len);
> > > -
> > >                 if (requesttype == 0x01) {
> > > -                       pipe = usb_rcvctrlpipe(udev, 0);/* read_in */
> > > -                       reqtype =  REALTEK_USB_VENQT_READ;
> > > +                       status = usb_control_msg_recv(udev, pipe, REALTEK_USB_VENQT_CMD_REQ,
> > > +                                                     REALTEK_USB_VENQT_READ, value,
> > > +                                                     REALTEK_USB_VENQT_CMD_IDX,
> > > +                                                     pIo_buf, len, RTW_USB_CONTROL_MSG_TIMEOUT,
> > > +                                                     GFP_KERNEL);
> > >                 } else {
> > > -                       pipe = usb_sndctrlpipe(udev, 0);/* write_out */
> > > -                       reqtype =  REALTEK_USB_VENQT_WRITE;
> > >                         memcpy(pIo_buf, pdata, len);
> > > +                       status = usb_control_msg_send(udev, pipe, REALTEK_USB_VENQT_CMD_REQ,
> > > +                                                     REALTEK_USB_VENQT_WRITE, value,
> > > +                                                     REALTEK_USB_VENQT_CMD_IDX,
> > > +                                                     pIo_buf, len, RTW_USB_CONTROL_MSG_TIMEOUT,
> > > +                                                     GFP_KERNEL);
> > >                 }
> > >
> > > -               status = usb_control_msg(udev, pipe, REALTEK_USB_VENQT_CMD_REQ,
> > > -                                        reqtype, value, REALTEK_USB_VENQT_CMD_IDX,
> > > -                                        pIo_buf, len, RTW_USB_CONTROL_MSG_TIMEOUT);
> > > -
> > > -               if (status == len) {   /*  Success this control transfer. */
> > > +               if (!status) {   /*  Success this control transfer. */
> > >                         rtw_reset_continual_urb_error(dvobjpriv);
> > >                         if (requesttype == 0x01)
> > >                                 memcpy(pdata, pIo_buf,  len);
> > > --
> > > 2.32.0
> > >
> > 
> > Dear Fabio,
> > 
> > Thanks for the patch. Sorry, but for some reason with my N10-Nano I
> > can't get a connection at all with this patch applied - it just won't
> > associate with my network. Interface shows up and no OOPS in log, but
> > just disassociates/no IP address/interface down etc. so perhaps
> > semantics differ slightly here somehow? Tried two separate
> > rollbacks/builds/runs just to make sure I wasn't losing my mind :-)
> > 
> > Regards,
> > Phil
> > 
> Dear Philip,
> 
> Thanks for testing. As I wrote in my RFC, I strongly suspected that I was
> not able to correctly understand the semantics of the new API. I'll try to
> read the code anew and try to understand what is wrong here.
> 
> However, I also think that I won't be able to figure it out. Maybe that I 
> have to wait for Greg to give me some hint about what are the errors in
> using usb_control_msg_send/recv() the way I did.
> 
> Anyway, thanks a lot for the time you spent testing.
> 
> Regards,
> 
> Fabio
> 
Dear Philip,

I think that I've inadvertently switched the order by which usb_control_msg_send()
and memcpy() are called. I'm very sorry for not doing my tests, but (as I had said 
before) at the moment I don't have my device with me.

I'm about to send a v2 series.

Thanks very much for testing on my behalf.

Regards,

Fabio




  reply	other threads:[~2021-08-24  1:38 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-23 22:37 [PATCH 0/2] staging: r8188eu: Use new usb_control_msg_recv/send() Fabio M. De Francesco
2021-08-23 22:37 ` [PATCH 1/2] staging: r8188eu: Use usb_control_msg_recv/send() in usbctrl_vendorreq() Fabio M. De Francesco
2021-08-24  0:08   ` Phillip Potter
2021-08-24  0:31     ` Fabio M. De Francesco
2021-08-24  1:38       ` Fabio M. De Francesco [this message]
2021-08-24  2:01         ` Fabio M. De Francesco
2021-08-24  5:44           ` Christophe JAILLET
2021-08-24 10:38             ` Fabio M. De Francesco
2021-08-24 17:03               ` Christophe JAILLET
2021-08-24 21:59         ` Phillip Potter
2021-08-24  8:13   ` Pavel Skripkin
2021-08-24  8:53     ` Fabio M. De Francesco
2021-08-24 11:07       ` Pavel Skripkin
2021-08-24 12:01         ` Fabio M. De Francesco
2021-08-24 12:09           ` Pavel Skripkin
2021-08-24 14:55             ` Fabio M. De Francesco
2021-08-23 22:37 ` [PATCH 2/2] staging: r8188eu: Make some clean-ups " Fabio M. De Francesco
2021-08-24  0:10   ` Phillip Potter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1815496.OexNakQ7IY@localhost.localdomain \
    --to=fmdefrancesco@gmail.com \
    --cc=Larry.Finger@lwfinger.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-staging@lists.linux.dev \
    --cc=paskripkin@gmail.com \
    --cc=phil@philpotter.co.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.