Hi Balbi, On 10/08/16 12:24, Felipe Balbi wrote: > > Hi, > > Baolin Wang <baolin.wang@xxxxxxxxxx> writes: >> On 26 July 2016 at 07:15, Felipe F. Tonello <eu@xxxxxxxxxxxxxxxxx> wrote: >>> USB spec specifies wMaxPacketSize to be little endian (as other properties), >>> so when using this variable in the driver we should convert to the current >>> CPU endianness if necessary. >>> >>> Signed-off-by: Felipe F. Tonello <eu@xxxxxxxxxxxxxxxxx> >>> --- >>> drivers/usb/gadget/function/f_midi.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/drivers/usb/gadget/function/f_midi.c b/drivers/usb/gadget/function/f_midi.c >>> index 58fc199a18ec..a83d852b1da5 100644 >>> --- a/drivers/usb/gadget/function/f_midi.c >>> +++ b/drivers/usb/gadget/function/f_midi.c >>> @@ -362,7 +362,7 @@ static int f_midi_set_alt(struct usb_function *f, unsigned intf, unsigned alt) >>> struct usb_request *req = >>> midi_alloc_ep_req(midi->out_ep, >>> max_t(unsigned, midi->buflen, >>> - bulk_out_desc.wMaxPacketSize)); >>> + le16_to_cpu(bulk_out_desc.wMaxPacketSize))); >> >> I think here we should use usb_ep_align_maybe() function instead of >> max_t() to handle 'quirk_ep_out_aligned_size' quirk, please see the >> patch I've send out: https://lkml.org/lkml/2016/7/12/106 > > agree, if usb_ep_align_maybe() has a bug with endianness, let's fix it > since there are other gadgets using usb_ep_align_maybe() > Can you take a look at v4 of this patchset, please? It's the latest stuff I have sent. -- Felipe
Attachment:
0x92698E6A.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
