On 11/26/2014 02:21 PM, Amit Virdi wrote:
>> - if ISOC is not available, we won't have INT as well.
> 
> I didn't understand this. The original patch added a new alternate
> setting (2) that has two interrupt endpoints. ISOC EP is available
> through alternate setting 1.

The ISOC code does this:
 no_iso:
                 /*
                  * We still want to work even if the UDC doesn't have isoc
                  * endpoints, so null out the alt interface that contains
                  * them and continue.
                  */
                 fs_source_sink_descs[FS_ALT_IFC_1_OFFSET] = NULL;
                 hs_source_sink_descs[HS_ALT_IFC_1_OFFSET] = NULL;
                 ss_source_sink_descs[SS_ALT_IFC_1_OFFSET] = NULL;

That means the descriptor is terminated early:
 static struct usb_descriptor_header *fs_source_sink_descs[] = {
         (struct usb_descriptor_header *) &source_sink_intf_alt0,
         (struct usb_descriptor_header *) &fs_sink_desc,
         (struct usb_descriptor_header *) &fs_source_desc,
=>         (struct usb_descriptor_header *) &source_sink_intf_alt1,
 #define FS_ALT_IFC_1_OFFSET     3

That means "no ISOC" will NULL the fourth descriptor and there is no
alt1 including your alt2. Those descs won't be passed to the host. It
was "okay" while it was ISOC only but now "disabling" ISOC means no INT
either.

>> - wMaxPacketSize is supposed to be LE. The assignments within the code
>>    does not use cpu_to_le16().
> 
> Can you please point to the code where it should have been and is missing?

You look for each assignment to wMaxPacketSize and you will notice that
the cpu_to_le16 isn't used:

         /* fill in the FS isoc descriptors from the module parameters */
         fs_iso_source_desc.wMaxPacketSize = isoc_maxpacket > 1023 ?
                                                 1023 : isoc_maxpacket;

this one example, the very same is true for your copy/pasted INT
handling.

> Regards
> Amit Virdi
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to