From: balbi@kernel.org (Felipe Balbi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH linux-next v2 1/1] usb: gadget: udc: atmel: Update endpoint allocation scheme
Date: Fri, 27 Jan 2017 17:01:53 +0200 [thread overview]
Message-ID: <878tpw7di6.fsf@linux.intel.com> (raw)
In-Reply-To: <e7d44f0d-d51a-316f-98b1-1582c60f2cac@microchip.com>
Hi,
Cristian Birsan <cristian.birsan@microchip.com> writes:
>>> + /* It might be a little bit late to set this */
>>
>> Is it too late or not? This comment is frightening... We may need some
>> feedback from the USB guys here...
>>
>
> If someone from USB can comment a bit on this topic I will be grateful.
it is not too late :-) Just look at the implementation of
usb_ep_autoconfig_ss(). That said, I haven't considered if gadget
drivers might want this value to be valid before calling
usb_ep_autoconfig_ss(). I can't see why they would, but still; just a
little warning.
struct usb_ep *usb_ep_autoconfig_ss(
struct usb_gadget *gadget,
struct usb_endpoint_descriptor *desc,
struct usb_ss_ep_comp_descriptor *ep_comp
)
{
struct usb_ep *ep;
u8 type;
type = desc->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK;
if (gadget->ops->match_ep) {
ep = gadget->ops->match_ep(gadget, desc, ep_comp);
if (ep)
goto found_ep;
}
/* Second, look at endpoints until an unclaimed one looks usable */
list_for_each_entry (ep, &gadget->ep_list, ep_list) {
if (usb_gadget_ep_match_desc(gadget, ep, desc, ep_comp))
goto found_ep;
}
/* Fail */
return NULL;
found_ep:
/*
* If the protocol driver hasn't yet decided on wMaxPacketSize
* and wants to know the maximum possible, provide the info.
*/
if (desc->wMaxPacketSize == 0)
desc->wMaxPacketSize = cpu_to_le16(ep->maxpacket_limit);
/* report address */
desc->bEndpointAddress &= USB_DIR_IN;
if (isdigit(ep->name[2])) {
u8 num = simple_strtoul(&ep->name[2], NULL, 10);
desc->bEndpointAddress |= num;
} else if (desc->bEndpointAddress & USB_DIR_IN) {
if (++gadget->in_epnum > 15)
return NULL;
desc->bEndpointAddress = USB_DIR_IN | gadget->in_epnum;
} else {
if (++gadget->out_epnum > 15)
return NULL;
desc->bEndpointAddress |= gadget->out_epnum;
}
/* report (variable) full speed bulk maxpacket */
if ((type == USB_ENDPOINT_XFER_BULK) && !ep_comp) {
int size = ep->maxpacket_limit;
/* min() doesn't work on bitfields with gcc-3.5 */
if (size > 64)
size = 64;
desc->wMaxPacketSize = cpu_to_le16(size);
}
ep->address = desc->bEndpointAddress;
ep->desc = NULL;
ep->comp_desc = NULL;
ep->claimed = true;
return ep;
}
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170127/fa9be2a4/attachment.sig>
WARNING: multiple messages have this Message-ID (diff)
From: Felipe Balbi <balbi@kernel.org>
To: Cristian Birsan <cristian.birsan@microchip.com>,
Nicolas Ferre <nicolas.ferre@atmel.com>,
gregkh@linuxfoundation.org, linux-arm-kernel@lists.infradead.org,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: ludovic.desroches@atmel.com,
alexandre.belloni@free-electrons.com,
boris.brezillon@free-electrons.com
Subject: Re: [PATCH linux-next v2 1/1] usb: gadget: udc: atmel: Update endpoint allocation scheme
Date: Fri, 27 Jan 2017 17:01:53 +0200 [thread overview]
Message-ID: <878tpw7di6.fsf@linux.intel.com> (raw)
In-Reply-To: <e7d44f0d-d51a-316f-98b1-1582c60f2cac@microchip.com>
[-- Attachment #1: Type: text/plain, Size: 2329 bytes --]
Hi,
Cristian Birsan <cristian.birsan@microchip.com> writes:
>>> + /* It might be a little bit late to set this */
>>
>> Is it too late or not? This comment is frightening... We may need some
>> feedback from the USB guys here...
>>
>
> If someone from USB can comment a bit on this topic I will be grateful.
it is not too late :-) Just look at the implementation of
usb_ep_autoconfig_ss(). That said, I haven't considered if gadget
drivers might want this value to be valid before calling
usb_ep_autoconfig_ss(). I can't see why they would, but still; just a
little warning.
struct usb_ep *usb_ep_autoconfig_ss(
struct usb_gadget *gadget,
struct usb_endpoint_descriptor *desc,
struct usb_ss_ep_comp_descriptor *ep_comp
)
{
struct usb_ep *ep;
u8 type;
type = desc->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK;
if (gadget->ops->match_ep) {
ep = gadget->ops->match_ep(gadget, desc, ep_comp);
if (ep)
goto found_ep;
}
/* Second, look at endpoints until an unclaimed one looks usable */
list_for_each_entry (ep, &gadget->ep_list, ep_list) {
if (usb_gadget_ep_match_desc(gadget, ep, desc, ep_comp))
goto found_ep;
}
/* Fail */
return NULL;
found_ep:
/*
* If the protocol driver hasn't yet decided on wMaxPacketSize
* and wants to know the maximum possible, provide the info.
*/
if (desc->wMaxPacketSize == 0)
desc->wMaxPacketSize = cpu_to_le16(ep->maxpacket_limit);
/* report address */
desc->bEndpointAddress &= USB_DIR_IN;
if (isdigit(ep->name[2])) {
u8 num = simple_strtoul(&ep->name[2], NULL, 10);
desc->bEndpointAddress |= num;
} else if (desc->bEndpointAddress & USB_DIR_IN) {
if (++gadget->in_epnum > 15)
return NULL;
desc->bEndpointAddress = USB_DIR_IN | gadget->in_epnum;
} else {
if (++gadget->out_epnum > 15)
return NULL;
desc->bEndpointAddress |= gadget->out_epnum;
}
/* report (variable) full speed bulk maxpacket */
if ((type == USB_ENDPOINT_XFER_BULK) && !ep_comp) {
int size = ep->maxpacket_limit;
/* min() doesn't work on bitfields with gcc-3.5 */
if (size > 64)
size = 64;
desc->wMaxPacketSize = cpu_to_le16(size);
}
ep->address = desc->bEndpointAddress;
ep->desc = NULL;
ep->comp_desc = NULL;
ep->claimed = true;
return ep;
}
--
balbi
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2017-01-27 15:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-23 14:45 [PATCH linux-next v2 0/1] usb: gadget: udc: atmel: Update endpoint allocation scheme cristian.birsan at microchip.com
2017-01-23 14:45 ` cristian.birsan
2017-01-23 14:45 ` [PATCH linux-next v2 1/1] " cristian.birsan at microchip.com
2017-01-23 14:45 ` cristian.birsan
2017-01-26 15:02 ` Nicolas Ferre
2017-01-26 15:02 ` Nicolas Ferre
2017-01-27 9:07 ` Felipe Balbi
2017-01-27 9:07 ` Felipe Balbi
2017-01-27 13:47 ` Cristian Birsan
2017-01-27 13:47 ` Cristian Birsan
2017-01-27 14:56 ` Nicolas Ferre
2017-01-27 14:56 ` Nicolas Ferre
2017-01-27 15:01 ` Felipe Balbi [this message]
2017-01-27 15:01 ` Felipe Balbi
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=878tpw7di6.fsf@linux.intel.com \
--to=balbi@kernel.org \
--cc=linux-arm-kernel@lists.infradead.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.