mbox series

[v3,00/12] drivers: usb: misc: update to use usb_control_msg_{send|recv}() API

Message ID 20210126183403.911653-1-anant.thazhemadam@gmail.com
Headers show
Series drivers: usb: misc: update to use usb_control_msg_{send|recv}() API | expand

Message

Anant Thazhemadam Jan. 26, 2021, 6:33 p.m. UTC
The new usb_control_msg_{send|recv}() API provides an improved way of 
using usb_control_msg(). Using this, short reads/writes are considered
as errors, data can be used off the stack, and the need for the calling
function to create a raw usb pipe is eliminated.
This patch series aims to update existing instances of usb_control_msg() 
in drivers/usb/misc/* to usb_control_msg_{send|recv}() appropriately, and
also update the return value checking mechanisms in place (if any), as
necessary so nothing breaks.

Changes in v3:

  * idmouse, emi26 and emi62 are left unchanged, and are not updated.
    -> since control transfers in idmouse are without a data stage, there's no
       real advantage in using the new helper here.
    -> in emi26, and emi62, FW_LOAD_SIZE = 1048 (> 1024). Thus, if we try to use the
       new helpers, it will result in either build warnings, or memory being allocated.

  * Link to v2:
      https://lore.kernel.org/linux-usb/20201130013103.2580467-1-anant.thazhemadam@gmail.com/T/


Changes in v2:

  * Buffer variables that were previously dynamically allocated are no
    longer dynamically allocated unless they have a variable length
    (since that threw a warning).

  * Link to v1:
        https://lore.kernel.org/linux-usb/20201129160612.1908074-1-anant.thazhemadam@gmail.com/ 


Anant Thazhemadam (12):
  usb: misc: appledisplay: update to use the
    usb_control_msg_{send|recv}() API
  usb: misc: cypress_cy7c63: update to use usb_control_msg_recv()
  usb: misc: cytherm: update to use usb_control_msg_recv()
  usb: misc: ehset: update to use the usb_control_msg_{send|recv}() API
  usb: misc: ezusb: update to use usb_control_msg_send()
  usb: misc: iowarrior: update to use the usb_control_msg_{send|recv}()
    API
  usb: misc: isight_firmware: update to use usb_control_msg_send()
  usb: misc: ldusb: update to use usb_control_msg_send()
  usb: misc: lvstest: update to use the usb_control_msg_{send|recv}()
    API
  usb: misc: trancevibrator: update to use usb_control_msg_send()
  usb: misc: usbsevseg: update to use usb_control_msg_send()
  usb: misc: usbtest: update to use the usb_control_msg_{send|recv}()
    API

 drivers/usb/misc/appledisplay.c    |  46 +++++------
 drivers/usb/misc/cypress_cy7c63.c  |  21 ++---
 drivers/usb/misc/cytherm.c         | 128 ++++++++++-------------------
 drivers/usb/misc/ehset.c           |  76 ++++++++---------
 drivers/usb/misc/ezusb.c           |  16 +---
 drivers/usb/misc/iowarrior.c       |  34 ++++----
 drivers/usb/misc/isight_firmware.c |  30 +++----
 drivers/usb/misc/ldusb.c           |   8 +-
 drivers/usb/misc/lvstest.c         |  38 ++++-----
 drivers/usb/misc/trancevibrator.c  |   4 +-
 drivers/usb/misc/usbsevseg.c       |  60 ++++----------
 drivers/usb/misc/usbtest.c         |  69 +++++++---------
 12 files changed, 198 insertions(+), 332 deletions(-)

Comments

Johan Hovold Jan. 27, 2021, 1:58 p.m. UTC | #1
On Wed, Jan 27, 2021 at 12:03:52AM +0530, Anant Thazhemadam wrote:
> The newer usb_control_msg_{send|recv}() API are an improvement on the

> existing usb_control_msg() as it ensures that a short read/write is treated


As I mentioned in my comments on v2, a short write has always been
treated as an error so you shouldn't imply that it wasn't here (and in
the other commit messages).

> as an error, data can be used off the stack, and raw usb pipes need not be

> created in the calling functions.

> For this reason, instances of usb_control_msg() have been replaced with

> usb_control_msg_{recv|send}(), and all return value checking

> conditions have also been modified appropriately.

> 

> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>

> ---

>  drivers/usb/misc/appledisplay.c | 46 ++++++++++++++-------------------

>  1 file changed, 19 insertions(+), 27 deletions(-)

> 

> diff --git a/drivers/usb/misc/appledisplay.c b/drivers/usb/misc/appledisplay.c

> index c8098e9b432e..117deb2fdc29 100644

> --- a/drivers/usb/misc/appledisplay.c

> +++ b/drivers/usb/misc/appledisplay.c

> @@ -132,21 +132,17 @@ static int appledisplay_bl_update_status(struct backlight_device *bd)

>  	pdata->msgdata[0] = 0x10;

>  	pdata->msgdata[1] = bd->props.brightness;

>  

> -	retval = usb_control_msg(

> -		pdata->udev,

> -		usb_sndctrlpipe(pdata->udev, 0),

> -		USB_REQ_SET_REPORT,

> -		USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE,

> -		ACD_USB_BRIGHTNESS,

> -		0,

> -		pdata->msgdata, 2,


In this case, the buffer is already DMA-able (and is in fact only used
for this purpose) so this patch introduces an extra allocation and
memcpy for no really good reason.

> -		ACD_USB_TIMEOUT);

> +	retval = usb_control_msg_send(pdata->udev,

> +				      0,

> +				      USB_REQ_SET_REPORT,

> +				      USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE,

> +				      ACD_USB_BRIGHTNESS,

> +				      0,

> +				      pdata->msgdata, 2,

> +				      ACD_USB_TIMEOUT, GFP_KERNEL);

>  	mutex_unlock(&pdata->sysfslock);

>  

> -	if (retval < 0)

> -		return retval;

> -	else

> -		return 0;

> +	return retval;

>  }

>  

>  static int appledisplay_bl_get_brightness(struct backlight_device *bd)

> @@ -155,21 +151,17 @@ static int appledisplay_bl_get_brightness(struct backlight_device *bd)

>  	int retval, brightness;

>  

>  	mutex_lock(&pdata->sysfslock);

> -	retval = usb_control_msg(

> -		pdata->udev,

> -		usb_rcvctrlpipe(pdata->udev, 0),

> -		USB_REQ_GET_REPORT,

> -		USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE,

> -		ACD_USB_BRIGHTNESS,

> -		0,

> -		pdata->msgdata, 2,

> -		ACD_USB_TIMEOUT);

> -	if (retval < 2) {

> -		if (retval >= 0)

> -			retval = -EMSGSIZE;

> -	} else {

> +	retval = usb_control_msg_recv(pdata->udev,

> +				      0,

> +				      USB_REQ_GET_REPORT,

> +				      USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE,

> +				      ACD_USB_BRIGHTNESS,

> +				      0,

> +				      pdata->msgdata, 2,

> +				      ACD_USB_TIMEOUT, GFP_KERNEL);

> +	if (retval == 0)

>  		brightness = pdata->msgdata[1];

> -	}

> +


Same here, this introduces an extra allocation and memcpy and the only
thing you gain is essentially the removal of the two lines for handling
a short read.

>  	mutex_unlock(&pdata->sysfslock);

>  

>  	if (retval < 0)


I'd consider dropping this one as well.

Johan
Johan Hovold Jan. 27, 2021, 2:09 p.m. UTC | #2
On Wed, Jan 27, 2021 at 12:03:53AM +0530, Anant Thazhemadam wrote:
> The newer usb_control_msg_{send|recv}() API are an improvement on the

> existing usb_control_msg() as it ensures that a short read/write is treated


Short write has always been an error (I won't repeat for the remaining
patches).

> as an error, data can be used off the stack, and raw usb pipes need not be

> created in the calling functions.

> For this reason, the instance of usb_control_msg() has been replaced with

> usb_control_msg_recv().

> 

> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>

> ---

>  drivers/usb/misc/cypress_cy7c63.c | 21 +++++----------------

>  1 file changed, 5 insertions(+), 16 deletions(-)

> 

> diff --git a/drivers/usb/misc/cypress_cy7c63.c b/drivers/usb/misc/cypress_cy7c63.c

> index 14faec51d7a5..76a320ef17a7 100644

> --- a/drivers/usb/misc/cypress_cy7c63.c

> +++ b/drivers/usb/misc/cypress_cy7c63.c

> @@ -70,24 +70,15 @@ static int vendor_command(struct cypress *dev, unsigned char request,

>  			  unsigned char address, unsigned char data)

>  {

>  	int retval = 0;

> -	unsigned int pipe;

> -	unsigned char *iobuf;

> -

> -	/* allocate some memory for the i/o buffer*/

> -	iobuf = kzalloc(CYPRESS_MAX_REQSIZE, GFP_KERNEL);

> -	if (!iobuf) {

> -		retval = -ENOMEM;

> -		goto error;

> -	}

> +	u8 iobuf[CYPRESS_MAX_REQSIZE] = {0};

>  

>  	dev_dbg(&dev->udev->dev, "Sending usb_control_msg (data: %d)\n", data);

>  

>  	/* prepare usb control message and send it upstream */

> -	pipe = usb_rcvctrlpipe(dev->udev, 0);

> -	retval = usb_control_msg(dev->udev, pipe, request,

> -				 USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER,

> -				 address, data, iobuf, CYPRESS_MAX_REQSIZE,

> -				 USB_CTRL_GET_TIMEOUT);

> +	retval = usb_control_msg_recv(dev->udev, 0, request,

> +				      USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER,

> +				      address, data, &iobuf, CYPRESS_MAX_REQSIZE,

> +				      USB_CTRL_GET_TIMEOUT, GFP_KERNEL);


Are you sure that the device always returns CYPRESS_MAX_REQSIZE here?
Otherwise, this change may break the driver as it currently only uses
the first two bytes of the received message, and only for some requests.

Note that the driver appears uses the same helper function for
CYPRESS_WRITE_PORT commands, which probably doesn't return 8 bytes in a
reply.

You could possibly add the missing short read check for the
CYPRESS_READ_PORT case, but I'm afraid that the new helper are not a
good fit here either.

>  	/* store returned data (more READs to be added) */

>  	switch (request) {

> @@ -107,8 +98,6 @@ static int vendor_command(struct cypress *dev, unsigned char request,

>  			break;

>  	}

>  

> -	kfree(iobuf);

> -error:

>  	return retval;

>  }


Johan
Anant Thazhemadam Jan. 27, 2021, 2:40 p.m. UTC | #3
On 27/01/21 7:39 pm, Johan Hovold wrote:
> On Wed, Jan 27, 2021 at 12:03:53AM +0530, Anant Thazhemadam wrote:

>> The newer usb_control_msg_{send|recv}() API are an improvement on the

>> existing usb_control_msg() as it ensures that a short read/write is treated

> Short write has always been an error (I won't repeat for the remaining

> patches).

>

>> as an error, data can be used off the stack, and raw usb pipes need not be

>> created in the calling functions.

>> For this reason, the instance of usb_control_msg() has been replaced with

>> usb_control_msg_recv().

>>

>> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>

>> ---

>>  drivers/usb/misc/cypress_cy7c63.c | 21 +++++----------------

>>  1 file changed, 5 insertions(+), 16 deletions(-)

>>

>> diff --git a/drivers/usb/misc/cypress_cy7c63.c b/drivers/usb/misc/cypress_cy7c63.c

>> index 14faec51d7a5..76a320ef17a7 100644

>> --- a/drivers/usb/misc/cypress_cy7c63.c

>> +++ b/drivers/usb/misc/cypress_cy7c63.c

>> @@ -70,24 +70,15 @@ static int vendor_command(struct cypress *dev, unsigned char request,

>>  			  unsigned char address, unsigned char data)

>>  {

>>  	int retval = 0;

>> -	unsigned int pipe;

>> -	unsigned char *iobuf;

>> -

>> -	/* allocate some memory for the i/o buffer*/

>> -	iobuf = kzalloc(CYPRESS_MAX_REQSIZE, GFP_KERNEL);

>> -	if (!iobuf) {

>> -		retval = -ENOMEM;

>> -		goto error;

>> -	}

>> +	u8 iobuf[CYPRESS_MAX_REQSIZE] = {0};

>>  

>>  	dev_dbg(&dev->udev->dev, "Sending usb_control_msg (data: %d)\n", data);

>>  

>>  	/* prepare usb control message and send it upstream */

>> -	pipe = usb_rcvctrlpipe(dev->udev, 0);

>> -	retval = usb_control_msg(dev->udev, pipe, request,

>> -				 USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER,

>> -				 address, data, iobuf, CYPRESS_MAX_REQSIZE,

>> -				 USB_CTRL_GET_TIMEOUT);

>> +	retval = usb_control_msg_recv(dev->udev, 0, request,

>> +				      USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER,

>> +				      address, data, &iobuf, CYPRESS_MAX_REQSIZE,

>> +				      USB_CTRL_GET_TIMEOUT, GFP_KERNEL);

> Are you sure that the device always returns CYPRESS_MAX_REQSIZE here?

> Otherwise, this change may break the driver as it currently only uses

> the first two bytes of the received message, and only for some requests.

>

> Note that the driver appears uses the same helper function for

> CYPRESS_WRITE_PORT commands, which probably doesn't return 8 bytes in a

> reply.

>

> You could possibly add the missing short read check for the

> CYPRESS_READ_PORT case, but I'm afraid that the new helper are not a

> good fit here either.

>


Understood, but I think that change might be better proposed (for this, and cytherm, both)
separately from this series, so I'll just drop it from this series for now.

Thanks,
Anant
Anant Thazhemadam Jan. 27, 2021, 2:42 p.m. UTC | #4
On 27/01/21 7:28 pm, Johan Hovold wrote:
> On Wed, Jan 27, 2021 at 12:03:52AM +0530, Anant Thazhemadam wrote:

>> The newer usb_control_msg_{send|recv}() API are an improvement on the

>> existing usb_control_msg() as it ensures that a short read/write is treated

> As I mentioned in my comments on v2, a short write has always been

> treated as an error so you shouldn't imply that it wasn't here (and in

> the other commit messages).


The newer API ensures that a short send/recv is an error, as they either
complete the complete translation, or return an error, and remove the need
for explicit return value checking that was previously expected to detect the short
read/write (which wasn't present in a lot of places).
That's what I was trying to say. But if the commit message isn't representative of
that, I'll try and modify it.

Does this sound like a better commit message?

"The newer usb_control_msg_{send|recv}() API are an improvement on the
existing usb_control_msg().

The new API ensures either the full translation is completed,
or an error is returned. This ensures that all short send/recv are detected as
errors even if there is no explicit return value checking performed.

The new API also allows us to use data off the stack, and don't require raw usb
pipes to be created in the calling functions."


>> as an error, data can be used off the stack, and raw usb pipes need not be

>> created in the calling functions.

>> For this reason, instances of usb_control_msg() have been replaced with

>> usb_control_msg_{recv|send}(), and all return value checking

>> conditions have also been modified appropriately.

>>

>> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>

>> ---

>>  drivers/usb/misc/appledisplay.c | 46 ++++++++++++++-------------------

>>  1 file changed, 19 insertions(+), 27 deletions(-)

>>

>> diff --git a/drivers/usb/misc/appledisplay.c b/drivers/usb/misc/appledisplay.c

>> index c8098e9b432e..117deb2fdc29 100644

>> --- a/drivers/usb/misc/appledisplay.c

>> +++ b/drivers/usb/misc/appledisplay.c

>> @@ -132,21 +132,17 @@ static int appledisplay_bl_update_status(struct backlight_device *bd)

>>  	pdata->msgdata[0] = 0x10;

>>  	pdata->msgdata[1] = bd->props.brightness;

>>  

>> -	retval = usb_control_msg(

>> -		pdata->udev,

>> -		usb_sndctrlpipe(pdata->udev, 0),

>> -		USB_REQ_SET_REPORT,

>> -		USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE,

>> -		ACD_USB_BRIGHTNESS,

>> -		0,

>> -		pdata->msgdata, 2,

> In this case, the buffer is already DMA-able (and is in fact only used

> for this purpose) so this patch introduces an extra allocation and

> memcpy for no really good reason.

>

>> -		ACD_USB_TIMEOUT);

>> +	retval = usb_control_msg_send(pdata->udev,

>> +				      0,

>> +				      USB_REQ_SET_REPORT,

>> +				      USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE,

>> +				      ACD_USB_BRIGHTNESS,

>> +				      0,

>> +				      pdata->msgdata, 2,

>> +				      ACD_USB_TIMEOUT, GFP_KERNEL);

>>  	mutex_unlock(&pdata->sysfslock);

>>  

>> -	if (retval < 0)

>> -		return retval;

>> -	else

>> -		return 0;

>> +	return retval;

>>  }

>>  

>>  static int appledisplay_bl_get_brightness(struct backlight_device *bd)

>> @@ -155,21 +151,17 @@ static int appledisplay_bl_get_brightness(struct backlight_device *bd)

>>  	int retval, brightness;

>>  

>>  	mutex_lock(&pdata->sysfslock);

>> -	retval = usb_control_msg(

>> -		pdata->udev,

>> -		usb_rcvctrlpipe(pdata->udev, 0),

>> -		USB_REQ_GET_REPORT,

>> -		USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE,

>> -		ACD_USB_BRIGHTNESS,

>> -		0,

>> -		pdata->msgdata, 2,

>> -		ACD_USB_TIMEOUT);

>> -	if (retval < 2) {

>> -		if (retval >= 0)

>> -			retval = -EMSGSIZE;

>> -	} else {

>> +	retval = usb_control_msg_recv(pdata->udev,

>> +				      0,

>> +				      USB_REQ_GET_REPORT,

>> +				      USB_DIR_IN | USB_TYPE_CLASS | USB_RECIP_INTERFACE,

>> +				      ACD_USB_BRIGHTNESS,

>> +				      0,

>> +				      pdata->msgdata, 2,

>> +				      ACD_USB_TIMEOUT, GFP_KERNEL);

>> +	if (retval == 0)

>>  		brightness = pdata->msgdata[1];

>> -	}

>> +

> Same here, this introduces an extra allocation and memcpy and the only

> thing you gain is essentially the removal of the two lines for handling

> a short read.

>

>>  	mutex_unlock(&pdata->sysfslock);

>>  

>>  	if (retval < 0)

> I'd consider dropping this one as well.



Yes, that's probably the better thing to do here.


Thanks,
Anant
Johan Hovold Jan. 27, 2021, 2:49 p.m. UTC | #5
On Wed, Jan 27, 2021 at 12:03:55AM +0530, Anant Thazhemadam wrote:
> The newer usb_control_msg_{send|recv}() API are an improvement on the

> existing usb_control_msg() as it ensures that a short read/write is treated

> as an error, data can be used off the stack, and raw usb pipes need not be

> created in the calling functions.

> For this reason, instances of usb_control_msg() have been replaced with

> usb_control_msg_{recv|send}() appropriately.

> 

> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>

> Reviewed-by: Peter Chen <peter.chen@nxp.com>

> ---

>  drivers/usb/misc/ehset.c | 76 +++++++++++++++++-----------------------

>  1 file changed, 32 insertions(+), 44 deletions(-)

> 

> diff --git a/drivers/usb/misc/ehset.c b/drivers/usb/misc/ehset.c

> index 2752e1f4f4d0..f87890f9cd26 100644

> --- a/drivers/usb/misc/ehset.c

> +++ b/drivers/usb/misc/ehset.c

> @@ -24,68 +24,57 @@ static int ehset_probe(struct usb_interface *intf,

>  	int ret = -EINVAL;

>  	struct usb_device *dev = interface_to_usbdev(intf);

>  	struct usb_device *hub_udev = dev->parent;

> -	struct usb_device_descriptor *buf;

> +	struct usb_device_descriptor buf;

>  	u8 portnum = dev->portnum;

>  	u16 test_pid = le16_to_cpu(dev->descriptor.idProduct);

>  

>  	switch (test_pid) {

>  	case TEST_SE0_NAK_PID:

> -		ret = usb_control_msg(hub_udev, usb_sndctrlpipe(hub_udev, 0),

> -					USB_REQ_SET_FEATURE, USB_RT_PORT,

> -					USB_PORT_FEAT_TEST,

> -					(USB_TEST_SE0_NAK << 8) | portnum,

> -					NULL, 0, 1000);

> +		ret = usb_control_msg_send(hub_udev, 0, USB_REQ_SET_FEATURE,

> +					   USB_RT_PORT, USB_PORT_FEAT_TEST,

> +					   (USB_TEST_SE0_NAK << 8) | portnum,

> +					   NULL, 0, 1000, GFP_KERNEL);

>  		break;


>  	case TEST_SINGLE_STEP_GET_DEV_DESC:

>  		/* Test: wait for 15secs -> GetDescriptor request */

>  		msleep(15 * 1000);

> -		buf = kmalloc(USB_DT_DEVICE_SIZE, GFP_KERNEL);

> -		if (!buf)

> -			return -ENOMEM;

>  

> -		ret = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),

> -					USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,

> -					USB_DT_DEVICE << 8, 0,

> -					buf, USB_DT_DEVICE_SIZE,

> -					USB_CTRL_GET_TIMEOUT);

> -		kfree(buf);

> +		ret = usb_control_msg_recv(dev, 0, USB_REQ_GET_DESCRIPTOR,

> +					   USB_DIR_IN, USB_DT_DEVICE << 8, 0,

> +					   &buf, USB_DT_DEVICE_SIZE,

> +					   USB_CTRL_GET_TIMEOUT, GFP_KERNEL);


Ok, here you now test for a short device descriptor (which USB core
should already have fetched if you get to probe this driver), but which
wasn't verified again here before. You may want to mention that in the
commit message.

And the buffer is small enough that moving it to the stack also for the
other test cases isn't an issue (and the redundant memcpy() introduced
by the helper is in the noise).

So, this looks ok (with an amended commit message dropping the short
write bit):

Reviewed-by: Johan Hovold <johan@kernel.org>


Johan
Johan Hovold Jan. 27, 2021, 2:52 p.m. UTC | #6
On Wed, Jan 27, 2021 at 12:03:56AM +0530, Anant Thazhemadam wrote:
> The newer usb_control_msg_{send|recv}() API are an improvement on the

> existing usb_control_msg() as it ensures that a short read/write is treated

> as an error, data can be used off the stack, and raw usb pipes need not be

> created in the calling functions.

> For this reason, the instance of usb_control_msg() has been replaced with

> usb_control_msg_send() appropriately.

> 

> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>

> ---

>  drivers/usb/misc/ezusb.c | 16 ++--------------

>  1 file changed, 2 insertions(+), 14 deletions(-)

> 

> diff --git a/drivers/usb/misc/ezusb.c b/drivers/usb/misc/ezusb.c

> index f058d8029761..78aaee56c2b7 100644

> --- a/drivers/usb/misc/ezusb.c

> +++ b/drivers/usb/misc/ezusb.c

> @@ -31,24 +31,12 @@ static const struct ezusb_fx_type ezusb_fx1 = {

>  static int ezusb_writememory(struct usb_device *dev, int address,

>  				unsigned char *data, int length, __u8 request)

>  {

> -	int result;

> -	unsigned char *transfer_buffer;

> -

>  	if (!dev)

>  		return -ENODEV;

>  

> -	transfer_buffer = kmemdup(data, length, GFP_KERNEL);

> -	if (!transfer_buffer) {

> -		dev_err(&dev->dev, "%s - kmalloc(%d) failed.\n",

> -							__func__, length);

> -		return -ENOMEM;

> -	}

> -	result = usb_control_msg(dev, usb_sndctrlpipe(dev, 0), request,

> +	return usb_control_msg_send(dev, 0, request,

>  				 USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,

> -				 address, 0, transfer_buffer, length, 3000);

> -

> -	kfree(transfer_buffer);

> -	return result;

> +				 address, 0, data, length, 3000, GFP_KERNEL);

>  }

>  

>  static int ezusb_set_reset(struct usb_device *dev, unsigned short cpucs_reg,


This is a prime example of how the new helpers should be used. 

With the short-write bit dropped from the commit message:

Reviewed-by: Johan Hovold <johan@kernel.org>


Johan
Johan Hovold Jan. 27, 2021, 2:59 p.m. UTC | #7
On Wed, Jan 27, 2021 at 12:03:57AM +0530, Anant Thazhemadam wrote:
> The newer usb_control_msg_{send|recv}() API are an improvement on the

> existing usb_control_msg() as it ensures that a short read/write is treated

> as an error, data can be used off the stack, and raw usb pipes need not be

> created in the calling functions.

> For this reason, instances of usb_control_msg() have been replaced with

> usb_control_msg_{recv|send}() appropriately.

> 

> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>

> ---

>  drivers/usb/misc/iowarrior.c | 34 +++++++++++++++++-----------------

>  1 file changed, 17 insertions(+), 17 deletions(-)

> 

> diff --git a/drivers/usb/misc/iowarrior.c b/drivers/usb/misc/iowarrior.c

> index efbd317f2f25..9d6a7548e537 100644

> --- a/drivers/usb/misc/iowarrior.c

> +++ b/drivers/usb/misc/iowarrior.c

> @@ -109,12 +109,12 @@ static int usb_get_report(struct usb_device *dev,

>  			  struct usb_host_interface *inter, unsigned char type,

>  			  unsigned char id, void *buf, int size)

>  {

> -	return usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),

> -			       USB_REQ_GET_REPORT,

> -			       USB_DIR_IN | USB_TYPE_CLASS |

> -			       USB_RECIP_INTERFACE, (type << 8) + id,

> -			       inter->desc.bInterfaceNumber, buf, size,

> -			       GET_TIMEOUT*HZ);

> +	return usb_control_msg_recv(dev, 0,

> +				    USB_REQ_GET_REPORT,

> +				    USB_DIR_IN | USB_TYPE_CLASS |

> +				    USB_RECIP_INTERFACE, (type << 8) + id,

> +				    inter->desc.bInterfaceNumber, buf, size,

> +				    GET_TIMEOUT*HZ, GFP_KERNEL);

>  }

>  //#endif

>  

> @@ -123,13 +123,13 @@ static int usb_get_report(struct usb_device *dev,

>  static int usb_set_report(struct usb_interface *intf, unsigned char type,

>  			  unsigned char id, void *buf, int size)

>  {

> -	return usb_control_msg(interface_to_usbdev(intf),

> -			       usb_sndctrlpipe(interface_to_usbdev(intf), 0),

> -			       USB_REQ_SET_REPORT,

> -			       USB_TYPE_CLASS | USB_RECIP_INTERFACE,

> -			       (type << 8) + id,

> -			       intf->cur_altsetting->desc.bInterfaceNumber, buf,

> -			       size, HZ);

> +	return usb_control_msg_send(interface_to_usbdev(intf),

> +				    0,

> +				    USB_REQ_SET_REPORT,

> +				    USB_TYPE_CLASS | USB_RECIP_INTERFACE,

> +				    (type << 8) + id,

> +				    intf->cur_altsetting->desc.bInterfaceNumber, buf,

> +				    size, HZ, GFP_KERNEL);

>  }


But here the buffers are already DMA-able so that the new helpers only
add redundant allocations and memcpy's() for no real gain.

I'd just drop this one as well.

You could consider adding the missing sanity check to the IOW_READ
ioctl, which would currently return zeroed data in case of a short read
(so there are no info leaks either way). But perhaps that is done on
purpose, so perhaps better to leave that too.

Johan
Johan Hovold Jan. 27, 2021, 3:04 p.m. UTC | #8
On Wed, Jan 27, 2021 at 12:03:58AM +0530, Anant Thazhemadam wrote:
> The newer usb_control_msg_{send|recv}() API are an improvement on the

> existing usb_control_msg() as it ensures that a short read/write is treated

> as an error, data can be used off the stack, and raw usb pipes need not be

> created in the calling functions.

> For this reason, the instances of usb_control_msg() have been replaced with

> usb_control_msg_send(), and return value checking has also been

> appropriately enforced.

> 

> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>

> ---

>  drivers/usb/misc/isight_firmware.c | 30 +++++++++++++-----------------

>  1 file changed, 13 insertions(+), 17 deletions(-)

> 

> diff --git a/drivers/usb/misc/isight_firmware.c b/drivers/usb/misc/isight_firmware.c

> index 4d30095d6ad2..1bd14a431f6c 100644

> --- a/drivers/usb/misc/isight_firmware.c

> +++ b/drivers/usb/misc/isight_firmware.c

> @@ -37,13 +37,10 @@ static int isight_firmware_load(struct usb_interface *intf,

>  	struct usb_device *dev = interface_to_usbdev(intf);

>  	int llen, len, req, ret = 0;

>  	const struct firmware *firmware;

> -	unsigned char *buf = kmalloc(50, GFP_KERNEL);

> +	unsigned char buf[50];


This buffer is probably large enough to not want to have it allocated on
the stack.

>  	unsigned char data[4];

>  	const u8 *ptr;

>  

> -	if (!buf)

> -		return -ENOMEM;

> -

>  	if (request_firmware(&firmware, "isight.fw", &dev->dev) != 0) {

>  		printk(KERN_ERR "Unable to load isight firmware\n");

>  		ret = -ENODEV;

> @@ -53,11 +50,11 @@ static int isight_firmware_load(struct usb_interface *intf,

>  	ptr = firmware->data;

>  

>  	buf[0] = 0x01;

> -	if (usb_control_msg

> -	    (dev, usb_sndctrlpipe(dev, 0), 0xa0, 0x40, 0xe600, 0, buf, 1,

> -	     300) != 1) {

> +	ret = usb_control_msg_send(dev, 0, 0xa0, 0x40, 0xe600,

> +				   0, &buf, 1, 300, GFP_KERNEL);

> +	if (ret != 0) {

>  		printk(KERN_ERR

> -		       "Failed to initialise isight firmware loader\n");

> +			"Failed to initialise isight firmware loader\n");

>  		ret = -ENODEV;

>  		goto out;

>  	}

> @@ -82,15 +79,15 @@ static int isight_firmware_load(struct usb_interface *intf,

>  				ret = -ENODEV;

>  				goto out;

>  			}

> -			memcpy(buf, ptr, llen);

> +			memcpy(&buf, ptr, llen);

>  

>  			ptr += llen;

>  

> -			if (usb_control_msg

> -			    (dev, usb_sndctrlpipe(dev, 0), 0xa0, 0x40, req, 0,

> -			     buf, llen, 300) != llen) {

> +			ret = usb_control_msg_send(dev, 0, 0xa0, 0x40, req, 0,

> +						   &buf, llen, 300, GFP_KERNEL);

> +			if (ret != 0) {

>  				printk(KERN_ERR

> -				       "Failed to load isight firmware\n");

> +					"Failed to load isight firmware\n");

>  				ret = -ENODEV;

>  				goto out;

>  			}


And here the same buffer is reused for each block of data, while the new
helpers would add an allocation and a redundant memcpy() of the data
(which was just copied a few lines above) for each iteration.

So I suggest you drop this one as well.

Johan
Johan Hovold Jan. 27, 2021, 3:06 p.m. UTC | #9
On Wed, Jan 27, 2021 at 12:03:59AM +0530, Anant Thazhemadam wrote:
> The newer usb_control_msg_{send|recv}() API are an improvement on the

> existing usb_control_msg() as it ensures that a short read/write is treated

> as an error, data can be used off the stack, and raw usb pipes need not be

> created in the calling functions.

> For this reason, the instance of usb_control_msg_send() has been replaced

> with usb_control_msg_send() appropriately.

> 

> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>

> ---

>  drivers/usb/misc/ldusb.c | 8 +++-----

>  1 file changed, 3 insertions(+), 5 deletions(-)

> 

> diff --git a/drivers/usb/misc/ldusb.c b/drivers/usb/misc/ldusb.c

> index 670e4d91e9ca..259ead4edecb 100644

> --- a/drivers/usb/misc/ldusb.c

> +++ b/drivers/usb/misc/ldusb.c

> @@ -573,15 +573,13 @@ static ssize_t ld_usb_write(struct file *file, const char __user *buffer,

>  	}

>  

>  	if (dev->interrupt_out_endpoint == NULL) {

> -		/* try HID_REQ_SET_REPORT=9 on control_endpoint instead of interrupt_out_endpoint */

> -		retval = usb_control_msg(interface_to_usbdev(dev->intf),

> -					 usb_sndctrlpipe(interface_to_usbdev(dev->intf), 0),

> -					 9,

> +		retval = usb_control_msg_send(interface_to_usbdev(dev->intf),

> +					 0, 9,

>  					 USB_TYPE_CLASS | USB_RECIP_INTERFACE | USB_DIR_OUT,

>  					 1 << 8, 0,

>  					 dev->interrupt_out_buffer,

>  					 bytes_to_write,

> -					 USB_CTRL_SET_TIMEOUT);

> +					 USB_CTRL_SET_TIMEOUT, GFP_KERNEL);

>  		if (retval < 0)

>  			dev_err(&dev->intf->dev,

>  				"Couldn't submit HID_REQ_SET_REPORT %d\n",


This would also only introduce a redundant allocation and memcpy() as
the buffer is already DMA-able and used for that purpose in other places
as well.

I suggest dropping this one too.

Johan
Johan Hovold Jan. 27, 2021, 3:15 p.m. UTC | #10
On Wed, Jan 27, 2021 at 12:09:43AM +0530, Anant Thazhemadam wrote:
> The newer usb_control_msg_{send|recv}() API are an improvement on the

> existing usb_control_msg() as it ensures that a short read/write is treated

> as an error, data can be used off the stack, and raw usb pipes need not be

> created in the calling functions.

> For this reason, instances of usb_control_msg() have been replaced with

> usb_control_msg_{recv|send}() and the return value checking conditions have

> also been modified appropriately.

> 

> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>

> ---

>  drivers/usb/misc/lvstest.c | 38 ++++++++++++++++----------------------

>  1 file changed, 16 insertions(+), 22 deletions(-)


> @@ -336,10 +330,10 @@ static void lvs_rh_work(struct work_struct *work)

>  

>  	/* Examine each root port */

>  	for (i = 1; i <= descriptor->bNbrPorts; i++) {

> -		ret = usb_control_msg(hdev, usb_rcvctrlpipe(hdev, 0),

> +		ret = usb_control_msg_recv(hdev, 0,

>  			USB_REQ_GET_STATUS, USB_DIR_IN | USB_RT_PORT, 0, i,

> -			port_status, sizeof(*port_status), 1000);

> -		if (ret < 4)

> +			port_status, sizeof(*port_status), 1000, GFP_KERNEL);

> +		if (ret < 0)

>  			continue;


I'm afraid this may introduce a regression as well since the
sizeof(*port_status) is 8 for some devices and the driver only cares
about the first 4 that all devices use (i.e. it is written to handle
short reads).

>  		portchange = le16_to_cpu(port_status->wPortChange);

> @@ -420,13 +414,13 @@ static int lvs_rh_probe(struct usb_interface *intf,

>  	usb_set_intfdata(intf, lvs);

>  

>  	/* how many number of ports this root hub has */

> -	ret = usb_control_msg(hdev, usb_rcvctrlpipe(hdev, 0),

> +	ret = usb_control_msg_recv(hdev, 0,

>  			USB_REQ_GET_DESCRIPTOR, USB_DIR_IN | USB_RT_HUB,

>  			USB_DT_SS_HUB << 8, 0, &lvs->descriptor,

> -			USB_DT_SS_HUB_SIZE, USB_CTRL_GET_TIMEOUT);

> -	if (ret < (USB_DT_HUB_NONVAR_SIZE + 2)) {

> +			USB_DT_SS_HUB_SIZE, USB_CTRL_GET_TIMEOUT, GFP_KERNEL);

> +	if (ret < 0) {

>  		dev_err(&hdev->dev, "wrong root hub descriptor read %d\n", ret);

> -		return ret < 0 ? ret : -EINVAL;

> +		return ret;

>  	}


This looks like it may break for similar reasons.

Johan
Johan Hovold Jan. 27, 2021, 3:17 p.m. UTC | #11
On Wed, Jan 27, 2021 at 12:10:10AM +0530, Anant Thazhemadam wrote:
> The newer usb_control_msg_{send|recv}() API are an improvement on the

> existing usb_control_msg() as it ensures that a short read/write is treated

> as an error, data can be used off the stack, and raw usb pipes need not be

> created in the calling functions.

> For this reason, the instance of usb_control_msg() has been replaced with

> usb_control_msg_send() and the return value checking condition has also

> been modified appropriately.

> 

> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>

> ---

>  drivers/usb/misc/trancevibrator.c | 4 ++--

>  1 file changed, 2 insertions(+), 2 deletions(-)

> 

> diff --git a/drivers/usb/misc/trancevibrator.c b/drivers/usb/misc/trancevibrator.c

> index a3dfc77578ea..c50807b4f4ef 100644

> --- a/drivers/usb/misc/trancevibrator.c

> +++ b/drivers/usb/misc/trancevibrator.c

> @@ -59,11 +59,11 @@ static ssize_t speed_store(struct device *dev, struct device_attribute *attr,

>  	dev_dbg(&tv->udev->dev, "speed = %d\n", tv->speed);

>  

>  	/* Set speed */

> -	retval = usb_control_msg(tv->udev, usb_sndctrlpipe(tv->udev, 0),

> +	retval = usb_control_msg_send(tv->udev, 0,

>  				 0x01, /* vendor request: set speed */

>  				 USB_DIR_IN | USB_TYPE_VENDOR | USB_RECIP_OTHER,

>  				 tv->speed, /* speed value */

> -				 0, NULL, 0, USB_CTRL_GET_TIMEOUT);

> +				 0, NULL, 0, USB_CTRL_GET_TIMEOUT, GFP_KERNEL);

>  	if (retval) {

>  		tv->speed = old;

>  		dev_dbg(&tv->udev->dev, "retval = %d\n", retval);


While this patch looks correct, the new helpers doesn't really buy us
anything for (OUT) control transfers without a data stage.

Johan
Alan Stern Jan. 27, 2021, 4:26 p.m. UTC | #12
On Wed, Jan 27, 2021 at 05:42:47PM +0530, Anant Thazhemadam wrote:
> The newer usb_control_msg_{send|recv}() API are an improvement on the

> existing usb_control_msg() as it ensures that a short read/write is treated

> as an error, data can be used off the stack, and raw usb pipes need not be

> created in the calling functions.

> For this reason, instances of usb_control_msg() have been replaced with

> usb_control_msg_{recv|send}() and the return value checking conditions have

> also been modified appropriately.

> 

> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>

> ---

> Resending this patch since the subject line for the initial submission 

> (sent as a part of the patch series) wasn't set correctly.


The benefits of these changes are rather minimal.  In some cases they 
actually make the code worse (doing an unnecessary allocation in order 
to copy a buffer that doesn't need to be copied).

>  drivers/usb/misc/usbtest.c | 69 ++++++++++++++++----------------------

>  1 file changed, 29 insertions(+), 40 deletions(-)

> 

> diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c

> index 150090ee4ec1..4337eff2a749 100644

> --- a/drivers/usb/misc/usbtest.c

> +++ b/drivers/usb/misc/usbtest.c

> @@ -672,19 +672,15 @@ static int get_altsetting(struct usbtest_dev *dev)

>  	struct usb_device	*udev = interface_to_usbdev(iface);

>  	int			retval;

>  

> -	retval = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),

> -			USB_REQ_GET_INTERFACE, USB_DIR_IN|USB_RECIP_INTERFACE,

> -			0, iface->altsetting[0].desc.bInterfaceNumber,

> -			dev->buf, 1, USB_CTRL_GET_TIMEOUT);

> -	switch (retval) {

> -	case 1:

> -		return dev->buf[0];

> -	case 0:

> -		retval = -ERANGE;

> -		fallthrough;

> -	default:

> +	retval = usb_control_msg_recv(udev, 0, USB_REQ_GET_INTERFACE,

> +				      USB_DIR_IN|USB_RECIP_INTERFACE,

> +				      0, iface->altsetting[0].desc.bInterfaceNumber,

> +				      dev->buf, 1, USB_CTRL_GET_TIMEOUT, GFP_KERNEL);


Here dev->buf is aleady DMA-able; there's no need to copy it.  The only 
advantage is avoiding the short-read check.

> +

> +	if (retval < 0)

>  		return retval;

> -	}

> +

> +	return dev->buf[0];

>  }

>  

>  static int set_altsetting(struct usbtest_dev *dev, int alternate)

> @@ -872,14 +868,15 @@ static int ch9_postconfig(struct usbtest_dev *dev)

>  		 * ... although some cheap devices (like one TI Hub I've got)

>  		 * won't return config descriptors except before set_config.

>  		 */

> -		retval = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),

> -				USB_REQ_GET_CONFIGURATION,

> -				USB_DIR_IN | USB_RECIP_DEVICE,

> -				0, 0, dev->buf, 1, USB_CTRL_GET_TIMEOUT);

> -		if (retval != 1 || dev->buf[0] != expected) {

> +		retval = usb_control_msg_recv(udev, 0, USB_REQ_GET_CONFIGURATION,

> +					      USB_DIR_IN | USB_RECIP_DEVICE,  0,

> +					      0, dev->buf, 1, USB_CTRL_GET_TIMEOUT,

> +					      GFP_KERNEL);

> +

> +		if (retval != 0 || dev->buf[0] != expected) {

>  			dev_err(&iface->dev, "get config --> %d %d (1 %d)\n",

>  				retval, dev->buf[0], expected);

> -			return (retval < 0) ? retval : -EDOM;

> +			return retval;


Here again, the advantage is minimal at best.

>  		}

>  	}

>  

> @@ -1683,10 +1680,10 @@ static int test_halt(struct usbtest_dev *tdev, int ep, struct urb *urb)

>  		return retval;

>  

>  	/* set halt (protocol test only), verify it worked */

> -	retval = usb_control_msg(urb->dev, usb_sndctrlpipe(urb->dev, 0),

> -			USB_REQ_SET_FEATURE, USB_RECIP_ENDPOINT,

> -			USB_ENDPOINT_HALT, ep,

> -			NULL, 0, USB_CTRL_SET_TIMEOUT);

> +	retval = usb_control_msg_send(urb->dev, 0, USB_REQ_SET_FEATURE,

> +				      USB_RECIP_ENDPOINT, USB_ENDPOINT_HALT,

> +				      ep, NULL, 0, USB_CTRL_SET_TIMEOUT,

> +				      GFP_KERNEL);


Here there is no advantage at all.  There is no buffer to copy and no 
possibility of a short write.

>  	if (retval < 0) {

>  		ERROR(tdev, "ep %02x couldn't set halt, %d\n", ep, retval);

>  		return retval;

> @@ -1845,30 +1842,22 @@ static int ctrl_out(struct usbtest_dev *dev,

>  		/* write patterned data */

>  		for (j = 0; j < len; j++)

>  			buf[j] = (u8)(i + j);

> -		retval = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),

> -				0x5b, USB_DIR_OUT|USB_TYPE_VENDOR,

> -				0, 0, buf, len, USB_CTRL_SET_TIMEOUT);

> -		if (retval != len) {

> +		retval = usb_control_msg_send(udev, 0, 0x5b,

> +					      USB_DIR_OUT | USB_TYPE_VENDOR, 0,

> +					      0, buf, len, USB_CTRL_SET_TIMEOUT,

> +					      GFP_KERNEL);

> +		if (retval < 0) {

>  			what = "write";

> -			if (retval >= 0) {

> -				ERROR(dev, "ctrl_out, wlen %d (expected %d)\n",

> -						retval, len);

> -				retval = -EBADMSG;

> -			}

>  			break;

>  		}


Here buf doesn't need to be copied, and a short write will return an 
error code anyway.

>  

>  		/* read it back -- assuming nothing intervened!!  */

> -		retval = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),

> -				0x5c, USB_DIR_IN|USB_TYPE_VENDOR,

> -				0, 0, buf, len, USB_CTRL_GET_TIMEOUT);

> -		if (retval != len) {

> +		retval = usb_control_msg_recv(udev, 0,

> +					      0x5c, USB_DIR_IN|USB_TYPE_VENDOR,

> +					      0, 0, buf, len, USB_CTRL_GET_TIMEOUT,

> +					      GFP_KERNEL);

> +		if (retval < 0) {

>  			what = "read";

> -			if (retval >= 0) {

> -				ERROR(dev, "ctrl_out, rlen %d (expected %d)\n",

> -						retval, len);

> -				retval = -EBADMSG;

> -			}


Similar to one of the cases above.

Alan Stern

>  			break;

>  		}

>  

> -- 

> 2.25.1

>
Johan Hovold Jan. 27, 2021, 4:46 p.m. UTC | #13
On Wed, Jan 27, 2021 at 12:10:30AM +0530, Anant Thazhemadam wrote:
> The newer usb_control_msg_{send|recv}() API are an improvement on the

> existing usb_control_msg() as it ensures that a short read/write is treated

> as an error, data can be used off the stack, and raw usb pipes need not be

> created in the calling functions.

> For this reason, instances of usb_control_msg() have been replaced with

> usb_control_msg_send() appropriately.

> 

> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>

> ---

>  drivers/usb/misc/usbsevseg.c | 60 ++++++++++--------------------------

>  1 file changed, 17 insertions(+), 43 deletions(-)

> 

> diff --git a/drivers/usb/misc/usbsevseg.c b/drivers/usb/misc/usbsevseg.c

 
> @@ -99,15 +94,10 @@ static void update_display_mode(struct usb_sevsegdev *mydev)

>  	if(mydev->shadow_power != 1)

>  		return;

>  

> -	rc = usb_control_msg(mydev->udev,

> -			usb_sndctrlpipe(mydev->udev, 0),

> -			0x12,

> -			0x48,

> -			(82 * 0x100) + 10, /* (set mode) */

> -			(mydev->mode_msb * 0x100) + mydev->mode_lsb,

> -			NULL,

> -			0,

> -			2000);

> +	rc = usb_control_msg_send(mydev->udev, 0, 0x12, 0x48,

> +				  (82 * 0x100) + 10, /* (set mode) */

> +				  (mydev->mode_msb * 0x100) + mydev->mode_lsb,

> +				  NULL, 0, 2000, GFP_KERNEL);

>  

>  	if (rc < 0)

>  		dev_dbg(&mydev->udev->dev, "mode retval = %d\n", rc);


This function is called from resume() and reset_resume() where GFP_NOIO
should be used (and is used for update_display_visual()) so I think you
need to add a GFP flag argument here too.

Looks good otherwise.

Johan
Johan Hovold Jan. 27, 2021, 5 p.m. UTC | #14
On Wed, Jan 27, 2021 at 05:42:47PM +0530, Anant Thazhemadam wrote:
> The newer usb_control_msg_{send|recv}() API are an improvement on the

> existing usb_control_msg() as it ensures that a short read/write is treated

> as an error, data can be used off the stack, and raw usb pipes need not be

> created in the calling functions.

> For this reason, instances of usb_control_msg() have been replaced with

> usb_control_msg_{recv|send}() and the return value checking conditions have

> also been modified appropriately.

> 

> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com>

> ---

> Resending this patch since the subject line for the initial submission 

> (sent as a part of the patch series) wasn't set correctly.

> 

>  drivers/usb/misc/usbtest.c | 69 ++++++++++++++++----------------------

>  1 file changed, 29 insertions(+), 40 deletions(-)

> 

> diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c

> index 150090ee4ec1..4337eff2a749 100644

> --- a/drivers/usb/misc/usbtest.c

> +++ b/drivers/usb/misc/usbtest.c

> @@ -672,19 +672,15 @@ static int get_altsetting(struct usbtest_dev *dev)

>  	struct usb_device	*udev = interface_to_usbdev(iface);

>  	int			retval;

>  

> -	retval = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),

> -			USB_REQ_GET_INTERFACE, USB_DIR_IN|USB_RECIP_INTERFACE,

> -			0, iface->altsetting[0].desc.bInterfaceNumber,

> -			dev->buf, 1, USB_CTRL_GET_TIMEOUT);

> -	switch (retval) {

> -	case 1:

> -		return dev->buf[0];

> -	case 0:

> -		retval = -ERANGE;

> -		fallthrough;

> -	default:

> +	retval = usb_control_msg_recv(udev, 0, USB_REQ_GET_INTERFACE,

> +				      USB_DIR_IN|USB_RECIP_INTERFACE,

> +				      0, iface->altsetting[0].desc.bInterfaceNumber,

> +				      dev->buf, 1, USB_CTRL_GET_TIMEOUT, GFP_KERNEL);

> +

> +	if (retval < 0)

>  		return retval;


This changes the return value for short reads. Maybe not an issue, but
since this a test driver and the value is propagated to user space it is
not clear cut.

> -	}

> +

> +	return dev->buf[0];

>  }

>  

>  static int set_altsetting(struct usbtest_dev *dev, int alternate)

> @@ -872,14 +868,15 @@ static int ch9_postconfig(struct usbtest_dev *dev)

>  		 * ... although some cheap devices (like one TI Hub I've got)

>  		 * won't return config descriptors except before set_config.

>  		 */

> -		retval = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),

> -				USB_REQ_GET_CONFIGURATION,

> -				USB_DIR_IN | USB_RECIP_DEVICE,

> -				0, 0, dev->buf, 1, USB_CTRL_GET_TIMEOUT);

> -		if (retval != 1 || dev->buf[0] != expected) {

> +		retval = usb_control_msg_recv(udev, 0, USB_REQ_GET_CONFIGURATION,

> +					      USB_DIR_IN | USB_RECIP_DEVICE,  0,

> +					      0, dev->buf, 1, USB_CTRL_GET_TIMEOUT,

> +					      GFP_KERNEL);

> +

> +		if (retval != 0 || dev->buf[0] != expected) {

>  			dev_err(&iface->dev, "get config --> %d %d (1 %d)\n",

>  				retval, dev->buf[0], expected);

> -			return (retval < 0) ? retval : -EDOM;

> +			return retval;


Same here (but different error, so probably not an issue in either
place).

> @@ -1845,30 +1842,22 @@ static int ctrl_out(struct usbtest_dev *dev,

>  		/* write patterned data */

>  		for (j = 0; j < len; j++)

>  			buf[j] = (u8)(i + j);

> -		retval = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),

> -				0x5b, USB_DIR_OUT|USB_TYPE_VENDOR,

> -				0, 0, buf, len, USB_CTRL_SET_TIMEOUT);

> -		if (retval != len) {

> +		retval = usb_control_msg_send(udev, 0, 0x5b,

> +					      USB_DIR_OUT | USB_TYPE_VENDOR, 0,

> +					      0, buf, len, USB_CTRL_SET_TIMEOUT,

> +					      GFP_KERNEL);


This introduces a redundant allocation and memcpy() for every iteration
for the buffer which is already DMA-able. So this looks like a bad fit
for the new helper.

> +		if (retval < 0) {

>  			what = "write";

> -			if (retval >= 0) {

> -				ERROR(dev, "ctrl_out, wlen %d (expected %d)\n",

> -						retval, len);

> -				retval = -EBADMSG;

> -			}


You could drop this redundant short write test though if you want.

>  			break;

>  		}

>  

>  		/* read it back -- assuming nothing intervened!!  */

> -		retval = usb_control_msg(udev, usb_rcvctrlpipe(udev, 0),

> -				0x5c, USB_DIR_IN|USB_TYPE_VENDOR,

> -				0, 0, buf, len, USB_CTRL_GET_TIMEOUT);

> -		if (retval != len) {

> +		retval = usb_control_msg_recv(udev, 0,

> +					      0x5c, USB_DIR_IN|USB_TYPE_VENDOR,

> +					      0, 0, buf, len, USB_CTRL_GET_TIMEOUT,

> +					      GFP_KERNEL);

> +		if (retval < 0) {

>  			what = "read";

> -			if (retval >= 0) {

> -				ERROR(dev, "ctrl_out, rlen %d (expected %d)\n",

> -						retval, len);

> -				retval = -EBADMSG;

> -			}


Same here; the buffer is already DMA-able and you remove the error
message, which someone using a test driver like this may want to see.

Probably better left as is.

>  			break;

>  		}


Johan
Johan Hovold Jan. 27, 2021, 5:20 p.m. UTC | #15
On Wed, Jan 27, 2021 at 08:12:21PM +0530, Anant Thazhemadam wrote:
> 

> On 27/01/21 7:28 pm, Johan Hovold wrote:

> > On Wed, Jan 27, 2021 at 12:03:52AM +0530, Anant Thazhemadam wrote:

> >> The newer usb_control_msg_{send|recv}() API are an improvement on the

> >> existing usb_control_msg() as it ensures that a short read/write is treated

> > As I mentioned in my comments on v2, a short write has always been

> > treated as an error so you shouldn't imply that it wasn't here (and in

> > the other commit messages).

> 

> The newer API ensures that a short send/recv is an error, as they

> either complete the complete translation, or return an error, and

> remove the need for explicit return value checking that was previously

> expected to detect the short read/write (which wasn't present in a lot

> of places).


But my point is that this claim isn't factually correct; there has never
been a need to check for short *writes* (even if a few drivers have such
redundant checks).

> That's what I was trying to say. But if the commit message isn't

> representative of that, I'll try and modify it.


Just drop the bit about "short writes".

> Does this sound like a better commit message?

> 

> "The newer usb_control_msg_{send|recv}() API are an improvement on the

> existing usb_control_msg().


Even this is disputable; in some situations the usb_control_msg() is
still preferred as I hope my comments have shown.

Perhaps they are better described as "convenience wrappers" or similar
as the real gain from using these helpers is to replace a pattern like:

	f(data, ...) {
		buf = malloc(data);
		usb_control_msg(..., buf, ...);
		memcpy(data, buf, ...);
		kfree(buf);
	}

for when data is on the stack *and* you do not expect variable-length IN
transfers.

But as soon as a driver is able to reuse a single buffer for multiple
transfers or the data buffer is already DMA-able, usb_control_msg() may
still be a better choice.

> The new API ensures either the full translation is completed,

> or an error is returned. This ensures that all short send/recv are detected as


recv only

> errors even if there is no explicit return value checking performed.

> 

> The new API also allows us to use data off the stack, and don't require raw usb

> pipes to be created in the calling functions."


Johan