| Message ID | 20190629094410.9106-1-cugyly@163.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v3] usb: core: message: remove memset in usb_get_descriptor() | expand |
On Sat, Jun 29, 2019 at 05:44:10PM +0800, yuan linyu wrote: > there is no need to clean buf at beginning of function, > when below condition occur, the buf will be dirty again. > if (result > 1 && ((u8 *)buf)[1] != type) { > result = -ENODATA; > continue; > } > > return negative result means buf is not valid. Yes, but why is removing the memset a required thing? What bug is this solving? What speed improvement can be seen by this change? Are you _sure_ that no code is relying on the fact that the buffer is cleaned out before sending the message and needs it to be zero terminated? We added that memset for a reason all those years ago, to just remove it now without a really good reason is worrying. thanks, greg k-h
diff --git a/drivers/usb/core/message.c b/drivers/usb/core/message.c index e844bb7b5676..03425e6b3da9 100644 --- a/drivers/usb/core/message.c +++ b/drivers/usb/core/message.c @@ -640,8 +640,6 @@ int usb_get_descriptor(struct usb_device *dev, unsigned char type, int i; int result; - memset(buf, 0, size); /* Make sure we parse really received data */ - for (i = 0; i < 3; ++i) { /* retry on length 0 or error; some devices are flakey */ result = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
there is no need to clean buf at beginning of function, when below condition occur, the buf will be dirty again. if (result > 1 && ((u8 *)buf)[1] != type) { result = -ENODATA; continue; } return negative result means buf is not valid. Signed-off-by: yuan linyu <cugyly@163.com> --- v3: enhance comment v2: enhance comment --- drivers/usb/core/message.c | 2 -- 1 file changed, 2 deletions(-)