Re: [PATCH 00/21] On-demand device registration
On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso wrote: > On 2 June 2015 at 10:48, Linus Walleij wrote: >> This is what systemd is doing in userspace for starting services: >> ask for your dependencies and wait for them if they are not >> there. So drivers ask for resources and wait for them. It also >> needs to be abstract, so for example we need to be able to >> hang on regulator_get() until the driver is up and providing that >> regulator, and as long as everything is in slowpath it should >> be OK. (And vice versa mutatis mutandis for clk, gpio, pin >> control, interrupts (!) and DMA channels for example.) > > I understood above that you propose probing devices in order, but now > you mention that resource getters would block until the dependency is > fulfilled which confuses me because if we are probing in order then > all dependencies would be fulfilled before the device in question gets > probed. Sorry, the problem space is a bit convoluted so the answers get a bit convoluted. Maybe I'm thinking aloud and altering the course of my thoughts as I type... I guess there can be explicit dependencies for resources like this patch does, but another way would be for all resource fetch functions to be instrumented, so that you do not block until you try to take a resource that is not yet there, e.g.: regulator_get(...) -> not available, so: - identify target regulator provider - this will need instrumentation - probe it It then turns out the regulator driver is on the i2c bus, so we need to probe the i2c driver: - identify target i2c host for the regulator driver - this will need instrumentation - probe the i2c host driver i2c host comes out, probes the regulator driver, regulator driver probes and then the regulator_get() call returns. This requires instrumentation on anything providing a resource to another driver like those I mentioned and a lot of overhead infrastructure, but I think it's the right approach. However I don't know if I would ever be able to pull that off myself, I know talk is cheap and I should show the code instead. Deepest respect for your efforts! Yours, Linus Walleij -- 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
Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties
On Tue, 9 Jun 2015 11:33:11 -0500 Rob Herring wrote: > On Tue, Jun 9, 2015 at 10:29 AM, Roger Quadros wrote: > > Rob, > > > > On Tue, 9 Jun 2015 08:26:20 -0500 > > Rob Herring wrote: > > > >> On Mon, Jun 8, 2015 at 8:18 PM, Li Jun wrote: > >> > On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote: > >> >> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun wrote: > >> >> > Add otg version, srp, hnp and adp support for usb OTG port, then > >> >> > those OTG > >> >> > features don't have to be decided by usb gadget drivers. > >> >> > > >> >> > Signed-off-by: Li Jun > >> >> > --- > >> >> > Documentation/devicetree/bindings/usb/generic.txt | 10 ++ > >> >> > 1 file changed, 10 insertions(+) > >> >> > > >> >> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt > >> >> > b/Documentation/devicetree/bindings/usb/generic.txt > >> >> > index 477d5bb..7386f4a 100644 > >> >> > --- a/Documentation/devicetree/bindings/usb/generic.txt > >> >> > +++ b/Documentation/devicetree/bindings/usb/generic.txt > >> >> > @@ -11,6 +11,12 @@ Optional properties: > >> >> > "peripheral" and "otg". In case this > >> >> > attribute isn't > >> >> > passed via DT, USB DRD controllers should > >> >> > default to > >> >> > OTG. > >> >> > + - otg-rev: tells usb driver the release number of the OTG and EH > >> >> > supplement > >> >> > + with which the device and its descriptors are > >> >> > compliant, > >> >> > + in binary-coded decimal (i.e. 2.0 is 0200H). > >> >> > >> >> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w > >> >> dependency or a driver feature? > >> >> > >> > Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a > >> > new > >> > member bcdOTG to identify the OTG version, this descriptor needs to be > >> > sent > >> > to OTG host with correct size and content, so we have to know which > >> > release > >> > version the OTG device is compliant with, either by menuconfig config or > >> > pass > >> > via DT. > >> > >> So you have to change the version depending on the host you are > >> connected to? That really seems strange that plugging in a OTG 2.0 > >> device to an OTG 1.3 host would not work and doesn't make for a good > >> user experience. > > > > No. The OTG version in the OTG descriptor for any device is usually fixed > > for the > > lifetime of the product. > > > > Let's assume it is 2.0. > > > > If you plug this to OTG 1.0 host, it won't be an issue as OTG 1.0 host > > doesn't > > read the BCD version. > > That makes sense, but there was some discussion about the size mattering. > > So is there a reason not to always report 2.0 with any kernel that has > 2.0 support? A 2.0 host would still need to know if the attached OTG device is 1.0 or 2.0 so we don't want to force existing 1.0 devices to 2.0. > > >> > >> >> > + - srp-support: tells OTG controllers we want to enable SRP. > >> >> > + - hnp-support: tells OTG controllers we want to enable HNP. > >> >> > + - adp-support: tells OTG controllers we want to enable ADP. > >> >> > >> >> I've recently run into a problem[1] and found that I have to disable > >> >> OTG in the kernel to get my device to work. Having to turn-off OTG > >> >> seems like the wrong solution, and shifting the problem to DT seems > >> >> wrong too. Why is this not a user configurable option (within whatever > >> >> h/w constraints there are)? > >> > The problem of below link, seems your device is claiming it's a HNP > >> > capable > >> > OTG device, but connecting to a non-OTG port of your Host, assume your > >> > Host > >> > does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your > >> > OTG device to remind it can use another port with HNP, but the request > >> > failed > >> > (maybe STALL by your device, this request is defined in OTG 1.3 but > >> > obsolete > >> > in OTG 2.0), so your Host just stopped enumeration of your device, this > >> > is not > >> > reasonable because current OTG code is some out of data. > >> > >> Do PCs have OTG ports typically? My expectation is that if I plug in > >> an OTG device as a B device to any host port, that it will work as a > >> device no matter what the host OTG capabilities are. If I have to > >> change the kernel config or DT, that is a problem. > > > > AFAIK PCs don't have OTG ports. > > > > If you plug in OTG device to a non-otg host port it will work as normal > > B-device. > > The host doesn't request for OTG descriptors and doesn't care what OTG > > features it > > supports or not. > > That is what I would expect. My testing and the bug report show otherwise. what kernel and platform are you on? > > >> > I am trying to make those OTG feaures to be configurable options, you > >> > mean > >> > by sys? > >> > >> Yes. > > > > why do you need OTG features to be sysfs configurable other than for > > debugging? > > I don't know. Buggy host
Re: Patch Request of option.c module to support Olicard-300 (2020:4000)
Lars Melin wrote:
> If these hints to "Joe" justifies a Suggested-by then he can add me,
> info is in this mails header.
>
> I do however not agree to the place where "Joe" has stuck it into the
> usb_device_id list, it should not be among
> the other Olivetti entries but further down among numeric value vid:pid
> entries.
>
> /Lars
Thank you Lars for your answer! :)
Here we have an other hint, I could shift down my Olicard entry before submit
the patch... no problem.
Here we are:
---
--- linux/drivers/usb/serial/option.c.orig 2015-06-10 10:42:43.0
+0200
+++ linux/drivers/usb/serial/option.c 2015-06-10 10:53:06.825265579 +0200
@@ -1765,6 +1765,7 @@ static const struct usb_device_id option
{ USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x7d03, 0xff, 0x00, 0x00) },
{ USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e01, 0xff, 0xff, 0xff) }, /*
D-Link DWM-152/C1 */
{ USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e02, 0xff, 0xff, 0xff) }, /*
D-Link DWM-156/C1 */
+ { USB_DEVICE_INTERFACE_CLASS(0x2020, 0x4000, 0xff) },/*
OLICARD300 - MT6225 */
{ USB_DEVICE(INOVIA_VENDOR_ID, INOVIA_SEW858) },
{ USB_DEVICE(VIATELECOM_VENDOR_ID, VIATELECOM_PRODUCT_CDS7) },
{ } /* Terminating entry */
---
What do you think about?
Could be a better placement?
Let me know,
thanks again! :)
--
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
[PATCH 0/5] usb: dwc3: handle non maxpacket aligned transfers > 512
Patch series adds support to handle non maxpacket aligned transfers greater than bounce buffer size (512). It first adds chained TRB support and then uses it to handle non maxpacket aligned transfers greater than bounce buffer size. Also included a cleanup patch to use 'roundup' macro. This series is created after applying [1] Non maxpacket aligned transfers can be initiated by "./testusb -t 14 -c 1 -s 520 -v 1" Before this series: unknown speed /dev/bus/usb/001/0180 /dev/bus/usb/001/018 test 14 --> 110 (Connection timed out) After this series: unknown speed /dev/bus/usb/001/0230 /dev/bus/usb/001/023 test 14,0.000486 secs Tested this patch using USB3 Gen X CV (ch9 tests: usb2 and usb3, link layer testing and MSC tests) and using USB2 X CV (ch9 tests, MSC tests) and verified this doesn't cause additional failures. Lecroy compliance tests fail even without this patch series so deferred testing it. [1] -> http://permalink.gmane.org/gmane.linux.kernel/1972684 Kishon Vijay Abraham I (5): usb: dwc3: ep0: use _roundup_ to calculate the transfer size usb: dwc3: ep0: preparation for handling non maxpacket aligned transfers > 512 usb: dwc3; ep0: Modify _dwc3_ep0_start_trans_ API to take 'chain' parameter usb: dwc3: ep0: Add chained TRB support usb: dwc3: ep0: handle non maxpacket aligned transfers > 512 drivers/usb/dwc3/ep0.c| 94 ++--- drivers/usb/dwc3/gadget.c |2 +- 2 files changed, 64 insertions(+), 32 deletions(-) -- 1.7.9.5 -- 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
[PATCH 1/5] usb: dwc3: ep0: use _roundup_ to calculate the transfer size
No functional change. Used _roundup_ macro to calculate the transfer
size aligned to maxpacket in dwc3_ep0_complete_data. It also makes it
similar to how transfer size is calculated in __dwc3_ep0_do_control_data.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/dwc3/ep0.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 8858c60..713e46a 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -812,10 +812,8 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
length = trb->size & DWC3_TRB_SIZE_MASK;
if (dwc->ep0_bounced) {
- unsigned transfer_size = ur->length;
unsigned maxp = ep0->endpoint.maxpacket;
-
- transfer_size += (maxp - (transfer_size % maxp));
+ unsigned transfer_size = roundup(ur->length, maxp);
/* Maximum of DWC3_EP0_BOUNCE_SIZE can only be received */
if (transfer_size > DWC3_EP0_BOUNCE_SIZE)
--
1.7.9.5
--
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
[PATCH 3/5] usb: dwc3; ep0: Modify _dwc3_ep0_start_trans_ API to take 'chain' parameter
No functional change. Added a new parameter in _dwc3_ep0_start_trans_ to
indicate whether the TRB is a chained TRB or last TRB. This is in
preparation for adding chained TRB support for ep0.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/dwc3/ep0.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 4998074..d1a2be1 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -56,7 +56,7 @@ static const char *dwc3_ep0_state_string(enum dwc3_ep0_state
state)
}
static int dwc3_ep0_start_trans(struct dwc3 *dwc, u8 epnum, dma_addr_t buf_dma,
- u32 len, u32 type)
+ u32 len, u32 type, unsigned chain)
{
struct dwc3_gadget_ep_cmd_params params;
struct dwc3_trb *trb;
@@ -302,7 +302,7 @@ void dwc3_ep0_out_start(struct dwc3 *dwc)
int ret;
ret = dwc3_ep0_start_trans(dwc, 0, dwc->ctrl_req_addr, 8,
- DWC3_TRBCTL_CONTROL_SETUP);
+ DWC3_TRBCTL_CONTROL_SETUP, false);
WARN_ON(ret < 0);
}
@@ -851,7 +851,7 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
ret = dwc3_ep0_start_trans(dwc, epnum,
dwc->ctrl_req_addr, 0,
- DWC3_TRBCTL_CONTROL_DATA);
+ DWC3_TRBCTL_CONTROL_DATA, false);
WARN_ON(ret < 0);
}
}
@@ -935,7 +935,7 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
if (req->request.length == 0) {
ret = dwc3_ep0_start_trans(dwc, dep->number,
dwc->ctrl_req_addr, 0,
- DWC3_TRBCTL_CONTROL_DATA);
+ DWC3_TRBCTL_CONTROL_DATA, false);
} else if (!IS_ALIGNED(req->request.length, dep->endpoint.maxpacket)
&& (dep->number == 0)) {
u32 transfer_size = 0;
@@ -966,7 +966,7 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
*/
ret = dwc3_ep0_start_trans(dwc, dep->number,
dwc->ep0_bounce_addr, transfer_size,
- DWC3_TRBCTL_CONTROL_DATA);
+ DWC3_TRBCTL_CONTROL_DATA, false);
} else {
ret = usb_gadget_map_request(&dwc->gadget, &req->request,
dep->number);
@@ -976,7 +976,8 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
}
ret = dwc3_ep0_start_trans(dwc, dep->number, req->request.dma,
- req->request.length, DWC3_TRBCTL_CONTROL_DATA);
+ req->request.length, DWC3_TRBCTL_CONTROL_DATA,
+ false);
}
WARN_ON(ret < 0);
@@ -991,7 +992,7 @@ static int dwc3_ep0_start_control_status(struct dwc3_ep
*dep)
: DWC3_TRBCTL_CONTROL_STATUS2;
return dwc3_ep0_start_trans(dwc, dep->number,
- dwc->ctrl_req_addr, 0, type);
+ dwc->ctrl_req_addr, 0, type, false);
}
static void __dwc3_ep0_do_control_status(struct dwc3 *dwc, struct dwc3_ep *dep)
--
1.7.9.5
--
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
[PATCH 5/5] usb: dwc3: ep0: handle non maxpacket aligned transfers > 512
Use chained TRB mechanism to handle non maxpacket aligned transfers
greater than bounce buffer size. With this the first TRB will be programmed
to receive 'ALIGN(ur->length - maxp, maxp)' data and the second TRB
will be programmed to receive the remaining data using bounce buffer.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/dwc3/ep0.c | 42 --
1 file changed, 28 insertions(+), 14 deletions(-)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 6847afe..4c777fe 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -830,13 +830,26 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
maxp = ep0->endpoint.maxpacket;
if (dwc->ep0_bounced) {
+ /*
+* Handle the first TRB before handling the bounce buffer if
+* the request length is greater than the bounce buffer size
+*/
+ if (ur->length > DWC3_EP0_BOUNCE_SIZE) {
+ transfer_size = ALIGN(ur->length - maxp, maxp);
+ transferred = transfer_size - length;
+ buf = (u8 *)buf + transferred;
+ ur->actual += transferred;
+ remaining_ur_length -= transferred;
+
+ trb++;
+ length = trb->size & DWC3_TRB_SIZE_MASK;
+
+ ep0->free_slot = 0;
+ }
+
transfer_size = roundup((ur->length - transfer_size),
maxp);
- /* Maximum of DWC3_EP0_BOUNCE_SIZE can only be received */
- if (transfer_size > DWC3_EP0_BOUNCE_SIZE)
- transfer_size = DWC3_EP0_BOUNCE_SIZE;
-
transferred = min_t(u32, remaining_ur_length,
transfer_size - length);
memcpy(buf, dwc->ep0_bounce, transferred);
@@ -959,21 +972,22 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
}
maxpacket = dep->endpoint.maxpacket;
- transfer_size = roundup((req->request.length - transfer_size),
- maxpacket);
- if (transfer_size > DWC3_EP0_BOUNCE_SIZE) {
- dev_WARN(dwc->dev, "bounce buf can't handle req len\n");
- transfer_size = DWC3_EP0_BOUNCE_SIZE;
+ if (req->request.length > DWC3_EP0_BOUNCE_SIZE) {
+ transfer_size = ALIGN(req->request.length - maxpacket,
+ maxpacket);
+ ret = dwc3_ep0_start_trans(dwc, dep->number,
+ req->request.dma,
+ transfer_size,
+ DWC3_TRBCTL_CONTROL_DATA,
+ true);
}
+ transfer_size = roundup((req->request.length - transfer_size),
+ maxpacket);
+
dwc->ep0_bounced = true;
- /*
-* REVISIT in case request length is bigger than
-* DWC3_EP0_BOUNCE_SIZE we will need two chained
-* TRBs to handle the transfer.
-*/
ret = dwc3_ep0_start_trans(dwc, dep->number,
dwc->ep0_bounce_addr, transfer_size,
DWC3_TRBCTL_CONTROL_DATA, false);
--
1.7.9.5
--
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
[PATCH 2/5] usb: dwc3: ep0: preparation for handling non maxpacket aligned transfers > 512
No functional change. This is in preparation for handling non maxpacket
aligned transfers greater than bounce buffer size. This is basically to
avoid code duplication when using chained TRB transfers to handle
non maxpacket aligned transfers greater than bounce buffer size.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/dwc3/ep0.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 713e46a..4998074 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -779,7 +779,11 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
struct usb_request *ur;
struct dwc3_trb *trb;
struct dwc3_ep *ep0;
- u32 transferred;
+ unsignedtransfer_size = 0;
+ unsignedmaxp;
+ unsignedremaining_ur_length;
+ void*buf;
+ u32 transferred = 0;
u32 status;
u32 length;
u8 epnum;
@@ -808,20 +812,24 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
}
ur = &r->request;
+ buf = ur->buf;
+ remaining_ur_length = ur->length;
length = trb->size & DWC3_TRB_SIZE_MASK;
+ maxp = ep0->endpoint.maxpacket;
+
if (dwc->ep0_bounced) {
- unsigned maxp = ep0->endpoint.maxpacket;
- unsigned transfer_size = roundup(ur->length, maxp);
+ transfer_size = roundup((ur->length - transfer_size),
+ maxp);
/* Maximum of DWC3_EP0_BOUNCE_SIZE can only be received */
if (transfer_size > DWC3_EP0_BOUNCE_SIZE)
transfer_size = DWC3_EP0_BOUNCE_SIZE;
- transferred = min_t(u32, ur->length,
- transfer_size - length);
- memcpy(ur->buf, dwc->ep0_bounce, transferred);
+ transferred = min_t(u32, remaining_ur_length,
+ transfer_size - length);
+ memcpy(buf, dwc->ep0_bounce, transferred);
} else {
transferred = ur->length - length;
}
@@ -930,7 +938,7 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
DWC3_TRBCTL_CONTROL_DATA);
} else if (!IS_ALIGNED(req->request.length, dep->endpoint.maxpacket)
&& (dep->number == 0)) {
- u32 transfer_size;
+ u32 transfer_size = 0;
u32 maxpacket;
ret = usb_gadget_map_request(&dwc->gadget, &req->request,
@@ -941,7 +949,8 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
}
maxpacket = dep->endpoint.maxpacket;
- transfer_size = roundup(req->request.length, maxpacket);
+ transfer_size = roundup((req->request.length - transfer_size),
+ maxpacket);
if (transfer_size > DWC3_EP0_BOUNCE_SIZE) {
dev_WARN(dwc->dev, "bounce buf can't handle req len\n");
--
1.7.9.5
--
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
[PATCH 4/5] usb: dwc3: ep0: Add chained TRB support
Add chained TRB support to ep0. Now TRB's can be chained just by
invoking _dwc3_ep0_start_trans_ with 'chain' parameter set to true.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/dwc3/ep0.c| 16 +---
drivers/usb/dwc3/gadget.c |2 +-
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index d1a2be1..6847afe 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
@@ -70,7 +70,10 @@ static int dwc3_ep0_start_trans(struct dwc3 *dwc, u8 epnum,
dma_addr_t buf_dma,
return 0;
}
- trb = dwc->ep0_trb;
+ trb = &dwc->ep0_trb[dep->free_slot];
+
+ if (chain)
+ dep->free_slot++;
trb->bpl = lower_32_bits(buf_dma);
trb->bph = upper_32_bits(buf_dma);
@@ -78,10 +81,17 @@ static int dwc3_ep0_start_trans(struct dwc3 *dwc, u8 epnum,
dma_addr_t buf_dma,
trb->ctrl = type;
trb->ctrl |= (DWC3_TRB_CTRL_HWO
- | DWC3_TRB_CTRL_LST
- | DWC3_TRB_CTRL_IOC
| DWC3_TRB_CTRL_ISP_IMI);
+ if (chain)
+ trb->ctrl |= DWC3_TRB_CTRL_CHN;
+ else
+ trb->ctrl |= (DWC3_TRB_CTRL_IOC
+ | DWC3_TRB_CTRL_LST);
+
+ if (chain)
+ return 0;
+
memset(¶ms, 0, sizeof(params));
params.param0 = upper_32_bits(dwc->ep0_trb_addr);
params.param1 = lower_32_bits(dwc->ep0_trb_addr);
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index 8946c32..b8d0a84 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2677,7 +2677,7 @@ int dwc3_gadget_init(struct dwc3 *dwc)
goto err0;
}
- dwc->ep0_trb = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ep0_trb),
+ dwc->ep0_trb = dma_alloc_coherent(dwc->dev, sizeof(*dwc->ep0_trb) * 2,
&dwc->ep0_trb_addr, GFP_KERNEL);
if (!dwc->ep0_trb) {
dev_err(dwc->dev, "failed to allocate ep0 trb\n");
--
1.7.9.5
--
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
Re: Patch Request of option.c module to support Olicard-300 (2020:4000)
On 2015-06-10 15:59, Joe wrote:
Lars Melin wrote:
If these hints to "Joe" justifies a Suggested-by then he can add me,
info is in this mails header.
I do however not agree to the place where "Joe" has stuck it into the
usb_device_id list, it should not be among
the other Olivetti entries but further down among numeric value vid:pid
entries.
/Lars
Thank you Lars for your answer! :)
Here we have an other hint, I could shift down my Olicard entry before submit
the patch... no problem.
Here we are:
---
--- linux/drivers/usb/serial/option.c.orig 2015-06-10 10:42:43.0
+0200
+++ linux/drivers/usb/serial/option.c 2015-06-10 10:53:06.825265579 +0200
@@ -1765,6 +1765,7 @@ static const struct usb_device_id option
{ USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x7d03, 0xff, 0x00, 0x00) },
{ USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e01, 0xff, 0xff, 0xff) },
/* D-Link DWM-152/C1 */
{ USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e02, 0xff, 0xff, 0xff) },
/* D-Link DWM-156/C1 */
+ { USB_DEVICE_INTERFACE_CLASS(0x2020, 0x4000, 0xff) },/*
OLICARD300 - MT6225 */
{ USB_DEVICE(INOVIA_VENDOR_ID, INOVIA_SEW858) },
{ USB_DEVICE(VIATELECOM_VENDOR_ID, VIATELECOM_PRODUCT_CDS7) },
{ } /* Terminating entry */
---
What do you think about?
Could be a better placement?
Let me know,
thanks again! :)
Yes that is a better place for it.
I have added the usb serial maintainer as recipient since he is the one
who has the final say.
--
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
Re: [PATCH 00/21] On-demand device registration
On 10 June 2015 at 09:30, Linus Walleij wrote: > On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso > wrote: >> On 2 June 2015 at 10:48, Linus Walleij wrote: > >>> This is what systemd is doing in userspace for starting services: >>> ask for your dependencies and wait for them if they are not >>> there. So drivers ask for resources and wait for them. It also >>> needs to be abstract, so for example we need to be able to >>> hang on regulator_get() until the driver is up and providing that >>> regulator, and as long as everything is in slowpath it should >>> be OK. (And vice versa mutatis mutandis for clk, gpio, pin >>> control, interrupts (!) and DMA channels for example.) >> >> I understood above that you propose probing devices in order, but now >> you mention that resource getters would block until the dependency is >> fulfilled which confuses me because if we are probing in order then >> all dependencies would be fulfilled before the device in question gets >> probed. > > Sorry, the problem space is a bit convoluted so the answers > get a bit convoluted. Maybe I'm thinking aloud and altering the course > of my thoughts as I type... > > I guess there can be explicit dependencies for resources like this > patch does, but another way would be for all resource fetch functions > to be instrumented, so that you do not block until you try to take > a resource that is not yet there, e.g.: > > regulator_get(...) -> not available, so: > - identify target regulator provider - this will need instrumentation > - probe it > > It then turns out the regulator driver is on the i2c bus, so we > need to probe the i2c driver: > - identify target i2c host for the regulator driver - this will need > instrumentation > - probe the i2c host driver > > i2c host comes out, probes the regulator driver, regulator driver > probes and then the regulator_get() call returns. Hmm, if I understand correctly what you say, this is exactly what this particular series does: regulator_get -> of_platform_device_ensure -> probe() on the platform device that encloses the requested device node (i2c host) -> i2c slave gets probed and the regulator registered -> regulator_get returns the requested resource The downside I'm currently looking at is that an explicit dependency graph would be useful to have for other purposes. For example to print a neat warning when a dependency cannot be fulfilled. Or to refuse to unbind a device which other devices depend on, or to automatically unbind the devices that depend on it, or to print a warning if a device is hotplugged off and other devices depend on it. > This requires instrumentation on anything providing a resource > to another driver like those I mentioned and a lot of overhead > infrastructure, but I think it's the right approach. However I don't > know if I would ever be able to pull that off myself, I know talk > is cheap and I should show the code instead. Yeah, if you can give it a second look and say if it matches what you wrote above, it would be very much appreciated. > Deepest respect for your efforts! Thanks! Tomeu > Yours, > Linus Walleij > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- 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
[PATCH] usb: udc: Convert use of __constant_cpu_to_leXX to cpu_to_leXX
In big endian cases, the macro cpu_to_le{16,32} unfolds to __swab{16,32}
which provides special case for constants. In little endian cases,
__constant_cpu_to_le{16,32} and cpu_to_le{16,32} expand directly to
the same expression. So, replace __constant_cpu_to_le{16,32} with
cpu_to_le{16,32} with the goal of getting rid of the definition of
__constant_cpu_to_le{16,32} completely.
The semantic patch that performs this transformation is as follows:
@@expression x;@@
(
- __constant_cpu_to_le16(x)
+ cpu_to_le16(x)
|
- __constant_cpu_to_le32(x)
+ cpu_to_le32(x)
)
Signed-off-by: Vaishali Thakkar
---
drivers/usb/gadget/udc/net2272.c | 4 ++--
drivers/usb/gadget/udc/pch_udc.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/udc/net2272.c b/drivers/usb/gadget/udc/net2272.c
index 195baf3..c2ed5da 100644
--- a/drivers/usb/gadget/udc/net2272.c
+++ b/drivers/usb/gadget/udc/net2272.c
@@ -1826,9 +1826,9 @@ net2272_handle_stat0_irqs(struct net2272 *dev, u8 stat)
if (!e || u.r.wLength > 2)
goto do_stall;
if (net2272_ep_read(e, EP_RSPSET) & (1 <<
ENDPOINT_HALT))
- status = __constant_cpu_to_le16(1);
+ status = cpu_to_le16(1);
else
- status = __constant_cpu_to_le16(0);
+ status = cpu_to_le16(0);
/* don't bother with a request object! */
net2272_ep_write(&dev->ep[0], EP_IRQENB, 0);
diff --git a/drivers/usb/gadget/udc/pch_udc.c b/drivers/usb/gadget/udc/pch_udc.c
index 613547f..dcf5def 100644
--- a/drivers/usb/gadget/udc/pch_udc.c
+++ b/drivers/usb/gadget/udc/pch_udc.c
@@ -1793,7 +1793,7 @@ static struct usb_request *pch_udc_alloc_request(struct
usb_ep *usbep,
}
/* prevent from using desc. - set HOST BUSY */
dma_desc->status |= PCH_UDC_BS_HST_BSY;
- dma_desc->dataptr = __constant_cpu_to_le32(DMA_ADDR_INVALID);
+ dma_desc->dataptr = cpu_to_le32(DMA_ADDR_INVALID);
req->td_data = dma_desc;
req->td_data_last = dma_desc;
req->chain_len = 1;
--
1.9.1
--
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
Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties
On Tue, Jun 09, 2015 at 09:26:20PM +0800, Rob Herring wrote: > On Mon, Jun 8, 2015 at 8:18 PM, Li Jun wrote: > > On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote: > >> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun wrote: > >> > Add otg version, srp, hnp and adp support for usb OTG port, then those > >> > OTG > >> > features don't have to be decided by usb gadget drivers. > >> > > >> > Signed-off-by: Li Jun > >> > --- > >> > Documentation/devicetree/bindings/usb/generic.txt | 10 ++ > >> > 1 file changed, 10 insertions(+) > >> > > >> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt > >> > b/Documentation/devicetree/bindings/usb/generic.txt > >> > index 477d5bb..7386f4a 100644 > >> > --- a/Documentation/devicetree/bindings/usb/generic.txt > >> > +++ b/Documentation/devicetree/bindings/usb/generic.txt > >> > @@ -11,6 +11,12 @@ Optional properties: > >> > "peripheral" and "otg". In case this attribute > >> > isn't > >> > passed via DT, USB DRD controllers should > >> > default to > >> > OTG. > >> > + - otg-rev: tells usb driver the release number of the OTG and EH > >> > supplement > >> > + with which the device and its descriptors are > >> > compliant, > >> > + in binary-coded decimal (i.e. 2.0 is 0200H). > >> > >> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w > >> dependency or a driver feature? > >> > > Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a new > > member bcdOTG to identify the OTG version, this descriptor needs to be sent > > to OTG host with correct size and content, so we have to know which release > > version the OTG device is compliant with, either by menuconfig config or > > pass > > via DT. > > So you have to change the version depending on the host you are > connected to? That really seems strange that plugging in a OTG 2.0 > device to an OTG 1.3 host would not work and doesn't make for a good > user experience. > Depending on the OTG device itself with which release version it's compliant , then OTG 2.0 host can differentiate them and talk to it with right version protocol. Maybe most of OTG 2.0 devices design does not consider to be compatible with OTG 1.3 host, chipidea udc driver has fixed this issue with below patch: http://www.spinics.net/lists/stable-commits/msg43003.html > >> > + - srp-support: tells OTG controllers we want to enable SRP. > >> > + - hnp-support: tells OTG controllers we want to enable HNP. > >> > + - adp-support: tells OTG controllers we want to enable ADP. > >> > >> I've recently run into a problem[1] and found that I have to disable > >> OTG in the kernel to get my device to work. Having to turn-off OTG > >> seems like the wrong solution, and shifting the problem to DT seems > >> wrong too. Why is this not a user configurable option (within whatever > >> h/w constraints there are)? > > The problem of below link, seems your device is claiming it's a HNP capable > > OTG device, but connecting to a non-OTG port of your Host, assume your Host > > does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your > > OTG device to remind it can use another port with HNP, but the request > > failed > > (maybe STALL by your device, this request is defined in OTG 1.3 but obsolete > > in OTG 2.0), so your Host just stopped enumeration of your device, this is > > not > > reasonable because current OTG code is some out of data. > > Do PCs have OTG ports typically? My expectation is that if I plug in > an OTG device as a B device to any host port, that it will work as a > device no matter what the host OTG capabilities are. If I have to > change the kernel config or DT, that is a problem. Unfortunately current host code for OTG is some out of data and has not been updated for OTG 2.0, so cannot work well with OTG 2.0 device, but this can be another OTG topic. For now if your PC has no OTG port, you have to disable CONFIG_USB_OTG, otherwise it will assume you have a OTG port on your machine. > > > I am trying to make those OTG feaures to be configurable options, you mean > > by sys? > > Yes. > This kind of feature may not be able to enable/disable at runtime. E.g. ADP and SRP need OTG devices do pre-defined sequence when power up. > >> What are the valid combinations? When do we want these enabled or not? > >> Wouldn't default enabled be better? > > > > We want to enable all those support in kernel driver, but some platform or > > hardware may not want to enable any or some of them, so those hardware > > can disable it by not pass the property in dt, the 3 sub features of OTG are > > not mandatory for so called OTG device, normally we at least enable HNP, and > > SRP and ADP are optional. > > Please answer my questions in the doc. > > >> > >> We already have dr_mode property. How is it related to these? > > > > dr_mode is to tell the device it will work a
Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties
On Tue, Jun 09, 2015 at 11:29:31PM +0800, Roger Quadros wrote: > Rob, > > On Tue, 9 Jun 2015 08:26:20 -0500 > Rob Herring wrote: > > > On Mon, Jun 8, 2015 at 8:18 PM, Li Jun wrote: > > > On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote: > > >> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun wrote: > > >> > Add otg version, srp, hnp and adp support for usb OTG port, then those > > >> > OTG > > >> > features don't have to be decided by usb gadget drivers. > > >> > > > >> > Signed-off-by: Li Jun > > >> > --- > > >> > Documentation/devicetree/bindings/usb/generic.txt | 10 ++ > > >> > 1 file changed, 10 insertions(+) > > >> > > > >> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt > > >> > b/Documentation/devicetree/bindings/usb/generic.txt > > >> > index 477d5bb..7386f4a 100644 > > >> > --- a/Documentation/devicetree/bindings/usb/generic.txt > > >> > +++ b/Documentation/devicetree/bindings/usb/generic.txt > > >> > @@ -11,6 +11,12 @@ Optional properties: > > >> > "peripheral" and "otg". In case this attribute > > >> > isn't > > >> > passed via DT, USB DRD controllers should > > >> > default to > > >> > OTG. > > >> > + - otg-rev: tells usb driver the release number of the OTG and EH > > >> > supplement > > >> > + with which the device and its descriptors are > > >> > compliant, > > >> > + in binary-coded decimal (i.e. 2.0 is 0200H). > > >> > > >> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w > > >> dependency or a driver feature? > > >> > > > Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding a > > > new > > > member bcdOTG to identify the OTG version, this descriptor needs to be > > > sent > > > to OTG host with correct size and content, so we have to know which > > > release > > > version the OTG device is compliant with, either by menuconfig config or > > > pass > > > via DT. > > > > So you have to change the version depending on the host you are > > connected to? That really seems strange that plugging in a OTG 2.0 > > device to an OTG 1.3 host would not work and doesn't make for a good > > user experience. > > No. The OTG version in the OTG descriptor for any device is usually fixed for > the > lifetime of the product. > > Let's assume it is 2.0. > > If you plug this to OTG 1.0 host, it won't be an issue as OTG 1.0 host doesn't > read the BCD version. > But OTG 1.0 host will send a 1.x specific OTG request for the 2.0 device. > > > > >> > + - srp-support: tells OTG controllers we want to enable SRP. > > >> > + - hnp-support: tells OTG controllers we want to enable HNP. > > >> > + - adp-support: tells OTG controllers we want to enable ADP. > > >> > > >> I've recently run into a problem[1] and found that I have to disable > > >> OTG in the kernel to get my device to work. Having to turn-off OTG > > >> seems like the wrong solution, and shifting the problem to DT seems > > >> wrong too. Why is this not a user configurable option (within whatever > > >> h/w constraints there are)? > > > The problem of below link, seems your device is claiming it's a HNP > > > capable > > > OTG device, but connecting to a non-OTG port of your Host, assume your > > > Host > > > does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to your > > > OTG device to remind it can use another port with HNP, but the request > > > failed > > > (maybe STALL by your device, this request is defined in OTG 1.3 but > > > obsolete > > > in OTG 2.0), so your Host just stopped enumeration of your device, this > > > is not > > > reasonable because current OTG code is some out of data. > > > > Do PCs have OTG ports typically? My expectation is that if I plug in > > an OTG device as a B device to any host port, that it will work as a > > device no matter what the host OTG capabilities are. If I have to > > change the kernel config or DT, that is a problem. > > AFAIK PCs don't have OTG ports. > > If you plug in OTG device to a non-otg host port it will work as normal > B-device. > The host doesn't request for OTG descriptors and doesn't care what OTG > features it > supports or not. > This is not true in OTG 1.x and our current code, the host still request for OTG descriptor and check if HNP is supported by it if CONFIG_USB_OTG is enabled for the host. > > > > > I am trying to make those OTG feaures to be configurable options, you mean > > > by sys? > > > > Yes. > > why do you need OTG features to be sysfs configurable other than for > debugging? > > > > > >> What are the valid combinations? When do we want these enabled or not? > > >> Wouldn't default enabled be better? > > > > > > We want to enable all those support in kernel driver, but some platform or > > > hardware may not want to enable any or some of them, so those hardware > > > can disable it by not pass the property in dt, the 3 sub features of OTG > >
Re: [PATCH 00/21] On-demand device registration
On 06/10/2015 12:19 PM, Tomeu Vizoso wrote: > On 10 June 2015 at 09:30, Linus Walleij wrote: >> On Tue, Jun 2, 2015 at 12:14 PM, Tomeu Vizoso >> wrote: >>> On 2 June 2015 at 10:48, Linus Walleij wrote: >> This is what systemd is doing in userspace for starting services: ask for your dependencies and wait for them if they are not there. So drivers ask for resources and wait for them. It also needs to be abstract, so for example we need to be able to hang on regulator_get() until the driver is up and providing that regulator, and as long as everything is in slowpath it should be OK. (And vice versa mutatis mutandis for clk, gpio, pin control, interrupts (!) and DMA channels for example.) >>> >>> I understood above that you propose probing devices in order, but now >>> you mention that resource getters would block until the dependency is >>> fulfilled which confuses me because if we are probing in order then >>> all dependencies would be fulfilled before the device in question gets >>> probed. >> >> Sorry, the problem space is a bit convoluted so the answers >> get a bit convoluted. Maybe I'm thinking aloud and altering the course >> of my thoughts as I type... >> >> I guess there can be explicit dependencies for resources like this >> patch does, but another way would be for all resource fetch functions >> to be instrumented, so that you do not block until you try to take >> a resource that is not yet there, e.g.: >> >> regulator_get(...) -> not available, so: >> - identify target regulator provider - this will need instrumentation >> - probe it >> >> It then turns out the regulator driver is on the i2c bus, so we >> need to probe the i2c driver: >> - identify target i2c host for the regulator driver - this will need >> instrumentation >> - probe the i2c host driver >> >> i2c host comes out, probes the regulator driver, regulator driver >> probes and then the regulator_get() call returns. > > Hmm, if I understand correctly what you say, this is exactly what this > particular series does: > > regulator_get -> of_platform_device_ensure -> probe() on the platform > device that encloses the requested device node (i2c host) -> i2c slave > gets probed and the regulator registered -> regulator_get returns the > requested resource The downside of this solution is that it will not work without device tree or even without device dependencies not explicitly specified in device tree. > > The downside I'm currently looking at is that an explicit dependency > graph would be useful to have for other purposes. For example to print > a neat warning when a dependency cannot be fulfilled. Or to refuse to > unbind a device which other devices depend on, As I understand Greg you cannot prevent unbinding by design, see [1]. [1]: http://thread.gmane.org/gmane.linux.kernel/1154308/focus=1154648 > or to automatically > unbind the devices that depend on it, What about devices that have weak dependency? They should not be unbound but they should be somehow noticed about unbinding. In general many kernel frameworks are broken in handling hot-unbinding of drivers, consumers are not noticed about unbinding of their resource providers and usually they stay with broken handles or handles to dummy resources. I suspect the only proper solution for handling resources that can dynamically appear/disappear is to provide notification to their consumers about appearance change of the resource. I have proposed some times ago solution for above problems based on the statement above, cover letter explains it in more detail [2]. In short it solves following issues: - consumer receives resource as soon as it becomes available, - consumer is notified just before resource removal, - it can properly handle provider unbind/re-bind, - it avoids late init due to deferred probing, - it allows to track optional resources. [2]: http://thread.gmane.org/gmane.linux.kernel.gpio/5201 Regards Andrzej > or to print a warning if a > device is hotplugged off and other devices depend on it. > >> This requires instrumentation on anything providing a resource >> to another driver like those I mentioned and a lot of overhead >> infrastructure, but I think it's the right approach. However I don't >> know if I would ever be able to pull that off myself, I know talk >> is cheap and I should show the code instead. > > Yeah, if you can give it a second look and say if it matches what you > wrote above, it would be very much appreciated. > >> Deepest respect for your efforts! > > Thanks! > > Tomeu > >> Yours, >> Linus Walleij >> ___ >> dri-devel mailing list >> dri-de...@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > -- > To unsubscribe from this list: send the line "unsubscribe linux-gpio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe
RE: [PATCH 1/3] usb: dwc2: host: allocate qh before atomic enqueue
> -Original Message-
> From: John Youn [mailto:john.y...@synopsys.com]
> Sent: Wednesday, June 10, 2015 1:06 AM
> To: Kaukab, Yousaf; linux-usb@vger.kernel.org; ba...@ti.com;
> john.y...@synopsys.com
> Cc: Herrero, Gregory; he...@sntech.de; Holmberg, Hans
> Subject: Re: [PATCH 1/3] usb: dwc2: host: allocate qh before atomic enqueue
>
> On 6/5/2015 7:23 AM, Mian Yousaf Kaukab wrote:
> > To avoid sleep while atomic bugs, allocate qh before calling
> > dwc2_hcd_urb_enqueue. qh pointer can be used directly now instead of
> > passing ep->hcpriv as double pointer.
> >
> > Signed-off-by: Mian Yousaf Kaukab
> > ---
> > drivers/usb/dwc2/hcd.c | 31 ++
> > drivers/usb/dwc2/hcd.h | 5 -
> > drivers/usb/dwc2/hcd_queue.c | 45
> >
> > 3 files changed, 43 insertions(+), 38 deletions(-)
> >
> > diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c index
> > b10377c..80bce71 100644
> > --- a/drivers/usb/dwc2/hcd.c
> > +++ b/drivers/usb/dwc2/hcd.c
> > @@ -359,7 +359,7 @@ void dwc2_hcd_stop(struct dwc2_hsotg *hsotg)
> >
> > /* Caller must hold driver lock */
> > static int dwc2_hcd_urb_enqueue(struct dwc2_hsotg *hsotg,
> > - struct
> dwc2_hcd_urb *urb, void **ep_handle,
> > + struct
> dwc2_hcd_urb *urb, struct dwc2_qh *qh,
> > gfp_t mem_flags)
> > {
> > struct dwc2_qtd *qtd;
> > @@ -391,8 +391,7 @@ static int dwc2_hcd_urb_enqueue(struct dwc2_hsotg
> *hsotg,
> > return -ENOMEM;
> >
> > dwc2_hcd_qtd_init(qtd, urb);
> > - retval = dwc2_hcd_qtd_add(hsotg, qtd, (struct dwc2_qh
> **)ep_handle,
> > - mem_flags);
> > + retval = dwc2_hcd_qtd_add(hsotg, qtd, qh);
> > if (retval) {
> > dev_err(hsotg->dev,
> > "DWC OTG HCD URB Enqueue
> failed adding QTD. Error status %d\n", @@
> > -2445,6 +2444,8 @@ static int _dwc2_hcd_urb_enqueue(struct usb_hcd *hcd,
> struct urb *urb,
> > u32 tflags = 0;
> > void *buf;
> > unsigned long flags;
> > + struct dwc2_qh *qh;
> > + bool qh_allocated = false;
> >
> > if (dbg_urb(urb)) {
> > dev_vdbg(hsotg->dev, "DWC OTG HCD URB
> Enqueue\n"); @@ -2523,13
> > +2524,24 @@ static int _dwc2_hcd_urb_enqueue(struct usb_hcd *hcd, struct
> urb *urb,
> >
>urb->iso_frame_desc[i].length);
> >
> > urb->hcpriv = dwc2_urb;
> > + qh = (struct dwc2_qh *) ep->hcpriv;
> > + /* Create QH for the endpoint if it doesn't exist */
> > + if (!qh) {
> > + qh = dwc2_hcd_qh_create(hsotg, dwc2_urb,
> mem_flags);
> > + if (!qh) {
> > + retval = -ENOMEM;
> > + goto fail0;
> > + }
> > + ep->hcpriv = qh;
> > + qh_allocated = true;
> > + }
> >
> > spin_lock_irqsave(&hsotg->lock, flags);
> > retval = usb_hcd_link_urb_to_ep(hcd, urb);
> > if (retval)
> > goto fail1;
> >
> > - retval = dwc2_hcd_urb_enqueue(hsotg, dwc2_urb, &ep->hcpriv,
> mem_flags);
> > + retval = dwc2_hcd_urb_enqueue(hsotg, dwc2_urb, qh,
> mem_flags);
> > if (retval)
> > goto fail2;
> >
> > @@ -2549,6 +2561,17 @@ fail2:
> > fail1:
> > spin_unlock_irqrestore(&hsotg->lock, flags);
> > urb->hcpriv = NULL;
> > + if (qh_allocated) {
> > + struct dwc2_qtd *qtd2, *qtd2_tmp;
> > +
> > + ep->hcpriv = NULL;
> > + dwc2_hcd_qh_unlink(hsotg, qh);
> > + /* Free each QTD in the QH's QTD list */
> > + list_for_each_entry_safe(qtd2, qtd2_tmp, &qh-
> >qtd_list,
> > +
>qtd_list_entry)
> > +
> dwc2_hcd_qtd_unlink_and_free(hsotg, qtd2, qh);
> > + dwc2_hcd_qh_free(hsotg, qh);
> > + }
> > fail0:
> > kfree(dwc2_urb);
> >
> > diff --git a/drivers/usb/dwc2/hcd.h b/drivers/usb/dwc2/hcd.h index
> > 7b5841c..fc10549 100644
> > --- a/drivers/usb/dwc2/hcd.h
> > +++ b/drivers/usb/dwc2/hcd.h
> > @@ -463,6 +463,9 @@ extern void dwc2_hcd_queue_transactions(struct
> > dwc2_hsotg *hsotg,
> > /* Schedule Queue Functions */
> > /* Implemented in hcd_queue.c */
> > extern void dwc2_hcd_init_usecs(struct dwc2_hsotg *hsotg);
> > +extern struct dwc2_qh *dwc2_hcd_qh_create(struct dwc2_hsotg *hsotg,
> > +
> struct dwc2_hcd_urb *urb,
> > +
> gfp_t mem_flags);
> > extern void dwc2_hcd_qh_free(struct dwc2_hsotg *hsotg, struct dwc2_qh
> > *qh); extern int dwc2_hcd_qh_add(struct dwc2_hsotg *hsotg, struct
> > dwc2_qh *qh); extern void dwc2_hcd_qh_unlink(struct dwc2_hsotg
> > *hsotg, struct dwc2_qh *qh); @@ -471,7 +474,7 @@ extern void
> > dwc2_hcd_qh_deactivate(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh,
> >
> > extern void dwc2_hcd_qtd_init(struct dwc2_qtd *qtd, struct
> > dwc2_hcd_urb *urb); extern int dwc2_hcd_qtd_add(struct dwc2_hsotg
> *hsotg, struct dwc2_qtd *qtd,
> > - struct dwc2_qh **qh, gfp_t
> mem_flags);
> > +
[PATCH v1 0/3] usb: dwc2: fix sleep while atomic bugs
This series fixes 3 sources of sleep while atomic bugs. Including the one reported by Heiko Stuebner here: http://www.spinics.net/lists/linux-usb/msg125186.html Please review. Thank you, Best regards, Yousaf History: v1: - Added John's Acked-by Mian Yousaf Kaukab (3): usb: dwc2: host: allocate qh before atomic enqueue usb: dwc2: host: allocate qtd before atomic enqueue usb: dwc2: embed storage for reg backup in struct dwc2_hsotg drivers/usb/dwc2/core.c | 55 drivers/usb/dwc2/core.h | 9 +--- drivers/usb/dwc2/hcd.c | 55 +--- drivers/usb/dwc2/hcd.h | 5 +++- drivers/usb/dwc2/hcd_queue.c | 45 ++-- 5 files changed, 79 insertions(+), 90 deletions(-) -- 2.3.3 -- 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
[PATCH v1 1/3] usb: dwc2: host: allocate qh before atomic enqueue
To avoid sleep while atomic bugs, allocate qh before calling
dwc2_hcd_urb_enqueue. qh pointer can be used directly now instead of
passing ep->hcpriv as double pointer.
Acked-by: John Youn
Signed-off-by: Mian Yousaf Kaukab
---
drivers/usb/dwc2/hcd.c | 31 ++
drivers/usb/dwc2/hcd.h | 5 -
drivers/usb/dwc2/hcd_queue.c | 45
3 files changed, 43 insertions(+), 38 deletions(-)
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index b10377c..80bce71 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -359,7 +359,7 @@ void dwc2_hcd_stop(struct dwc2_hsotg *hsotg)
/* Caller must hold driver lock */
static int dwc2_hcd_urb_enqueue(struct dwc2_hsotg *hsotg,
- struct dwc2_hcd_urb *urb, void **ep_handle,
+ struct dwc2_hcd_urb *urb, struct dwc2_qh *qh,
gfp_t mem_flags)
{
struct dwc2_qtd *qtd;
@@ -391,8 +391,7 @@ static int dwc2_hcd_urb_enqueue(struct dwc2_hsotg *hsotg,
return -ENOMEM;
dwc2_hcd_qtd_init(qtd, urb);
- retval = dwc2_hcd_qtd_add(hsotg, qtd, (struct dwc2_qh **)ep_handle,
- mem_flags);
+ retval = dwc2_hcd_qtd_add(hsotg, qtd, qh);
if (retval) {
dev_err(hsotg->dev,
"DWC OTG HCD URB Enqueue failed adding QTD. Error
status %d\n",
@@ -2445,6 +2444,8 @@ static int _dwc2_hcd_urb_enqueue(struct usb_hcd *hcd,
struct urb *urb,
u32 tflags = 0;
void *buf;
unsigned long flags;
+ struct dwc2_qh *qh;
+ bool qh_allocated = false;
if (dbg_urb(urb)) {
dev_vdbg(hsotg->dev, "DWC OTG HCD URB Enqueue\n");
@@ -2523,13 +2524,24 @@ static int _dwc2_hcd_urb_enqueue(struct usb_hcd *hcd,
struct urb *urb,
urb->iso_frame_desc[i].length);
urb->hcpriv = dwc2_urb;
+ qh = (struct dwc2_qh *) ep->hcpriv;
+ /* Create QH for the endpoint if it doesn't exist */
+ if (!qh) {
+ qh = dwc2_hcd_qh_create(hsotg, dwc2_urb, mem_flags);
+ if (!qh) {
+ retval = -ENOMEM;
+ goto fail0;
+ }
+ ep->hcpriv = qh;
+ qh_allocated = true;
+ }
spin_lock_irqsave(&hsotg->lock, flags);
retval = usb_hcd_link_urb_to_ep(hcd, urb);
if (retval)
goto fail1;
- retval = dwc2_hcd_urb_enqueue(hsotg, dwc2_urb, &ep->hcpriv, mem_flags);
+ retval = dwc2_hcd_urb_enqueue(hsotg, dwc2_urb, qh, mem_flags);
if (retval)
goto fail2;
@@ -2549,6 +2561,17 @@ fail2:
fail1:
spin_unlock_irqrestore(&hsotg->lock, flags);
urb->hcpriv = NULL;
+ if (qh_allocated) {
+ struct dwc2_qtd *qtd2, *qtd2_tmp;
+
+ ep->hcpriv = NULL;
+ dwc2_hcd_qh_unlink(hsotg, qh);
+ /* Free each QTD in the QH's QTD list */
+ list_for_each_entry_safe(qtd2, qtd2_tmp, &qh->qtd_list,
+qtd_list_entry)
+ dwc2_hcd_qtd_unlink_and_free(hsotg, qtd2, qh);
+ dwc2_hcd_qh_free(hsotg, qh);
+ }
fail0:
kfree(dwc2_urb);
diff --git a/drivers/usb/dwc2/hcd.h b/drivers/usb/dwc2/hcd.h
index 7b5841c..fc10549 100644
--- a/drivers/usb/dwc2/hcd.h
+++ b/drivers/usb/dwc2/hcd.h
@@ -463,6 +463,9 @@ extern void dwc2_hcd_queue_transactions(struct dwc2_hsotg
*hsotg,
/* Schedule Queue Functions */
/* Implemented in hcd_queue.c */
extern void dwc2_hcd_init_usecs(struct dwc2_hsotg *hsotg);
+extern struct dwc2_qh *dwc2_hcd_qh_create(struct dwc2_hsotg *hsotg,
+ struct dwc2_hcd_urb *urb,
+ gfp_t mem_flags);
extern void dwc2_hcd_qh_free(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh);
extern int dwc2_hcd_qh_add(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh);
extern void dwc2_hcd_qh_unlink(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh);
@@ -471,7 +474,7 @@ extern void dwc2_hcd_qh_deactivate(struct dwc2_hsotg
*hsotg, struct dwc2_qh *qh,
extern void dwc2_hcd_qtd_init(struct dwc2_qtd *qtd, struct dwc2_hcd_urb *urb);
extern int dwc2_hcd_qtd_add(struct dwc2_hsotg *hsotg, struct dwc2_qtd *qtd,
- struct dwc2_qh **qh, gfp_t mem_flags);
+ struct dwc2_qh *qh);
/* Unlinks and frees a QTD */
static inline void dwc2_hcd_qtd_unlink_and_free(struct dwc2_hsotg *hsotg,
diff --git a/drivers/usb/dwc2/hcd_queue.c b/drivers/usb/dwc2/hcd_queue.c
index 9b5c362..e573a4f 100644
--- a/drivers/usb/dwc2/hcd_queue.c
+++ b/drivers/usb/dwc2/hcd_queue.c
@@ -191,7 +191,7 @@ static void dwc2_qh_init(struct dwc2_hsotg *hsotg, struct
dwc2_qh *qh,
*
* Return: Pointer to the newly allocate
[PATCH v1 3/3] usb: dwc2: embed storage for reg backup in struct dwc2_hsotg
Register backup function can be called from atomic context. Instead
of using atomic memory pool, embed backup storage space in
struct dwc2_hsotg.
Also add a valid flag in each struct as NULL pointer can't be used as
the content validity check any more.
Acked-by: John Youn
Signed-off-by: Mian Yousaf Kaukab
---
drivers/usb/dwc2/core.c | 55 ++---
drivers/usb/dwc2/core.h | 9 +---
2 files changed, 21 insertions(+), 43 deletions(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index e5b546f..c3cc1a7 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -72,17 +72,7 @@ static int dwc2_backup_host_registers(struct dwc2_hsotg
*hsotg)
dev_dbg(hsotg->dev, "%s\n", __func__);
/* Backup Host regs */
- hr = hsotg->hr_backup;
- if (!hr) {
- hr = devm_kzalloc(hsotg->dev, sizeof(*hr), GFP_KERNEL);
- if (!hr) {
- dev_err(hsotg->dev, "%s: can't allocate host regs\n",
- __func__);
- return -ENOMEM;
- }
-
- hsotg->hr_backup = hr;
- }
+ hr = &hsotg->hr_backup;
hr->hcfg = readl(hsotg->regs + HCFG);
hr->haintmsk = readl(hsotg->regs + HAINTMSK);
for (i = 0; i < hsotg->core_params->host_channels; ++i)
@@ -90,6 +80,7 @@ static int dwc2_backup_host_registers(struct dwc2_hsotg
*hsotg)
hr->hprt0 = readl(hsotg->regs + HPRT0);
hr->hfir = readl(hsotg->regs + HFIR);
+ hr->valid = true;
return 0;
}
@@ -109,12 +100,13 @@ static int dwc2_restore_host_registers(struct dwc2_hsotg
*hsotg)
dev_dbg(hsotg->dev, "%s\n", __func__);
/* Restore host regs */
- hr = hsotg->hr_backup;
- if (!hr) {
+ hr = &hsotg->hr_backup;
+ if (!hr->valid) {
dev_err(hsotg->dev, "%s: no host registers to restore\n",
__func__);
return -EINVAL;
}
+ hr->valid = false;
writel(hr->hcfg, hsotg->regs + HCFG);
writel(hr->haintmsk, hsotg->regs + HAINTMSK);
@@ -152,17 +144,7 @@ static int dwc2_backup_device_registers(struct dwc2_hsotg
*hsotg)
dev_dbg(hsotg->dev, "%s\n", __func__);
/* Backup dev regs */
- dr = hsotg->dr_backup;
- if (!dr) {
- dr = devm_kzalloc(hsotg->dev, sizeof(*dr), GFP_KERNEL);
- if (!dr) {
- dev_err(hsotg->dev, "%s: can't allocate device regs\n",
- __func__);
- return -ENOMEM;
- }
-
- hsotg->dr_backup = dr;
- }
+ dr = &hsotg->dr_backup;
dr->dcfg = readl(hsotg->regs + DCFG);
dr->dctl = readl(hsotg->regs + DCTL);
@@ -195,7 +177,7 @@ static int dwc2_backup_device_registers(struct dwc2_hsotg
*hsotg)
dr->doeptsiz[i] = readl(hsotg->regs + DOEPTSIZ(i));
dr->doepdma[i] = readl(hsotg->regs + DOEPDMA(i));
}
-
+ dr->valid = true;
return 0;
}
@@ -215,12 +197,13 @@ static int dwc2_restore_device_registers(struct
dwc2_hsotg *hsotg)
dev_dbg(hsotg->dev, "%s\n", __func__);
/* Restore dev regs */
- dr = hsotg->dr_backup;
- if (!dr) {
+ dr = &hsotg->dr_backup;
+ if (!dr->valid) {
dev_err(hsotg->dev, "%s: no device registers to restore\n",
__func__);
return -EINVAL;
}
+ dr->valid = false;
writel(dr->dcfg, hsotg->regs + DCFG);
writel(dr->dctl, hsotg->regs + DCTL);
@@ -268,17 +251,7 @@ static int dwc2_backup_global_registers(struct dwc2_hsotg
*hsotg)
int i;
/* Backup global regs */
- gr = hsotg->gr_backup;
- if (!gr) {
- gr = devm_kzalloc(hsotg->dev, sizeof(*gr), GFP_KERNEL);
- if (!gr) {
- dev_err(hsotg->dev, "%s: can't allocate global regs\n",
- __func__);
- return -ENOMEM;
- }
-
- hsotg->gr_backup = gr;
- }
+ gr = &hsotg->gr_backup;
gr->gotgctl = readl(hsotg->regs + GOTGCTL);
gr->gintmsk = readl(hsotg->regs + GINTMSK);
@@ -291,6 +264,7 @@ static int dwc2_backup_global_registers(struct dwc2_hsotg
*hsotg)
for (i = 0; i < MAX_EPS_CHANNELS; i++)
gr->dtxfsiz[i] = readl(hsotg->regs + DPTXFSIZN(i));
+ gr->valid = true;
return 0;
}
@@ -309,12 +283,13 @@ static int dwc2_restore_global_registers(struct
dwc2_hsotg *hsotg)
dev_dbg(hsotg->dev, "%s\n", __func__);
/* Restore global regs */
- gr = hsotg->gr_backup;
- if (!gr) {
+ gr = &hsotg->gr_backup;
+ if (!gr->valid) {
dev_err(hsotg->dev, "%s: no global registers to restore\n",
[PATCH v1 2/3] usb: dwc2: host: allocate qtd before atomic enqueue
To avoid sleep while atomic bugs, allocate qtd before calling
dwc2_hcd_urb_enqueue. No need to pass mem_flags to
dwc2_hcd_urb_enqueue any more as no memory allocations are done in it.
Acked-by: John Youn
Signed-off-by: Mian Yousaf Kaukab
---
drivers/usb/dwc2/hcd.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c
index 80bce71..f845c41 100644
--- a/drivers/usb/dwc2/hcd.c
+++ b/drivers/usb/dwc2/hcd.c
@@ -360,9 +360,8 @@ void dwc2_hcd_stop(struct dwc2_hsotg *hsotg)
/* Caller must hold driver lock */
static int dwc2_hcd_urb_enqueue(struct dwc2_hsotg *hsotg,
struct dwc2_hcd_urb *urb, struct dwc2_qh *qh,
- gfp_t mem_flags)
+ struct dwc2_qtd *qtd)
{
- struct dwc2_qtd *qtd;
u32 intr_mask;
int retval;
int dev_speed;
@@ -386,9 +385,8 @@ static int dwc2_hcd_urb_enqueue(struct dwc2_hsotg *hsotg,
return -ENODEV;
}
- qtd = kzalloc(sizeof(*qtd), mem_flags);
if (!qtd)
- return -ENOMEM;
+ return -EINVAL;
dwc2_hcd_qtd_init(qtd, urb);
retval = dwc2_hcd_qtd_add(hsotg, qtd, qh);
@@ -396,7 +394,6 @@ static int dwc2_hcd_urb_enqueue(struct dwc2_hsotg *hsotg,
dev_err(hsotg->dev,
"DWC OTG HCD URB Enqueue failed adding QTD. Error
status %d\n",
retval);
- kfree(qtd);
return retval;
}
@@ -2446,6 +2443,7 @@ static int _dwc2_hcd_urb_enqueue(struct usb_hcd *hcd,
struct urb *urb,
unsigned long flags;
struct dwc2_qh *qh;
bool qh_allocated = false;
+ struct dwc2_qtd *qtd;
if (dbg_urb(urb)) {
dev_vdbg(hsotg->dev, "DWC OTG HCD URB Enqueue\n");
@@ -2536,14 +2534,20 @@ static int _dwc2_hcd_urb_enqueue(struct usb_hcd *hcd,
struct urb *urb,
qh_allocated = true;
}
+ qtd = kzalloc(sizeof(*qtd), mem_flags);
+ if (!qtd) {
+ retval = -ENOMEM;
+ goto fail1;
+ }
+
spin_lock_irqsave(&hsotg->lock, flags);
retval = usb_hcd_link_urb_to_ep(hcd, urb);
if (retval)
- goto fail1;
+ goto fail2;
- retval = dwc2_hcd_urb_enqueue(hsotg, dwc2_urb, qh, mem_flags);
+ retval = dwc2_hcd_urb_enqueue(hsotg, dwc2_urb, qh, qtd);
if (retval)
- goto fail2;
+ goto fail3;
if (alloc_bandwidth) {
dwc2_allocate_bus_bandwidth(hcd,
@@ -2555,12 +2559,14 @@ static int _dwc2_hcd_urb_enqueue(struct usb_hcd *hcd,
struct urb *urb,
return 0;
-fail2:
+fail3:
dwc2_urb->priv = NULL;
usb_hcd_unlink_urb_from_ep(hcd, urb);
-fail1:
+fail2:
spin_unlock_irqrestore(&hsotg->lock, flags);
urb->hcpriv = NULL;
+ kfree(qtd);
+fail1:
if (qh_allocated) {
struct dwc2_qtd *qtd2, *qtd2_tmp;
--
2.3.3
--
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
Re: [PATCH v2 05/22] doc: dt-binding: usb: add otg related properties
On Wed, Jun 10, 2015 at 03:37:37PM +0800, Roger Quadros wrote: > On Tue, 9 Jun 2015 11:33:11 -0500 > Rob Herring wrote: > > > On Tue, Jun 9, 2015 at 10:29 AM, Roger Quadros wrote: > > > Rob, > > > > > > On Tue, 9 Jun 2015 08:26:20 -0500 > > > Rob Herring wrote: > > > > > >> On Mon, Jun 8, 2015 at 8:18 PM, Li Jun wrote: > > >> > On Mon, Jun 08, 2015 at 11:06:49AM -0500, Rob Herring wrote: > > >> >> On Mon, Jun 8, 2015 at 10:02 AM, Li Jun wrote: > > >> >> > Add otg version, srp, hnp and adp support for usb OTG port, then > > >> >> > those OTG > > >> >> > features don't have to be decided by usb gadget drivers. > > >> >> > > > >> >> > Signed-off-by: Li Jun > > >> >> > --- > > >> >> > Documentation/devicetree/bindings/usb/generic.txt | 10 ++ > > >> >> > 1 file changed, 10 insertions(+) > > >> >> > > > >> >> > diff --git a/Documentation/devicetree/bindings/usb/generic.txt > > >> >> > b/Documentation/devicetree/bindings/usb/generic.txt > > >> >> > index 477d5bb..7386f4a 100644 > > >> >> > --- a/Documentation/devicetree/bindings/usb/generic.txt > > >> >> > +++ b/Documentation/devicetree/bindings/usb/generic.txt > > >> >> > @@ -11,6 +11,12 @@ Optional properties: > > >> >> > "peripheral" and "otg". In case this > > >> >> > attribute isn't > > >> >> > passed via DT, USB DRD controllers should > > >> >> > default to > > >> >> > OTG. > > >> >> > + - otg-rev: tells usb driver the release number of the OTG and EH > > >> >> > supplement > > >> >> > + with which the device and its descriptors > > >> >> > are compliant, > > >> >> > + in binary-coded decimal (i.e. 2.0 is 0200H). > > >> >> > > >> >> I would assume OTG 2.0 is somehow backwards compatible? Is this a h/w > > >> >> dependency or a driver feature? > > >> >> > > >> > Not fully compatible, OTG 2.0 extend the usb_otg_descriptor by adding > > >> > a new > > >> > member bcdOTG to identify the OTG version, this descriptor needs to be > > >> > sent > > >> > to OTG host with correct size and content, so we have to know which > > >> > release > > >> > version the OTG device is compliant with, either by menuconfig config > > >> > or pass > > >> > via DT. > > >> > > >> So you have to change the version depending on the host you are > > >> connected to? That really seems strange that plugging in a OTG 2.0 > > >> device to an OTG 1.3 host would not work and doesn't make for a good > > >> user experience. > > > > > > No. The OTG version in the OTG descriptor for any device is usually fixed > > > for the > > > lifetime of the product. > > > > > > Let's assume it is 2.0. > > > > > > If you plug this to OTG 1.0 host, it won't be an issue as OTG 1.0 host > > > doesn't > > > read the BCD version. > > > > That makes sense, but there was some discussion about the size mattering. > > > > So is there a reason not to always report 2.0 with any kernel that has > > 2.0 support? > > A 2.0 host would still need to know if the attached OTG device is 1.0 or 2.0 > so we don't want to force existing 1.0 devices to 2.0. > > > > > >> > > >> >> > + - srp-support: tells OTG controllers we want to enable SRP. > > >> >> > + - hnp-support: tells OTG controllers we want to enable HNP. > > >> >> > + - adp-support: tells OTG controllers we want to enable ADP. > > >> >> > > >> >> I've recently run into a problem[1] and found that I have to disable > > >> >> OTG in the kernel to get my device to work. Having to turn-off OTG > > >> >> seems like the wrong solution, and shifting the problem to DT seems > > >> >> wrong too. Why is this not a user configurable option (within whatever > > >> >> h/w constraints there are)? > > >> > The problem of below link, seems your device is claiming it's a HNP > > >> > capable > > >> > OTG device, but connecting to a non-OTG port of your Host, assume your > > >> > Host > > >> > does have a OTG port, your Host issue a A_ALT_HNP_SUPPORT request to > > >> > your > > >> > OTG device to remind it can use another port with HNP, but the request > > >> > failed > > >> > (maybe STALL by your device, this request is defined in OTG 1.3 but > > >> > obsolete > > >> > in OTG 2.0), so your Host just stopped enumeration of your device, > > >> > this is not > > >> > reasonable because current OTG code is some out of data. > > >> > > >> Do PCs have OTG ports typically? My expectation is that if I plug in > > >> an OTG device as a B device to any host port, that it will work as a > > >> device no matter what the host OTG capabilities are. If I have to > > >> change the kernel config or DT, that is a problem. > > > > > > AFAIK PCs don't have OTG ports. > > > > > > If you plug in OTG device to a non-otg host port it will work as normal > > > B-device. > > > The host doesn't request for OTG descriptors and doesn't care what OTG > > > features it > > > supports or not. > > > > That is what I would expect. My testing and the bug report sho
Re: [PATCH v2 01/22] usb: add OTG version number in usb_otg_descriptor
On Tue, Jun 09, 2015 at 10:16:23AM -0400, Alan Stern wrote:
> On Tue, 9 Jun 2015, Li Jun wrote:
>
> > > > -/* USB_DT_OTG (from OTG 1.0a supplement) */
> > > > +/* USB_DT_OTG */
> > > > struct usb_otg_descriptor {
> > > > __u8 bLength;
> > > > __u8 bDescriptorType;
> > > >
> > > > __u8 bmAttributes; /* support for HNP, SRP, etc */
> > > > + struct bcdOTG otg_rev[0];
> > >
> > > why not just __le16 bcdOTG here ?
> >
> > usb_otg_descriptor of OTG 1.0 and 2.0 have different size, if directly add
> > __le16 bcdOTG here, then it cannot used for OTG 1.0.
> > I use a zero length array as Peter suggested here for bcdOTG, then the size
> > of usb_otg_descriptor is still 3(not 5), which is compliant with OTG 1.x,
> > if OTG
> > 2.0 or later, we can use member of otg_rev to add bcdOTG, then the size
> > of usb_otg_descriptor + bcdOTG will be 5, in one word, I want to use
> > existing
> > usb_otg_descriptor struct to cover both OTG 1.x and 2.0
>
> In the end, you may find it is simpler to use two different
> structures: usb_otg_descriptor and usb_otg_20_descriptor.
> Try it and see.
That should be, I will try your suggested approach, thanks.
Li Jun
>
> Alan Stern
>
--
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
Re: [PATCH v2 09/22] usb: gadget: add usb_otg_descriptor_add interface to init usb_otg_descriptor
On Tue, Jun 09, 2015 at 09:27:51PM +0800, Roger Quadros wrote:
> On Mon, 8 Jun 2015 23:02:04 +0800
> Li Jun wrote:
>
> > Allocate usb_otg_descriptor and initialize it according to gadget otg
> > options, if none of options is not set, keep bmAttributes setting as
> > current gadget drivers, with this new interface, usb_otg_descriptor can
> > include bcdOTG if OTG 2.0 or later, and otg features can be decided by
> > the combination of usb hardware property and driver config.
> >
> > Signed-off-by: Li Jun
> > ---
> > drivers/usb/gadget/config.c | 37 +
> > include/linux/usb/gadget.h | 1 +
> > 2 files changed, 38 insertions(+)
> >
> > diff --git a/drivers/usb/gadget/config.c b/drivers/usb/gadget/config.c
> > index 34e12fc..a86e079 100644
> > --- a/drivers/usb/gadget/config.c
> > +++ b/drivers/usb/gadget/config.c
> > @@ -195,3 +195,40 @@ void usb_free_all_descriptors(struct usb_function *f)
> > usb_free_descriptors(f->ss_descriptors);
> > }
> > EXPORT_SYMBOL_GPL(usb_free_all_descriptors);
> > +
> > +struct usb_otg_descriptor *usb_otg_descriptor_add(struct usb_gadget
> > *gadget)
> > +{
> > + struct usb_otg_descriptor *otg_desc;
> > + unsigned otg_desc_length;
> > +
> > + if (gadget->otg_rev >= 0x0200)
> > + otg_desc_length = sizeof(*otg_desc) + sizeof(struct bcdOTG);
> > + else
> > + otg_desc_length = sizeof(*otg_desc);
> > +
> > + otg_desc = (struct usb_otg_descriptor *)kzalloc(otg_desc_length,
> > + GFP_KERNEL);
>
> You are allocating memory here and expecting users will free it.
> I suggest that you pass pointer to otg_desc as function argument and leave it
> upto
> the caller to allocate/deallocate memory for it.
Agreed, I will update accordingly.
>
> Most likely users will be a static allocation like they do now and it is a
> lot simpler.
>
I need allocate different size memory at runtime, that static
allocation should be changed, I will try Alan's suggestion with
2 different structures to make it simpler.
> > + if (!otg_desc)
> > + return otg_desc;
> > +
> > + otg_desc->bLength = otg_desc_length;
> > + otg_desc->bDescriptorType = USB_DT_OTG;
> > +
> > + if (gadget->adp_support || gadget->hnp_support ||
> > + gadget->srp_support) {
> > + if (gadget->adp_support)
> > + otg_desc->bmAttributes |= USB_OTG_ADP;
> > + if (gadget->hnp_support)
> > + otg_desc->bmAttributes |= USB_OTG_HNP;
> > + if (gadget->srp_support)
> > + otg_desc->bmAttributes |= USB_OTG_SRP;
> > + } else {
> > + otg_desc->bmAttributes = USB_OTG_SRP | USB_OTG_HNP;
> > + }
> > +
> > + if (gadget->otg_rev >= 0x0200)
> > + otg_desc->otg_rev[0].bcdOTG = cpu_to_le16(gadget->otg_rev);
> > +
> > + return otg_desc;
> > +}
> > +EXPORT_SYMBOL_GPL(usb_otg_descriptor_add);
> > diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> > index 2f4f39c..e210466 100644
> > --- a/include/linux/usb/gadget.h
> > +++ b/include/linux/usb/gadget.h
> > @@ -1013,6 +1013,7 @@ int usb_assign_descriptors(struct usb_function *f,
> > struct usb_descriptor_header **ss);
> > void usb_free_all_descriptors(struct usb_function *f);
> >
> > +struct usb_otg_descriptor *usb_otg_descriptor_add(struct usb_gadget
> > *gadget);
> >
> > /*-*/
> >
> > /* utility to simplify map/unmap of usb_requests to/from DMA */
>
> cheers,
> -roger
--
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
Re: questions about uas
Please use Reply-To-All so that your messages gets sent to the mailing list as well as to me. On Wed, 10 Jun 2015, Tom Yan wrote: > Hi Alan. > > Yes you were right about the blacklisting. I guess I didn't read the > output carefully enough. It was empty for both cases. > > So I assume there's no way to "globablly" disable uas in runtime? Also Either blacklisting or deleting the module will globally disable uas, as you found out in your tests. However, there is no way to globally substitute usb-storage for uas at runtime. The only way to do that is to rebuild with kernel without the uas driver. > I can see that some quirks will be enabled for certain devices by > default. Is there no way to revert those in runtime as well? Some of those quirks can be turned off by the "quirks=" module parameter. But why would you want to? The reason those predefined quirks are there is because the devices won't work right without them. Alan Stern -- 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
[PATCH] USB SERIAL: option.c: add 2020:4000 IDs
From: Claudio Cappelli
Add device Olivetti Olicard 300 (Network Connect: MT6225) - IDs 2020:4000.
Signed-off-by: Claudio Cappelli
Suggested-by: Lars Melin
---
drivers/usb/serial/option.c |1 +
1 file changed, 1 insertion(+)
--- linux/drivers/usb/serial/option.c.orig 2015-06-10 10:42:43.0
+0200
+++ linux/drivers/usb/serial/option.c 2015-06-10 10:53:06.825265579 +0200
@@ -1765,6 +1765,7 @@ static const struct usb_device_id option
{ USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x7d03, 0xff, 0x00, 0x00) },
{ USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e01, 0xff, 0xff, 0xff) }, /*
D-Link DWM-152/C1 */
{ USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e02, 0xff, 0xff, 0xff) }, /*
D-Link DWM-156/C1 */
+ { USB_DEVICE_INTERFACE_CLASS(0x2020, 0x4000, 0xff) },/*
OLICARD300 - MT6225 */
{ USB_DEVICE(INOVIA_VENDOR_ID, INOVIA_SEW858) },
{ USB_DEVICE(VIATELECOM_VENDOR_ID, VIATELECOM_PRODUCT_CDS7) },
{ } /* Terminating entry */
--
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
Re: Patch Request of option.c module to support Olicard-300 (2020:4000)
On Wed, Jun 10, 2015 at 05:17:10PM +0700, Lars Melin wrote:
> On 2015-06-10 15:59, Joe wrote:
> > Lars Melin wrote:
> >
> >> If these hints to "Joe" justifies a Suggested-by then he can add me,
> >> info is in this mails header.
> >>
> >> I do however not agree to the place where "Joe" has stuck it into the
> >> usb_device_id list, it should not be among
> >> the other Olivetti entries but further down among numeric value vid:pid
> >> entries.
> >>
> >> /Lars
> > Thank you Lars for your answer! :)
> > Here we have an other hint, I could shift down my Olicard entry before
> > submit the patch... no problem.
> > Here we are:
> >
> > ---
> > --- linux/drivers/usb/serial/option.c.orig 2015-06-10
> > 10:42:43.0 +0200
> > +++ linux/drivers/usb/serial/option.c 2015-06-10 10:53:06.825265579 +0200
> > @@ -1765,6 +1765,7 @@ static const struct usb_device_id option
> > { USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x7d03, 0xff, 0x00, 0x00)
> > },
> > { USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e01, 0xff, 0xff, 0xff)
> > }, /* D-Link DWM-152/C1 */
> > { USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e02, 0xff, 0xff, 0xff)
> > }, /* D-Link DWM-156/C1 */
> > + { USB_DEVICE_INTERFACE_CLASS(0x2020, 0x4000, 0xff) },
> > /* OLICARD300 - MT6225 */
> > { USB_DEVICE(INOVIA_VENDOR_ID, INOVIA_SEW858) },
> > { USB_DEVICE(VIATELECOM_VENDOR_ID, VIATELECOM_PRODUCT_CDS7) },
> > { } /* Terminating entry */
> > ---
> >
> > What do you think about?
> > Could be a better placement?
> >
> > Let me know,
> > thanks again! :)
> >
>
> Yes that is a better place for it.
> I have added the usb serial maintainer as recipient since he is the one
> who has the final say.
Looks good to me. The general guideline is simply to keep related
entries together and to try to keep them sorted if possible (hard in
this case).
But why not use defines for the VID and PID (e.g. MEDIATEK_VENDOR_ID and
MEDIATEK_PRODUCT_MT6225) even if the device is sold under different
names? That way there would be more room to list any such aliases in a
comment section if needed.
Johan
--
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
Re: [PATCH] USB SERIAL: option.c: add 2020:4000 IDs
On Wed, Jun 10, 2015 at 06:08:09PM +0200, Claudio Cappelli wrote:
> From: Claudio Cappelli
>
> Add device Olivetti Olicard 300 (Network Connect: MT6225) - IDs 2020:4000.
>
> Signed-off-by: Claudio Cappelli
> Suggested-by: Lars Melin
>
> ---
>
> drivers/usb/serial/option.c |1 +
> 1 file changed, 1 insertion(+)
>
>
> --- linux/drivers/usb/serial/option.c.orig 2015-06-10 10:42:43.0
> +0200
> +++ linux/drivers/usb/serial/option.c 2015-06-10 10:53:06.825265579 +0200
> @@ -1765,6 +1765,7 @@ static const struct usb_device_id option
> { USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x7d03, 0xff, 0x00, 0x00) },
> { USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e01, 0xff, 0xff, 0xff) },
> /* D-Link DWM-152/C1 */
> { USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e02, 0xff, 0xff, 0xff) },
> /* D-Link DWM-156/C1 */
> + { USB_DEVICE_INTERFACE_CLASS(0x2020, 0x4000, 0xff) },
> /* OLICARD300 - MT6225 */
> { USB_DEVICE(INOVIA_VENDOR_ID, INOVIA_SEW858) },
> { USB_DEVICE(VIATELECOM_VENDOR_ID, VIATELECOM_PRODUCT_CDS7) },
> { } /* Terminating entry */
You should run checkpatch.pl on your patch before submitting. It would
have let you know that there are some white space issues (leading
spaces). You can ignore the long-line-warning in this case.
Thanks,
Johan
--
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
Re: [PATCH 1/3] usb: dwc2: host: allocate qh before atomic enqueue
On 6/10/2015 6:27 AM, Kaukab, Yousaf wrote:
>> -Original Message-
>> From: John Youn [mailto:john.y...@synopsys.com]
>> Sent: Wednesday, June 10, 2015 1:06 AM
>> To: Kaukab, Yousaf; linux-usb@vger.kernel.org; ba...@ti.com;
>> john.y...@synopsys.com
>> Cc: Herrero, Gregory; he...@sntech.de; Holmberg, Hans
>> Subject: Re: [PATCH 1/3] usb: dwc2: host: allocate qh before atomic enqueue
>>
>> On 6/5/2015 7:23 AM, Mian Yousaf Kaukab wrote:
>>> To avoid sleep while atomic bugs, allocate qh before calling
>>> dwc2_hcd_urb_enqueue. qh pointer can be used directly now instead of
>>> passing ep->hcpriv as double pointer.
>>>
>>> Signed-off-by: Mian Yousaf Kaukab
>>> ---
>>> drivers/usb/dwc2/hcd.c | 31 ++
>>> drivers/usb/dwc2/hcd.h | 5 -
>>> drivers/usb/dwc2/hcd_queue.c | 45
>>>
>>> 3 files changed, 43 insertions(+), 38 deletions(-)
>>>
>>> diff --git a/drivers/usb/dwc2/hcd.c b/drivers/usb/dwc2/hcd.c index
>>> b10377c..80bce71 100644
>>> --- a/drivers/usb/dwc2/hcd.c
>>> +++ b/drivers/usb/dwc2/hcd.c
>>> @@ -359,7 +359,7 @@ void dwc2_hcd_stop(struct dwc2_hsotg *hsotg)
>>>
>>> /* Caller must hold driver lock */
>>> static int dwc2_hcd_urb_enqueue(struct dwc2_hsotg *hsotg,
>>> - struct
>> dwc2_hcd_urb *urb, void **ep_handle,
>>> + struct
>> dwc2_hcd_urb *urb, struct dwc2_qh *qh,
>>> gfp_t mem_flags)
>>> {
>>> struct dwc2_qtd *qtd;
>>> @@ -391,8 +391,7 @@ static int dwc2_hcd_urb_enqueue(struct dwc2_hsotg
>> *hsotg,
>>> return -ENOMEM;
>>>
>>> dwc2_hcd_qtd_init(qtd, urb);
>>> - retval = dwc2_hcd_qtd_add(hsotg, qtd, (struct dwc2_qh
>> **)ep_handle,
>>> - mem_flags);
>>> + retval = dwc2_hcd_qtd_add(hsotg, qtd, qh);
>>> if (retval) {
>>> dev_err(hsotg->dev,
>>> "DWC OTG HCD URB Enqueue
>> failed adding QTD. Error status %d\n", @@
>>> -2445,6 +2444,8 @@ static int _dwc2_hcd_urb_enqueue(struct usb_hcd *hcd,
>> struct urb *urb,
>>> u32 tflags = 0;
>>> void *buf;
>>> unsigned long flags;
>>> + struct dwc2_qh *qh;
>>> + bool qh_allocated = false;
>>>
>>> if (dbg_urb(urb)) {
>>> dev_vdbg(hsotg->dev, "DWC OTG HCD URB
>> Enqueue\n"); @@ -2523,13
>>> +2524,24 @@ static int _dwc2_hcd_urb_enqueue(struct usb_hcd *hcd, struct
>> urb *urb,
>>>
>> urb->iso_frame_desc[i].length);
>>>
>>> urb->hcpriv = dwc2_urb;
>>> + qh = (struct dwc2_qh *) ep->hcpriv;
>>> + /* Create QH for the endpoint if it doesn't exist */
>>> + if (!qh) {
>>> + qh = dwc2_hcd_qh_create(hsotg, dwc2_urb,
>> mem_flags);
>>> + if (!qh) {
>>> + retval = -ENOMEM;
>>> + goto fail0;
>>> + }
>>> + ep->hcpriv = qh;
>>> + qh_allocated = true;
>>> + }
>>>
>>> spin_lock_irqsave(&hsotg->lock, flags);
>>> retval = usb_hcd_link_urb_to_ep(hcd, urb);
>>> if (retval)
>>> goto fail1;
>>>
>>> - retval = dwc2_hcd_urb_enqueue(hsotg, dwc2_urb, &ep->hcpriv,
>> mem_flags);
>>> + retval = dwc2_hcd_urb_enqueue(hsotg, dwc2_urb, qh,
>> mem_flags);
>>> if (retval)
>>> goto fail2;
>>>
>>> @@ -2549,6 +2561,17 @@ fail2:
>>> fail1:
>>> spin_unlock_irqrestore(&hsotg->lock, flags);
>>> urb->hcpriv = NULL;
>>> + if (qh_allocated) {
>>> + struct dwc2_qtd *qtd2, *qtd2_tmp;
>>> +
>>> + ep->hcpriv = NULL;
>>> + dwc2_hcd_qh_unlink(hsotg, qh);
>>> + /* Free each QTD in the QH's QTD list */
>>> + list_for_each_entry_safe(qtd2, qtd2_tmp, &qh-
>>> qtd_list,
>>> +
>> qtd_list_entry)
>>> +
>> dwc2_hcd_qtd_unlink_and_free(hsotg, qtd2, qh);
>>> + dwc2_hcd_qh_free(hsotg, qh);
>>> + }
>>> fail0:
>>> kfree(dwc2_urb);
>>>
>>> diff --git a/drivers/usb/dwc2/hcd.h b/drivers/usb/dwc2/hcd.h index
>>> 7b5841c..fc10549 100644
>>> --- a/drivers/usb/dwc2/hcd.h
>>> +++ b/drivers/usb/dwc2/hcd.h
>>> @@ -463,6 +463,9 @@ extern void dwc2_hcd_queue_transactions(struct
>>> dwc2_hsotg *hsotg,
>>> /* Schedule Queue Functions */
>>> /* Implemented in hcd_queue.c */
>>> extern void dwc2_hcd_init_usecs(struct dwc2_hsotg *hsotg);
>>> +extern struct dwc2_qh *dwc2_hcd_qh_create(struct dwc2_hsotg *hsotg,
>>> +
>> struct dwc2_hcd_urb *urb,
>>> +
>> gfp_t mem_flags);
>>> extern void dwc2_hcd_qh_free(struct dwc2_hsotg *hsotg, struct dwc2_qh
>>> *qh); extern int dwc2_hcd_qh_add(struct dwc2_hsotg *hsotg, struct
>>> dwc2_qh *qh); extern void dwc2_hcd_qh_unlink(struct dwc2_hsotg
>>> *hsotg, struct dwc2_qh *qh); @@ -471,7 +474,7 @@ extern void
>>> dwc2_hcd_qh_deactivate(struct dwc2_hsotg *hsotg, struct dwc2_qh *qh,
>>>
>>> extern void dwc2_hcd_qtd_init(struct dwc2_qtd *qtd, struct
>>> dwc2_hcd_urb *urb); extern int dwc2_hcd_qtd_add(struct dwc2_hsotg
>> *hsotg, struct dwc2_qtd *qtd,
>>> -
Re: [PATCH 4/5] usb: dwc3: ep0: Add chained TRB support
Hello. On 06/10/2015 12:18 PM, Kishon Vijay Abraham I wrote: Add chained TRB support to ep0. Now TRB's can be chained just by invoking _dwc3_ep0_start_trans_ with 'chain' parameter set to true. Signed-off-by: Kishon Vijay Abraham I --- drivers/usb/dwc3/ep0.c| 16 +--- drivers/usb/dwc3/gadget.c |2 +- 2 files changed, 14 insertions(+), 4 deletions(-) diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c index d1a2be1..6847afe 100644 --- a/drivers/usb/dwc3/ep0.c +++ b/drivers/usb/dwc3/ep0.c [...] @@ -78,10 +81,17 @@ static int dwc3_ep0_start_trans(struct dwc3 *dwc, u8 epnum, dma_addr_t buf_dma, trb->ctrl = type; trb->ctrl |= (DWC3_TRB_CTRL_HWO - | DWC3_TRB_CTRL_LST - | DWC3_TRB_CTRL_IOC | DWC3_TRB_CTRL_ISP_IMI); + if (chain) + trb->ctrl |= DWC3_TRB_CTRL_CHN; + else + trb->ctrl |= (DWC3_TRB_CTRL_IOC + | DWC3_TRB_CTRL_LST); Parens not needed here (and above too). [...] WBR, Sergei -- 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
Re: [PATCH 2/5] usb: dwc3: ep0: preparation for handling non maxpacket aligned transfers > 512
On 06/10/2015 12:18 PM, Kishon Vijay Abraham I wrote:
No functional change. This is in preparation for handling non maxpacket
aligned transfers greater than bounce buffer size. This is basically to
avoid code duplication when using chained TRB transfers to handle
non maxpacket aligned transfers greater than bounce buffer size.
Signed-off-by: Kishon Vijay Abraham I
---
drivers/usb/dwc3/ep0.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
index 713e46a..4998074 100644
--- a/drivers/usb/dwc3/ep0.c
+++ b/drivers/usb/dwc3/ep0.c
[...]
@@ -808,20 +812,24 @@ static void dwc3_ep0_complete_data(struct dwc3 *dwc,
}
ur = &r->request;
+ buf = ur->buf;
+ remaining_ur_length = ur->length;
length = trb->size & DWC3_TRB_SIZE_MASK;
+ maxp = ep0->endpoint.maxpacket;
+
if (dwc->ep0_bounced) {
- unsigned maxp = ep0->endpoint.maxpacket;
- unsigned transfer_size = roundup(ur->length, maxp);
+ transfer_size = roundup((ur->length - transfer_size),
+ maxp);
The innermost parens shouldn't be needed (if thay are, fix the macro
instead).
[...]
@@ -941,7 +949,8 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc,
}
maxpacket = dep->endpoint.maxpacket;
- transfer_size = roundup(req->request.length, maxpacket);
+ transfer_size = roundup((req->request.length - transfer_size),
+ maxpacket);
Likewise.
[...]
WBR, Sergei
--
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
Re: [PATCH 3/5] usb: dwc3; ep0: Modify _dwc3_ep0_start_trans_ API to take 'chain' parameter
Hello. On 06/10/2015 12:18 PM, Kishon Vijay Abraham I wrote: No functional change. Added a new parameter in _dwc3_ep0_start_trans_ to indicate whether the TRB is a chained TRB or last TRB. This is in preparation for adding chained TRB support for ep0. Signed-off-by: Kishon Vijay Abraham I --- drivers/usb/dwc3/ep0.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c index 4998074..d1a2be1 100644 --- a/drivers/usb/dwc3/ep0.c +++ b/drivers/usb/dwc3/ep0.c @@ -56,7 +56,7 @@ static const char *dwc3_ep0_state_string(enum dwc3_ep0_state state) } static int dwc3_ep0_start_trans(struct dwc3 *dwc, u8 epnum, dma_addr_t buf_dma, - u32 len, u32 type) + u32 len, u32 type, unsigned chain) Why not *bool*? You're passing boolean values anyway... [...] WBR, Sergei -- 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
[PATCH v2] USB SERIAL: option.c: add 2020:4000 IDs
From: Claudio Cappelli
Add device Olivetti Olicard 300 (Network Connect: MT6225) - IDs 2020:4000.
Signed-off-by: Claudio Cappelli
Suggested-by: Lars Melin
---
drivers/usb/serial/option.c |1 +
1 file changed, 1 insertion(+)
--- linux/drivers/usb/serial/option.c.orig 2015-06-10 10:42:43.0
+0200
+++ linux/drivers/usb/serial/option.c 2015-06-10 10:53:06.825265579 +0200
@@ -1765,6 +1765,7 @@ static const struct usb_device_id option
{ USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x7d03, 0xff, 0x00, 0x00) },
{ USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e01, 0xff, 0xff, 0xff) }, /*
D-Link DWM-152/C1 */
{ USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e02, 0xff, 0xff, 0xff) }, /*
D-Link DWM-156/C1 */
+ { USB_DEVICE_INTERFACE_CLASS(0x2020, 0x4000, 0xff) },/*
OLICARD300 - MT6225 */
{ USB_DEVICE(INOVIA_VENDOR_ID, INOVIA_SEW858) },
{ USB_DEVICE(VIATELECOM_VENDOR_ID, VIATELECOM_PRODUCT_CDS7) },
{ } /* Terminating entry */
--
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
Re: [GIT PULL] USB Chipidea updates for v4.2-rc1
On Mon, Jun 08, 2015 at 11:15:50AM +0800, Peter Chen wrote: > Hi Greg, > > Below is the pull request for USB Chipidea tree, thanks. > > Peter > > The following changes since commit b3d424e3dcbb5eba572baae30e1052b2fff7b51e: > > Merge tag 'phy-for-v4.2' of > git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy into usb-next > (2015-06-03 14:13:41 +0900) > > are available in the git repository at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/usb.git/ > tags/usb-ci-v4.2-rc1 Pulled and pushed out, thanks. greg k-h -- 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
Re: [PATCH v1] usb: dwc2: gadget: fix a memory use-after-free bug
On 5/28/2015 10:22 PM, Yunzhi Li wrote: > When s3c_hsotg_handle_unaligned_buf_complete() hs_req->req.buf > already destroyed, in s3c_hsotg_unmap_dma(), it touches > hs_req->req.dma again, so s3c_hsotg_unmap_dma() should be called > before s3c_hsotg_handle_unaligned_buf_complete(). Otherwise, it > will cause a bad_page BUG, when allocate this memory page next > time. > > This bug led to the following crash: > > BUG: Bad page state in process swapper/0 pfn:2bdbc > [ 26.820440] page:eed76780 count:0 mapcount:0 mapping: (null) index:0x0 > [ 26.854710] page flags: 0x200(arch_1) > [ 26.885836] page dumped because: PAGE_FLAGS_CHECK_AT_PREP flag set > [ 26.919179] bad because of flags: > [ 26.948917] page flags: 0x200(arch_1) > [ 26.979100] Modules linked in: > [ 27.008401] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W3.14.0 #17 > [ 27.041816] [] (unwind_backtrace) from [] > (show_stack+0x20/0x24) > [ 27.076108] [] (show_stack) from [] > (dump_stack+0x70/0x8c) > [ 27.110246] [] (dump_stack) from [] > (bad_page+0xfc/0x12c) > [ 27.143958] [] (bad_page) from [] > (get_page_from_freelist+0x3e4/0x50c) > [ 27.179298] [] (get_page_from_freelist) from [] > (__alloc_pages_nodemask) > [ 27.216296] [] (__alloc_pages_nodemask) from [] > (__get_free_pages+0x20/) > [ 27.252326] [] (__get_free_pages) from [] > (kmalloc_order_trace+0x34/0xa) > [ 27.288295] [] (kmalloc_order_trace) from [] > (__kmalloc+0x40/0x1ac) > [ 27.323751] [] (__kmalloc) from [] > (s3c_hsotg_ep_queue.isra.12+0x7c/0x1) > [ 27.359937] [] (s3c_hsotg_ep_queue.isra.12) from [] > (s3c_hsotg_ep_queue) > [ 27.397478] [] (s3c_hsotg_ep_queue_lock) from [] > (rx_submit+0xfc/0x164) > [ 27.433619] [] (rx_submit) from [] > (rx_complete+0x22c/0x230) > [ 27.468872] [] (rx_complete) from [] > (s3c_hsotg_complete_request+0xfc/0) > [ 27.506240] [] (s3c_hsotg_complete_request) from [] > (s3c_hsotg_handle_o) > [ 27.545401] [] (s3c_hsotg_handle_outdone) from [] > (s3c_hsotg_epint+0x2c) > [ 27.583689] [] (s3c_hsotg_epint) from [] > (s3c_hsotg_irq+0x1dc/0x4ac) > [ 27.621041] [] (s3c_hsotg_irq) from [] > (handle_irq_event_percpu+0x70/0x) > [ 27.659066] [] (handle_irq_event_percpu) from [] > (handle_irq_event+0x4c) > [ 27.697322] [] (handle_irq_event) from [] > (handle_fasteoi_irq+0xc8/0x11) > [ 27.735451] [] (handle_fasteoi_irq) from [] > (generic_handle_irq+0x30/0x) > [ 27.773918] [] (generic_handle_irq) from [] > (__handle_domain_irq+0x84/0) > [ 27.812018] [] (__handle_domain_irq) from [] > (gic_handle_irq+0x48/0x6c) > [ 27.849695] [] (gic_handle_irq) from [] > (__irq_svc+0x40/0x50) > [ 27.886907] Exception stack(0xc0d01ee0 to 0xc0d01f28) > > Signed-off-by: Yunzhi Li > > --- > > drivers/usb/dwc2/gadget.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c > index 6a30887..8070602 100644 > --- a/drivers/usb/dwc2/gadget.c > +++ b/drivers/usb/dwc2/gadget.c > @@ -1389,14 +1389,14 @@ static void s3c_hsotg_complete_request(struct > dwc2_hsotg *hsotg, > if (hs_req->req.status == -EINPROGRESS) > hs_req->req.status = result; > > + if (using_dma(hsotg)) > + s3c_hsotg_unmap_dma(hsotg, hs_ep, hs_req); > + > s3c_hsotg_handle_unaligned_buf_complete(hsotg, hs_ep, hs_req); > > hs_ep->req = NULL; > list_del_init(&hs_req->queue); > > - if (using_dma(hsotg)) > - s3c_hsotg_unmap_dma(hsotg, hs_ep, hs_req); > - > /* >* call the complete request with the locks off, just in case the >* request tries to queue more work for this endpoint. > Acked-by: John Youn John -- 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
Ongoing resets of JMicron (ID 152d:0567) JMS567 USB3-SATA-bridges
Hello List. I am having trouble solving a problem with a bunch of USB3-SATA-bridge connected to 2 USB3-hubs. I was not able finding any useful help for weeks now. Perhaps by bringing this issue to linux-usb can help me troubleshot the problem or sort out a bug or help improve Linux USB stability. The issue is an ongoing reset of different JMicron (ID 152d:0567) JMS567 USB3-SATA-bridges partitioned equally to 2 USB3-hubs (ID 2109:0812). I have 8 of theses bridges with 8 3TB WD (WDC WD30EZRX) hard drives connected to them. That 8 drives are configured running as a raid6. Reading/writing using 1 hard disk at a time works fine, even with higher speeds using dd or copying large files. Using several drives simultaneously is causing ongoing resets on a number of these bridges randomly (but 1 a time). It is like reading for seconds, then the read blocks for may by 5 seconds, a reset on one bridge happens and the reading continues. The host is a Debian 8 with Linux 3.16.0-4-amd64. What i noticed today was, by lowering max_sectors to 16 or 8 improves stability much, but it is still fare from stable. What could be done improving this? Are there any quirks worth trying? Any idea would be much appreciated. Axel ~# dmesg [2134752.916530] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800d55701c0 [2134752.916543] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800d5570208 [2134786.815641] usb 3-3.1.3: reset SuperSpeed USB device number 9 using xhci_hcd [2134786.830932] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800d55701c0 [2134786.830945] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800d5570208 [2134820.858285] usb 3-3.1.3: reset SuperSpeed USB device number 9 using xhci_hcd [2134820.873365] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800d55701c0 [2134820.873378] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800d5570208 [2134825.450020] usb 3-3.1.2: reset SuperSpeed USB device number 8 using xhci_hcd [2134825.464474] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800d5570340 [2134825.464488] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800d5570388 [2134856.820071] usb 3-3.1.3: reset SuperSpeed USB device number 9 using xhci_hcd [2134856.835270] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800d55701c0 [2134856.835283] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800d5570208 [2134891.886229] usb 3-3.1.3: reset SuperSpeed USB device number 9 using xhci_hcd [2134891.901496] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800d55701c0 [2134891.901509] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800d5570208 [2134926.824496] usb 3-3.1.3: reset SuperSpeed USB device number 9 using xhci_hcd [2134926.839680] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800d55701c0 [2134926.839693] xhci_hcd :00:14.0: xHCI xhci_drop_endpoint called with disabled ep 8800d5570208 ~# lsblk sdc 8:32 0 2,7T 0 disk └─md09:00 16,4T 0 raid6 └─stor 254:80 16,4T 0 crypt /mnt/stor sdd 8:48 0 2,7T 0 disk └─md09:00 16,4T 0 raid6 └─stor 254:80 16,4T 0 crypt /mnt/stor sde 8:64 0 2,7T 0 disk └─md09:00 16,4T 0 raid6 └─stor 254:80 16,4T 0 crypt /mnt/stor sdf 8:80 0 2,7T 0 disk └─md09:00 16,4T 0 raid6 └─stor 254:80 16,4T 0 crypt /mnt/stor sdg 8:96 0 2,7T 0 disk └─md09:00 16,4T 0 raid6 └─stor 254:80 16,4T 0 crypt /mnt/stor sdh 8:112 0 2,7T 0 disk └─md09:00 16,4T 0 raid6 └─stor 254:80 16,4T 0 crypt /mnt/stor sdi 8:128 0 2,7T 0 disk └─md09:00 16,4T 0 raid6 └─stor 254:80 16,4T 0 crypt /mnt/stor sdj 8:144 0 2,7T 0 disk └─md09:00 16,4T 0 raid6 └─stor 254:80 16,4T 0 crypt /mnt/stor ~# lsusb Bus 001 Device 002: ID 8087:8000 Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 007: ID 152d:0567 JMicron Technology Corp. / JMicron USA Technology Corp. Bus 003 Device 013: ID 152d:0567 JMicron Technology Corp. / JMicron
Re: [PATCH v4 1/2] phy-sun4i-usb: Add full support for usb0 phy / OTG
+Chanwoo
Hi,
On Sunday 31 May 2015 09:40 PM, Hans de Goede wrote:
The usb0 phy is connected to an OTG controller, and as such needs some special
handling:
1) It allows explicit control over the pullups, enable these on phy_init and
disable them on phy_exit.
2) It has bits to signal id and vbus detect to the musb-core, add support for
for monitoring id and vbus detect gpio-s for use in dual role mode, and set
these bits to the correct values for operating in host only mode when no
gpios are specified in the devicetree.
3) When in dual role mode the musb sunxi glue needs to know if the a host or
device cable is plugged in, so when in dual role mode register an extcon.
While updating the devicetree binding documentation also add documentation
for the sofar undocumented usage of regulators for vbus for all 3 phys.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Removed the sunxi specific phy functions, instead the id / vbus gpio polling
has been moved to the phy-sun4i-usb driver and their status is exported
through extcon for the sunxi-musb glue
Changes in v3:
-No changes
Changes in v4:
-Do not call regulator_disable in an unbalanced manner when an external vbus
is present
---
.../devicetree/bindings/phy/sun4i-usb-phy.txt | 18 +-
drivers/phy/Kconfig| 1 +
drivers/phy/phy-sun4i-usb.c| 273 -
3 files changed, 281 insertions(+), 11 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
index 16528b9..557fa99 100644
--- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -23,6 +23,13 @@ Required properties:
* "usb1_reset"
* "usb2_reset" for sun4i, sun6i or sun7i
+Optional properties:
+- usb0_id_det-gpios : gpio phandle for reading the otg id pin value
+- usb0_vbus_det-gpios : gpio phandle for detecting the presence of usb0 vbus
+- usb0_vbus-supply : regulator phandle for controller usb0 vbus
+- usb1_vbus-supply : regulator phandle for controller usb1 vbus
+- usb2_vbus-supply : regulator phandle for controller usb2 vbus
+
Example:
usbphy: phy@0x01c13400 {
#phy-cells = <1>;
@@ -32,6 +39,13 @@ Example:
reg-names = "phy_ctrl", "pmu1", "pmu2";
clocks = <&usb_clk 8>;
clock-names = "usb_phy";
- resets = <&usb_clk 1>, <&usb_clk 2>;
- reset-names = "usb1_reset", "usb2_reset";
+ resets = <&usb_clk 0>, <&usb_clk 1>, <&usb_clk 2>;
+ reset-names = "usb0_reset", "usb1_reset", "usb2_reset";
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
+ usb0_id_det-gpios = <&pio 7 19 GPIO_ACTIVE_HIGH>; /* PH19 */
+ usb0_vbus_det-gpios = <&pio 7 22 GPIO_ACTIVE_HIGH>; /* PH22 */
+ usb0_vbus-supply = <®_usb0_vbus>;
+ usb1_vbus-supply = <®_usb1_vbus>;
+ usb2_vbus-supply = <®_usb2_vbus>;
};
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index a53bd5b..4614fba 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -173,6 +173,7 @@ config PHY_SUN4I_USB
tristate "Allwinner sunxi SoC USB PHY driver"
depends on ARCH_SUNXI && HAS_IOMEM && OF
depends on RESET_CONTROLLER
+ select EXTCON
Avoid using 'select' on visible Kconfig symbols.
Also please split the patch to make the reviewing a bit easier.
Thanks
Kishon
select GENERIC_PHY
help
Enable this to support the transceiver that is part of Allwinner
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index 91c5be4..b45d707 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -1,7 +1,7 @@
/*
* Allwinner sun4i USB phy driver
*
- * Copyright (C) 2014 Hans de Goede
+ * Copyright (C) 2014-2015 Hans de Goede
*
* Based on code from
* Allwinner Technology Co., Ltd.
@@ -23,17 +23,23 @@
#include
#include
+#include
#include
+#include
#include
#include
#include
#include
#include
+#include
#include
#include
#include
#include
#include
+#include
+
+#define DRIVER_NAME "sun4i-usb-phy"
#define REG_ISCR 0x00
#define REG_PHYCTL0x04
@@ -47,6 +53,17 @@
#define SUNXI_AHB_INCRX_ALIGN_EN BIT(8)
#define SUNXI_ULPI_BYPASS_EN BIT(0)
+/* ISCR, Interface Status and Control bits */
+#define ISCR_ID_PULLUP_EN (1 << 17)
+#define ISCR_DPDM_PULLUP_EN(1 << 16)
+/* sunxi has the phy id/vbus pins not connected, so we use the force bits */
+#define ISCR_FORCE_ID_MASK (3 << 14)
+#define ISCR_FORCE_ID_LOW (2 << 14)
+#define ISCR_FORCE_ID_HIGH (3 << 14)
+#define ISCR_FORCE_VBUS_MASK (3 << 12)
+#define ISCR_FORCE_VBUS_LOW
