Re: [PATCH 0/5] usb: xhci: Fix breakage on dual-role case
Hi Mathias, On 18/08/15 13:39, Roger Quadros wrote: Hi, Plugging and unplugging a USB-OTG adapter with a USB device into a am437x-gp-evm dual-role port (USB1) causes XHCI to malfunction and USB device to be no longer detected after a few iterations. The triggering case is so 1) USB1 in peripheal mode 2) plug OTG adapter with USB device 3) USB1 switches to host mode 4) Detects new USB device 5) unplug OTG adapter 6) OTG core tries to remove host controller while new device is being processed. At 6 some races are observed in the XHCI driver causing it to malfunction. See kernel log at the end of this mail. This series tries to address some of the issues. Althouth it is not 100% fool proof yet and XHCI can still get stuck up for a few seconds occasionally, it did recover always in a max of 10 seconds and the USB device was enumerated after that. During a dual-role switch, usb_remove_hcd() and usb_add_hcd() will be called consecutively for both Shared and Primary HCDs. This can happen asynchronously and we have to be prepared for it. Even after this series I do occasionally see a delay of 5 seconds during adapter detach. (please see kernel log below). Is it possible to further optimize so that when xhci_stop is called we don't depend entirely on timeout timers to stop queued commands? [ 106.301771] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller [ 106.307480] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 3 [ 106.320818] xhci-hcd xhci-hcd.0.auto: hcc params 0x0238f06d hci version 0x100 quirks 0x00010010 [ 106.329809] xhci-hcd xhci-hcd.0.auto: irq 253, io mem 0x4839 [ 106.337587] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 [ 106.344455] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 106.352769] usb usb3: Product: xHCI Host Controller [ 106.357813] usb usb3: Manufacturer: Linux 4.1.6-01054-g496f557-dirty xhci-hcd [ 106.365012] usb usb3: SerialNumber: xhci-hcd.0.auto [ 106.381914] hub 3-0:1.0: USB hub found [ 106.390765] hub 3-0:1.0: 1 port detected [ 106.400732] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller [ 106.407492] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 4 [ 106.421396] usb usb4: We don't know the algorithms for LPM for this host, disabling LPM. [ 106.436701] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003 [ 106.443577] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 106.454456] usb usb4: Product: xHCI Host Controller [ 106.460990] usb usb4: Manufacturer: Linux 4.1.6-01054-g496f557-dirty xhci-hcd [ 106.473275] usb usb4: SerialNumber: xhci-hcd.0.auto [ 106.502263] hub 4-0:1.0: USB hub found [ 106.511431] hub 4-0:1.0: 1 port detected [ 106.715490] usb 3-1: new high-speed USB device number 2 using xhci-hcd [ 106.822091] xhci-hcd xhci-hcd.0.auto: remove, state 4 [ 106.827261] usb usb4: USB disconnect, device number 1 [ 111.845544] xhci-hcd xhci-hcd.0.auto: Command completion event does not match command [ 111.853518] xhci-hcd xhci-hcd.0.auto: Timeout while waiting for setup device command [ 111.888145] xhci-hcd xhci-hcd.0.auto: Host not halted after 16000 microseconds. [ 111.895528] xhci-hcd xhci-hcd.0.auto: Host controller not halted, aborting reset. [ 111.905732] xhci-hcd xhci-hcd.0.auto: USB bus 4 deregistered [ 111.912598] xhci-hcd xhci-hcd.0.auto: remove, state 1 [ 111.918695] usb usb3: USB disconnect, device number 1 [ 112.125544] usb 3-1: device descriptor read/all, error -22 [ 112.131106] usb usb3-port1: couldn't allocate usb_device [ 112.140019] xhci-hcd xhci-hcd.0.auto: USB bus 3 deregistered 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: [PATCH] UAS: also check for ESHUTDOWN in error reporting
Hi,
On 08/20/2015 11:16 AM, Oliver Neukum wrote:
-ESHUTDOWN means that the HC has been unplugged.
Reporting an error in that case makes no sense.
Signed-off-by: Oliver Neukum oneu...@suse.com
Looks good to me:
Acked-by: Hans de Goede hdego...@redhat.com
Regards,
Hans
---
drivers/usb/host/xhci-ext-caps.h | 0
drivers/usb/storage/uas.c| 15 ---
2 files changed, 8 insertions(+), 7 deletions(-)
mode change 100644 = 100755 drivers/usb/host/xhci-ext-caps.h
diff --git a/drivers/usb/host/xhci-ext-caps.h b/drivers/usb/host/xhci-ext-caps.h
old mode 100644
new mode 100755
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index f689219..c9a04c5 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -257,16 +257,16 @@ static void uas_stat_cmplt(struct urb *urb)
struct uas_cmd_info *cmdinfo;
unsigned long flags;
unsigned int idx;
+ int status = urb-status;
spin_lock_irqsave(devinfo-lock, flags);
if (devinfo-resetting)
goto out;
- if (urb-status) {
- if (urb-status != -ENOENT urb-status != -ECONNRESET) {
- dev_err(urb-dev-dev, stat urb: status %d\n,
- urb-status);
+ if (status) {
+ if (status != -ENOENT status != -ECONNRESET status !=
-ESHUTDOWN) {
+ dev_err(urb-dev-dev, stat urb: status %d\n,
status);
}
goto out;
}
@@ -348,6 +348,7 @@ static void uas_data_cmplt(struct urb *urb)
struct uas_dev_info *devinfo = (void *)cmnd-device-hostdata;
struct scsi_data_buffer *sdb = NULL;
unsigned long flags;
+ int status = urb-status;
spin_lock_irqsave(devinfo-lock, flags);
@@ -374,9 +375,9 @@ static void uas_data_cmplt(struct urb *urb)
goto out;
}
- if (urb-status) {
- if (urb-status != -ENOENT urb-status != -ECONNRESET)
- uas_log_cmd_state(cmnd, data cmplt err, urb-status);
+ if (status) {
+ if (status != -ENOENT status != -ECONNRESET status !=
-ESHUTDOWN)
+ uas_log_cmd_state(cmnd, data cmplt err, status);
/* error: no data transfered */
sdb-resid = sdb-length;
} else {
--
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
Some restrictions when using usbtest and g_zero
Hi all, I have played usbtest and g_zero (f_sourcesink f_loopback) to do the tests between two boards these days, and have found some restrictions, I list them here, and to see if they are common problems and can be improved or not. - Test 13 will fail due to there is pending IN request (f_sourcesink will queue a request unconditionally at its completion), and udc driver will run out error if that. udc driver must do that if it wants to pass USB CV2.0 MSC TEST. (othwerwise, Command Set Test - Device Configured will fail) - The parameter 'vary' must be the same with 'length' when do bulk/iso READ test, the host's packet size can't be smaller than device's. And 'vary' must be smaller than 'length' when do ctrl test. - When using pattern = 1 as module parameters to compare the data, the packet size must be same between host and device's. So, I do the test, I need to write customize commands for kinds of tests Eg: below are two module parameters: modprobe usbtest pattern=1 alt=1 (host side) modprobe g_zero pattern=1 buflen=512 isoc_interval=1 isoc_mult=2 (device side) The test script is like below: counter = 0 while [ 1 ] do i=0; while [ $i -lt 14 ] do ./testusb -a -t $i i=$(( $i + 1 )) done ./testusb -a -t 14 -v 128 ./testusb -a -t 15 ./testusb -a -t 16 -s 3072 ./testusb -a -t 17 ./testusb -a -t 18 ./testusb -a -t 19 ./testusb -a -t 20 ./testusb -a -t 21 -v 128 ./testusb -a -t 22 ./testusb -a -t 23 -s 3072 ./testusb -a -t 24 counter=$(( $counter + 1 )) echo loop $counter th ends\n done Thanks. -- Best Regards, Peter Chen -- 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: Some restrictions when using usbtest and g_zero
On Thu, 20 Aug 2015, Felipe Balbi wrote:
- Test 13 will fail due to there is pending IN request (f_sourcesink
will queue a request unconditionally at its completion), and udc driver
will run out error if that. udc driver must do that if it wants to
wait, what ? test 13 works just fine here. (I'll try again in a few
minutes just to make sure)
It may depend on what UDC and what test device you use.
Why ? Why would SET_FEATURE(HALT) fail ? I can only see it as a bug on
the UDC driver. A bug which should be fixed.
Here's what the kerneldoc for usb_ep_set_halt() says:
* Returns zero, or a negative error code. On success, this call sets
* underlying hardware state that blocks data transfers.
* Attempts to halt IN endpoints will fail (returning -EAGAIN) if any
* transfer requests are still queued, or if the controller hardware
* (usually a FIFO) still holds bytes that the host hasn't collected.
That's talking about IN endpoints only, not OUT -- but Peter's original
email mentioned that Test 13 fails if there's a pending IN usb_request.
usbtest's halt set/clear
test is pretty simple:
1. move data on EP to verify it's not halted
2. set halt
3. move data on EP to verify STALL is returned
4. clear halt
5. move data on EP to verify it's not halted
I did fix that months ago on DWC3 because there was a bug on DWC3. MUSB
was fixed years back too for a similar bug.
According to the kerneldoc above, step 2 will fail if the gadget driver
automatically submits a new IN request after step 1 completes. Since
gadget zero (either loopback or source-sink mode) does resubmit IN
requests, you can understand Peter's problem.
pass USB CV2.0 MSC TEST. (othwerwise, Command Set Test - Device
Configured
will fail)
Why would a pending struct usb_request in your queue fail USB CV ?
_Lack_ of a pending request can cause the USB CV to fail. In Peter's
example, if you're testing a Mass-Storage gadget, USB CV requires that
there be a pending Bulk-OUT request when the gadget is idle (so that
the next SCSI command can be sent out).
But if there's a pending usb_request on a bulk-OUT endpoint, will a UDC
driver be able to carry out a Set-Halt-Feature request from the host?
The answer isn't clear. And it's even worse for bulk-IN.
how can USB CV even test that there is a pending request on the UDC's
side ? Short of actually moving data on that pipe, there's not way.
That's exactly what the USB CV does -- it tries to send data. If it
can't, the test fails. (At least, that's what I remember; it was a
while ago that I looked at this.)
However, in this respect Peter was a little inconsistent. The USB CV
MSC test requires a pending bulk-OUT request, but the Set-Halt problem
affects bulk-IN endpoints.
Also, when the Halt request comes, UDC must take care of doing whatever
necessary to make halt work. If that means cancelling transfers on a
particular EP, so be it. Give them back with -ESHUTDOWN or -EPIPE or
whatever. Just look at usb_ep_set_halt()'s documentation which states
that drivers may need to empty the endpoint's request queue first.
Exactly. As far as I know, UDCs _don't_ bother to cancel transfers on
an endpoint when the host sends Set-Halt. If you want to say that this
is a bug in the UDC drivers, I won't argue.
On top of that, we have the stall=0 flag for cases where the UDC really
can't handle that halt request correctly.
True. As far as I know, f_mass_storage is the only code which uses
that flag (because no protocols other than Mass Storage require stalls
on endpoints other than ep0).
- When using pattern = 1 as module parameters to compare the data, the
packet size must be same between host and device's.
why ?
The gadget stores the pattern data starting from 0 for each packet it
sends. But the host tests the pattern data starting from 0 only at the
beginning of the transfer; the host expects the pattern to continue
without resetting at packet boundaries (if the transfer length is
larger than the maxpacket size).
then that's another bug which needs to be fixed :-)
That at least should be relatively simple. A few changes to
simple_fill_buf(), simple_check_buf(), and alloc_sglist() should do it.
(One extra complication is that these routines will need to know the
maxpacket size, but currently they don't.)
I suppose the right thing is for the UDC to temporarily disable the
endpoint, set the HALT feature, and then re-enable the endpoint (along
with the pending request). But changing a bunch of UDC drivers for
such a minor thing doesn't seem worthwhile.
we can move that into udc-core.c:
int usb_ep_set_halt(struct usb_ep *ep)
{
if (WARN_ON(!ep))
return -EINVAL;
if (!usb_ep_queue_is_empty(ep))
usb_ep_empty_queue(ep, -EPIPE);
return __usb_ep_set_halt(ep);
}
or something similar.
It's a good idea, but I'm
Re: [PATCH v5 01/46] usb: gadget: encapsulate endpoint claiming mechanism
On 08/20/2015 06:48 PM, Felipe Balbi wrote: On Thu, Aug 20, 2015 at 06:28:14PM +0200, Robert Baldyga wrote: Hi Felipe, On 08/20/2015 05:35 PM, Felipe Balbi wrote: [...] just letting you know that this regresses all gadget drivers making them try to disable previously disabled endpoints and enable previously enabled endpoints. I have a possible fix (see below) but then it shows a problem on the host side when using with g_zero (see further below): commit 3b8932100aacb6cfbffe288ca93025d8b8430c00 Author: Felipe Balbi ba...@ti.com Date: Wed Aug 19 18:05:27 2015 -0500 usb: gadget: fix ep-claimed lifetime In order to fix a regression introduced by commit cc476b42a39d (usb: gadget: encapsulate endpoint claiming mechanism) we have to introduce a simple helper to check if a particular is enabled or not. After that, we need to move ep-claimed lifetime to usb_ep_enable() and usb_ep_disable() since those are the only functions which actually enable and disable endpoints. A follow-up patch will come to drop all driver_data checks from function drivers, since those are, now, pointless. Fixes: cc476b42a39d (usb: gadget: encapsulate endpoint claiming mechanism) Cc: Robert Baldyga r.bald...@samsung.com Signed-off-by: Felipe Balbi ba...@ti.com diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c index 978435a51038..ad45070cd76f 100644 --- a/drivers/usb/gadget/epautoconf.c +++ b/drivers/usb/gadget/epautoconf.c @@ -126,7 +126,6 @@ found_ep: ep-address = desc-bEndpointAddress; ep-desc = NULL; ep-comp_desc = NULL; - ep-claimed = true; Removing this line causes autoconfig can return the same endpoint many times. This probably causes problems with g_zero. I will try to fix it ASAP. I was considering the same thing, but the lifetime of -claimed doesn't look correct to me either way. Note that once the flag is enabled, it won't get disabled by most gadget drivers. And it should not be. This flag is indicator, that endpoint is used by some function. It should be set once by usb_ep_autoconfig() and cleared by usb_ep_autoconfig_reset(). I wonder what is reason of this enable/disable regression. Maybe the problem is that we don't set ep-driver_data to NULL in usb_ep_autoconfig_reset() (so far it was done). Does this problem occur while gadget is binded to UDC for the first time, or at any next time? Unfortunately at this moment I don't have access to my hardware, so it will take a moment before I will setup some testing environment. Thanks, Robert -- 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
MUSB sysfs node naming convention
Hi, Currently, the sysfs MUSB node name uses kernel device name global *auto* convention. So depending on kernel configuration, the two MUSB device nodes could be musb-hdrc.0.auto/musb-hdrc.1.auto, or musb-hdrc.1.auto/musb-hdrc.2.auto. Of cause the index could be any other number if there were more devices using this naming convention. Why we decided to name MUSB nodes this way? It gives me a lot of troubles in scripting and documentation. Thanks, -Bin. -- 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: musb: omap2430: use *syscon* framework API to write to mailbox register
Hi, On Thursday 06 August 2015 02:17 PM, Tony Lindgren wrote: * Kishon Vijay Abraham I kis...@ti.com [150805 07:10]: On Wednesday 05 August 2015 01:31 PM, Tony Lindgren wrote: We don't have syscon-otghs and to me it seems we need a PHY driver as I pointed out at: If *syscon-otghs* is not present, then it'll fall-back to using the *ctrl-module*. OK great. https://lkml.org/lkml/2015/6/24/231 Maybe I should have explained this in the previous thread. The *otghs* register that we are trying to access here does _not_ belong to the PHY. It acts as mailbox register from MUSB glue (TI integration layer) to MUSB core. That's why it's programmed in the TI glue layer (omap2430.c). Even when we were using the older API [omap_control_usb_set_mode()], we first call omap_musb_mailbox from the PHY drivers (phy-twl4030-usb.c, phy-twl6030-usb.c) and then omap_musb_mailbox in the TI glue writes to the control module instead of PHY drivers directly calling omap_control_usb_set_mode(). Hmm looking at Table 18-204. CONTROL_USBOTGHS_CONTROL it seems to mention transceiver for quite a few bitfields :) Probably what that register does is control a PHY over ULPI. OMAP4 uses UTMI PHY and it uses CONTROL_USBOTGHS_CONTROL too. So from Linux kernel point of view we're best off treating it as a PHY. It seems it should have a minimal PHY driver similar to what we have for dm816x control module in drivers/phy/phy-dm816x-usb.c. hmm.. IMHO CONTROL_USBOTGHS_CONTROL register belongs to the TI MUSB glue and should be programmed in omap2430.c. It's better to get the opinion of Felipe here. Felipe? For reference, here is the register bitfields pasted from 4460 TRM: Table 18-204. CONTROL_USBOTGHS_CONTROL, p3972 Physical Address 0x4A00 233C BIT NAMEDESCIPTION 8 DISCHRGVBUS ... OTG transceiver does (not) discharge VBUS ... 7 CHRGVBUS... OTG transceiver does (not) charge VBUS ... 6 IDPULLUP... OTG transceiver does (not) drive VBUS ... 4 IDDIG ... OTG transceiver does (not) apply a pullup to ID ... 3 SESSEND ... VBUS voltage is above/below VB_SESS_END ... 2 VBUSVALID ... VBUS is above the threshold ... 1 BVALID ... VBUS voltage is above/below VB_SESS_VLD ... 0 AVALID ... BUS voltage is above/below VA_SESS_VLD ... So how about just adding ONTROL_USBOTGHS_CONTROL support to the existing drivers/phy/phy-omap-usb2.c instead? It seems that it should allow us to completely get rid of the custom mailbox stuff for MUSB 2430 support? Not in phy-omap-usb2.c. It's the UTMI PHY driver and is not used by OMAP3 based boards (uses twl4030 ULPI PHY). CONTROL_USBOTGHS_CONTROL has to be programmed for OMAP3 also. Thanks Kishon -- 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] UAS: also check for ESHUTDOWN in error reporting
-ESHUTDOWN means that the HC has been unplugged.
Reporting an error in that case makes no sense.
Signed-off-by: Oliver Neukum oneu...@suse.com
---
drivers/usb/host/xhci-ext-caps.h | 0
drivers/usb/storage/uas.c| 15 ---
2 files changed, 8 insertions(+), 7 deletions(-)
mode change 100644 = 100755 drivers/usb/host/xhci-ext-caps.h
diff --git a/drivers/usb/host/xhci-ext-caps.h b/drivers/usb/host/xhci-ext-caps.h
old mode 100644
new mode 100755
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index f689219..c9a04c5 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -257,16 +257,16 @@ static void uas_stat_cmplt(struct urb *urb)
struct uas_cmd_info *cmdinfo;
unsigned long flags;
unsigned int idx;
+ int status = urb-status;
spin_lock_irqsave(devinfo-lock, flags);
if (devinfo-resetting)
goto out;
- if (urb-status) {
- if (urb-status != -ENOENT urb-status != -ECONNRESET) {
- dev_err(urb-dev-dev, stat urb: status %d\n,
- urb-status);
+ if (status) {
+ if (status != -ENOENT status != -ECONNRESET status !=
-ESHUTDOWN) {
+ dev_err(urb-dev-dev, stat urb: status %d\n,
status);
}
goto out;
}
@@ -348,6 +348,7 @@ static void uas_data_cmplt(struct urb *urb)
struct uas_dev_info *devinfo = (void *)cmnd-device-hostdata;
struct scsi_data_buffer *sdb = NULL;
unsigned long flags;
+ int status = urb-status;
spin_lock_irqsave(devinfo-lock, flags);
@@ -374,9 +375,9 @@ static void uas_data_cmplt(struct urb *urb)
goto out;
}
- if (urb-status) {
- if (urb-status != -ENOENT urb-status != -ECONNRESET)
- uas_log_cmd_state(cmnd, data cmplt err, urb-status);
+ if (status) {
+ if (status != -ENOENT status != -ECONNRESET status !=
-ESHUTDOWN)
+ uas_log_cmd_state(cmnd, data cmplt err, status);
/* error: no data transfered */
sdb-resid = sdb-length;
} else {
--
2.1.4
--
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 3/3] power: wm831x_power: Support USB charger current limit management
From: Baolin Wang
Sent: 14 August 2015 10:48
+/* In miliamps */
Spelling police: milliamps
+static unsigned int wm831x_usb_limits[] = {
+ 0,
+ 2,
+ 100,
+ 500,
+ 900,
+ 1500,
+ 1800,
+ 550,
+};
David
--
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 4/5] usb: xhci: stop everything on the first call to xhci_stop
On 18/08/15 15:14, Mathias Nyman wrote:
On 18.08.2015 13:39, Roger Quadros wrote:
xhci_stop will be called twice, once for the shared hcd
and again for the primary hcd.
We stop the XHCI controller in any case so clean up
everything on the first call else we can timeout
waiting for pending requests to complete.
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/host/xhci.c | 20 +---
1 file changed, 5 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index d5f44b1..9a7f12c 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -655,15 +655,6 @@ int xhci_run(struct usb_hcd *hcd)
}
EXPORT_SYMBOL_GPL(xhci_run);
-static void xhci_only_stop_hcd(struct usb_hcd *hcd)
-{
-struct xhci_hcd *xhci = hcd_to_xhci(hcd);
-
-spin_lock_irq(xhci-lock);
-xhci_halt(xhci);
-spin_unlock_irq(xhci-lock);
-}
-
/*
* Stop xHCI driver.
*
@@ -678,15 +669,14 @@ void xhci_stop(struct usb_hcd *hcd)
u32 temp;
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
-mutex_lock(xhci-mutex);
-
-if (!usb_hcd_is_primary_hcd(hcd)) {
-xhci_only_stop_hcd(xhci-shared_hcd);
-mutex_unlock(xhci-mutex);
+if (xhci-xhc_state XHCI_STATE_HALTED)
return;
-}
+mutex_lock(xhci-mutex);
spin_lock_irq(xhci-lock);
+xhci-xhc_state |= XHCI_STATE_HALTED;
+xhci-cmd_ring_state = CMD_RING_STATE_STOPPED;
+
The XHCI_STATE_HALTED and CMD_RING_STATE_STOPPED states will be set in
xhci_halt() right
after this.
Well, or, it actually sets them after waiting for the controller to really
halt.
I guess setting them here helps the second call to hcd_stop() to return
early, not taking the mutex and
trying to stop controller once again.
Yes, that was my intention :)
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
[PATCH v2 1/2] usb: gadget: composite: fill bcdUSB for any gadget max speed
When handling device GET_DESCRIPTOR, composite gadget driver fills
the bcdUSB field only if the gadget supports USB 3.0. Otherwise
the field is left unfilled.
For consistency, set bcdUSB to 0x0200 for gadgets that don't
support superspeed.
It's correct to use 0x0200 for any setting that doesn't use
superspeed, since USB 2.0 devices can restrict themselves to
full speed only. It is NOT correct to use 0x0210, since BOS
descriptors are handled only if gadget_is_superspeed() is
satisfied, otherwise it results in a stall.
Signed-off-by: Igor Kotrasinski i.kotrasi...@samsung.com
---
drivers/usb/gadget/composite.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 58b4657..b3196e2 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1499,6 +1499,8 @@ composite_setup(struct usb_gadget *gadget, const struct
usb_ctrlrequest *ctrl)
} else {
cdev-desc.bcdUSB = cpu_to_le16(0x0210);
}
+ } else {
+ cdev-desc.bcdUSB = cpu_to_le16(0x0200);
}
value = min(w_length, (u16) sizeof cdev-desc);
--
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
[PATCH v2 2/2] usb: gadget: composite: remove redundant bcdUSB setting in legacy
Since composite now overwrites bcdUSB for any gadget, remove
setting it in legacy gadgets. All legacy gadgets set 0x0200, the
same as the value additionally set by composite, so there is no
behaviour change.
Signed-off-by: Igor Kotrasinski i.kotrasi...@samsung.com
---
drivers/usb/gadget/legacy/acm_ms.c | 2 +-
drivers/usb/gadget/legacy/audio.c | 2 +-
drivers/usb/gadget/legacy/cdc2.c | 2 +-
drivers/usb/gadget/legacy/ether.c | 2 +-
drivers/usb/gadget/legacy/g_ffs.c | 2 +-
drivers/usb/gadget/legacy/gmidi.c | 2 +-
drivers/usb/gadget/legacy/hid.c| 2 +-
drivers/usb/gadget/legacy/mass_storage.c | 2 +-
drivers/usb/gadget/legacy/multi.c | 2 +-
drivers/usb/gadget/legacy/ncm.c| 2 +-
drivers/usb/gadget/legacy/nokia.c | 2 +-
drivers/usb/gadget/legacy/printer.c| 2 +-
drivers/usb/gadget/legacy/serial.c | 2 +-
drivers/usb/gadget/legacy/tcm_usb_gadget.c | 2 +-
drivers/usb/gadget/legacy/webcam.c | 2 +-
drivers/usb/gadget/legacy/zero.c | 2 +-
16 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/usb/gadget/legacy/acm_ms.c
b/drivers/usb/gadget/legacy/acm_ms.c
index 1194b09..4ee598f 100644
--- a/drivers/usb/gadget/legacy/acm_ms.c
+++ b/drivers/usb/gadget/legacy/acm_ms.c
@@ -40,7 +40,7 @@ static struct usb_device_descriptor device_desc = {
.bLength = sizeof device_desc,
.bDescriptorType = USB_DT_DEVICE,
- .bcdUSB = cpu_to_le16(0x0200),
+ /* .bcdUSB = DYNAMIC */
.bDeviceClass = USB_CLASS_MISC /* 0xEF */,
.bDeviceSubClass = 2,
diff --git a/drivers/usb/gadget/legacy/audio.c
b/drivers/usb/gadget/legacy/audio.c
index f289caf..f7399eb 100644
--- a/drivers/usb/gadget/legacy/audio.c
+++ b/drivers/usb/gadget/legacy/audio.c
@@ -124,7 +124,7 @@ static struct usb_device_descriptor device_desc = {
.bLength = sizeof device_desc,
.bDescriptorType = USB_DT_DEVICE,
- .bcdUSB = __constant_cpu_to_le16(0x200),
+ /* .bcdUSB = DYNAMIC */
#ifdef CONFIG_GADGET_UAC1
.bDeviceClass = USB_CLASS_PER_INTERFACE,
diff --git a/drivers/usb/gadget/legacy/cdc2.c b/drivers/usb/gadget/legacy/cdc2.c
index afd3e37..4b0458e 100644
--- a/drivers/usb/gadget/legacy/cdc2.c
+++ b/drivers/usb/gadget/legacy/cdc2.c
@@ -43,7 +43,7 @@ static struct usb_device_descriptor device_desc = {
.bLength = sizeof device_desc,
.bDescriptorType = USB_DT_DEVICE,
- .bcdUSB = cpu_to_le16(0x0200),
+ /* .bcdUSB = DYNAMIC */
.bDeviceClass = USB_CLASS_COMM,
.bDeviceSubClass = 0,
diff --git a/drivers/usb/gadget/legacy/ether.c
b/drivers/usb/gadget/legacy/ether.c
index a3323dc..2e14894 100644
--- a/drivers/usb/gadget/legacy/ether.c
+++ b/drivers/usb/gadget/legacy/ether.c
@@ -151,7 +151,7 @@ static struct usb_device_descriptor device_desc = {
.bLength = sizeof device_desc,
.bDescriptorType = USB_DT_DEVICE,
- .bcdUSB = cpu_to_le16 (0x0200),
+ /* .bcdUSB = DYNAMIC */
.bDeviceClass = USB_CLASS_COMM,
.bDeviceSubClass = 0,
diff --git a/drivers/usb/gadget/legacy/g_ffs.c
b/drivers/usb/gadget/legacy/g_ffs.c
index e821931..97ef1c2 100644
--- a/drivers/usb/gadget/legacy/g_ffs.c
+++ b/drivers/usb/gadget/legacy/g_ffs.c
@@ -69,7 +69,7 @@ static struct usb_device_descriptor gfs_dev_desc = {
.bLength= sizeof gfs_dev_desc,
.bDescriptorType= USB_DT_DEVICE,
- .bcdUSB = cpu_to_le16(0x0200),
+ /* .bcdUSB = DYNAMIC */
.bDeviceClass = USB_CLASS_PER_INTERFACE,
.idVendor = cpu_to_le16(GFS_VENDOR_ID),
diff --git a/drivers/usb/gadget/legacy/gmidi.c
b/drivers/usb/gadget/legacy/gmidi.c
index da19c48..cad1b51 100644
--- a/drivers/usb/gadget/legacy/gmidi.c
+++ b/drivers/usb/gadget/legacy/gmidi.c
@@ -88,7 +88,7 @@ MODULE_PARM_DESC(out_ports, Number of MIDI output ports);
static struct usb_device_descriptor device_desc = {
.bLength = USB_DT_DEVICE_SIZE,
.bDescriptorType = USB_DT_DEVICE,
- .bcdUSB = __constant_cpu_to_le16(0x0200),
+ /* .bcdUSB = DYNAMIC */
.bDeviceClass = USB_CLASS_PER_INTERFACE,
.idVendor = __constant_cpu_to_le16(DRIVER_VENDOR_NUM),
.idProduct =__constant_cpu_to_le16(DRIVER_PRODUCT_NUM),
diff --git a/drivers/usb/gadget/legacy/hid.c b/drivers/usb/gadget/legacy/hid.c
index 2baa572..0b31036 100644
--- a/drivers/usb/gadget/legacy/hid.c
+++ b/drivers/usb/gadget/legacy/hid.c
@@ -48,7 +48,7 @@ static struct usb_device_descriptor device_desc = {
.bLength = sizeof device_desc,
.bDescriptorType = USB_DT_DEVICE,
- .bcdUSB =
[PATCH v4 3/5] gadget: Support for the usb charger framework
For supporting the usb charger, it adds the usb_charger_init() and
usb_charger_exit() functions for usb charger initialization and exit.
Introduce a callback 'get_charger_type' which will implemented by
user for usb gadget operations to get the usb charger type.
Signed-off-by: Baolin Wang baolin.w...@linaro.org
---
drivers/usb/gadget/udc/udc-core.c |8
include/linux/usb/gadget.h|2 ++
2 files changed, 10 insertions(+)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index 4238fc3..370376e 100644
--- a/drivers/usb/gadget/udc/udc-core.c
+++ b/drivers/usb/gadget/udc/udc-core.c
@@ -28,6 +28,7 @@
#include linux/usb/ch9.h
#include linux/usb/gadget.h
#include linux/usb.h
+#include linux/usb/usb_charger.h
/**
* struct usb_udc - describes one usb device controller
@@ -437,8 +438,14 @@ int usb_add_gadget_udc_release(struct device *parent,
struct usb_gadget *gadget,
mutex_unlock(udc_lock);
+ ret = usb_charger_init(gadget);
+ if (ret)
+ goto err5;
+
return 0;
+err5:
+ device_del(udc-dev);
err4:
list_del(udc-list);
mutex_unlock(udc_lock);
@@ -513,6 +520,7 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
kobject_uevent(udc-dev.kobj, KOBJ_REMOVE);
flush_work(gadget-work);
device_unregister(udc-dev);
+ usb_charger_exit(gadget);
device_unregister(gadget-dev);
}
EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index 755e8bc..451ad32 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -537,6 +537,7 @@ struct usb_gadget_ops {
struct usb_ep *(*match_ep)(struct usb_gadget *,
struct usb_endpoint_descriptor *,
struct usb_ss_ep_comp_descriptor *);
+ enum usb_charger_type (*get_charger_type)(struct usb_gadget *);
};
/**
@@ -611,6 +612,7 @@ struct usb_gadget {
struct usb_otg_caps *otg_caps;
struct raw_notifier_headnh;
struct mutexlock;
+ struct usb_charger *charger;
unsignedsg_supported:1;
unsignedis_otg:1;
--
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 v4 5/5] power: wm831x_power: Support USB charger current limit management
Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.
Signed-off-by: Mark Brown broo...@kernel.org
Signed-off-by: Baolin Wang baolin.w...@linaro.org
Acked-by: Lee Jones lee.jo...@linaro.org
Acked-by: Charles Keepax ckee...@opensource.wolfsonmicro.com
Acked-by: Peter Chen peter.c...@freescale.com
---
drivers/power/wm831x_power.c | 69 ++
include/linux/mfd/wm831x/pdata.h |3 ++
2 files changed, 72 insertions(+)
diff --git a/drivers/power/wm831x_power.c b/drivers/power/wm831x_power.c
index db11ae6..33ae27a 100644
--- a/drivers/power/wm831x_power.c
+++ b/drivers/power/wm831x_power.c
@@ -13,6 +13,7 @@
#include linux/platform_device.h
#include linux/power_supply.h
#include linux/slab.h
+#include linux/usb/usb_charger.h
#include linux/mfd/wm831x/core.h
#include linux/mfd/wm831x/auxadc.h
@@ -31,6 +32,8 @@ struct wm831x_power {
char usb_name[20];
char battery_name[20];
bool have_battery;
+ struct usb_charger *usb_charger;
+ struct notifier_block usb_notify;
};
static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
@@ -125,6 +128,43 @@ static enum power_supply_property wm831x_usb_props[] = {
POWER_SUPPLY_PROP_VOLTAGE_NOW,
};
+/* In milliamps */
+static unsigned int wm831x_usb_limits[] = {
+ 0,
+ 2,
+ 100,
+ 500,
+ 900,
+ 1500,
+ 1800,
+ 550,
+};
+
+static int wm831x_usb_limit_change(struct notifier_block *nb,
+ unsigned long limit, void *data)
+{
+ struct wm831x_power *wm831x_power = container_of(nb,
+struct wm831x_power,
+usb_notify);
+ int i, best;
+
+ /* Find the highest supported limit */
+ best = 0;
+ for (i = 0; i ARRAY_SIZE(wm831x_usb_limits); i++) {
+ if (limit = wm831x_usb_limits[i]
+ wm831x_usb_limits[best] wm831x_usb_limits[i])
+ best = i;
+ }
+
+ dev_dbg(wm831x_power-wm831x-dev,
+ Limiting USB current to %dmA, wm831x_usb_limits[best]);
+
+ wm831x_set_bits(wm831x_power-wm831x, WM831X_POWER_STATE,
+ WM831X_USB_ILIM_MASK, best);
+
+ return 0;
+}
+
/*
* Battery properties
*/
@@ -606,8 +646,31 @@ static int wm831x_power_probe(struct platform_device *pdev)
}
}
+ if (wm831x_pdata wm831x_pdata-usb_gadget) {
+ power-usb_charger =
+ usb_charger_find_by_name(wm831x_pdata-usb_gadget);
+ if (IS_ERR(power-usb_charger)) {
+ ret = PTR_ERR(power-usb_charger);
+ dev_err(pdev-dev,
+ Failed to find USB gadget: %d\n, ret);
+ goto err_bat_irq;
+ }
+
+ power-usb_notify.notifier_call = wm831x_usb_limit_change;
+
+ ret = usb_charger_register_notify(power-usb_charger,
+ power-usb_notify);
+ if (ret != 0) {
+ dev_err(pdev-dev,
+ Failed to register notifier: %d\n, ret);
+ goto err_usb_charger;
+ }
+ }
+
return ret;
+err_usb_charger:
+ /* put_device on charger */
err_bat_irq:
--i;
for (; i = 0; i--) {
@@ -637,6 +700,12 @@ static int wm831x_power_remove(struct platform_device
*pdev)
struct wm831x *wm831x = wm831x_power-wm831x;
int irq, i;
+ if (wm831x_power-usb_charger) {
+ usb_charger_unregister_notify(wm831x_power-usb_charger,
+ wm831x_power-usb_notify);
+ /* Free charger */
+ }
+
for (i = 0; i ARRAY_SIZE(wm831x_bat_irqs); i++) {
irq = wm831x_irq(wm831x,
platform_get_irq_byname(pdev,
diff --git a/include/linux/mfd/wm831x/pdata.h b/include/linux/mfd/wm831x/pdata.h
index dcc9631..5af8399 100644
--- a/include/linux/mfd/wm831x/pdata.h
+++ b/include/linux/mfd/wm831x/pdata.h
@@ -126,6 +126,9 @@ struct wm831x_pdata {
/** The driver should initiate a power off sequence during shutdown */
bool soft_shutdown;
+ /** dev_name of USB charger gadget to integrate with */
+ const char *usb_gadget;
+
int irq_base;
int gpio_base;
int gpio_defaults[WM831X_GPIO_NUM];
--
1.7.9.5
--
To unsubscribe from
[PATCH v4 4/5] gadget: Integrate with the usb gadget supporting for usb charger
When the usb gadget supporting for usb charger is ready, the usb charger
should get the type by the 'get_charger_type' callback which is implemented
by the usb gadget operations, and get the usb charger pointer from struct
'usb_gadget'.
Signed-off-by: Baolin Wang baolin.w...@linaro.org
---
drivers/usb/gadget/charger.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/charger.c b/drivers/usb/gadget/charger.c
index 35b46c1..a919f38 100644
--- a/drivers/usb/gadget/charger.c
+++ b/drivers/usb/gadget/charger.c
@@ -181,6 +181,13 @@ int usb_charger_unregister_notify(struct usb_charger
*uchger,
enum usb_charger_type
usb_charger_detect_type(struct usb_charger *uchger)
{
+ if (uchger-gadget uchger-gadget-ops
+uchger-gadget-ops-get_charger_type)
+ uchger-type =
+ uchger-gadget-ops-get_charger_type(uchger-gadget);
+ else
+ uchger-type = UNKNOWN_TYPE;
+
return uchger-type;
}
@@ -313,7 +320,8 @@ static int
usb_charger_plug_by_gadget(struct notifier_block *nb,
unsigned long state, void *data)
{
- struct usb_charger *uchger = NULL;
+ struct usb_gadget *gadget = (struct usb_gadget *)data;
+ struct usb_charger *uchger = gadget-charger;
enum usb_charger_state uchger_state;
if (!uchger)
@@ -480,6 +488,7 @@ int usb_charger_init(struct usb_gadget *ugadget)
/* register a notifier on a usb gadget device */
uchger-gadget = ugadget;
+ ugadget-charger = uchger;
uchger-old_gadget_state = ugadget-state;
uchger-gadget_nb.notifier_call = usb_charger_plug_by_gadget;
usb_gadget_register_notify(ugadget, uchger-gadget_nb);
@@ -503,7 +512,7 @@ fail:
int usb_charger_exit(struct usb_gadget *ugadget)
{
- struct usb_charger *uchger = NULL;
+ struct usb_charger *uchger = ugadget-charger;
if (!uchger)
return -EINVAL;
--
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] usb: gadget: f_uac1: Convert use of __constant_cpu_to_le16 to cpu_to_le16
From: Vaishali Thakkar
Sent: 19 August 2015 06:31
To: Felipe Balbi
Cc: Greg Kroah-Hartman; linux-usb@vger.kernel.org;
linux-ker...@vger.kernel.org
Subject: [PATCH] usb: gadget: f_uac1: Convert use of __constant_cpu_to_le16
to cpu_to_le16
In big endian cases, macro cpu_to_le16 unfolds to __swab16 which
provides special case for constants. In little endian cases,
__constant_cpu_to_le16 and cpu_to_le16 expand directly to the
same expression. So, replace __constant_cpu_to_le16 with
cpu_to_le16 with the goal of getting rid of the definition of
__constant_cpu_to_le16 completely.
The semantic patch that performs this transformation is as follows:
@@expression x;@@
- __constant_cpu_to_le16(x)
+ cpu_to_le16(x)
Signed-off-by: Vaishali Thakkar vthakkar1...@gmail.com
---
drivers/usb/gadget/function/f_uac1.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/gadget/function/f_uac1.c
b/drivers/usb/gadget/function/f_uac1.c
index 7856b33..5aa8d8a 100644
--- a/drivers/usb/gadget/function/f_uac1.c
+++ b/drivers/usb/gadget/function/f_uac1.c
@@ -57,8 +57,8 @@ static struct uac1_ac_header_descriptor_1 ac_header_desc = {
.bLength = UAC_DT_AC_HEADER_LENGTH,
.bDescriptorType = USB_DT_CS_INTERFACE,
.bDescriptorSubtype = UAC_HEADER,
- .bcdADC = __constant_cpu_to_le16(0x0100),
- .wTotalLength = __constant_cpu_to_le16(UAC_DT_TOTAL_LENGTH),
+ .bcdADC = cpu_to_le16(0x0100),
+ .wTotalLength = cpu_to_le16(UAC_DT_TOTAL_LENGTH),
Have you test compiled this on a big-endian system?
My gut feeling is that is fails.
David
--
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] UAS: also check for ESHUTDOWN in error reporting
Hello.
On 8/20/2015 12:16 PM, Oliver Neukum wrote:
-ESHUTDOWN means that the HC has been unplugged.
Reporting an error in that case makes no sense.
Signed-off-by: Oliver Neukum oneu...@suse.com
---
drivers/usb/host/xhci-ext-caps.h | 0
drivers/usb/storage/uas.c| 15 ---
2 files changed, 8 insertions(+), 7 deletions(-)
mode change 100644 = 100755 drivers/usb/host/xhci-ext-caps.h
diff --git a/drivers/usb/host/xhci-ext-caps.h b/drivers/usb/host/xhci-ext-caps.h
old mode 100644
new mode 100755
Say what? :-)
diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c
index f689219..c9a04c5 100644
--- a/drivers/usb/storage/uas.c
+++ b/drivers/usb/storage/uas.c
@@ -257,16 +257,16 @@ static void uas_stat_cmplt(struct urb *urb)
struct uas_cmd_info *cmdinfo;
unsigned long flags;
unsigned int idx;
+ int status = urb-status;
spin_lock_irqsave(devinfo-lock, flags);
if (devinfo-resetting)
goto out;
- if (urb-status) {
- if (urb-status != -ENOENT urb-status != -ECONNRESET) {
- dev_err(urb-dev-dev, stat urb: status %d\n,
- urb-status);
+ if (status) {
+ if (status != -ENOENT status != -ECONNRESET status !=
-ESHUTDOWN) {
+ dev_err(urb-dev-dev, stat urb: status %d\n,
status);
}
{} not needed here.
[...]
MBR, 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 v3] usb: dwc2: reset dwc2 core before dwc2_get_hwparams()
On 8/19/2015 5:22 AM, Yunzhi Li wrote:
We initiate dwc2 usb controller in BIOS, dwc2_core_reset() should
be called before dwc2_get_hwparams() to reset core registers to
default value. Without this the FIFO setting might be incorrect
because calculating FIFO size need power-on value of
GRXFSIZ/GNPTXFSIZ/HPTXFSIZ registers.
This patch could avoid warnning massage like in rk3288 platform:
[2.074764] dwc2 ff58.usb: 256 invalid for
host_perio_tx_fifo_size. Check HW configuration.
Signed-off-by: Yunzhi Li l...@rock-chips.com
---
drivers/usb/dwc2/core.c | 2 +-
drivers/usb/dwc2/core.h | 1 +
drivers/usb/dwc2/platform.c | 21 -
3 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index c3cc1a7..86d1d65 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -474,7 +474,7 @@ static void dwc2_init_fs_ls_pclk_sel(struct dwc2_hsotg
*hsotg)
* Do core a soft reset of the core. Be careful with this because it
* resets all the internal state machines of the core.
*/
-static int dwc2_core_reset(struct dwc2_hsotg *hsotg)
+int dwc2_core_reset(struct dwc2_hsotg *hsotg)
{
u32 greset;
int count = 0;
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 0ed87620..5d95aec 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -846,6 +846,7 @@ enum dwc2_halt_status {
* The following functions support initialization of the core driver
component
* and the DWC_otg controller
*/
+extern int dwc2_core_reset(struct dwc2_hsotg *hsotg);
extern void dwc2_core_host_init(struct dwc2_hsotg *hsotg);
extern int dwc2_enter_hibernation(struct dwc2_hsotg *hsotg);
extern int dwc2_exit_hibernation(struct dwc2_hsotg *hsotg, bool restore);
diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
index 9093530..55d378a 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -166,7 +166,8 @@ static int dwc2_driver_probe(struct platform_device *dev)
struct phy *phy;
struct usb_phy *uphy;
int retval;
- int irq;
+ int irq, count = 0;
+ u32 greset;
match = of_match_device(dwc2_of_match_table, dev-dev);
if (match match-data) {
@@ -243,6 +244,24 @@ static int dwc2_driver_probe(struct platform_device *dev)
spin_lock_init(hsotg-lock);
mutex_init(hsotg-init_mutex);
+ /*
+ * Reset before dwc2_get_hwparams() then it could get power-on real
+ * reset value form registers.
+ */
+ count = 0;
+ greset |= GRSTCTL_CSFTRST;
+ writel(greset, hsotg-regs + GRSTCTL);
+ do {
+ usleep_range(2, 4);
+ greset = readl(hsotg-regs + GRSTCTL);
+ if (++count 50) {
+ dev_warn(hsotg-dev,
+ %s() HANG! Soft Reset GRSTCTL=%0x\n,
+ __func__, greset);
+ return -EBUSY;
+ }
+ } while (greset GRSTCTL_CSFTRST);
+
Could you move this out to a separate function so
that we don't have duplicate code?
Thanks,
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
Re: [PATCH v2 3/3] power: wm831x_power: Support USB charger current limit management
On 20 August 2015 at 17:02, David Laight david.lai...@aculab.com wrote:
From: Baolin Wang
Sent: 14 August 2015 10:48
+/* In miliamps */
Spelling police: milliamps
Hi David,
I'll correct it in next patch series. Thanks for your comments.
+static unsigned int wm831x_usb_limits[] = {
+ 0,
+ 2,
+ 100,
+ 500,
+ 900,
+ 1500,
+ 1800,
+ 550,
+};
David
--
Baolin.wang
Best Regards
--
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 v5 01/46] usb: gadget: encapsulate endpoint claiming mechanism
On Thu, Aug 20, 2015 at 10:51:46PM +0200, Robert Baldyga wrote: On 08/20/2015 10:23 PM, Alan Stern wrote: [CC: list drastically trimmed] On Thu, 20 Aug 2015, Robert Baldyga wrote: On 08/20/2015 06:48 PM, Felipe Balbi wrote: On Thu, Aug 20, 2015 at 06:28:14PM +0200, Robert Baldyga wrote: Hi Felipe, On 08/20/2015 05:35 PM, Felipe Balbi wrote: [...] just letting you know that this regresses all gadget drivers making them try to disable previously disabled endpoints and enable previously enabled endpoints. I have a possible fix (see below) but then it shows a problem on the host side when using with g_zero (see further below): commit 3b8932100aacb6cfbffe288ca93025d8b8430c00 Author: Felipe Balbi ba...@ti.com Date: Wed Aug 19 18:05:27 2015 -0500 usb: gadget: fix ep-claimed lifetime In order to fix a regression introduced by commit cc476b42a39d (usb: gadget: encapsulate endpoint claiming mechanism) we have to introduce a simple helper to check if a particular is enabled or not. After that, we need to move ep-claimed lifetime to usb_ep_enable() and usb_ep_disable() since those are the only functions which actually enable and disable endpoints. A follow-up patch will come to drop all driver_data checks from function drivers, since those are, now, pointless. Fixes: cc476b42a39d (usb: gadget: encapsulate endpoint claiming mechanism) Cc: Robert Baldyga r.bald...@samsung.com Signed-off-by: Felipe Balbi ba...@ti.com diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c index 978435a51038..ad45070cd76f 100644 --- a/drivers/usb/gadget/epautoconf.c +++ b/drivers/usb/gadget/epautoconf.c @@ -126,7 +126,6 @@ found_ep: ep-address = desc-bEndpointAddress; ep-desc = NULL; ep-comp_desc = NULL; - ep-claimed = true; Removing this line causes autoconfig can return the same endpoint many times. This probably causes problems with g_zero. I will try to fix it ASAP. I was considering the same thing, but the lifetime of -claimed doesn't look correct to me either way. Note that once the flag is enabled, it won't get disabled by most gadget drivers. And it should not be. This flag is indicator, that endpoint is used by some function. It should be set once by usb_ep_autoconfig() and cleared by usb_ep_autoconfig_reset(). I wonder what is reason of this enable/disable regression. Maybe the problem is that we don't set ep-driver_data to NULL in usb_ep_autoconfig_reset() (so far it was done). Does this problem occur while gadget is binded to UDC for the first time, or at any next time? Unfortunately at this moment I don't have access to my hardware, so it will take a moment before I will setup some testing environment. To understand this, you have to think back over the history. Originally there was no composite gadget driver; each function was its own gadget. The driver would allocate endpoints only once, when starting up. ep-claimed was used for telling whether or not ep had , already been allocated, not for whether ep was enabled or anything like that (none of the endpoints were enabled at this stage). The only thing the driver had to be careful about was clearing all the -claimed flags initially, in case some other gadget driver had been loaded earlier and left the flags set. Things are different now with the composite driver. I don't know the details of how it works, but some things are clear. One function driver must not be allowed to interfere with the endpoints allocated by another. A function driver can't allocate all the endpoints it needs for all configs in one go; instead the configs have to be handled independently and each function belonging to the config must allocate all the endpoints it needs before another config is handled. The only time usb_ep_autoconfig_reset() should be called is when the composite core is ready to start allocating endpoints for a new config. At any rate, I don't see how ep-claimed is related in any way to whether or not the endpoint is enabled. Claiming endpoints takes place when the physical endpoints are allocated for use as the functions' logical endpoints. This has to happen before the host reads the config descriptors -- before any endpoints get enabled. Thats right. My intention was to introduce flag which can be used only for marking endpoints as claimed during functions bind. It should definitely not have anything to do with endpoint enable/disable. It looks like before ep-claimed flag was added, ep-driver_data was used for both, marking endpoint as claimed during bind and marking endpoints as enabled/disabled after gadget enumeration. My patch slightly modified ep-driver_data handling during bind/unbind process,
PROBLEM: USB devices not appearing after upgrading 4.1.4 = 4.1.5
Description: After upgrading from linux kernel 4.1.4 to 4.1.5 I'm having trouble with my USB devices. First boot: my external keyboard wasn't working Second boot: my external mouse wasn't working Third boot: my internal touchpad wasn't working Additional info: The computer is a Dell M3800. Example log snippets: Aug 19 09:57:54 daurn-m3800 kernel: xhci_hcd :00:14.0: Timeout while waiting for configure endpoint command Aug 19 09:57:54 daurn-m3800 kernel: usb 3-11: Not enough bandwidth for altsetting 0 Aug 19 09:57:54 daurn-m3800 kernel: input: Integrated_Webcam_HD as /devices/pci:00/:00:14.0/usb3/3-11/3-11:1.0/input/input20 Aug 19 09:57:54 daurn-m3800 kernel: usbcore: registered new interface driver uvcvideo Aug 19 09:57:54 daurn-m3800 kernel: USB Video Class driver (1.1.1) Aug 19 09:57:54 daurn-m3800 kernel: xhci_hcd :00:14.0: xHCI host not responding to stop endpoint command. Aug 19 09:57:54 daurn-m3800 kernel: xhci_hcd :00:14.0: Assuming host is dying, halting host. Aug 19 09:57:54 daurn-m3800 kernel: xhci_hcd :00:14.0: HC died; cleaning up Aug 19 10:00:45 daurn-m3800 systemd-udevd[360]: seq 1835 '/devices/pci:00/:00:14.0/usb4/4-2/4-2.4' killed Aug 19 10:01:12 daurn-m3800 sudo[1283]: pam_unix(sudo:session): session closed for user root Aug 19 10:01:39 daurn-m3800 kernel: INFO: task kworker/0:2:61 blocked for more than 120 seconds. Aug 19 10:01:39 daurn-m3800 kernel: Tainted: P O 4.1.5-1-ARCH #1 Aug 19 10:01:39 daurn-m3800 kernel: echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. Aug 19 10:01:39 daurn-m3800 kernel: kworker/0:2 D 88046cf0ba58 0 61 2 0x Aug 19 10:01:39 daurn-m3800 kernel: Workqueue: usb_hub_wq hub_event [usbcore] Aug 19 10:01:39 daurn-m3800 kernel: 88046cf0ba58 88046d649e90 88046ced9460 88046d6494c8 Aug 19 10:01:39 daurn-m3800 kernel: 88046cf0c000 88046c634170 88046c634168 Aug 19 10:01:39 daurn-m3800 kernel: 88046ced9460 88046cf0ba78 815882d7 88046cf0ba98 Aug 19 10:01:39 daurn-m3800 kernel: Call Trace: Aug 19 10:01:39 daurn-m3800 kernel: [815882d7] schedule+0x37/0x90 Aug 19 10:01:39 daurn-m3800 kernel: [8158acfc] schedule_timeout+0x1bc/0x250 Aug 19 10:01:39 daurn-m3800 kernel: [810b61b6] ? pick_next_task_fair+0x456/0x530 Aug 19 10:01:39 daurn-m3800 kernel: [8101477c] ? __switch_to+0x2bc/0x5e0 Aug 19 10:01:39 daurn-m3800 kernel: [8109f60d] ? finish_task_switch+0x5d/0x100 Aug 19 10:01:39 daurn-m3800 kernel: [81588e2b] wait_for_common+0xcb/0x190 Aug 19 10:01:39 daurn-m3800 kernel: [810a5a60] ? wake_up_process+0x50/0x50 Aug 19 10:01:39 daurn-m3800 kernel: [81588f0d] wait_for_completion+0x1d/0x20 Aug 19 10:01:39 daurn-m3800 kernel: [a01befb2] xhci_setup_device+0x182/0x7a0 [xhci_hcd] Aug 19 10:01:39 daurn-m3800 kernel: [810e4f10] ? timer_cpu_notify+0x170/0x170 Aug 19 10:01:39 daurn-m3800 kernel: [a01bf5e3] xhci_address_device+0x13/0x20 [xhci_hcd] Aug 19 10:01:39 daurn-m3800 kernel: [a00cb2f3] hub_port_init+0x323/0xbf0 [usbcore] Aug 19 10:01:39 daurn-m3800 kernel: [81400729] ? update_autosuspend+0x39/0x60 Aug 19 10:01:39 daurn-m3800 kernel: [814007a1] ? pm_runtime_set_autosuspend_delay+0x51/0x60 Aug 19 10:01:39 daurn-m3800 kernel: [a00cf74f] hub_event+0x94f/0x1620 [usbcore] Aug 19 10:01:39 daurn-m3800 kernel: [8109195b] process_one_work+0x14b/0x470 Aug 19 10:01:39 daurn-m3800 kernel: [81091cc8] worker_thread+0x48/0x4c0 Aug 19 10:01:39 daurn-m3800 kernel: [81091c80] ? process_one_work+0x470/0x470 Aug 19 10:01:39 daurn-m3800 kernel: [81091c80] ? process_one_work+0x470/0x470 Aug 19 10:01:39 daurn-m3800 kernel: [81097818] kthread+0xd8/0xf0 Aug 19 10:01:39 daurn-m3800 kernel: [81097740] ? kthread_worker_fn+0x170/0x170 Aug 19 10:01:39 daurn-m3800 kernel: [8158c322] ret_from_fork+0x42/0x70 Aug 19 10:01:39 daurn-m3800 kernel: [81097740] ? kthread_worker_fn+0x170/0x170 Aug 19 10:01:39 daurn-m3800 kernel: INFO: task kworker/3:2:344 blocked for more than 120 seconds. Aug 19 10:01:39 daurn-m3800 kernel: Tainted: P O 4.1.5-1-ARCH #1 Aug 19 10:01:39 daurn-m3800 kernel: echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. Aug 19 10:01:39 daurn-m3800 kernel: kworker/3:2 D 88046be67b78 0 344 2 0x Aug 19 10:01:39 daurn-m3800 kernel: Workqueue: usb_hub_wq hub_event [usbcore] Aug 19 10:01:39 daurn-m3800 kernel: 88046be67b78 88046d6c0a30 88046963d180 88046be67ba8 Aug 19 10:01:39 daurn-m3800 kernel: 88046be68000 88046d1e30f4 88046963d180 Aug 19 10:01:39 daurn-m3800 kernel: 88046d1e30f8 88046be67b98 815882d7 0003 Aug 19 10:01:39 daurn-m3800 kernel: Call Trace: Aug 19 10:01:39 daurn-m3800 kernel: [815882d7] schedule+0x37/0x90 Aug 19 10:01:39 daurn-m3800 kernel: [815886a5]
Re: Some restrictions when using usbtest and g_zero
Hi, On Thu, Aug 20, 2015 at 01:08:30PM -0400, Alan Stern wrote: On Thu, 20 Aug 2015, Felipe Balbi wrote: - Test 13 will fail due to there is pending IN request (f_sourcesink will queue a request unconditionally at its completion), and udc driver will run out error if that. udc driver must do that if it wants to wait, what ? test 13 works just fine here. (I'll try again in a few minutes just to make sure) It may depend on what UDC and what test device you use. Why ? Why would SET_FEATURE(HALT) fail ? I can only see it as a bug on the UDC driver. A bug which should be fixed. Here's what the kerneldoc for usb_ep_set_halt() says: * Returns zero, or a negative error code. On success, this call sets * underlying hardware state that blocks data transfers. * Attempts to halt IN endpoints will fail (returning -EAGAIN) if any * transfer requests are still queued, or if the controller hardware * (usually a FIFO) still holds bytes that the host hasn't collected. That's talking about IN endpoints only, not OUT -- but Peter's original email mentioned that Test 13 fails if there's a pending IN usb_request. oh right, IN endpoints are special in that sense :-) But that's only true for some cases. When host side sends SetFeature(HALT), that should always succeed, right ? See commit 7a60855972f0d for example. usbtest's halt set/clear test is pretty simple: 1. move data on EP to verify it's not halted 2. set halt 3. move data on EP to verify STALL is returned 4. clear halt 5. move data on EP to verify it's not halted I did fix that months ago on DWC3 because there was a bug on DWC3. MUSB was fixed years back too for a similar bug. According to the kerneldoc above, step 2 will fail if the gadget driver automatically submits a new IN request after step 1 completes. Since gadget zero (either loopback or source-sink mode) does resubmit IN requests, you can understand Peter's problem. Doesn't Peter need to cope with differentiating protocol vs non-protocol stalls ? pass USB CV2.0 MSC TEST. (othwerwise, Command Set Test - Device Configured will fail) Why would a pending struct usb_request in your queue fail USB CV ? _Lack_ of a pending request can cause the USB CV to fail. In Peter's example, if you're testing a Mass-Storage gadget, USB CV requires that there be a pending Bulk-OUT request when the gadget is idle (so that the next SCSI command can be sent out). But if there's a pending usb_request on a bulk-OUT endpoint, will a UDC driver be able to carry out a Set-Halt-Feature request from the host? The answer isn't clear. And it's even worse for bulk-IN. how can USB CV even test that there is a pending request on the UDC's side ? Short of actually moving data on that pipe, there's not way. That's exactly what the USB CV does -- it tries to send data. If it can't, the test fails. (At least, that's what I remember; it was a while ago that I looked at this.) However, in this respect Peter was a little inconsistent. The USB CV MSC test requires a pending bulk-OUT request, but the Set-Halt problem affects bulk-IN endpoints. right Also, when the Halt request comes, UDC must take care of doing whatever necessary to make halt work. If that means cancelling transfers on a particular EP, so be it. Give them back with -ESHUTDOWN or -EPIPE or whatever. Just look at usb_ep_set_halt()'s documentation which states that drivers may need to empty the endpoint's request queue first. Exactly. As far as I know, UDCs _don't_ bother to cancel transfers on an endpoint when the host sends Set-Halt. If you want to say that this is a bug in the UDC drivers, I won't argue. see commit above. On top of that, we have the stall=0 flag for cases where the UDC really can't handle that halt request correctly. True. As far as I know, f_mass_storage is the only code which uses that flag (because no protocols other than Mass Storage require stalls on endpoints other than ep0). - When using pattern = 1 as module parameters to compare the data, the packet size must be same between host and device's. why ? The gadget stores the pattern data starting from 0 for each packet it sends. But the host tests the pattern data starting from 0 only at the beginning of the transfer; the host expects the pattern to continue without resetting at packet boundaries (if the transfer length is larger than the maxpacket size). then that's another bug which needs to be fixed :-) That at least should be relatively simple. A few changes to simple_fill_buf(), simple_check_buf(), and alloc_sglist() should do it. (One extra complication is that these routines will need to know the maxpacket size, but currently they don't.) maxpacket size should be simple to fetch, however. I suppose the right thing is for the UDC
Re: [PATCH v5 01/46] usb: gadget: encapsulate endpoint claiming mechanism
Hi, On Thu, Aug 20, 2015 at 07:16:48PM +0200, Robert Baldyga wrote: On 08/20/2015 06:48 PM, Felipe Balbi wrote: On Thu, Aug 20, 2015 at 06:28:14PM +0200, Robert Baldyga wrote: Hi Felipe, On 08/20/2015 05:35 PM, Felipe Balbi wrote: [...] just letting you know that this regresses all gadget drivers making them try to disable previously disabled endpoints and enable previously enabled endpoints. I have a possible fix (see below) but then it shows a problem on the host side when using with g_zero (see further below): commit 3b8932100aacb6cfbffe288ca93025d8b8430c00 Author: Felipe Balbi ba...@ti.com Date: Wed Aug 19 18:05:27 2015 -0500 usb: gadget: fix ep-claimed lifetime In order to fix a regression introduced by commit cc476b42a39d (usb: gadget: encapsulate endpoint claiming mechanism) we have to introduce a simple helper to check if a particular is enabled or not. After that, we need to move ep-claimed lifetime to usb_ep_enable() and usb_ep_disable() since those are the only functions which actually enable and disable endpoints. A follow-up patch will come to drop all driver_data checks from function drivers, since those are, now, pointless. Fixes: cc476b42a39d (usb: gadget: encapsulate endpoint claiming mechanism) Cc: Robert Baldyga r.bald...@samsung.com Signed-off-by: Felipe Balbi ba...@ti.com diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c index 978435a51038..ad45070cd76f 100644 --- a/drivers/usb/gadget/epautoconf.c +++ b/drivers/usb/gadget/epautoconf.c @@ -126,7 +126,6 @@ found_ep: ep-address = desc-bEndpointAddress; ep-desc = NULL; ep-comp_desc = NULL; - ep-claimed = true; Removing this line causes autoconfig can return the same endpoint many times. This probably causes problems with g_zero. I will try to fix it ASAP. I was considering the same thing, but the lifetime of -claimed doesn't look correct to me either way. Note that once the flag is enabled, it won't get disabled by most gadget drivers. And it should not be. This flag is indicator, that endpoint is used by some function. It should be set once by usb_ep_autoconfig() and cleared by usb_ep_autoconfig_reset(). have you considered switching interfaces and/or alternate settings ? I wonder what is reason of this enable/disable regression. Maybe the problem is that we don't set ep-driver_data to NULL in usb_ep_autoconfig_reset() (so far it was done). Does this problem occur while gadget is binded to UDC for the first time, or at any next time? Unfortunately at this moment I don't have access to my hardware, so it will take a moment before I will setup some testing environment. yeah, that's okay. We've got time. -- balbi signature.asc Description: Digital signature
Re: MUSB sysfs node naming convention
On Thu, Aug 20, 2015 at 12:21:29PM -0500, Bin Liu wrote: Hi, Currently, the sysfs MUSB node name uses kernel device name global *auto* convention. So depending on kernel configuration, the two MUSB device nodes could be musb-hdrc.0.auto/musb-hdrc.1.auto, or musb-hdrc.1.auto/musb-hdrc.2.auto. Of cause the index could be any other number if there were more devices using this naming convention. Why we decided to name MUSB nodes this way? It gives me a lot of troubles in scripting and documentation. it's just the device name, that's all. We could name it with a string representing the register address. Something like 'musb-47401c00' -- balbi signature.asc Description: Digital signature
[PATCH v3] usb: dwc2: add support for big-endian Lantiq SoCs
Here is a patch which makes it possible to support mips based big-endian SoCs made by Lantiq in the dwc2 driver. The patch converts the readl/writel io-accessors of dwc2 to big-endian friendly versions and was discussed on the linux-usb ml already earlier [1]. The patch has been included in OpenWrt for some time now and it would be nice to get some more exposure to it. It was also agreed that this patch would be redone once certain other patches have been applied to dwc2 [2]. As dust has probably settled enough here is the patch again, rebased to the latest usb-next tree. I've also dropped the dwc2 core parameters patch for Lantiq from this series for now as finding the right parameters is still a bit of a work in progress. [1] http://www.spinics.net/lists/linux-usb/msg122814.html [2] http://www.spinics.net/lists/linux-usb/msg122897.html Antti Seppälä (1): usb: dwc2: Use platform endianness when accessing registers drivers/usb/dwc2/core.c | 469 ++- drivers/usb/dwc2/core.h | 28 ++- drivers/usb/dwc2/core_intr.c | 73 +++ drivers/usb/dwc2/debugfs.c | 52 ++--- drivers/usb/dwc2/gadget.c| 314 ++--- drivers/usb/dwc2/hcd.c | 140 ++--- drivers/usb/dwc2/hcd.h | 15 +- drivers/usb/dwc2/hcd_ddma.c | 10 +- drivers/usb/dwc2/hcd_intr.c | 82 drivers/usb/dwc2/hcd_queue.c | 10 +- 10 files changed, 606 insertions(+), 587 deletions(-) -- 2.4.6 -- 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 v3] usb: dwc2: Use platform endianness when accessing registers
This patch switches calls to readl/writel to their
dwc2_readl/dwc2_writel equivalents which preserve platform endianness.
This patch is necessary to access dwc2 registers correctly on big-endian
systems such as the mips based SoCs made by Lantiq. Then dwc2 can be
used to replace ifx-hcd driver for Lantiq platforms found e.g. in
OpenWrt.
The patch was autogenerated with the following commands:
$EDITOR core.h
sed -i s/\readl\/dwc2_readl/g *.c hcd.h hw.h
sed -i s/\writel\/dwc2_writel/g *.c hcd.h hw.h
Some files were then hand-edited to fix checkpatch.pl warnings about
too long lines.
Signed-off-by: Antti Seppälä a.sepp...@gmail.com
Signed-off-by: Vincent Pelletier plr.vinc...@gmail.com
---
Notes:
Changes in v2:
- Fixed wrong comment style
Changes in v3
- Rebased against latest linux-next
- Tweaked indentation in some files
drivers/usb/dwc2/core.c | 469 ++-
drivers/usb/dwc2/core.h | 28 ++-
drivers/usb/dwc2/core_intr.c | 73 +++
drivers/usb/dwc2/debugfs.c | 52 ++---
drivers/usb/dwc2/gadget.c| 314 ++---
drivers/usb/dwc2/hcd.c | 140 ++---
drivers/usb/dwc2/hcd.h | 15 +-
drivers/usb/dwc2/hcd_ddma.c | 10 +-
drivers/usb/dwc2/hcd_intr.c | 82
drivers/usb/dwc2/hcd_queue.c | 10 +-
10 files changed, 606 insertions(+), 587 deletions(-)
diff --git a/drivers/usb/dwc2/core.c b/drivers/usb/dwc2/core.c
index c3cc1a7..a9de441 100644
--- a/drivers/usb/dwc2/core.c
+++ b/drivers/usb/dwc2/core.c
@@ -73,13 +73,13 @@ static int dwc2_backup_host_registers(struct dwc2_hsotg
*hsotg)
/* Backup Host regs */
hr = hsotg-hr_backup;
- hr-hcfg = readl(hsotg-regs + HCFG);
- hr-haintmsk = readl(hsotg-regs + HAINTMSK);
+ hr-hcfg = dwc2_readl(hsotg-regs + HCFG);
+ hr-haintmsk = dwc2_readl(hsotg-regs + HAINTMSK);
for (i = 0; i hsotg-core_params-host_channels; ++i)
- hr-hcintmsk[i] = readl(hsotg-regs + HCINTMSK(i));
+ hr-hcintmsk[i] = dwc2_readl(hsotg-regs + HCINTMSK(i));
- hr-hprt0 = readl(hsotg-regs + HPRT0);
- hr-hfir = readl(hsotg-regs + HFIR);
+ hr-hprt0 = dwc2_readl(hsotg-regs + HPRT0);
+ hr-hfir = dwc2_readl(hsotg-regs + HFIR);
hr-valid = true;
return 0;
@@ -108,14 +108,14 @@ static int dwc2_restore_host_registers(struct dwc2_hsotg
*hsotg)
}
hr-valid = false;
- writel(hr-hcfg, hsotg-regs + HCFG);
- writel(hr-haintmsk, hsotg-regs + HAINTMSK);
+ dwc2_writel(hr-hcfg, hsotg-regs + HCFG);
+ dwc2_writel(hr-haintmsk, hsotg-regs + HAINTMSK);
for (i = 0; i hsotg-core_params-host_channels; ++i)
- writel(hr-hcintmsk[i], hsotg-regs + HCINTMSK(i));
+ dwc2_writel(hr-hcintmsk[i], hsotg-regs + HCINTMSK(i));
- writel(hr-hprt0, hsotg-regs + HPRT0);
- writel(hr-hfir, hsotg-regs + HFIR);
+ dwc2_writel(hr-hprt0, hsotg-regs + HPRT0);
+ dwc2_writel(hr-hfir, hsotg-regs + HFIR);
return 0;
}
@@ -146,15 +146,15 @@ static int dwc2_backup_device_registers(struct dwc2_hsotg
*hsotg)
/* Backup dev regs */
dr = hsotg-dr_backup;
- dr-dcfg = readl(hsotg-regs + DCFG);
- dr-dctl = readl(hsotg-regs + DCTL);
- dr-daintmsk = readl(hsotg-regs + DAINTMSK);
- dr-diepmsk = readl(hsotg-regs + DIEPMSK);
- dr-doepmsk = readl(hsotg-regs + DOEPMSK);
+ dr-dcfg = dwc2_readl(hsotg-regs + DCFG);
+ dr-dctl = dwc2_readl(hsotg-regs + DCTL);
+ dr-daintmsk = dwc2_readl(hsotg-regs + DAINTMSK);
+ dr-diepmsk = dwc2_readl(hsotg-regs + DIEPMSK);
+ dr-doepmsk = dwc2_readl(hsotg-regs + DOEPMSK);
for (i = 0; i hsotg-num_of_eps; i++) {
/* Backup IN EPs */
- dr-diepctl[i] = readl(hsotg-regs + DIEPCTL(i));
+ dr-diepctl[i] = dwc2_readl(hsotg-regs + DIEPCTL(i));
/* Ensure DATA PID is correctly configured */
if (dr-diepctl[i] DXEPCTL_DPID)
@@ -162,11 +162,11 @@ static int dwc2_backup_device_registers(struct dwc2_hsotg
*hsotg)
else
dr-diepctl[i] |= DXEPCTL_SETD0PID;
- dr-dieptsiz[i] = readl(hsotg-regs + DIEPTSIZ(i));
- dr-diepdma[i] = readl(hsotg-regs + DIEPDMA(i));
+ dr-dieptsiz[i] = dwc2_readl(hsotg-regs + DIEPTSIZ(i));
+ dr-diepdma[i] = dwc2_readl(hsotg-regs + DIEPDMA(i));
/* Backup OUT EPs */
- dr-doepctl[i] = readl(hsotg-regs + DOEPCTL(i));
+ dr-doepctl[i] = dwc2_readl(hsotg-regs + DOEPCTL(i));
/* Ensure DATA PID is correctly configured */
if (dr-doepctl[i] DXEPCTL_DPID)
@@ -174,8 +174,8 @@ static int dwc2_backup_device_registers(struct dwc2_hsotg
*hsotg)
else
dr-doepctl[i] |= DXEPCTL_SETD0PID;
-
Re: MUSB sysfs node naming convention
On Thu, Aug 20, 2015 at 1:23 PM, Felipe Balbi ba...@ti.com wrote: On Thu, Aug 20, 2015 at 12:21:29PM -0500, Bin Liu wrote: Hi, Currently, the sysfs MUSB node name uses kernel device name global *auto* convention. So depending on kernel configuration, the two MUSB device nodes could be musb-hdrc.0.auto/musb-hdrc.1.auto, or musb-hdrc.1.auto/musb-hdrc.2.auto. Of cause the index could be any other number if there were more devices using this naming convention. Why we decided to name MUSB nodes this way? It gives me a lot of troubles in scripting and documentation. it's just the device name, that's all. We could name it with a string representing the register address. Something like 'musb-47401c00' Yeah, I know it is just a name, that is why I want to know if possible to change the default to not use the global name, to something static, so that it is easier for scripting and documentation? Thanks, -Bin. -- balbi -- 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: Some restrictions when using usbtest and g_zero
Hi, On Thu, Aug 20, 2015 at 04:25:08PM +0800, Peter Chen wrote: Hi all, I have played usbtest and g_zero (f_sourcesink f_loopback) to do the tests between two boards these days, and have found some restrictions, I list them here, and to see if they are common problems and can be improved or not. first of all: why don't you just use the hcd-tests.sh shipped with the kernel ? Just start it with: ./hcd-tests.sh control in out halt - Test 13 will fail due to there is pending IN request (f_sourcesink will queue a request unconditionally at its completion), and udc driver will run out error if that. udc driver must do that if it wants to wait, what ? test 13 works just fine here. (I'll try again in a few minutes just to make sure) pass USB CV2.0 MSC TEST. (othwerwise, Command Set Test - Device Configured will fail) Why would a pending struct usb_request in your queue fail USB CV ? - The parameter 'vary' must be the same with 'length' when do bulk/iso READ test, the host's packet size can't be smaller than device's. And 'vary' must be smaller than 'length' when do ctrl test. yeah, I don't think vary works well for iso as of now. If you can fix that, we can merge the patch. - When using pattern = 1 as module parameters to compare the data, the packet size must be same between host and device's. why ? -- balbi signature.asc Description: Digital signature
Re: Some restrictions when using usbtest and g_zero
On Thu, 20 Aug 2015, Peter Chen wrote: Hi all, I have played usbtest and g_zero (f_sourcesink f_loopback) to do the tests between two boards these days, and have found some restrictions, I list them here, and to see if they are common problems and can be improved or not. - Test 13 will fail due to there is pending IN request (f_sourcesink will queue a request unconditionally at its completion), and udc driver will run out error if that. udc driver must do that if it wants to pass USB CV2.0 MSC TEST. (othwerwise, Command Set Test - Device Configured will fail) The USB spec isn't very clear about this. All it says about the Set-Halt request is: When set by the SetFeature() request, the endpoint exhibits the same stall behavior as if the field had been set by a hardware condition. But if there's a pending request, many UDC drivers are unable to set the HALT feature -- even due to a hardware condition. I suppose the right thing is for the UDC to temporarily disable the endpoint, set the HALT feature, and then re-enable the endpoint (along with the pending request). But changing a bunch of UDC drivers for such a minor thing doesn't seem worthwhile. - The parameter 'vary' must be the same with 'length' when do bulk/iso READ test, the host's packet size can't be smaller than device's. You're talking about Test 4, right? Yes, the host's packet size better not be smaller than the device's. But the transfer size could be larger. For example, 'vary' could be equal to the maxpacket size and 'length' could 3*(maxpacket size). And 'vary' must be smaller than 'length' when do ctrl test. 'vary' should always be 'length', even for bulk/iso tests. - When using pattern = 1 as module parameters to compare the data, the packet size must be same between host and device's. Yes, there's a comment about that in the simple_check_buf() routine: /* mod63 stays in sync with short-terminated transfers, * or otherwise when host and gadget agree on how large * each usb transfer request should be. ... So, I do the test, I need to write customize commands for kinds of tests It's quite true that blindly running the test program doesn't always work. You have to be careful about setting the parameters correctly for some of the tests. 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 3/8][v3]usb:fsl:otg: Add support to add/remove usb host driver
On Thu, 20 Aug 2015, Ramneek Mehresh wrote:
--- a/drivers/usb/host/ehci-fsl.h
+++ b/drivers/usb/host/ehci-fsl.h
@@ -63,4 +63,22 @@
#define UTMI_PHY_EN (19)
#define ULPI_PHY_CLK_SEL(110)
#define PHY_CLK_VALID(117)
+
+struct ehci_fsl {
+#ifdef CONFIG_PM
+ /* Saved USB PHY settings, need to restore after deep sleep. */
+ u32 usb_ctrl;
+#endif
Do you need this #ifdef?
Yes, this is required for deep-sleep support...we need to save/restore
controller
registers during deep-sleep when usb controller power is shut-off. Don't need
this
during normal usb operation...saving/restoring usb controller registers in
non deep-sleep
scenario will add unnecessary delays
What I meant was, can you keep the u32 usb_ctrl; line but get rid of
the #ifdef CONFIG_PM and #endif lines?
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: Some restrictions when using usbtest and g_zero
On Thu, 20 Aug 2015, Felipe Balbi wrote: Hi, On Thu, Aug 20, 2015 at 04:25:08PM +0800, Peter Chen wrote: Hi all, I have played usbtest and g_zero (f_sourcesink f_loopback) to do the tests between two boards these days, and have found some restrictions, I list them here, and to see if they are common problems and can be improved or not. first of all: why don't you just use the hcd-tests.sh shipped with the kernel ? Just start it with: ./hcd-tests.sh control in out halt - Test 13 will fail due to there is pending IN request (f_sourcesink will queue a request unconditionally at its completion), and udc driver will run out error if that. udc driver must do that if it wants to wait, what ? test 13 works just fine here. (I'll try again in a few minutes just to make sure) It may depend on what UDC and what test device you use. pass USB CV2.0 MSC TEST. (othwerwise, Command Set Test - Device Configured will fail) Why would a pending struct usb_request in your queue fail USB CV ? _Lack_ of a pending request can cause the USB CV to fail. In Peter's example, if you're testing a Mass-Storage gadget, USB CV requires that there be a pending Bulk-OUT request when the gadget is idle (so that the next SCSI command can be sent out). But if there's a pending usb_request on a bulk-OUT endpoint, will a UDC driver be able to carry out a Set-Halt-Feature request from the host? The answer isn't clear. And it's even worse for bulk-IN. - When using pattern = 1 as module parameters to compare the data, the packet size must be same between host and device's. why ? The gadget stores the pattern data starting from 0 for each packet it sends. But the host tests the pattern data starting from 0 only at the beginning of the transfer; the host expects the pattern to continue without resetting at packet boundaries (if the transfer length is larger than the maxpacket size). 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 v5 1/2] usb: make xhci platform driver use 64 bit or 32 bit DMA
On Wednesday 19 August 2015 14:28:33 Duc Dang wrote:
Hi Arnd,
So the check will look like this, please let me know what do you think:
if (!pdev-dev.dma_mask) {
WARN_ON(1);
/* Initialize dma_mask if the broken platform code has
not done so */
pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
}
The condition can be written as
if (WARN_ON(!pdev-dev.dma_mask))
and I'd use dma_coerce_mask_and_coherent() instead of manually setting the
pointer, as an annotation for the fact that we are knowingly violating the
API here.
Those two points are just cosmetic though, aside from them, your code
above is what I had in mind.
Thanks,
Arnd
--
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 v5 01/46] usb: gadget: encapsulate endpoint claiming mechanism
On 08/20/2015 10:23 PM, Alan Stern wrote: [CC: list drastically trimmed] On Thu, 20 Aug 2015, Robert Baldyga wrote: On 08/20/2015 06:48 PM, Felipe Balbi wrote: On Thu, Aug 20, 2015 at 06:28:14PM +0200, Robert Baldyga wrote: Hi Felipe, On 08/20/2015 05:35 PM, Felipe Balbi wrote: [...] just letting you know that this regresses all gadget drivers making them try to disable previously disabled endpoints and enable previously enabled endpoints. I have a possible fix (see below) but then it shows a problem on the host side when using with g_zero (see further below): commit 3b8932100aacb6cfbffe288ca93025d8b8430c00 Author: Felipe Balbi ba...@ti.com Date: Wed Aug 19 18:05:27 2015 -0500 usb: gadget: fix ep-claimed lifetime In order to fix a regression introduced by commit cc476b42a39d (usb: gadget: encapsulate endpoint claiming mechanism) we have to introduce a simple helper to check if a particular is enabled or not. After that, we need to move ep-claimed lifetime to usb_ep_enable() and usb_ep_disable() since those are the only functions which actually enable and disable endpoints. A follow-up patch will come to drop all driver_data checks from function drivers, since those are, now, pointless. Fixes: cc476b42a39d (usb: gadget: encapsulate endpoint claiming mechanism) Cc: Robert Baldyga r.bald...@samsung.com Signed-off-by: Felipe Balbi ba...@ti.com diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c index 978435a51038..ad45070cd76f 100644 --- a/drivers/usb/gadget/epautoconf.c +++ b/drivers/usb/gadget/epautoconf.c @@ -126,7 +126,6 @@ found_ep: ep-address = desc-bEndpointAddress; ep-desc = NULL; ep-comp_desc = NULL; - ep-claimed = true; Removing this line causes autoconfig can return the same endpoint many times. This probably causes problems with g_zero. I will try to fix it ASAP. I was considering the same thing, but the lifetime of -claimed doesn't look correct to me either way. Note that once the flag is enabled, it won't get disabled by most gadget drivers. And it should not be. This flag is indicator, that endpoint is used by some function. It should be set once by usb_ep_autoconfig() and cleared by usb_ep_autoconfig_reset(). I wonder what is reason of this enable/disable regression. Maybe the problem is that we don't set ep-driver_data to NULL in usb_ep_autoconfig_reset() (so far it was done). Does this problem occur while gadget is binded to UDC for the first time, or at any next time? Unfortunately at this moment I don't have access to my hardware, so it will take a moment before I will setup some testing environment. To understand this, you have to think back over the history. Originally there was no composite gadget driver; each function was its own gadget. The driver would allocate endpoints only once, when starting up. ep-claimed was used for telling whether or not ep had already been allocated, not for whether ep was enabled or anything like that (none of the endpoints were enabled at this stage). The only thing the driver had to be careful about was clearing all the -claimed flags initially, in case some other gadget driver had been loaded earlier and left the flags set. Things are different now with the composite driver. I don't know the details of how it works, but some things are clear. One function driver must not be allowed to interfere with the endpoints allocated by another. A function driver can't allocate all the endpoints it needs for all configs in one go; instead the configs have to be handled independently and each function belonging to the config must allocate all the endpoints it needs before another config is handled. The only time usb_ep_autoconfig_reset() should be called is when the composite core is ready to start allocating endpoints for a new config. At any rate, I don't see how ep-claimed is related in any way to whether or not the endpoint is enabled. Claiming endpoints takes place when the physical endpoints are allocated for use as the functions' logical endpoints. This has to happen before the host reads the config descriptors -- before any endpoints get enabled. Thats right. My intention was to introduce flag which can be used only for marking endpoints as claimed during functions bind. It should definitely not have anything to do with endpoint enable/disable. It looks like before ep-claimed flag was added, ep-driver_data was used for both, marking endpoint as claimed during bind and marking endpoints as enabled/disabled after gadget enumeration. My patch slightly modified ep-driver_data handling during bind/unbind process, and that is probably cause of problems with enable/disable. However using ep-driver_data field to marking endpoint as enabled/disabled is not the most fortunate solution.
Re: Some restrictions when using usbtest and g_zero
On Thu, 20 Aug 2015, Felipe Balbi wrote: Doesn't Peter need to cope with differentiating protocol vs non-protocol stalls ? Those matter only for ep0, not for bulk/interrupt. huh ? usbtest send SetFeature(HALT) for the bulk endpoint, right ? That's what Peter's UDC driver is missing. It's this special case of halting the endpoint when the host asks it to regardless of having queued struct usb_requests or not. Yes, that's what I said. Peter's UDC driver doesn't handle halts for bulk endpoints properly. But the difference between protocol and functional (or non-protocol) stalls matters only for ep0, not for bulk/interrupt, so it's not relevant to Peter's problem. 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: Some restrictions when using usbtest and g_zero
On Thu, 20 Aug 2015, Felipe Balbi wrote:
- When using pattern = 1 as module parameters to compare the data, the
packet size must be same between host and device's.
why ?
The gadget stores the pattern data starting from 0 for each packet it
sends. But the host tests the pattern data starting from 0 only at the
beginning of the transfer; the host expects the pattern to continue
without resetting at packet boundaries (if the transfer length is
larger than the maxpacket size).
then that's another bug which needs to be fixed :-)
Here's my attempt at a fix. Completely untested, but it does compile
without errors. Peter, do you mind trying this out?
Alan Stern
Index: usb-4.2/drivers/usb/misc/usbtest.c
===
--- usb-4.2.orig/drivers/usb/misc/usbtest.c
+++ usb-4.2/drivers/usb/misc/usbtest.c
@@ -303,11 +303,20 @@ static unsigned mod_pattern;
module_param_named(pattern, mod_pattern, uint, S_IRUGO | S_IWUSR);
MODULE_PARM_DESC(mod_pattern, i/o pattern (0 == zeroes));
-static inline void simple_fill_buf(struct urb *urb)
+static unsigned get_maxpacket(struct usb_device *udev, int pipe)
+{
+ struct usb_host_endpoint*ep;
+
+ ep = usb_pipe_endpoint(udev, pipe);
+ return le16_to_cpup(ep-desc.wMaxPacketSize);
+}
+
+static void simple_fill_buf(struct urb *urb)
{
unsignedi;
u8 *buf = urb-transfer_buffer;
unsignedlen = urb-transfer_buffer_length;
+ unsignedmaxpacket;
switch (pattern) {
default:
@@ -316,8 +325,9 @@ static inline void simple_fill_buf(struc
memset(buf, 0, len);
break;
case 1: /* mod63 */
+ maxpacket = get_maxpacket(urb-dev, urb-pipe);
for (i = 0; i len; i++)
- *buf++ = (u8) (i % 63);
+ *buf++ = (u8) ((i % maxpacket) % 63);
break;
}
}
@@ -349,6 +359,7 @@ static int simple_check_buf(struct usbte
u8 expected;
u8 *buf = urb-transfer_buffer;
unsignedlen = urb-actual_length;
+ unsignedmaxpacket = get_maxpacket(urb-dev, urb-pipe);
int ret = check_guard_bytes(tdev, urb);
if (ret)
@@ -366,7 +377,7 @@ static int simple_check_buf(struct usbte
* with set_interface or set_config.
*/
case 1: /* mod63 */
- expected = i % 63;
+ expected = (i % maxpacket) % 63;
break;
/* always fail unsupported patterns */
default:
@@ -478,11 +489,12 @@ static void free_sglist(struct scatterli
}
static struct scatterlist *
-alloc_sglist(int nents, int max, int vary)
+alloc_sglist(int nents, int max, int vary, struct usbtest_dev *dev, int pipe)
{
struct scatterlist *sg;
unsignedi;
unsignedsize = max;
+ unsignedmaxpacket =
get_maxpacket(interface_to_usbdev(dev-intf), pipe);
if (max == 0)
return NULL;
@@ -511,7 +523,7 @@ alloc_sglist(int nents, int max, int var
break;
case 1:
for (j = 0; j size; j++)
- *buf++ = (u8) (j % 63);
+ *buf++ = (u8) ((j % maxpacket) % 63);
break;
}
@@ -2175,7 +2187,7 @@ usbtest_ioctl(struct usb_interface *intf
TEST 5: write %d sglists %d entries of %d bytes\n,
param-iterations,
param-sglen, param-length);
- sg = alloc_sglist(param-sglen, param-length, 0);
+ sg = alloc_sglist(param-sglen, param-length, 0, dev,
dev-out_pipe);
if (!sg) {
retval = -ENOMEM;
break;
@@ -2193,7 +2205,7 @@ usbtest_ioctl(struct usb_interface *intf
TEST 6: read %d sglists %d entries of %d bytes\n,
param-iterations,
param-sglen, param-length);
- sg = alloc_sglist(param-sglen, param-length, 0);
+ sg = alloc_sglist(param-sglen, param-length, 0, dev,
dev-in_pipe);
if (!sg) {
retval = -ENOMEM;
break;
@@ -2210,7 +,7 @@ usbtest_ioctl(struct usb_interface *intf
TEST 7: write/%d %d sglists %d entries 0..%d bytes\n,
param-vary, param-iterations,
param-sglen, param-length);
- sg = alloc_sglist(param-sglen, param-length, param-vary);
+ sg = alloc_sglist(param-sglen, param-length, param-vary,
Re: MUSB sysfs node naming convention
On Thu, Aug 20, 2015 at 01:28:30PM -0500, Bin Liu wrote: On Thu, Aug 20, 2015 at 1:23 PM, Felipe Balbi ba...@ti.com wrote: On Thu, Aug 20, 2015 at 12:21:29PM -0500, Bin Liu wrote: Hi, Currently, the sysfs MUSB node name uses kernel device name global *auto* convention. So depending on kernel configuration, the two MUSB device nodes could be musb-hdrc.0.auto/musb-hdrc.1.auto, or musb-hdrc.1.auto/musb-hdrc.2.auto. Of cause the index could be any other number if there were more devices using this naming convention. Why we decided to name MUSB nodes this way? It gives me a lot of troubles in scripting and documentation. it's just the device name, that's all. We could name it with a string representing the register address. Something like 'musb-47401c00' Yeah, I know it is just a name, that is why I want to know if possible to change the default to not use the global name, to something static, so that it is easier for scripting and documentation? sure, why not ? I don't think anybody is really relying on those. Send a patch and let's see if anybody complains. -- balbi signature.asc Description: Digital signature
[PATCH v7 2/2] usb: Add support for ACPI identification to xhci-platform
Provide the methods to let ACPI identify the need to use
xhci-platform. Change the Kconfig files so the
xhci-plat.o file is selectable during kernel config.
This has been tested on an ARM64 machine with platform XHCI, an
x86_64 machine with XHCI, and an x86_64 machine without XHCI.
There were no regressions or error messages on the machines
without platform XHCI.
[dhdang: regenerate the patch over 4.2-rc5 and address new comments]
Signed-off-by: Mark Langsdorf mlang...@redhat.com
Signed-off-by: Duc Dang dhd...@apm.com
---
Changes from v6:
-None
Change from v5:
-Change comment to XHCI-compliant USB Controller as
PNP0D10 ID is not X-Gene specific
Changes from v4:
-Remove #ifdef CONFIG_ACPI
Changes from v3:
-Regenerate the patch over 4.2-rc5
-No code change
Changes from v2
-Replaced tristate with a boolean as the driver doesn't
compile as a module
-Correct --help-- to ---help---
Changes from v1
-Renamed from add support for APM X-Gene to xhci-platform
-Removed changes to arm64/Kconfig
-Made CONFIG_USB_XHCI_PLATFORM a user selectable config option
drivers/usb/host/Kconfig | 7 ++-
drivers/usb/host/xhci-plat.c | 9 +
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index 8afc3c1..96231ee 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -32,7 +32,12 @@ config USB_XHCI_PCI
default y
config USB_XHCI_PLATFORM
- tristate
+ tristate xHCI platform driver support
+ ---help---
+ Say 'Y' to enable the support for the xHCI host controller
+ as a platform device. Many ARM SoCs provide USB this way.
+
+ If unsure, say 'Y'.
config USB_XHCI_MVEBU
tristate xHCI support for Marvell Armada 375/38x
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index e4c7f9d..6c03e1c 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -19,6 +19,7 @@
#include linux/usb/phy.h
#include linux/slab.h
#include linux/usb/xhci_pdriver.h
+#include linux/acpi.h
#include xhci.h
#include xhci-mvebu.h
@@ -267,6 +268,13 @@ static const struct of_device_id usb_xhci_of_match[] = {
MODULE_DEVICE_TABLE(of, usb_xhci_of_match);
#endif
+static const struct acpi_device_id usb_xhci_acpi_match[] = {
+ /* XHCI-compliant USB Controller */
+ { PNP0D10, },
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, usb_xhci_acpi_match);
+
static struct platform_driver usb_xhci_driver = {
.probe = xhci_plat_probe,
.remove = xhci_plat_remove,
@@ -274,6 +282,7 @@ static struct platform_driver usb_xhci_driver = {
.name = xhci-hcd,
.pm = DEV_PM_OPS,
.of_match_table = of_match_ptr(usb_xhci_of_match),
+ .acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),
},
};
MODULE_ALIAS(platform:xhci-hcd);
--
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 v5 01/46] usb: gadget: encapsulate endpoint claiming mechanism
[CC: list drastically trimmed] On Thu, 20 Aug 2015, Robert Baldyga wrote: On 08/20/2015 06:48 PM, Felipe Balbi wrote: On Thu, Aug 20, 2015 at 06:28:14PM +0200, Robert Baldyga wrote: Hi Felipe, On 08/20/2015 05:35 PM, Felipe Balbi wrote: [...] just letting you know that this regresses all gadget drivers making them try to disable previously disabled endpoints and enable previously enabled endpoints. I have a possible fix (see below) but then it shows a problem on the host side when using with g_zero (see further below): commit 3b8932100aacb6cfbffe288ca93025d8b8430c00 Author: Felipe Balbi ba...@ti.com Date: Wed Aug 19 18:05:27 2015 -0500 usb: gadget: fix ep-claimed lifetime In order to fix a regression introduced by commit cc476b42a39d (usb: gadget: encapsulate endpoint claiming mechanism) we have to introduce a simple helper to check if a particular is enabled or not. After that, we need to move ep-claimed lifetime to usb_ep_enable() and usb_ep_disable() since those are the only functions which actually enable and disable endpoints. A follow-up patch will come to drop all driver_data checks from function drivers, since those are, now, pointless. Fixes: cc476b42a39d (usb: gadget: encapsulate endpoint claiming mechanism) Cc: Robert Baldyga r.bald...@samsung.com Signed-off-by: Felipe Balbi ba...@ti.com diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c index 978435a51038..ad45070cd76f 100644 --- a/drivers/usb/gadget/epautoconf.c +++ b/drivers/usb/gadget/epautoconf.c @@ -126,7 +126,6 @@ found_ep: ep-address = desc-bEndpointAddress; ep-desc = NULL; ep-comp_desc = NULL; - ep-claimed = true; Removing this line causes autoconfig can return the same endpoint many times. This probably causes problems with g_zero. I will try to fix it ASAP. I was considering the same thing, but the lifetime of -claimed doesn't look correct to me either way. Note that once the flag is enabled, it won't get disabled by most gadget drivers. And it should not be. This flag is indicator, that endpoint is used by some function. It should be set once by usb_ep_autoconfig() and cleared by usb_ep_autoconfig_reset(). I wonder what is reason of this enable/disable regression. Maybe the problem is that we don't set ep-driver_data to NULL in usb_ep_autoconfig_reset() (so far it was done). Does this problem occur while gadget is binded to UDC for the first time, or at any next time? Unfortunately at this moment I don't have access to my hardware, so it will take a moment before I will setup some testing environment. To understand this, you have to think back over the history. Originally there was no composite gadget driver; each function was its own gadget. The driver would allocate endpoints only once, when starting up. ep-claimed was used for telling whether or not ep had already been allocated, not for whether ep was enabled or anything like that (none of the endpoints were enabled at this stage). The only thing the driver had to be careful about was clearing all the -claimed flags initially, in case some other gadget driver had been loaded earlier and left the flags set. Things are different now with the composite driver. I don't know the details of how it works, but some things are clear. One function driver must not be allowed to interfere with the endpoints allocated by another. A function driver can't allocate all the endpoints it needs for all configs in one go; instead the configs have to be handled independently and each function belonging to the config must allocate all the endpoints it needs before another config is handled. The only time usb_ep_autoconfig_reset() should be called is when the composite core is ready to start allocating endpoints for a new config. At any rate, I don't see how ep-claimed is related in any way to whether or not the endpoint is enabled. Claiming endpoints takes place when the physical endpoints are allocated for use as the functions' logical endpoints. This has to happen before the host reads the config descriptors -- before any endpoints get enabled. 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: Some restrictions when using usbtest and g_zero
Hi, On Thu, Aug 20, 2015 at 10:48:15AM -0400, Alan Stern wrote: On Thu, 20 Aug 2015, Felipe Balbi wrote: Hi, On Thu, Aug 20, 2015 at 04:25:08PM +0800, Peter Chen wrote: Hi all, I have played usbtest and g_zero (f_sourcesink f_loopback) to do the tests between two boards these days, and have found some restrictions, I list them here, and to see if they are common problems and can be improved or not. first of all: why don't you just use the hcd-tests.sh shipped with the kernel ? Just start it with: ./hcd-tests.sh control in out halt - Test 13 will fail due to there is pending IN request (f_sourcesink will queue a request unconditionally at its completion), and udc driver will run out error if that. udc driver must do that if it wants to wait, what ? test 13 works just fine here. (I'll try again in a few minutes just to make sure) It may depend on what UDC and what test device you use. Why ? Why would SET_FEATURE(HALT) fail ? I can only see it as a bug on the UDC driver. A bug which should be fixed. usbtest's halt set/clear test is pretty simple: 1. move data on EP to verify it's not halted 2. set halt 3. move data on EP to verify STALL is returned 4. clear halt 5. move data on EP to verify it's not halted I did fix that months ago on DWC3 because there was a bug on DWC3. MUSB was fixed years back too for a similar bug. pass USB CV2.0 MSC TEST. (othwerwise, Command Set Test - Device Configured will fail) Why would a pending struct usb_request in your queue fail USB CV ? _Lack_ of a pending request can cause the USB CV to fail. In Peter's example, if you're testing a Mass-Storage gadget, USB CV requires that there be a pending Bulk-OUT request when the gadget is idle (so that the next SCSI command can be sent out). But if there's a pending usb_request on a bulk-OUT endpoint, will a UDC driver be able to carry out a Set-Halt-Feature request from the host? The answer isn't clear. And it's even worse for bulk-IN. how can USB CV even test that there is a pending request on the UDC's side ? Short of actually moving data on that pipe, there's not way. Also, when the Halt request comes, UDC must take care of doing whatever necessary to make halt work. If that means cancelling transfers on a particular EP, so be it. Give them back with -ESHUTDOWN or -EPIPE or whatever. Just look at usb_ep_set_halt()'s documentation which states that drivers may need to empty the endpoint's request queue first. On top of that, we have the stall=0 flag for cases where the UDC really can't handle that halt request correctly. - When using pattern = 1 as module parameters to compare the data, the packet size must be same between host and device's. why ? The gadget stores the pattern data starting from 0 for each packet it sends. But the host tests the pattern data starting from 0 only at the beginning of the transfer; the host expects the pattern to continue without resetting at packet boundaries (if the transfer length is larger than the maxpacket size). then that's another bug which needs to be fixed :-) -- balbi signature.asc Description: Digital signature
Re: [PATCH] UAS: also check for ESHUTDOWN in error reporting
On Thu, Aug 20, 2015 at 11:16:00AM +0200, Oliver Neukum wrote: mode change 100644 = 100755 drivers/usb/host/xhci-ext-caps.h That's not good, I can't take this :( -- 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 v5 01/46] usb: gadget: encapsulate endpoint claiming mechanism
Hi,
On Fri, Jul 31, 2015 at 04:00:13PM +0200, Robert Baldyga wrote:
So far it was necessary for usb functions to set ep-driver_data in
endpoint obtained from autoconfig to non-null value, to indicate that
endpoint is claimed by function (in autoconfig it was checked if endpoint
has set this field to non-null value, and if it has, it was assumed that
it is claimed). It could cause bugs because if some function doesn't
set this field autoconfig could return the same endpoint more than one
time.
To help to avoid such bugs this patch adds claimed flag to struct usb_ep,
and encapsulates endpoint claiming mechanism inside usb_ep_autoconfig_ss()
and usb_ep_autoconfig_reset(), so now usb functions don't need to perform
any additional actions to mark endpoint obtained from autoconfig as claimed.
Signed-off-by: Robert Baldyga r.bald...@samsung.com
just letting you know that this regresses all gadget drivers making them
try to disable previously disabled endpoints and enable previously
enabled endpoints.
I have a possible fix (see below) but then it shows a problem on the
host side when using with g_zero (see further below):
commit 3b8932100aacb6cfbffe288ca93025d8b8430c00
Author: Felipe Balbi ba...@ti.com
Date: Wed Aug 19 18:05:27 2015 -0500
usb: gadget: fix ep-claimed lifetime
In order to fix a regression introduced by commit
cc476b42a39d (usb: gadget: encapsulate endpoint
claiming mechanism) we have to introduce a simple
helper to check if a particular is enabled or not.
After that, we need to move ep-claimed lifetime to
usb_ep_enable() and usb_ep_disable() since those
are the only functions which actually enable and
disable endpoints.
A follow-up patch will come to drop all driver_data
checks from function drivers, since those are, now,
pointless.
Fixes: cc476b42a39d (usb: gadget: encapsulate endpoint
claiming mechanism)
Cc: Robert Baldyga r.bald...@samsung.com
Signed-off-by: Felipe Balbi ba...@ti.com
diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c
index 978435a51038..ad45070cd76f 100644
--- a/drivers/usb/gadget/epautoconf.c
+++ b/drivers/usb/gadget/epautoconf.c
@@ -126,7 +126,6 @@ found_ep:
ep-address = desc-bEndpointAddress;
ep-desc = NULL;
ep-comp_desc = NULL;
- ep-claimed = true;
return ep;
}
EXPORT_SYMBOL_GPL(usb_ep_autoconfig_ss);
@@ -182,11 +181,6 @@ EXPORT_SYMBOL_GPL(usb_ep_autoconfig);
*/
void usb_ep_autoconfig_reset (struct usb_gadget *gadget)
{
- struct usb_ep *ep;
-
- list_for_each_entry (ep, gadget-ep_list, ep_list) {
- ep-claimed = false;
- }
gadget-in_epnum = 0;
gadget-out_epnum = 0;
}
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index c14a69b36d27..9b3d60c1cf9f 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -243,6 +243,22 @@ static inline void usb_ep_set_maxpacket_limit(struct
usb_ep *ep,
}
/**
+ * usb_ep_enabled - is endpoint enabled ?
+ * @ep: the endpoint being checked. may not be the endpoint named ep0.
+ *
+ * Whenever a function driver wants to check if a particular endpoint is
+ * enabled or not, it must check using this helper function. This will
+ * encapsulate details about how the endpoint is checked, saving the function
+ * driver from using private methods for doing so.
+ *
+ * return true if endpoint is enabled, false otherwise.
+ */
+static inline bool usb_ep_enabled(struct usb_ep *ep)
+{
+ return ep-claimed;
+}
+
+/**
* usb_ep_enable - configure endpoint, making it usable
* @ep:the endpoint being configured. may not be the endpoint named ep0.
* drivers discover endpoints through the ep_list of a usb_gadget.
@@ -264,7 +280,18 @@ static inline void usb_ep_set_maxpacket_limit(struct
usb_ep *ep,
*/
static inline int usb_ep_enable(struct usb_ep *ep)
{
- return ep-ops-enable(ep, ep-desc);
+ int ret;
+
+ if (usb_ep_enabled(ep))
+ return 0;
+
+ ret = ep-ops-enable(ep, ep-desc);
+ if (ret)
+ return ret;
+
+ ep-claimed = true;
+
+ return 0;
}
/**
@@ -281,7 +308,18 @@ static inline int usb_ep_enable(struct usb_ep *ep)
*/
static inline int usb_ep_disable(struct usb_ep *ep)
{
- return ep-ops-disable(ep);
+ int ret;
+
+ if (!usb_ep_enabled(ep))
+ return 0;
+
+ ret = ep-ops-disable(ep);
+ if (ret)
+ return ret;
+
+ ep-claimed = false;
+
+ return 0;
}
/**
[ 73.290345] WARNING: CPU: 0 PID: 300 at lib/kobject.c:240
kobject_add_internal+0x25c/0x2d8()
[ 73.299172] kobject_add_internal failed for ep_81 with -EEXIST, don't try to
register things with the same name in the same directory.
[ 73.311825] Modules linked in: usbtest usb_f_ss_lb g_zero libcomposite
xhci_plat_hcd xhci_hcd usbcore joydev dwc3 udc_core usb_common m25p80
Re: Some restrictions when using usbtest and g_zero
On Thu, Aug 20, 2015 at 10:40:17AM -0400, Alan Stern wrote:
On Thu, 20 Aug 2015, Peter Chen wrote:
Hi all,
I have played usbtest and g_zero (f_sourcesink f_loopback) to do
the tests between two boards these days, and have found some restrictions,
I list them here, and to see if they are common problems and can
be improved or not.
- Test 13 will fail due to there is pending IN request (f_sourcesink
will queue a request unconditionally at its completion), and udc driver
will run out error if that. udc driver must do that if it wants to
pass USB CV2.0 MSC TEST. (othwerwise, Command Set Test - Device Configured
will fail)
The USB spec isn't very clear about this. All it says about the
Set-Halt request is:
When set by the SetFeature() request, the endpoint exhibits the
same stall behavior as if the field had been set by a hardware
condition.
But if there's a pending request, many UDC drivers are unable to set
the HALT feature -- even due to a hardware condition.
I suppose the right thing is for the UDC to temporarily disable the
endpoint, set the HALT feature, and then re-enable the endpoint (along
with the pending request). But changing a bunch of UDC drivers for
such a minor thing doesn't seem worthwhile.
we can move that into udc-core.c:
int usb_ep_set_halt(struct usb_ep *ep)
{
if (WARN_ON(!ep))
return -EINVAL;
if (!usb_ep_queue_is_empty(ep))
usb_ep_empty_queue(ep, -EPIPE);
return __usb_ep_set_halt(ep);
}
or something similar.
--
balbi
signature.asc
Description: Digital signature
Re: MUSB sysfs node naming convention
On Thu, Aug 20, 2015 at 2:11 PM, Felipe Balbi ba...@ti.com wrote: On Thu, Aug 20, 2015 at 01:28:30PM -0500, Bin Liu wrote: On Thu, Aug 20, 2015 at 1:23 PM, Felipe Balbi ba...@ti.com wrote: On Thu, Aug 20, 2015 at 12:21:29PM -0500, Bin Liu wrote: Hi, Currently, the sysfs MUSB node name uses kernel device name global *auto* convention. So depending on kernel configuration, the two MUSB device nodes could be musb-hdrc.0.auto/musb-hdrc.1.auto, or musb-hdrc.1.auto/musb-hdrc.2.auto. Of cause the index could be any other number if there were more devices using this naming convention. Why we decided to name MUSB nodes this way? It gives me a lot of troubles in scripting and documentation. it's just the device name, that's all. We could name it with a string representing the register address. Something like 'musb-47401c00' Yeah, I know it is just a name, that is why I want to know if possible to change the default to not use the global name, to something static, so that it is easier for scripting and documentation? sure, why not ? I don't think anybody is really relying on those. Send a patch and let's see if anybody complains. Cool, I will find a time to make the patch. Thanks. -- balbi -- 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 v7 1/2] usb: make xhci platform driver use 64 bit or 32 bit DMA
The xhci platform driver needs to work on systems that
either only support 64-bit DMA or only support 32-bit DMA.
Attempt to set a coherent dma mask for 64-bit DMA, and
attempt again with 32-bit DMA if that fails.
[dhdang: regenerate the patch over 4.2-rc5 and address new comments]
Signed-off-by: Mark Langsdorf mlang...@redhat.com
Tested-by: Mark Salter msal...@redhat.com
Signed-off-by: Duc Dang dhd...@apm.com
---
Changes from v6:
-Add WARN_ON if dma_mask is NULL
-Use dma_coerce_mask_and_coherent to assign
dma_mask and coherent_dma_mask
Changes from v5:
-Change comment
-Assign dma_mask to coherent_dma_mask if dma_mask is NULL
to make sure dma_set_mask_and_coherent does not fail prematurely.
Changes from v4:
-None
Changes from v3:
-Re-generate the patch over 4.2-rc5
-No code change.
Changes from v2:
-None
Changes from v1:
-Consolidated to use dma_set_mask_and_coherent
-Got rid of the check against sizeof(dma_addr_t)
drivers/usb/host/xhci-plat.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 890ad9d..e4c7f9d 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -93,14 +93,19 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (irq 0)
return -ENODEV;
- /* Initialize dma_mask and coherent_dma_mask to 32-bits */
- ret = dma_set_coherent_mask(pdev-dev, DMA_BIT_MASK(32));
- if (ret)
- return ret;
- if (!pdev-dev.dma_mask)
- pdev-dev.dma_mask = pdev-dev.coherent_dma_mask;
- else
- dma_set_mask(pdev-dev, DMA_BIT_MASK(32));
+ /* Throw a waring if broken platform code didn't initialize dma_mask */
+ WARN_ON(!pdev-dev.dma_mask);
+ /*
+* Try setting dma_mask and coherent_dma_mask to 64 bits,
+* then try 32 bits
+*/
+ ret = dma_coerce_mask_and_coherent(pdev-dev, DMA_BIT_MASK(64));
+ if (ret) {
+ ret = dma_coerce_mask_and_coherent(pdev-dev,
+ DMA_BIT_MASK(32));
+ if (ret)
+ return ret;
+ }
hcd = usb_create_hcd(driver, pdev-dev, dev_name(pdev-dev));
if (!hcd)
--
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
[GIT PULL] USB driver patches for 4.3-rc1
The following changes since commit f7644cbfcdf03528f0f450f3940c4985b2291f49: Linux 4.2-rc6 (2015-08-09 15:54:30 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/ tags/usb-4.3-rc1 for you to fetch changes up to 44840dec6127e4d7c5074f75d2dd96bc4ab85fe3: USB: qcserial: add HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module (2015-08-18 10:07:40 -0700) USB patches for 4.3-rc1 Here's the big USB and PHY patchset for 4.3-rc1. As usual, the majority of the changes are in the USB gadget portion of the tree, lots of little changes all over the place for bugs and new hardware. Other than that, the normal mix of new hardware support and bugfixes. All have been in linux-next with no reported issues. Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Aaron Raimist (1): USB: atm: cxacru: fix blank line after declaration Alban Bedel (1): usb: ehci-platform: Fix using multiple controllers from OF Alexandre Belloni (5): usb: gadget: atmel: remove useless include USB: host: ohci-at91: move at91_usbh_data definition in c file USB: host: ohci-at91: depend on OF USB: host: ohci-at91: merge ohci_at91_of_init in ohci_hcd_at91_drv_probe USB: host: ohci-at91: merge loops in ohci_hcd_at91_drv_probe Axel Lin (2): phy: ulpi_phy: Add const qualifier to ops phy: Constify struct phy_ops variables Chanwoo Choi (5): usb: dwc3: omap: Replace deprecated API of extcon usb: phy: omap-otg: Replace deprecated API of extcon usb: phy: tahvo: Use devm_extcon_dev_[allocate|register]() and replace deprecated API usb: renesas_usbhs: Replace deprecated API of extcon usb: phy: msm-usb: Replace deprecated API of extcon Chase Metzger (2): usb: core: hub.c: Removed some warnings generated by checkpatch.pl usb: core: hub: Removed some warnings generated by checkpatch.pl Dan Carpenter (2): usb: gadget: fotg210-udc: remove duplicate conditions usb: gadget: m66592-udc: forever loop in set_feature() David Ward (1): USB: qcserial: add HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module Diego Viola (1): usb: gadget: composite.c: i18n is not an acronym Felipe Balbi (15): usb: dwc2: gadget: use | instead of + for bitmasks usb: dwc3: omap: drop dev_dbg() usage usb: dwc3: keystone: convert dev_dbg() to dev_err() usb: dwc3: exynos: switch dev_dbg() to dev_info() usb: dwc3: qcom: switch dev_dbg() to dev_info() usb: dwc3: st: remove two unnecessary messages usb: dwc3: drop CONFIG_USB_DWC3_DEBUG usb: dwc3: core: remove unnecessary dev_warn() usb: dwc3: gadget: add a trace when disabling EPs usb: dwc3: gadget: defer endpoint name change usb: gadget: f_uac2: fix build warning usb: musb: gadget: remove remaining DMA ifdeferry usb: musb: cppi41: allow it to work again usb: gadget: f_mass_storage: add mising linux/uaccess.h usb: gadget: legacy: nokia: add CONFIG_BLOCK dependency Fupan Li (1): usb: gadget: f_printer: fix deadlock caused by nested spinlock Greg Kroah-Hartman (13): Merge 4.2-rc4 into usb-next Merge 4.2-rc6 into usb-next Merge tag 'usb-for-v4.3' of git://git.kernel.org/.../balbi/usb into usb-next Merge tag 'usb-ci-v4.3-rc1' of git://git.kernel.org/.../peter.chen/usb into usb-next Merge tag 'phy-for-4.3' of git://git.kernel.org/.../kishon/linux-phy into usb-next Merge tag 'usb-serial-4.3-rc1' of git://git.kernel.org/.../johan/usb-serial into usb-next Revert usb: interface authorization: Use a flag for the default device authorization Revert usb: interface authorization: Documentation part Revert usb: interface authorization: SysFS part of USB interface authorization Revert usb: interface authorization: Introduces the USB interface authorization Revert usb: interface authorization: Control interface probing and claiming Revert usb: interface authorization: Introduces the default interface authorization Revert usb: interface authorization: Declare authorized attribute Hans de Goede (12): phy-sun4i-usb: Add id and vbus detection support for the otg phy (phy0) phy-sun4i-usb: Add extcon support for the otg phy (phy0) phy-sun4i-usb: Swap check for disconnect threshold phy-sun4i-usb: Add support for the usb-phys on the sun8i-a23 SoC phy-sun4i-usb: Add support for the usb-phys on the sun8i-a33 SoC phy-sun4i-usb: Add support for boards with broken Vusb-detection phy-sun4i-usb: Add support for monitoring vbus via a power-supply usb: musb: sunxi: Add support for the Allwinner sunxi musb controller usb: musb: sunxi: Add support for musb controller in A31 SoC usb: musb: sunxi: Add support for musb controller in
Re: Some restrictions when using usbtest and g_zero
On Thu, 20 Aug 2015, Felipe Balbi wrote: Hi, On Thu, Aug 20, 2015 at 01:08:30PM -0400, Alan Stern wrote: On Thu, 20 Aug 2015, Felipe Balbi wrote: - Test 13 will fail due to there is pending IN request (f_sourcesink will queue a request unconditionally at its completion), and udc driver will run out error if that. udc driver must do that if it wants to wait, what ? test 13 works just fine here. (I'll try again in a few minutes just to make sure) It may depend on what UDC and what test device you use. Why ? Why would SET_FEATURE(HALT) fail ? I can only see it as a bug on the UDC driver. A bug which should be fixed. Here's what the kerneldoc for usb_ep_set_halt() says: * Returns zero, or a negative error code. On success, this call sets * underlying hardware state that blocks data transfers. * Attempts to halt IN endpoints will fail (returning -EAGAIN) if any * transfer requests are still queued, or if the controller hardware * (usually a FIFO) still holds bytes that the host hasn't collected. That's talking about IN endpoints only, not OUT -- but Peter's original email mentioned that Test 13 fails if there's a pending IN usb_request. oh right, IN endpoints are special in that sense :-) But that's only true for some cases. When host side sends SetFeature(HALT), that should always succeed, right ? See commit 7a60855972f0d for example. Yeah, that fixed DWC3. Peter didn't say which UDC driver he was using. I went back and looked at net2280. That driver treates Set-Halt requests from the host differently from set_halt() calls from the gadget driver. The request from the host always succeeds immediately, whereas the call from the gadget driver fails if the request queue or the hardware FIFO is non-empty. So it looks like Test 13 should work with net2280. And indeed it does; I just tried it. Doesn't Peter need to cope with differentiating protocol vs non-protocol stalls ? Those matter only for ep0, not for bulk/interrupt. 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: Some restrictions when using usbtest and g_zero
On Thu, Aug 20, 2015 at 04:12:24PM -0400, Alan Stern wrote: On Thu, 20 Aug 2015, Felipe Balbi wrote: Hi, On Thu, Aug 20, 2015 at 01:08:30PM -0400, Alan Stern wrote: On Thu, 20 Aug 2015, Felipe Balbi wrote: - Test 13 will fail due to there is pending IN request (f_sourcesink will queue a request unconditionally at its completion), and udc driver will run out error if that. udc driver must do that if it wants to wait, what ? test 13 works just fine here. (I'll try again in a few minutes just to make sure) It may depend on what UDC and what test device you use. Why ? Why would SET_FEATURE(HALT) fail ? I can only see it as a bug on the UDC driver. A bug which should be fixed. Here's what the kerneldoc for usb_ep_set_halt() says: * Returns zero, or a negative error code. On success, this call sets * underlying hardware state that blocks data transfers. * Attempts to halt IN endpoints will fail (returning -EAGAIN) if any * transfer requests are still queued, or if the controller hardware * (usually a FIFO) still holds bytes that the host hasn't collected. That's talking about IN endpoints only, not OUT -- but Peter's original email mentioned that Test 13 fails if there's a pending IN usb_request. oh right, IN endpoints are special in that sense :-) But that's only true for some cases. When host side sends SetFeature(HALT), that should always succeed, right ? See commit 7a60855972f0d for example. Yeah, that fixed DWC3. Peter didn't say which UDC driver he was using. I went back and looked at net2280. That driver treates Set-Halt requests from the host differently from set_halt() calls from the gadget driver. The request from the host always succeeds immediately, whereas the call from the gadget driver fails if the request queue or the hardware FIFO is non-empty. So it looks like Test 13 should work with net2280. And indeed it does; I just tried it. Doesn't Peter need to cope with differentiating protocol vs non-protocol stalls ? Those matter only for ep0, not for bulk/interrupt. huh ? usbtest send SetFeature(HALT) for the bulk endpoint, right ? That's what Peter's UDC driver is missing. It's this special case of halting the endpoint when the host asks it to regardless of having queued struct usb_requests or not. -- balbi signature.asc Description: Digital signature
PROBLEM: lsusb -v freezes kernel on Acer ES1-111M
[1.] One line summary of the problem: lsusb -v as root freezes the kernel on Acer ES1-111M [2.] Full description of the problem/report: As root, lsusb -v against USB devices 003:001 or 003:002 of my Acer ES1-111M netbook freezes the kernel. No log entry, no oops, no magic sysreq key. Reproducible: always. There are only those two devices on bus 003. There is no problem with the other USB buses or devices of the machine. I have no external USB devices attached. When I had, there was no problem with them. [3.] Keywords (i.e., modules, networking, kernel): [4.] Kernel version (from /proc/version): Linux version 4.1.6-040106-generic (kernel@gomeisa) (gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04) ) #201508170230 SMP Mon Aug 17 06:32:14 UTC 2015 The problem also occurs with kernel versions 4.2-rc7 and 3.18. There is no problem with kernel versions 3.17 and 3.17.8. [5.] Output of Oops.. not applicable [6.] A small shell script or example program which triggers the problem (if possible) lsusb -v [7.] Environment lsb_release -rd Description:Ubuntu 15.04 Release:15.04 [7.1.] Software /usr/src/linux-headers-4.1.6-040106/scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux Nightwing 4.1.6-040106-generic #201508170230 SMP Mon Aug 17 06:32:14 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Gnu C 4.9.2 Gnu make 4.0 binutils 2.25 util-linux 2.25.2 mount debug module-init-tools 18 e2fsprogs 1.42.12 pcmciautils018 PPP2.4.6 Linux C Library2.21 Dynamic linker (ldd) 2.21 Procps 3.3.9 Net-tools 1.60 Kbd1.15.5 Sh-utils 8.23 wireless-tools 30 Modules Loaded ctr ccm cmac rfcomm bnep acer_wmi sparse_keymap intel_rapl intel_soc_dts_thermal intel_powerclamp coretemp kvm_intel kvm joydev snd_hda_codec_hdmi snd_hda_codec_realtek crct10dif_pclmul snd_hda_codec_generic crc32_pclmul ghash_clmulni_intel cryptd arc4 ath9k uvcvideo snd_hda_intel ath9k_common snd_hda_controller snd_hda_codec videobuf2_vmalloc ath9k_hw snd_hda_core videobuf2_memops videobuf2_core v4l2_common snd_hwdep i915 ath videodev snd_pcm mac80211 serio_raw media snd_seq_midi snd_seq_midi_event ath3k snd_rawmidi btusb btbcm lpc_ich cfg80211 btintel snd_seq bluetooth drm_kms_helper snd_seq_device snd_timer drm snd soundcore mei_txe i2c_algo_bit mei iosf_mbi shpchp 8250_fintek video wmi int3400_thermal processor_thermal_device int3403_thermal acpi_thermal_rel int340x_thermal_zone intel_smartconnect mac_hid parport_pc ppdev lp parport autofs4 mmc_block psmouse r8169 mii sdhci_pci sdhci [7.2.] Processor information (from /proc/cpuinfo): cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 55 model name : Intel(R) Celeron(R) CPU N2840 @ 2.16GHz stepping: 8 microcode : 0x829 cpu MHz : 622.413 cache size : 1024 KB physical id : 0 siblings: 2 core id : 0 cpu cores : 2 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer rdrand lahf_lm 3dnowprefetch ida arat epb dtherm tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms bugs: bogomips: 4326.40 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: processor : 1 vendor_id : GenuineIntel cpu family : 6 model : 55 model name : Intel(R) Celeron(R) CPU N2840 @ 2.16GHz stepping: 8 microcode : 0x829 cpu MHz : 565.307 cache size : 1024 KB physical id : 0 siblings: 2 core id : 1 cpu cores : 2 apicid : 2 initial apicid : 2 fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer rdrand lahf_lm 3dnowprefetch ida arat epb dtherm tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms bugs: bogomips: 4326.40 clflush size: 64 cache_alignment : 64 address
Re: [PATCH v5 01/46] usb: gadget: encapsulate endpoint claiming mechanism
Hi Felipe, On 08/20/2015 05:35 PM, Felipe Balbi wrote: [...] just letting you know that this regresses all gadget drivers making them try to disable previously disabled endpoints and enable previously enabled endpoints. I have a possible fix (see below) but then it shows a problem on the host side when using with g_zero (see further below): commit 3b8932100aacb6cfbffe288ca93025d8b8430c00 Author: Felipe Balbi ba...@ti.com Date: Wed Aug 19 18:05:27 2015 -0500 usb: gadget: fix ep-claimed lifetime In order to fix a regression introduced by commit cc476b42a39d (usb: gadget: encapsulate endpoint claiming mechanism) we have to introduce a simple helper to check if a particular is enabled or not. After that, we need to move ep-claimed lifetime to usb_ep_enable() and usb_ep_disable() since those are the only functions which actually enable and disable endpoints. A follow-up patch will come to drop all driver_data checks from function drivers, since those are, now, pointless. Fixes: cc476b42a39d (usb: gadget: encapsulate endpoint claiming mechanism) Cc: Robert Baldyga r.bald...@samsung.com Signed-off-by: Felipe Balbi ba...@ti.com diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c index 978435a51038..ad45070cd76f 100644 --- a/drivers/usb/gadget/epautoconf.c +++ b/drivers/usb/gadget/epautoconf.c @@ -126,7 +126,6 @@ found_ep: ep-address = desc-bEndpointAddress; ep-desc = NULL; ep-comp_desc = NULL; - ep-claimed = true; Removing this line causes autoconfig can return the same endpoint many times. This probably causes problems with g_zero. I will try to fix it ASAP. Thanks, Robert -- 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: MUSB dual-role on AM335x behaving weirdly
Hi Felipe, On 18/08/2015 16:13, Felipe Balbi wrote: Hi, On Tue, Aug 18, 2015 at 02:36:13PM +0200, Gregory CLEMENT wrote: Hi again Felipe, I sent this email again without the capture because it prevented to be delivered to the mailing lists. On 04/08/2015 21:32, Felipe Balbi wrote: On Tue, Aug 04, 2015 at 04:23:02PM +0200, Gregory CLEMENT wrote: Hi again, On 04/08/2015 15:08, Gregory CLEMENT wrote: Hi Bin, On 02/07/2015 19:05, Bin Liu wrote: Hi, On Thu, Jul 2, 2015 at 2:16 AM, Gregory CLEMENT gregory.clem...@free-electrons.com wrote: Hi Felipe, On 27/05/2015 11:42, Alexandre Belloni wrote: Hi, On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote : On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote: Alexandre, On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni alexandre.bell...@free-electrons.com wrote: On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote : I think I found the root cause of the problem: board design issue - I bet the custom board has too much cap on VBUS line. It should be 10uF. We have a custom board that exhibits the issue but it only has a 100nF cap on VBUS. Have you measured the VBUS discharging? Is there any way to share your schematics? Alexandre, any further comments ? Yeah, I have just got more info. This is the relevant part of the schematic: http://free-electrons.com/~alexandre/usb.png The total VBUS capacitance is 200nF and the USB0 pins are connected directly to the AM3358 pins. U1 is actually not fitted. We didn't measure VBUS discharging but we observe the OTG pin sensing stops when plugging an OTG cable without any device. Do you have any news about this topic? Is there something else that we can do to help solving this issue? In the case of CONFIG_USB_MUSB_DUAL_ROLE=y and dr_mode=otg, how is the gadget driver configured? It has to be a module not built-in. Indeed when I configured CONFIG_USB_MUSB_HDRC=m and CONFIG_USB_MUSB_DSPS=m it worked seamless. Actually it didn't worked. And now sometimes I even received continuously the following message: musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active this is likely because your VBUS hasn't dropped below 0.8V fast enough. I could only trigger this message in that situation. Use a scope to poke at VBUS and see how long is takes to reach 0.8V, this could all be cause by too much capacitance on VBUS line. We got some news: The capacitance on VBUS due to components is 200nF and the additional parasitic capacitance will be much smaller than this The rail discharge time is ~36ms when an USB drive is removed from the OTG adapter. I attached a capture of this. What do you think about these values? However, there appears to be a considerable delay between the removal of a usb drive and the initiation of the VBUS discharge (maybe ~1 second, I wasn't able to measure this time). yeah, this is really weird. I can't think of anything that would make VBUS discharge slower from a SW point of view. Once you remove the cable, VBUS is physically removed and there's nothing else charging it. I have more feedback about it: When I look at it on the oscilloscope this isn't a 'slow discharge' like a slowly draining capacitor, it is a delay between the removal of a device and the initiation of the discharge. The discharge itself is quite fast once it begins, it just seems as if the SOC/driver is taking a long time to notice the cable is disconnected. At this stage, this isn't actually a problem, just odd. While working on this issue we found that the tg_state_a_wait_vrise_timeout case seemed not managed by musb_dsps driver. I've just submitted a patch for it: https://lkml.org/lkml/2015/8/20/507 I made most of my test on a 3.17 kernel and today by using a 4.1 kernel with the patch I have submitted I didn't manage to reproduce the issue. I saw that since 3.17, there were some patches related to the babble interrupts; so maybe it was enough to fix the issue we saw. It is still weird because one month ago I also tested with a 4.1 kernel and I had issues... It needs more testing to see if it is really fixed because the issue comes only time to time. I will keep you inform about our last tests. Thanks, Gregory -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- 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: MUSB dual-role on AM335x behaving weirdly
On Thu, Aug 20, 2015 at 06:35:17PM +0200, Gregory CLEMENT wrote: Hi Felipe, On 18/08/2015 16:13, Felipe Balbi wrote: Hi, On Tue, Aug 18, 2015 at 02:36:13PM +0200, Gregory CLEMENT wrote: Hi again Felipe, I sent this email again without the capture because it prevented to be delivered to the mailing lists. On 04/08/2015 21:32, Felipe Balbi wrote: On Tue, Aug 04, 2015 at 04:23:02PM +0200, Gregory CLEMENT wrote: Hi again, On 04/08/2015 15:08, Gregory CLEMENT wrote: Hi Bin, On 02/07/2015 19:05, Bin Liu wrote: Hi, On Thu, Jul 2, 2015 at 2:16 AM, Gregory CLEMENT gregory.clem...@free-electrons.com wrote: Hi Felipe, On 27/05/2015 11:42, Alexandre Belloni wrote: Hi, On 26/05/2015 at 09:51:18 -0500, Felipe Balbi wrote : On Thu, May 14, 2015 at 04:36:33PM -0500, Bin Liu wrote: Alexandre, On Thu, May 14, 2015 at 4:26 PM, Alexandre Belloni alexandre.bell...@free-electrons.com wrote: On 14/05/2015 at 16:16:12 -0500, Bin Liu wrote : I think I found the root cause of the problem: board design issue - I bet the custom board has too much cap on VBUS line. It should be 10uF. We have a custom board that exhibits the issue but it only has a 100nF cap on VBUS. Have you measured the VBUS discharging? Is there any way to share your schematics? Alexandre, any further comments ? Yeah, I have just got more info. This is the relevant part of the schematic: http://free-electrons.com/~alexandre/usb.png The total VBUS capacitance is 200nF and the USB0 pins are connected directly to the AM3358 pins. U1 is actually not fitted. We didn't measure VBUS discharging but we observe the OTG pin sensing stops when plugging an OTG cable without any device. Do you have any news about this topic? Is there something else that we can do to help solving this issue? In the case of CONFIG_USB_MUSB_DUAL_ROLE=y and dr_mode=otg, how is the gadget driver configured? It has to be a module not built-in. Indeed when I configured CONFIG_USB_MUSB_HDRC=m and CONFIG_USB_MUSB_DSPS=m it worked seamless. Actually it didn't worked. And now sometimes I even received continuously the following message: musb_bus_suspend 2484: trying to suspend as a_wait_vfall while active this is likely because your VBUS hasn't dropped below 0.8V fast enough. I could only trigger this message in that situation. Use a scope to poke at VBUS and see how long is takes to reach 0.8V, this could all be cause by too much capacitance on VBUS line. We got some news: The capacitance on VBUS due to components is 200nF and the additional parasitic capacitance will be much smaller than this The rail discharge time is ~36ms when an USB drive is removed from the OTG adapter. I attached a capture of this. What do you think about these values? However, there appears to be a considerable delay between the removal of a usb drive and the initiation of the VBUS discharge (maybe ~1 second, I wasn't able to measure this time). yeah, this is really weird. I can't think of anything that would make VBUS discharge slower from a SW point of view. Once you remove the cable, VBUS is physically removed and there's nothing else charging it. I have more feedback about it: When I look at it on the oscilloscope this isn't a 'slow discharge' like a slowly draining capacitor, it is a delay between the removal of a device and the initiation of the discharge. The discharge itself is quite fast once it begins, it just seems as if the SOC/driver is taking a long time to notice the cable is disconnected. At this stage, this isn't actually a problem, just odd. While working on this issue we found that the tg_state_a_wait_vrise_timeout case seemed not managed by musb_dsps driver. I've just submitted a patch for it: https://lkml.org/lkml/2015/8/20/507 cool, I'll test it next week. Good finding btw. I made most of my test on a 3.17 kernel and today by using a 4.1 kernel with the patch I have submitted I didn't manage to reproduce the issue. I saw that since 3.17, there were some patches related to the babble interrupts; so maybe it was enough to fix the issue we saw. It is still weird because one month ago I also tested with a 4.1 kernel and I had issues... It needs more testing to see if it is really fixed because the issue comes only time to time. I will keep you inform about our last tests. all right. Seems like we really need to turn some of those states handling into a reusable (musb-specific) library. -- balbi signature.asc Description: Digital signature
Re: [PATCH v5 01/46] usb: gadget: encapsulate endpoint claiming mechanism
On Thu, Aug 20, 2015 at 06:28:14PM +0200, Robert Baldyga wrote: Hi Felipe, On 08/20/2015 05:35 PM, Felipe Balbi wrote: [...] just letting you know that this regresses all gadget drivers making them try to disable previously disabled endpoints and enable previously enabled endpoints. I have a possible fix (see below) but then it shows a problem on the host side when using with g_zero (see further below): commit 3b8932100aacb6cfbffe288ca93025d8b8430c00 Author: Felipe Balbi ba...@ti.com Date: Wed Aug 19 18:05:27 2015 -0500 usb: gadget: fix ep-claimed lifetime In order to fix a regression introduced by commit cc476b42a39d (usb: gadget: encapsulate endpoint claiming mechanism) we have to introduce a simple helper to check if a particular is enabled or not. After that, we need to move ep-claimed lifetime to usb_ep_enable() and usb_ep_disable() since those are the only functions which actually enable and disable endpoints. A follow-up patch will come to drop all driver_data checks from function drivers, since those are, now, pointless. Fixes: cc476b42a39d (usb: gadget: encapsulate endpoint claiming mechanism) Cc: Robert Baldyga r.bald...@samsung.com Signed-off-by: Felipe Balbi ba...@ti.com diff --git a/drivers/usb/gadget/epautoconf.c b/drivers/usb/gadget/epautoconf.c index 978435a51038..ad45070cd76f 100644 --- a/drivers/usb/gadget/epautoconf.c +++ b/drivers/usb/gadget/epautoconf.c @@ -126,7 +126,6 @@ found_ep: ep-address = desc-bEndpointAddress; ep-desc = NULL; ep-comp_desc = NULL; -ep-claimed = true; Removing this line causes autoconfig can return the same endpoint many times. This probably causes problems with g_zero. I will try to fix it ASAP. I was considering the same thing, but the lifetime of -claimed doesn't look correct to me either way. Note that once the flag is enabled, it won't get disabled by most gadget drivers. -- balbi signature.asc Description: Digital signature
[PATCH] usb: musb: dsps: handle the otg_state_a_wait_vrise_timeout case
According to the OTG specification after a timeout of
OTG_TIME_A_WAIT_VRISE (the maximum value is 100ms) the driver must
move from the state a_wait_vrise to the state a_wait_bcon. However,
the dsps version of musb does not handle this case.
Without it, the driver could remain stuck in the a_wait_vrise. It can
be reproduce with the following steps:
1) Boot a board with no USB adapter inserted
2) Insert an empty OTG adapter
3) Wait 2 seconds then remove the OTG adapter
4) The unit is now stuck in host mode, the VBUS switch is latched on
and the ID pin is no longer polled.
The only way to exit this state was to insert a OTG adapter with an
USB device connected. Until this, the usb device mode was not
available.
It was tested on a AM35x based board.
CC: sta...@vger.kernel.org
Signed-off-by: Gregory CLEMENT gregory.clem...@free-electrons.com
---
drivers/usb/musb/musb_dsps.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_dsps.c b/drivers/usb/musb/musb_dsps.c
index 65d931a..2d22683 100644
--- a/drivers/usb/musb/musb_dsps.c
+++ b/drivers/usb/musb/musb_dsps.c
@@ -145,6 +145,7 @@ struct dsps_glue {
struct timer_list timer;/* otg_workaround timer */
unsigned long last_timer;/* last timer data for each instance */
bool sw_babble_enabled;
+ int otg_state_a_wait_vrise_timeout;
struct dsps_context context;
struct debugfs_regset32 regset;
@@ -268,9 +269,18 @@ static void otg_timer(unsigned long _musb)
spin_lock_irqsave(musb-lock, flags);
switch (musb-xceiv-otg-state) {
+ case OTG_STATE_A_WAIT_VRISE:
+ if ((glue-otg_state_a_wait_vrise_timeout)) {
+ musb-xceiv-otg-state = OTG_STATE_A_WAIT_BCON;
+ musb-is_active = 0;
+ }
+ mod_timer(glue-timer, jiffies +
+ msecs_to_jiffies(OTG_TIME_A_WAIT_VRISE));
+ break;
case OTG_STATE_A_WAIT_BCON:
dsps_writeb(musb-mregs, MUSB_DEVCTL, 0);
skip_session = 1;
+ glue-otg_state_a_wait_vrise_timeout = 0;
/* fall */
case OTG_STATE_A_IDLE:
@@ -359,7 +369,9 @@ static irqreturn_t dsps_interrupt(int irq, void *hci)
MUSB_HST_MODE(musb);
musb-xceiv-otg-default_a = 1;
musb-xceiv-otg-state = OTG_STATE_A_WAIT_VRISE;
- del_timer(glue-timer);
+ glue-otg_state_a_wait_vrise_timeout = 1;
+ mod_timer(glue-timer, jiffies +
+ msecs_to_jiffies(OTG_TIME_A_WAIT_VRISE));
} else {
musb-is_active = 0;
MUSB_DEV_MODE(musb);
--
2.1.0
--
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
Support of Mark-10 Force Gauge USB
Hi Johan,
if you want to take the following patch then the Mark-10 Force Gauge Series 5
is supported by the cp210x driver. We have tested only with kernel 4.1.5
It works perfect.
Thanks, Sepp Käsbauer
see: http://www.mark-10.com/instruments/force/series5.html
diff -c cp210x.c.orig cp210x.c
*** cp210x.c.orig 2015-08-20 10:09:31.811953677 +0200
--- cp210x.c2015-08-20 10:11:26.203796713 +0200
***
*** 111,116
--- 111,117
{ USB_DEVICE(0x10C4, 0x8341) }, /* Siemens MC35PU GPRS Modem */
{ USB_DEVICE(0x10C4, 0x8382) }, /* Cygnal Integrated Products, Inc. */
{ USB_DEVICE(0x10C4, 0x83A8) }, /* Amber Wireless AMB2560 */
+ { USB_DEVICE(0x10C4, 0x83AA) }, /* Mark-10 Force Gauge M5-05 */
{ USB_DEVICE(0x10C4, 0x83D8) }, /* DekTec DTA Plus VHF/UHF
Booster/Attenuator */
{ USB_DEVICE(0x10C4, 0x8411) }, /* Kyocera GPS Module */
{ USB_DEVICE(0x10C4, 0x8418) }, /* IRZ Automation Teleport SG-10
GSM/GPRS Modem */
--
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
