On 01/11/20 2:41 am, Jakub Kicinski wrote:
> On Thu, 29 Oct 2020 18:52:56 +0530 Anant Thazhemadam wrote:
>> +return usb_control_msg_recv(dev->udev, 0,
>> + cmd, reqtype, value, index, data, size,
>> + USB_CTRL_GET_TIMEOUT, GFP_KERNEL);
> Pleas
On Thu, 29 Oct 2020 18:52:56 +0530 Anant Thazhemadam wrote:
> + return usb_control_msg_recv(dev->udev, 0,
> + cmd, reqtype, value, index, data, size,
> + USB_CTRL_GET_TIMEOUT, GFP_KERNEL);
Please align continuation lines after the opening bra
On Thu, Oct 29, 2020 at 08:46:59PM +0530, Anant Thazhemadam wrote:
> I had a v2 prepared and ready but was told to wait for a week before sending
> it in,
> since usb_control_msg_{send|recv}() that were being used were not present in
> the
> networking tree at the time, and all the trees would be
On 29/10/20 6:52 pm, Anant Thazhemadam wrote:
> Currently, __usbnet_{read|write}_cmd() use usb_control_msg(),
> and thus consider potential partial reads/writes being done to
> be perfectly valid.
> Quite a few callers of usbnet_{read|write}_cmd() don't enforce
> checking for partial reads/write
Currently, __usbnet_{read|write}_cmd() use usb_control_msg(),
and thus consider potential partial reads/writes being done to
be perfectly valid.
Quite a few callers of usbnet_{read|write}_cmd() don't enforce
checking for partial reads/writes into account either, automatically
assuming that a compl