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>,
	Christophe JAILLET <christophe.jaillet@wanadoo.fr>
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 12:38:20 +0200	[thread overview]
Message-ID: <1751314.Y7PUP2lcel@localhost.localdomain> (raw)
In-Reply-To: <50d40020-5b0e-4bb9-357b-3640a0f9e8c6@wanadoo.fr>

On Tuesday, August 24, 2021 7:44:40 AM CEST Christophe JAILLET wrote:
> Le 24/08/2021 à 04:01, Fabio M. De Francesco a écrit :
> > On Tuesday, August 24, 2021 3:38:03 AM CEST Fabio M. De Francesco wrote:
> >> 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.
> > 
> > No, I did not switch them. There must be something else...
> > Sorry for the noise.
> > 
> > Fabio
> > 
> 
> Hi,
> 
> 'usb_control_msg_recv()' looks like:
> 
> int usb_control_msg_recv(struct usb_device *dev, __u8 endpoint, ...)
> {
> 	unsigned int pipe = usb_rcvctrlpipe(dev, endpoint);
> 	...
> 	ret = usb_control_msg(dev, pipe, ...);
> 
> 
> 'usb_control_msg()' looks like:
> int usb_control_msg(struct usb_device *dev, unsigned int pipe, ...)
> {
> 
> The difference is that one expect an 'endpoint' (and compute the pipe 
> from it), and the other expect a 'pipe'.

Hi Christophe,

Yes, correct. That's why I changed the type of 'pipe' from "unsigned int"
to "u8". I also saw that usb_control_msg_recv/send take care of calling 
usb_rcvctrpipe() and usb_sndctrlpipe(); so, in my patch I deleted 
those calls.

Not related to my patch... why Linux has u8 and __u8? What are the  
different use cases they are meant for? 

> Also, in your code, 'pipe' looks un-initialized.

Oh yes, good catch.  Thanks!

> So, my guess is that you should rename 'pipe' into 'endpoint' (to keep 
> the semantic),
> have "endpoint = 0;" somewhere and pass it to 
> usb_control_msg_{recv|send}.
> Or just remove 'pipe' and pass an explicit 0 directly.

I've just seen that in other drivers the code passes an explicit 0.
So, also according to your suggestion, I'll remove "pipe/endpoint".

> Not sure it is enough, but it looks like a difference between before and 
> after your patch.

Since I cannot see other issues, I'm about to fix the code as said above and
then submit a v2 series.

Your 2c are worth much more than how much you think :)

Thanks very much,

Fabio

> just my 2c,
> CJ
> 





  reply	other threads:[~2021-08-24 10: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
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 [this message]
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=1751314.Y7PUP2lcel@localhost.localdomain \
    --to=fmdefrancesco@gmail.com \
    --cc=Larry.Finger@lwfinger.net \
    --cc=christophe.jaillet@wanadoo.fr \
    --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.