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