All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anant Thazhemadam <anant.thazhemadam@gmail.com>
To: Johan Hovold <johan@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 05/15] usb: misc: emi26: update to use usb_control_msg_send()
Date: Thu, 7 Jan 2021 19:43:54 +0530	[thread overview]
Message-ID: <6806f8e4-c2f7-3c6a-b855-3f87ab8d9e22@gmail.com> (raw)
In-Reply-To: <X8pKmmdvO0cIQXnL@localhost>


On 04/12/20 8:11 pm, Johan Hovold wrote:
> On Mon, Nov 30, 2020 at 06:58:47AM +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,
> Short writes have always been treated as an error. The new send helper
> only changes the return value from the transfer size to 0.
>
> And this driver never reads.
>
> Try to describe the motivation for changing this driver which is to
> avoid the explicit kmemdup().
>
Thank you. I will try and put a more appropriate commit message.
>> 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/emi26.c | 31 ++++++++-----------------------
>>  1 file changed, 8 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/usb/misc/emi26.c b/drivers/usb/misc/emi26.c
>> index 24d841850e05..1dd024507f40 100644
>> --- a/drivers/usb/misc/emi26.c
>> +++ b/drivers/usb/misc/emi26.c
>> @@ -27,7 +27,7 @@
>>  #define INTERNAL_RAM(address)   (address <= MAX_INTERNAL_ADDRESS)
>>  
>>  static int emi26_writememory( struct usb_device *dev, int address,
>> -			      const unsigned char *data, int length,
>> +			      const void *data, int length,
> Why is this needed?
>
>>  			      __u8 bRequest);
>>  static int emi26_set_reset(struct usb_device *dev, unsigned char reset_bit);
>>  static int emi26_load_firmware (struct usb_device *dev);
>> @@ -35,22 +35,12 @@ static int emi26_probe(struct usb_interface *intf, const struct usb_device_id *i
>>  static void emi26_disconnect(struct usb_interface *intf);
>>  
>>  /* thanks to drivers/usb/serial/keyspan_pda.c code */
>> -static int emi26_writememory (struct usb_device *dev, int address,
>> -			      const unsigned char *data, int length,
>> +static int emi26_writememory(struct usb_device *dev, int address,
>> +			      const void *data, int length,
>>  			      __u8 request)
>>  {
>> -	int result;
>> -	unsigned char *buffer =  kmemdup(data, length, GFP_KERNEL);
>> -
>> -	if (!buffer) {
>> -		dev_err(&dev->dev, "kmalloc(%d) failed.\n", length);
>> -		return -ENOMEM;
>> -	}
>> -	/* Note: usb_control_msg returns negative value on error or length of the
>> -	 * 		 data that was written! */
>> -	result = usb_control_msg (dev, usb_sndctrlpipe(dev, 0), request, 0x40, address, 0, buffer, length, 300);
>> -	kfree (buffer);
>> -	return result;
>> +	return usb_control_msg_send(dev, 0, request, 0x40, address, 0,
>> +				    data, length, 300, GFP_KERNEL);
> So you're changing the return value on success from length to 0 here.
> Did you make sure that all callers can handle that?

All the callers presently contain only an error checking condition for a return value < 0,
which still applies even with this change. So this wouldn't raise any issues.

>>  }
>>  
>>  /* thanks to drivers/usb/serial/keyspan_pda.c code */
>> @@ -77,11 +67,7 @@ static int emi26_load_firmware (struct usb_device *dev)
>>  	int err = -ENOMEM;
>>  	int i;
>>  	__u32 addr;	/* Address to write */
>> -	__u8 *buf;
>> -
>> -	buf = kmalloc(FW_LOAD_SIZE, GFP_KERNEL);
>> -	if (!buf)
>> -		goto wraperr;
>> +	__u8 buf[FW_LOAD_SIZE];
> As the build bots reported, you must not put large structures like this
> on the stack.

Understood. 
But I'm considering dropping this change (and the one proposed for emi62)
altogether in v3 - since these would end up requiring memory to dynamically allocated
twice for the same purpose.
However, if you still think the pros of updating this (and emi62) outweigh the cons,
please let me know, and I'll make sure to send in another version fixing it.


>>  
>>  	err = request_ihex_firmware(&loader_fw, "emi26/loader.fw", &dev->dev);
>>  	if (err)
>> @@ -133,11 +119,11 @@ static int emi26_load_firmware (struct usb_device *dev)
>>  
>>  		/* intel hex records are terminated with type 0 element */
>>  		while (rec && (i + be16_to_cpu(rec->len) < FW_LOAD_SIZE)) {
>> -			memcpy(buf + i, rec->data, be16_to_cpu(rec->len));
>> +			memcpy(&buf[i], rec->data, be16_to_cpu(rec->len));
>>  			i += be16_to_cpu(rec->len);
>>  			rec = ihex_next_binrec(rec);
>>  		}
>> -		err = emi26_writememory(dev, addr, buf, i, ANCHOR_LOAD_FPGA);
>> +		err = emi26_writememory(dev, addr, &buf, i, ANCHOR_LOAD_FPGA);
>>  		if (err < 0)
>>  			goto wraperr;
>>  	} while (rec);
>> @@ -211,7 +197,6 @@ static int emi26_load_firmware (struct usb_device *dev)
>>  	release_firmware(bitstream_fw);
>>  	release_firmware(firmware_fw);
>>  
>> -	kfree(buf);
>>  	return err;
>>  }
> Looks good otherwise.
>
> Johan

Thanks,
Anant


  reply	other threads:[~2021-01-07 14:14 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-30  1:18 [PATCH v2 00/15] drivers: usb: misc: update to use usb_control_msg_{send|recv}() Anant Thazhemadam
2020-11-30  1:18 ` Anant Thazhemadam
2020-11-30  1:18 ` Anant Thazhemadam
2020-11-30  1:23 ` [PATCH v2 01/15] usb: misc: appledisplay: update to use the usb_control_msg_{send|recv}() API Anant Thazhemadam
2020-11-30  1:26 ` [PATCH v2 02/15] usb: misc: cypress_cy7c63: update to use usb_control_msg_recv() Anant Thazhemadam
2020-11-30  1:27 ` [PATCH v2 03/15] usb: misc: cytherm: " Anant Thazhemadam
2020-11-30  1:28 ` [PATCH v2 04/15] usb: misc: ehset: update to use the usb_control_msg_{send|recv}() API Anant Thazhemadam
2020-11-30  1:28   ` Anant Thazhemadam
2020-11-30  1:28   ` Anant Thazhemadam
2020-11-30  1:28 ` [PATCH v2 05/15] usb: misc: emi26: update to use usb_control_msg_send() Anant Thazhemadam
2020-11-30  5:37   ` kernel test robot
2020-11-30  5:37     ` kernel test robot
2020-12-04 14:41   ` Johan Hovold
2021-01-07 14:13     ` Anant Thazhemadam [this message]
2021-01-08  9:20       ` Johan Hovold
2020-11-30  1:29 ` [PATCH v2 06/15] usb: misc: emi62: " Anant Thazhemadam
2020-11-30  3:54   ` kernel test robot
2020-11-30  3:54     ` kernel test robot
2020-12-04 14:43   ` Johan Hovold
2020-11-30  1:29 ` [PATCH v2 07/15] usb: misc: ezusb: " Anant Thazhemadam
2020-11-30  1:30 ` [PATCH v2 08/15] usb: misc: idmouse: " Anant Thazhemadam
2020-12-04 14:46   ` Johan Hovold
2021-01-07 14:06     ` Anant Thazhemadam
2020-11-30  1:31 ` [PATCH v2 09/15] usb: misc: iowarrior: update to use the usb_control_msg_{send|recv}() API Anant Thazhemadam
2020-11-30  1:31 ` [PATCH v2 10/15] usb: misc: isight_firmware: update to use usb_control_msg_send() Anant Thazhemadam
2020-11-30  1:32 ` [PATCH v2 11/15] usb: misc: ldusb: " Anant Thazhemadam
2020-11-30  1:32 ` [PATCH v2 12/15] usb: misc: lvstest: update to use the usb_control_msg_{send|recv}() API Anant Thazhemadam
2020-11-30  1:33 ` [PATCH v2 13/15] usb: misc: trancevibrator: update to use usb_control_msg_send() Anant Thazhemadam
2020-11-30  1:33 ` [PATCH v2 14/15] usb: misc: usbsevseg: " Anant Thazhemadam
2020-11-30  1:34 ` [PATCH v2 15/15] usb: misc: usbtest: update to use the usb_control_msg_{send|recv}() API Anant Thazhemadam

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=6806f8e4-c2f7-3c6a-b855-3f87ab8d9e22@gmail.com \
    --to=anant.thazhemadam@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=johan@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    /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.