[PATCH 5/5] usb: xhci: exit early in xhci_setup_device() if we're halted or dying
During quick plug/removal of OTG adapter during dual-role testing
it can happen that xhci_alloc_device() is called for the newly
detected device after the DRD library has called xhci_stop to
remove the HCD.
If that is the case, just fail early to prevent the following warning.
[ 154.732649] hub 4-0:1.0: USB hub found
[ 154.742204] hub 4-0:1.0: 1 port detected
[ 154.824458] hub 3-0:1.0: state 7 ports 1 chg 0002 evt
[ 154.854609] hub 4-0:1.0: state 7 ports 1 chg evt
[ 154.944430] usb 3-1: new high-speed USB device number 2 using xhci-hcd
[ 154.951009] xhci-hcd xhci-hcd.0.auto: xhci_setup_device
[ 155.038191] xhci-hcd xhci-hcd.0.auto: remove, state 4
[ 155.043315] usb usb4: USB disconnect, device number 1
[ 155.055270] xhci-hcd xhci-hcd.0.auto: xhci_stop
[ 155.060094] xhci-hcd xhci-hcd.0.auto: USB bus 4 deregistered
[ 155.066576] xhci-hcd xhci-hcd.0.auto: remove, state 1
[ 155.071710] usb usb3: USB disconnect, device number 1
[ 155.077124] xhci-hcd xhci-hcd.0.auto: xhci_setup_device
[ 155.082389] [ cut here ]
[ 155.087690] WARNING: CPU: 0 PID: 72 at drivers/usb/host/xhci.c:3800
xhci_setup_device+0x410/0x484 [xhci_hcd]()
[ 155.097861] Modules linked in: sd_mod usb_storage scsi_mod usb_f_ss_lb
g_zero libcomposite ipv6 xhci_plat_hcd xhci_hcd usbcore dwc3 udc_core evdev
ti_am335x_adc joydev kfifo_buf industrialio snd_soc_simple_cc
[ 155.146734] CPU: 0 PID: 72 Comm: kworker/0:3 Tainted: GW
4.1.4-00834-gcd9380b-dirty #50
[ 155.156073] Hardware name: Generic AM43 (Flattened Device Tree)
[ 155.162117] Workqueue: usb_hub_wq hub_event [usbcore]
[ 155.167249] Backtrace:
[ 155.169751] [c0012af0] (dump_backtrace) from [c0012c8c]
(show_stack+0x18/0x1c)
[ 155.177390] r6:c089d4a4 r5: r4: r3:ee46c000
[ 155.183137] [c0012c74] (show_stack) from [c05f7c14]
(dump_stack+0x84/0xd0)
[ 155.190446] [c05f7b90] (dump_stack) from [c00439ac]
(warn_slowpath_common+0x80/0xbc)
[ 155.198605] r7:0009 r6:0ed8 r5:bf27eb70 r4:
[ 155.204348] [c004392c] (warn_slowpath_common) from [c0043a0c]
(warn_slowpath_null+0x24/0x2c)
[ 155.213202] r8:ee49f000 r7:ee7c0004 r6: r5:ee7c0158 r4:ee7c
[ 155.220051] [c00439e8] (warn_slowpath_null) from [bf27eb70]
(xhci_setup_device+0x410/0x484 [xhci_hcd])
[ 155.229816] [bf27e760] (xhci_setup_device [xhci_hcd]) from [bf27ec10]
(xhci_address_device+0x14/0x18 [xhci_hcd])
[ 155.240415] r10:ee598200 r9:0001 r8:0002 r7:0001 r6:0003
r5:0002
[ 155.248363] r4:ee49f000
[ 155.250978] [bf27ebfc] (xhci_address_device [xhci_hcd]) from [bf20cb94]
(hub_port_init+0x1b8/0xa9c [usbcore])
[ 155.261403] [bf20c9dc] (hub_port_init [usbcore]) from [bf2101e0]
(hub_event+0x738/0x1020 [usbcore])
[ 155.270874] r10:ee598200 r9:ee7c r8:ee7c0038 r7:ee518800 r6:ee49f000
r5:0001
[ 155.278822] r4:
[ 155.281426] [bf20faa8] (hub_event [usbcore]) from [c005754c]
(process_one_work+0x128/0x340)
[ 155.290196] r10: r9:0003 r8: r7:fedfa000 r6:eeec5400
r5:ee598314
[ 155.298151] r4:ee434380
[ 155.300718] [c0057424] (process_one_work) from [c00578f8]
(worker_thread+0x158/0x49c)
[ 155.308963] r10:ee434380 r9:0003 r8:eeec5400 r7:0008 r6:ee434398
r5:eeec5400
[ 155.316913] r4:eeec5414
[ 155.319482] [c00577a0] (worker_thread) from [c005cc40]
(kthread+0xdc/0xf8)
[ 155.326765] r10: r9: r8: r7:c00577a0 r6:ee434380
r5:ee4441c0
[ 155.334713] r4: r3:
[ 155.338341] [c005cb64] (kthread) from [c000fc08]
(ret_from_fork+0x14/0x2c)
[ 155.345626] r7: r6: r5:c005cb64 r4:ee4441c0
[ 155.356108] ---[ end trace a58d34c223b190e6 ]---
[ 155.360783] xhci-hcd xhci-hcd.0.auto: Virt dev invalid for slot_id 0x1!
[ 155.574404] xhci-hcd xhci-hcd.0.auto: xhci_setup_device
[ 155.579667] [ cut here ]
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/host/xhci.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 9a7f12c..accfb14 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -3783,6 +3783,9 @@ static int xhci_setup_device(struct usb_hcd *hcd, struct
usb_device *udev,
mutex_lock(xhci-mutex);
+ if (xhci-xhc_state)/* dying or halted */
+ goto out;
+
if (!udev-slot_id) {
xhci_dbg_trace(xhci, trace_xhci_dbg_address,
Bad Slot ID %d, udev-slot_id);
--
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
[PATCH 3/5] usb: xhci: Clear XHCI_STATE_DYING on start
For whatever reason if XHCI died in the previous instant then it will never recover on the next xhci_start unless we clear the DYING flag. Signed-off-by: Roger Quadros rog...@ti.com --- drivers/usb/host/xhci.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index f998ddf..d5f44b1 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -146,7 +146,8 @@ static int xhci_start(struct xhci_hcd *xhci) waited %u microseconds.\n, XHCI_MAX_HALT_USEC); if (!ret) - xhci-xhc_state = ~XHCI_STATE_HALTED; + xhci-xhc_state = ~(XHCI_STATE_HALTED | XHCI_STATE_DYING); + return ret; } -- 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
[PATCH 4/5] usb: xhci: stop everything on the first call to xhci_stop
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;
+
/* Make sure the xHC is halted for a USB3 roothub
* (xhci_stop() could be called as part of failed init).
*/
--
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
On Mon, Aug 17, 2015 at 10:26:23AM -0700, Mark Brown wrote:
On Mon, Aug 17, 2015 at 09:07:08AM +0800, Peter Chen wrote:
On Fri, Aug 14, 2015 at 05:47:46PM +0800, Baolin Wang wrote:
+ 1500,
+ 1800,
+ 550,
+};
Why 550 is the last, but not 1800?
You'd have to ask the hardware engineers who designed the chip. I
suspect it's because 550 was added at a late stage in the design process
but I'm basically just guessing there.
ok, I just had suspected below function's correctness, after looking
it again, it always set 1800 as charging limit, does it be expected?
+/* In miliamps */
+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;
+}
+
*/
@@ -606,8 +646,31 @@ static int wm831x_power_probe(struct platform_device
*pdev)
}
}
+ if (wm831x_pdata wm831x_pdata-usb_gadget) {
Where the wm831x_pdata-usb_gadget is initialized?
It's platform data, it will be initialised by whatever registers the
platform data.
Get it, I just do not find in this patch set, 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
[PATCH 0/2] USB: serial: new device ids for 4.3-rc1
Greg, Do you want to pick these up as well? Otherwise, I'll just send them after rc1 is out. Thanks, Johan David Ward (1): USB: qcserial: add HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module Matthijs Kooijman (1): USB: ftdi_sio: Added custom PID for CustomWare products drivers/usb/serial/ftdi_sio.c | 4 drivers/usb/serial/ftdi_sio_ids.h | 8 drivers/usb/serial/qcserial.c | 1 + 3 files changed, 13 insertions(+) -- 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 1/2] USB: ftdi_sio: Added custom PID for CustomWare products
From: Matthijs Kooijman matth...@stdin.nl
CustomWare uses the FTDI VID with custom PIDs for their ShipModul MiniPlex
products.
Signed-off-by: Matthijs Kooijman matth...@stdin.nl
Cc: stable sta...@vger.kernel.org
Signed-off-by: Johan Hovold jo...@kernel.org
---
drivers/usb/serial/ftdi_sio.c | 4
drivers/usb/serial/ftdi_sio_ids.h | 8
2 files changed, 12 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index 4c8b3b82103d..a5a0376bbd48 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -605,6 +605,10 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(FTDI_VID, FTDI_NT_ORIONLXM_PID),
.driver_info = (kernel_ulong_t)ftdi_jtag_quirk },
{ USB_DEVICE(FTDI_VID, FTDI_SYNAPSE_SS200_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_CUSTOMWARE_MINIPLEX_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_CUSTOMWARE_MINIPLEX2_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_CUSTOMWARE_MINIPLEX2WI_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_CUSTOMWARE_MINIPLEX3_PID) },
/*
* ELV devices:
*/
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index 792e054126de..2943b97b2a83 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -568,6 +568,14 @@
*/
#define FTDI_SYNAPSE_SS200_PID 0x9090 /* SS200 - SNAP Stick 200 */
+/*
+ * CustomWare / ShipModul NMEA multiplexers product ids (FTDI_VID)
+ */
+#define FTDI_CUSTOMWARE_MINIPLEX_PID 0xfd48 /* MiniPlex first generation
NMEA Multiplexer */
+#define FTDI_CUSTOMWARE_MINIPLEX2_PID 0xfd49 /* MiniPlex-USB and MiniPlex-2
series */
+#define FTDI_CUSTOMWARE_MINIPLEX2WI_PID0xfd4a /* MiniPlex-2Wi */
+#define FTDI_CUSTOMWARE_MINIPLEX3_PID 0xfd4b /* MiniPlex-3 series */
+
//
/** third-party VID/PID combos **/
--
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 v2] usb: dwc2: reset dwc2 core before dwc2_get_hwparams()
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 | 6 ++
3 files changed, 8 insertions(+), 1 deletion(-)
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..8d3be4a 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -243,6 +243,12 @@ 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.
+*/
+ dwc2_core_reset(hsotg);
+
/* Detect config values from hardware */
retval = dwc2_get_hwparams(hsotg);
if (retval)
--
2.0.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
[PATCH 0/5] usb: xhci: Fix breakage on dual-role case
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. -- cheers, -roger Roger Quadros (5): usb: xhci: lock mutex on xhci_stop usb: hcd: Initialize hcd-flags to 0 usb: xhci: Clear XHCI_STATE_DYING on start usb: xhci: stop everything on the first call to xhci_stop usb: xhci: exit early in xhci_setup_device() if we're halted or dying drivers/usb/core/hcd.c | 1 + drivers/usb/host/xhci.c | 24 +++- 2 files changed, 12 insertions(+), 13 deletions(-) -- 2.1.4 kernel log during dual-role switch. Platform: am437x-gp-evm. Test case: Repeatedly plug and unplug a USB-OTG adapter to/from a dual role port (USB1 in this case) with Mass storage device attached to the adapter all the while. Adapter plugged [ 112.720322] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller [ 112.726209] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 3 [ 112.736919] xhci-hcd xhci-hcd.0.auto: hcc params 0x0238f06d hci version 0x100 quirks 0x00010010 [ 112.746162] xhci-hcd xhci-hcd.0.auto: irq 216, io mem 0x4839 [ 112.754717] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 [ 112.761815] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 112.769423] usb usb3: Product: xHCI Host Controller [ 112.774542] usb usb3: Manufacturer: Linux 4.2.0-rc6-00027-g26afc4a xhci-hcd [ 112.781805] usb usb3: SerialNumber: xhci-hcd.0.auto [ 112.791761] hub 3-0:1.0: USB hub found [ 112.796374] hub 3-0:1.0: 1 port detected [ 112.801893] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller [ 112.807786] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 4 [ 112.828676] usb usb4: We don't know the algorithms for LPM for this host, disabling LPM. [ 112.842572] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003 [ 112.849911] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 112.857537] usb usb4: Product: xHCI Host Controller [ 112.862640] usb usb4: Manufacturer: Linux 4.2.0-rc6-00027-g26afc4a xhci-hcd [ 112.869973] usb usb4: SerialNumber: xhci-hcd.0.auto [ 112.888053] hub 4-0:1.0: USB hub found [ 112.893454] hub 4-0:1.0: 1 port detected adapter unplugged [ 113.114023] usb 3-1: new high-speed USB device number 2 using xhci-hcd [ 113.254855] usb 3-1: New USB device found, idVendor=0781, idProduct=5539 [ 113.261863] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 113.269374] usb 3-1: Product: Cruzer Micro [ 113.273652] usb 3-1: Manufacturer: SanDisk [ 113.277953] usb 3-1: SerialNumber: 173733160C524A8E [ 113.288636] usb-storage 3-1:1.0: USB Mass Storage device detected [ 113.296663] scsi host7: usb-storage 3-1:1.0 [ 113.368620] xhci-hcd xhci-hcd.0.auto: remove, state 4 [ 113.374142] usb usb4: USB disconnect, device number 1 [ 113.382381] usb 3-1: USB disconnect, device number 2 [ 113.405815] xhci-hcd xhci-hcd.0.auto: USB bus 4 deregistered [ 113.411817] xhci-hcd xhci-hcd.0.auto: remove, state 1 [ 113.417278] usb usb3: USB disconnect, device number 1 [ 113.449219] xhci-hcd xhci-hcd.0.auto: USB bus 3 deregistered adapter plugged [ 116.540119] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller [ 116.545984] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 3 [ 116.555638] xhci-hcd xhci-hcd.0.auto: hcc params 0x0238f06d hci version 0x100 quirks 0x00010010 [ 116.564863] xhci-hcd xhci-hcd.0.auto: irq 216, io mem 0x4839 [ 116.571860] usb usb3: New USB device found, idVendor=1d6b, idProduct=0002 [ 116.579005] usb usb3: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [ 116.586567] usb usb3: Product: xHCI Host Controller [ 116.591655] usb usb3: Manufacturer: Linux 4.2.0-rc6-00027-g26afc4a xhci-hcd [ 116.598940] usb usb3: SerialNumber: xhci-hcd.0.auto [ 116.609018] hub 3-0:1.0: USB hub found [ 116.613451] hub 3-0:1.0: 1 port detected [ 116.619814] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller [ 116.625711] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 4 [ 116.646673] usb usb4: We don't
[PATCH 2/5] usb: hcd: Initialize hcd-flags to 0
When using the OTG/drd library we can call hcd_add/remove consecutively without and hcd_alloc so flags can be stale. If the HC dies due to whatever reason then without this patch we get the below error on next hcd_add. [ 91.494257] xhci-hcd xhci-hcd.0.auto: HC died; cleaning up [ 91.502068] hub 3-0:1.0: state 0 ports 1 chg evt [ 91.510240] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller [ 91.516940] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 4 [ 91.529745] usb usb4: We don't know the algorithms for LPM for this host, disabling LPM. [ 91.540637] usb usb4: New USB device found, idVendor=1d6b, idProduct=0003 [ 91.757865] irq 254: nobody cared (try booting with the irqpoll option) [ 91.757880] CPU: 0 PID: 68 Comm: kworker/u2:2 Not tainted 4.1.4-00828-g1f0ed8c-dirty #44 [ 91.757885] Hardware name: Generic AM43 (Flattened Device Tree) [ 91.757914] Workqueue: usb_otg usb_otg_work [ 91.757921] Backtrace: [ 91.757954] [c0012af0] (dump_backtrace) from [c0012c8c] (show_stack+0x18/0x1c) [ 91.757972] r6:c089d4a4 r5: r4: r3:ee44 [ 91.757991] [c0012c74] (show_stack) from [c05f7c14] (dump_stack+0x84/0xd0) [ 91.758008] [c05f7b90] (dump_stack) from [c0084b30] (__report_bad_irq+0x28/0xc8) [ 91.758024] r7: r6:00fe r5: r4:ee514c40 [ 91.758037] [c0084b08] (__report_bad_irq) from [c00850b0] (note_interrupt+0x24c/0x2ac) [ 91.758052] r6:00fe r5: r4:ee514c40 r3: [ 91.758065] [c0084e64] (note_interrupt) from [c00828fc] (handle_irq_event_percpu+0xb0/0x158) [ 91.758085] r10:ee514c40 r9:c08ce49a r8:00fe r7: r6: r5: [ 91.758094] r4: r3: [ 91.758105] [c008284c] (handle_irq_event_percpu) from [c00829e8] (handle_irq_event+0x44/0x64) [ 91.758126] r10:0001 r9:ee441ab0 r8:ee441bb8 r7:c0858b4c r6:ed174280 r5:ee514ca0 [ 91.758132] r4:ee514c40 [ 91.758144] [c00829a4] (handle_irq_event) from [c0085970] (handle_fasteoi_irq+0x100/0x1bc) [ 91.758159] r6:c085dba0 r5:ee514ca0 r4:ee514c40 r3: [ 91.758171] [c0085870] (handle_fasteoi_irq) from [c0082058] (generic_handle_irq+0x28/0x38) [ 91.758186] r7:c0853d40 r6:c0858b4c r5:00fe r4:00fe [ 91.758197] [c0082030] (generic_handle_irq) from [c00821c0] (__handle_domain_irq+0x98/0x12c) [ 91.758207] r4:c0853d40 r3:0100 [ 91.758219] [c0082128] (__handle_domain_irq) from [c00094e0] (gic_handle_irq+0x28/0x68) [ 91.758239] r10:0001 r9:ee441bb8 r8:fa240100 r7:c0858d70 r6:ee441ab0 r5:00b8 [ 91.758245] r4:fa24010c [ 91.758264] [c00094b8] (gic_handle_irq) from [c05fd540] (__irq_svc+0x40/0x74) [ 91.758271] Exception stack(0xee441ab0 to 0xee441af8) [ 91.758280] 1aa0: c08d2980 ee441ac0 [ 91.758292] 1ac0: 0008 0089 c0858b4c c0858080 ee441bb8 0001 ee441b3c [ 91.758301] 1ae0: 0101 ee441af8 c02fc418 c0046a1c 2113 [ 91.758321] r8: r7:ee441ae4 r6: r5:2113 r4:c0046a1c r3:c02fc418 [ 91.758347] [c00469a0] (__do_softirq) from [c0046eac] (irq_exit+0xb8/0x104) [ 91.758367] r10:0001 r9:ee441bb8 r8: r7:c0853d40 r6:c0858b4c r5:0089 [ 91.758373] r4: [ 91.758386] [c0046df4] (irq_exit) from [c00821c8] (__handle_domain_irq+0xa0/0x12c) [ 91.758395] r4: r3:0100 [ 91.758406] [c0082128] (__handle_domain_irq) from [c00094e0] (gic_handle_irq+0x28/0x68) [ 91.758426] r10:c08e3510 r9:2013 r8:fa240100 r7:c0858d70 r6:ee441bb8 r5:0039 [ 91.758433] r4:fa24010c [ 91.758445] [c00094b8] (gic_handle_irq) from [c05fd540] (__irq_svc+0x40/0x74) [ 91.758450] Exception stack(0xee441bb8 to 0xee441c00) [ 91.758457] 1ba0: 0001 [ 91.758468] 1bc0: ee44 c08e2524 004d 0274 2013 [ 91.758479] 1be0: c08e3510 ee441c4c ee441b60 ee441c00 c03acfec c0080d4c 6013 [ 91.758499] r8: r7:ee441bec r6: r5:6013 r4:c0080d4c r3:c03acfec [ 91.758524] [c0080950] (console_unlock) from [c0081670] (vprintk_emit+0x20c/0x500) [ 91.758544] r10:ee441cc0 r9:c08d3550 r8:c08e3ea0 r7: r6:0001 r5:003d [ 91.758551] r4:c08d3550 [ 91.758573] [c0081464] (vprintk_emit) from [c03f6f70] (dev_vprintk_emit+0x104/0x1ac) [ 91.758593] r10:ee441d8c r9:000e r8:c07951e0 r7:0006 r6:ee441cc0 r5:000d [ 91.758599] r4:ee731068 [ 91.758612] [c03f6e6c] (dev_vprintk_emit) from [c03f7040] (dev_printk_emit+0x28/0x30) [ 91.758632] r10:0001 r9:ee5f8410 r8:ee731000 r7:ed429000 r6:0006 r5:ee441dc0 [ 91.758638] r4:ee731068 [ 91.758651] [c03f701c] (dev_printk_emit) from [c03f7098] (__dev_printk+0x50/0x70) [ 91.758660] r3:bf2268cc r2:c07951e0 [ 91.758673] [c03f7048] (__dev_printk) from [c03f70f4] (_dev_info+0x3c/0x48) [ 91.758686]
[PATCH 1/5] usb: xhci: lock mutex on xhci_stop
Else it races with xhci_setup_device
Signed-off-by: Roger Quadros rog...@ti.com
---
drivers/usb/host/xhci.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 526ebc0..f998ddf 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -677,8 +677,11 @@ 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);
return;
}
@@ -717,6 +720,7 @@ void xhci_stop(struct usb_hcd *hcd)
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
xhci_stop completed - status = %x,
readl(xhci-op_regs-status));
+ mutex_unlock(xhci-mutex);
}
/*
--
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 v1 1/3] usb: dwc2: reset AHB hclk domain before init
Hi John, 在 2015/8/15 3:41, John Youn 写道: On 8/13/2015 8:29 PM, Yunzhi Li wrote: 在 2015/8/14 8:09, John Youn 写道: On 8/11/2015 12:57 AM, Yunzhi Li wrote: We initiate dwc2 usb controller in BIOS, when kernel driver start-up we should reset AHB hclk domain to reset all AHB interface registers to default. Without this the FIFO value setting might be incorrect because calculating FIFO size need the 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. .. I didn't receive the other two patches in this series so I was confused about where the ahb_reset was coming from when I replied to your other patch. I see you changed the name and documented the DT so never mind. Another thing is that there probably shouldn't be a debug message on the IS_ERR condition since that is the common case and of no interest to other platforms. The other two resets you added aren't used by the driver anywhere right? Maybe those should be left out until they are. John Hi John , Here is the other two patches : https://patchwork.kernel.org/patch/6989541/ https://patchwork.kernel.org/patch/6989531/ ahb_reset is hreset_n signal of dwc2 IP. Our rk3288 SoC implement connect this signal to a special register in clock ang reset unit (CRU) module, set this register will reset dwc2 control and status registers(CSR) to default value. You could find more info in DesignWare Cores USB 2.0 Hi Speed On-TheGo (OTG) Databook 3.10a 4.4.1 System Clock and Reset Signals. Our problem is that dwc2_get_hwparams() reads fifo size registers and reguards it as the power-on reset value, then dwc2_set_param_host_perio_tx_fifo_size() will check this value and make sure the new fifo size value is no bigger than the power-on reset value. But we init and set these fifo registers in BIOS, so here hw-xxx_fifo_size is not the real power-on reset vaule. So we hope to reset CSR before dwc2_get_hwparams(). I have another ideal: we might use GRSTCTL.CSftRst instead of hreset_n to reset dwc2 CSR. Yes, please try doing that before calling dwc2_get_hwparams(). Maybe by calling dwc2_core_reset(). If that works for you, I think it would be better. John It works and please help review the new patch. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: phy: msm: Unregister driver interest for VBUS and ID events
Right now even if driver failed to probe extcon framework will
still deliver its VBUS and ID events, which will lead to random
exception codes.
Fix this by removing driver interest for VBUS and ID events when
probe fail.
Fixes: 591fc116f330 (usb: phy: msm: Use extcon framework for VBUS and ID
detection)
Reported-by: Tim Bird tim.b...@sonymobile.com
Signed-off-by: Ivan T. Ivanov ivan.iva...@linaro.org
---
drivers/usb/phy/phy-msm-usb.c | 26 +-
1 file changed, 17 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 00c49bb1bd29..a9082567f114 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -1581,6 +1581,8 @@ static int msm_otg_read_dt(struct platform_device *pdev,
struct msm_otg *motg)
ret = extcon_register_interest(motg-id.conn, ext_id-name,
USB-HOST, motg-id.nb);
if (ret 0) {
+ if (!IS_ERR(ext_vbus))
+ extcon_unregister_interest(motg-vbus.conn);
dev_err(pdev-dev, register ID notifier failed\n);
return ret;
}
@@ -1630,15 +1632,6 @@ static int msm_otg_probe(struct platform_device *pdev)
if (!motg)
return -ENOMEM;
- pdata = dev_get_platdata(pdev-dev);
- if (!pdata) {
- if (!np)
- return -ENXIO;
- ret = msm_otg_read_dt(pdev, motg);
- if (ret)
- return ret;
- }
-
motg-phy.otg = devm_kzalloc(pdev-dev, sizeof(struct usb_otg),
GFP_KERNEL);
if (!motg-phy.otg)
@@ -1709,6 +1702,15 @@ static int msm_otg_probe(struct platform_device *pdev)
if (ret)
return ret;
+ pdata = dev_get_platdata(pdev-dev);
+ if (!pdata) {
+ if (!np)
+ return -ENXIO;
+ ret = msm_otg_read_dt(pdev, motg);
+ if (ret)
+ return ret;
+ }
+
motg-vddcx = regs[0].consumer;
motg-v3p3 = regs[1].consumer;
motg-v1p8 = regs[2].consumer;
@@ -1793,6 +1795,12 @@ disable_clks:
clk_disable_unprepare(motg-clk);
if (!IS_ERR(motg-core_clk))
clk_disable_unprepare(motg-core_clk);
+
+ if (motg-id.conn.edev)
+ extcon_unregister_interest(motg-id.conn);
+ if (motg-vbus.conn.edev)
+ extcon_unregister_interest(motg-vbus.conn);
+
return ret;
}
--
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] usb: Move xhci_pme_quirk() behind an #ifdef CONFIG_PM, as it is not used when it's not defined
Signed-off-by: Tomer Barletz barl...@gmail.com
---
drivers/usb/host/xhci-pci.c | 90 ++---
1 file changed, 45 insertions(+), 45 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 5590eac..c79d336 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -180,51 +180,6 @@ static void xhci_pci_quirks(struct device *dev, struct
xhci_hcd *xhci)
QUIRK: Resetting on resume);
}
-/*
- * In some Intel xHCI controllers, in order to get D3 working,
- * through a vendor specific SSIC CONFIG register at offset 0x883c,
- * SSIC PORT need to be marked as unused before putting xHCI
- * into D3. After D3 exit, the SSIC port need to be marked as used.
- * Without this change, xHCI might not enter D3 state.
- * Make sure PME works on some Intel xHCI controllers by writing 1 to clear
- * the Internal PME flag bit in vendor specific PMCTRL register at offset
0x80a4
- */
-static void xhci_pme_quirk(struct usb_hcd *hcd, bool suspend)
-{
- struct xhci_hcd *xhci = hcd_to_xhci(hcd);
- struct pci_dev *pdev = to_pci_dev(hcd-self.controller);
- u32 val;
- void __iomem *reg;
-
- if (pdev-vendor == PCI_VENDOR_ID_INTEL
-pdev-device == PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI) {
-
- reg = (void __iomem *) xhci-cap_regs + PORT2_SSIC_CONFIG_REG2;
-
- /* Notify SSIC that SSIC profile programming is not done */
- val = readl(reg) ~PROG_DONE;
- writel(val, reg);
-
- /* Mark SSIC port as unused(suspend) or used(resume) */
- val = readl(reg);
- if (suspend)
- val |= SSIC_PORT_UNUSED;
- else
- val = ~SSIC_PORT_UNUSED;
- writel(val, reg);
-
- /* Notify SSIC that SSIC profile programming is done */
- val = readl(reg) | PROG_DONE;
- writel(val, reg);
- readl(reg);
- }
-
- reg = (void __iomem *) xhci-cap_regs + 0x80a4;
- val = readl(reg);
- writel(val | BIT(28), reg);
- readl(reg);
-}
-
#ifdef CONFIG_ACPI
static void xhci_pme_acpi_rtd3_enable(struct pci_dev *dev)
{
@@ -345,6 +300,51 @@ static void xhci_pci_remove(struct pci_dev *dev)
}
#ifdef CONFIG_PM
+/*
+ * In some Intel xHCI controllers, in order to get D3 working,
+ * through a vendor specific SSIC CONFIG register at offset 0x883c,
+ * SSIC PORT need to be marked as unused before putting xHCI
+ * into D3. After D3 exit, the SSIC port need to be marked as used.
+ * Without this change, xHCI might not enter D3 state.
+ * Make sure PME works on some Intel xHCI controllers by writing 1 to clear
+ * the Internal PME flag bit in vendor specific PMCTRL register at offset
0x80a4
+ */
+static void xhci_pme_quirk(struct usb_hcd *hcd, bool suspend)
+{
+ struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+ struct pci_dev *pdev = to_pci_dev(hcd-self.controller);
+ u32 val;
+ void __iomem *reg;
+
+ if (pdev-vendor == PCI_VENDOR_ID_INTEL
+pdev-device == PCI_DEVICE_ID_INTEL_CHERRYVIEW_XHCI) {
+
+ reg = (void __iomem *) xhci-cap_regs + PORT2_SSIC_CONFIG_REG2;
+
+ /* Notify SSIC that SSIC profile programming is not done */
+ val = readl(reg) ~PROG_DONE;
+ writel(val, reg);
+
+ /* Mark SSIC port as unused(suspend) or used(resume) */
+ val = readl(reg);
+ if (suspend)
+ val |= SSIC_PORT_UNUSED;
+ else
+ val = ~SSIC_PORT_UNUSED;
+ writel(val, reg);
+
+ /* Notify SSIC that SSIC profile programming is done */
+ val = readl(reg) | PROG_DONE;
+ writel(val, reg);
+ readl(reg);
+ }
+
+ reg = (void __iomem *) xhci-cap_regs + 0x80a4;
+ val = readl(reg);
+ writel(val | BIT(28), reg);
+ readl(reg);
+}
+
static int xhci_pci_suspend(struct usb_hcd *hcd, bool do_wakeup)
{
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
--
2.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] USB: qcserial: add HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module
From: David Ward david.w...@ll.mit.edu
This is an HP-branded Sierra Wireless EM7355:
https://bugzilla.redhat.com/show_bug.cgi?id=1223646#c2
Signed-off-by: David Ward david.w...@ll.mit.edu
Cc: stable sta...@vger.kernel.org
Signed-off-by: Johan Hovold jo...@kernel.org
---
drivers/usb/serial/qcserial.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/serial/qcserial.c b/drivers/usb/serial/qcserial.c
index d156545728c2..ebcec8cda858 100644
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -139,6 +139,7 @@ static const struct usb_device_id id_table[] = {
{USB_DEVICE(0x0AF0, 0x8120)}, /* Option GTM681W */
/* non-Gobi Sierra Wireless devices */
+ {DEVICE_SWI(0x03f0, 0x4e1d)}, /* HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G
Module */
{DEVICE_SWI(0x0f3d, 0x68a2)}, /* Sierra Wireless MC7700 */
{DEVICE_SWI(0x114f, 0x68a2)}, /* Sierra Wireless MC7750 */
{DEVICE_SWI(0x1199, 0x68a2)}, /* Sierra Wireless MC7710 */
--
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
Re: repeat... Re: BUG: usb: phy: msm: problem with EPROBE defer and extcon cleanup
On Mon, 2015-08-17 at 16:46 -0700, Tim Bird wrote: Sorry - I mistyped Ivan's e-mail the first time. On 08/17/2015 04:43 PM, Tim Bird wrote: Ivan, I'm seeing a bug in the phy-msm-usb.c code, when I get an EPROBE defer during probing the driver. The code is statically linked in the kernel, and the dts for my board is specifying an extcon phandle for the ID pin. Below is a fragment of the kernel output for a boot of this code. Messages prefixed with TRB are my own debug printks. Note that the notifier block (at ee23513c) that gets registered with extcon before the first probe failure, ultimately gets used during an ID pin event (status change) by raw_notifier_call_chain(). This notifier block should be unregistered if the probe fails, so that only the second one registered is on the call chain. Right, I have missed to send one patch, sorry. Please, could you try this one [1]. Regards, Ivan [1] https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg957405.html -- 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: Stack dump when try to store uframe_periodic_max
On Mon, Aug 17, 2015 at 12:04:07PM -0400, Alan Stern wrote: On Mon, 17 Aug 2015, Peter Zijlstra wrote: On Mon, Aug 17, 2015 at 10:32:20AM -0400, Alan Stern wrote: On Mon, 17 Aug 2015, Peter Chen wrote: Hi Alan, When run echo 105 /sys/bus/platform/devices/ci_hdrc.1/uframe_periodic_max, if lockdep check is enabled, there is below dump, I am afraid it can't find how to fix it, the warning shows the key is not persistent. (see line 757, kernel/locking/lockdep.c). [ 70.190430] INFO: trying to register non-static key. [ 70.195437] the code is fine but needs lockdep annotation. [ 70.200939] turning off the locking correctness validator. I don't understand this either. Maybe Peter Z. can help. This dump is triggered by the spin_lock_irqsave() call in drivers/usb/host/ehci-sysfs.c:store_uframe_periodic_max(). That function doesn't appear to be unusual in any way. Can it happen this code is called before a corresponding spin_lock_init()? No; the spinlock gets initialized in ehci_init() long before the sysfs file is registered. Alternatively, memory corruption is an option. If something stomped on the lockdep state you can trigger this I suppose. oops, sorry, it is memory corruption. The chipidea driver overrides platform device's drvdata as its private data (struct ci_hdrc *), this data was expected as struct usb_hcd * at store_uframe_periodic_max. -- 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
[PATCH v3 3/3] 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
---
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..72c661f 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 miliamps */
+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:
+ usb_charger_put(power-usb_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);
+ usb_charger_put(wm831x_power-usb_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 this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo
Re: [PATCH 4/5] usb: xhci: stop everything on the first call to xhci_stop
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.
Applied
-Mathias
--
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: Re: Re: [PATCH v4]USB:OHCI: BugFix:Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
Hi Greg What tree are you making it against? I made it for 4.2-rc6. I need it made against linux-next please. Thanks for information. I will make patch against latest linux-next tree (18 Aug). Thanks Regards, Aman Deep --- Original Message --- Sender : Greg KHgre...@linuxfoundation.org Date : Aug 17, 2015 09:57 (GMT+06:00) Title : Re: Re: [PATCH v4]USB:OHCI: BugFix:Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks() On Mon, Aug 17, 2015 at 03:30:11AM +, AMAN DEEP wrote: This still does not apply properly :( Sorry for inconveince. What tree are you making it against? I made it for 4.2-rc6. I need it made against linux-next please. thanks, greg k-h Thanks Regards, Aman Deep
Re: MUSB dual-role on AM335x behaving weirdly
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). 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: [PATCH 1/5] usb: xhci: lock mutex on xhci_stop
On 18.08.2015 13:39, Roger Quadros wrote: Else it races with xhci_setup_device Signed-off-by: Roger Quadros rog...@ti.com --- Thanks. Applied, will send forward after 4.3-rc1 -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] usb: xhci: Clear XHCI_STATE_DYING on start
On 18.08.2015 13:39, Roger Quadros wrote: For whatever reason if XHCI died in the previous instant then it will never recover on the next xhci_start unless we clear the DYING flag. Signed-off-by: Roger Quadros rog...@ti.com --- drivers/usb/host/xhci.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c index f998ddf..d5f44b1 100644 --- a/drivers/usb/host/xhci.c +++ b/drivers/usb/host/xhci.c @@ -146,7 +146,8 @@ static int xhci_start(struct xhci_hcd *xhci) waited %u microseconds.\n, XHCI_MAX_HALT_USEC); if (!ret) - xhci-xhc_state = ~XHCI_STATE_HALTED; + xhci-xhc_state = ~(XHCI_STATE_HALTED | XHCI_STATE_DYING); + return ret; } Thanks, applied -Mathias -- 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 3/3] power: wm831x_power: Support USB charger current limit management
On Tue, 18 Aug 2015, Baolin Wang wrote:
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
---
drivers/power/wm831x_power.c | 69
++
include/linux/mfd/wm831x/pdata.h |3 ++
MFD:
Acked-by: Lee Jones lee.jo...@linaro.org
2 files changed, 72 insertions(+)
diff --git a/drivers/power/wm831x_power.c b/drivers/power/wm831x_power.c
index db11ae6..72c661f 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 miliamps */
+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:
+ usb_charger_put(power-usb_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);
+ usb_charger_put(wm831x_power-usb_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];
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Re: [PATCH 5/5] usb: xhci: exit early in xhci_setup_device() if we're halted or dying
On 18.08.2015 13:39, Roger Quadros wrote: During quick plug/removal of OTG adapter during dual-role testing it can happen that xhci_alloc_device() is called for the newly detected device after the DRD library has called xhci_stop to remove the HCD. If that is the case, just fail early to prevent the following warning. Thanks, applied -Mathias -- 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 2/3] gadget: Introduce the usb charger framework
This patch introduces the usb charger driver based on usb gadget that
makes an enhancement to a power driver. It works well in practice but
that requires a system with suitable hardware.
The basic conception of the usb charger is that, when one usb charger
is added or removed by reporting from the usb gadget state change or
the extcon device state change, the usb charger will report to power
user to set the current limitation.
The usb charger will register notifiees on the usb gadget or the extcon
device to get notified the usb charger state.
Power user will register a notifiee on the usb charger to get notified
by status changes from the usb charger. It will report to power user
to set the current limitation when detecting the usb charger is added
or removed from extcon device state or usb gadget state.
Signed-off-by: Baolin Wang baolin.w...@linaro.org
---
drivers/usb/gadget/Kconfig |7 +
drivers/usb/gadget/Makefile |1 +
drivers/usb/gadget/charger.c| 538 +++
include/linux/usb/usb_charger.h | 138 ++
4 files changed, 684 insertions(+)
create mode 100644 drivers/usb/gadget/charger.c
create mode 100644 include/linux/usb/usb_charger.h
diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index bcf83c0..3d2b959 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -127,6 +127,13 @@ config USB_GADGET_STORAGE_NUM_BUFFERS
a module parameter as well.
If unsure, say 2.
+config USB_CHARGER
+ bool USB charger support
+ help
+ The usb charger driver based on the usb gadget that makes an
+ enhancement to a power driver which can set the current limitation
+ when the usb charger is added or removed.
+
source drivers/usb/gadget/udc/Kconfig
#
diff --git a/drivers/usb/gadget/Makefile b/drivers/usb/gadget/Makefile
index 598a67d..1e421c1 100644
--- a/drivers/usb/gadget/Makefile
+++ b/drivers/usb/gadget/Makefile
@@ -10,3 +10,4 @@ libcomposite-y:= usbstring.o config.o
epautoconf.o
libcomposite-y += composite.o functions.o configfs.o u_f.o
obj-$(CONFIG_USB_GADGET) += udc/ function/ legacy/
+obj-$(CONFIG_USB_CHARGER) += charger.o
diff --git a/drivers/usb/gadget/charger.c b/drivers/usb/gadget/charger.c
new file mode 100644
index 000..93fd36f
--- /dev/null
+++ b/drivers/usb/gadget/charger.c
@@ -0,0 +1,538 @@
+/*
+ * charger.c -- USB charger driver
+ *
+ * Copyright (C) 2015 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/device.h
+#include linux/err.h
+#include linux/extcon.h
+#include linux/export.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/of_address.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/usb.h
+#include linux/usb/ch9.h
+#include linux/usb/gadget.h
+#include linux/usb/usb_charger.h
+
+#define DEFAULT_CUR_PROTECT(50)
+#define DEFAULT_SDP_CUR_LIMIT (500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_DCP_CUR_LIMIT (1500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_CDP_CUR_LIMIT (1500 - DEFAULT_CUR_PROTECT)
+#define DEFAULT_ACA_CUR_LIMIT (1500 - DEFAULT_CUR_PROTECT)
+
+static DEFINE_IDA(usb_charger_ida);
+static struct bus_type usb_charger_subsys = {
+ .name = usb-charger,
+ .dev_name = usb-charger,
+};
+
+static struct usb_charger *dev_to_uchger(struct device *udev)
+{
+ return container_of(udev, struct usb_charger, dev);
+}
+
+static ssize_t cur_limit_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct usb_charger *uchger = dev_to_uchger(dev);
+
+ return scnprintf(buf, PAGE_SIZE, %d %d %d %d\n,
+uchger-cur_limit.sdp_cur_limit,
+uchger-cur_limit.dcp_cur_limit,
+uchger-cur_limit.cdp_cur_limit,
+uchger-cur_limit.aca_cur_limit);
+}
+
+static ssize_t cur_limit_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct usb_charger *uchger = dev_to_uchger(dev);
+ struct usb_charger_cur_limit cur;
+ int ret;
+
+ ret = sscanf(buf, %d %d %d %d,
+cur.sdp_cur_limit, cur.dcp_cur_limit,
+cur.cdp_cur_limit, cur.aca_cur_limit);
+ if (ret == 0)
+ return -EINVAL;
+
+ ret = usb_charger_set_cur_limit(uchger, cur);
+ if (ret 0)
+ return ret;
+
+ return count;
+}
+static DEVICE_ATTR_RW(cur_limit);
+
+static struct attribute *usb_charger_attrs[] = {
+ dev_attr_cur_limit.attr,
+ NULL
+};
[PATCH v3 0/3] Introduce usb charger framework to deal with the usb gadget power negotation
Currently the Linux kernel does not provide any standard integration of this feature that integrates the USB subsystem with the system power regulation provided by PMICs meaning that either vendors must add this in their kernels or USB gadget devices based on Linux (such as mobile phones) may not behave as they should. Providing a standard framework for doing this in the kernel. Now introduce one user with wm831x_power to support and test the usb charger, which is pending testing. Moreover there may be other potential users will use it in future. Changes since v2: - Use macro DEVICE_ATTR_RW()/ATTRIBUTE_GROUPS() and change the method to register the attruibutes. - Remove the 'name' and 'entry' member of struct 'usb_charger'. - Replace devm_kzalloc() with kzalloc() to follow the the lifetime rules. - Other modifications. Baolin Wang (3): gadget: Support for the usb charger framework gadget: Introduce the usb charger framework power: wm831x_power: Support USB charger current limit management drivers/power/wm831x_power.c | 69 + drivers/usb/gadget/Kconfig|7 + drivers/usb/gadget/Makefile |1 + drivers/usb/gadget/charger.c | 538 + drivers/usb/gadget/udc/udc-core.c | 41 ++- include/linux/mfd/wm831x/pdata.h |3 + include/linux/usb/gadget.h| 20 ++ include/linux/usb/usb_charger.h | 138 ++ 8 files changed, 816 insertions(+), 1 deletion(-) create mode 100644 drivers/usb/gadget/charger.c create mode 100644 include/linux/usb/usb_charger.h -- 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 v3 1/3] gadget: Support for the usb charger framework
The usb charger framework is based on usb gadget, and each usb gadget
can be one usb charger to set the current limitation.
This patch adds a notifier mechanism for usb charger to report to usb
charger when the usb gadget state is changed.
Also we 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 | 41 -
include/linux/usb/gadget.h| 20 ++
2 files changed, 60 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/gadget/udc/udc-core.c
b/drivers/usb/gadget/udc/udc-core.c
index f660afb..1971218 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
@@ -129,6 +130,32 @@ void usb_gadget_giveback_request(struct usb_ep *ep,
}
EXPORT_SYMBOL_GPL(usb_gadget_giveback_request);
+int usb_gadget_register_notify(struct usb_gadget *gadget,
+ struct notifier_block *nb)
+{
+ int ret;
+
+ mutex_lock(gadget-lock);
+ ret = raw_notifier_chain_register(gadget-nh, nb);
+ mutex_unlock(gadget-lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(usb_gadget_register_notify);
+
+int usb_gadget_unregister_notify(struct usb_gadget *gadget,
+struct notifier_block *nb)
+{
+ int ret;
+
+ mutex_lock(gadget-lock);
+ ret = raw_notifier_chain_unregister(gadget-nh, nb);
+ mutex_unlock(gadget-lock);
+
+ return ret;
+}
+EXPORT_SYMBOL_GPL(usb_gadget_unregister_notify);
+
/* - */
/**
@@ -226,6 +253,10 @@ static void usb_gadget_state_work(struct work_struct *work)
struct usb_gadget *gadget = work_to_gadget(work);
struct usb_udc *udc = gadget-udc;
+ mutex_lock(gadget-lock);
+ raw_notifier_call_chain(gadget-nh, gadget-state, gadget);
+ mutex_unlock(gadget-lock);
+
if (udc)
sysfs_notify(udc-dev.kobj, NULL, state);
}
@@ -364,6 +395,8 @@ int usb_add_gadget_udc_release(struct device *parent,
struct usb_gadget *gadget,
dev_set_name(gadget-dev, gadget);
INIT_WORK(gadget-work, usb_gadget_state_work);
+ RAW_INIT_NOTIFIER_HEAD(gadget-nh);
+ mutex_init(gadget-lock);
gadget-dev.parent = parent;
#ifdef CONFIG_HAS_DMA
@@ -405,8 +438,13 @@ int usb_add_gadget_udc_release(struct device *parent,
struct usb_gadget *gadget,
mutex_unlock(udc_lock);
- return 0;
+ 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);
@@ -481,6 +519,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 c14a69b..78cc862 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 *);
};
/**
@@ -609,6 +610,9 @@ struct usb_gadget {
unsignedout_epnum;
unsignedin_epnum;
struct usb_otg_caps *otg_caps;
+ struct raw_notifier_headnh;
+ struct usb_charger *uchger;
+ struct mutexlock;
unsignedsg_supported:1;
unsignedis_otg:1;
@@ -1183,6 +1187,22 @@ extern void usb_gadget_unmap_request(struct usb_gadget
*gadget,
/*-*/
+/**
+ * Register a notifiee to get notified by any attach status changes from
+ * the usb gadget
+ */
+int usb_gadget_register_notify(struct usb_gadget *gadget,
+ struct notifier_block *nb);
+
+/*-*/
+
+
+/* Unregister a notifiee from the usb gadget */
+int usb_gadget_unregister_notify(struct usb_gadget *gadget,
+struct notifier_block *nb);
+
+/*-*/
+
/* utility to set gadget state properly
[PATCH v5]USB:OHCI: BugFix:Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
There is a race condition between
finish_unlinks-finish_urb() function and
usb_kill_urb() in ohci controller case. The finish_urb
calls spin_unlock(ohci-lock) before
usb_hcd_giveback_urb() function call, then if during
this time, usb_kill_urb is called for another endpoint,
then new ed will be added to ed_rm_list at beginning
for unlink. and ed_rm_list will point to newly added
ed.
When finish_urb() is completed in finish_unlinks() and
ed-td_list becomes empty as in below code (in finish_unlinks() function)
if (list_empty(ed-td_list)) {
*last = ed-ed_next;
ed-ed_next = NULL;
} else if (ohci-rh_state == OHCI_RH_RUNNING) {
*last = ed-ed_next;
ed-ed_next = NULL;
ed_schedule(ohci, ed);
}
*last = ed-ed_next will make ed_rm_list to point to ed-ed_next and
previously added ed by usb_kill_urb will be left unreferenced by
ed_rm_list. This causes usb_kill_urb() hang forever waiting for
finish_unlink to remove added ed from ed_rm_list.
The main reason for hang in this race condtion is addition and removal
of ed from ed_rm_list in the beginning during usb_kill_urb and later last*
is modified in finish_unlinks().
As suggested by Alan Stern, the solution for proper handling of
ohci-ed_rm_list is to remove ed from the ed_rm_list before finishing
any URBs. Then at the end, we can add ed back to the list if necessary.
This properly handle the updated ohci-ed_rm_list in
usb_kill_urb().
Fixes:977dcfdc6031(USB:OHCI:don't lose track of EDs when a
controller dies)
Acked-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Aman Deep aman.d...@samsung.com
CC: sta...@vger.kernel.org
---
drivers/usb/host/ohci-q.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/host/ohci-q.c b/drivers/usb/host/ohci-q.c
index d029bbe..da878f3 100644
--- a/drivers/usb/host/ohci-q.c
+++ b/drivers/usb/host/ohci-q.c
@@ -1017,6 +1017,8 @@ skip_ed:
* have modified this list. normally it's just prepending
* entries (which we'd ignore), but paranoia won't hurt.
*/
+ *last = ed-ed_next;
+ ed-ed_next = NULL;
modified = 0;
/* unlink urbs as requested, but rescan the list after
@@ -1075,21 +1077,22 @@ rescan_this:
goto rescan_this;
/*
-* If no TDs are queued, take ED off the ed_rm_list.
+* If no TDs are queued, ED is now idle.
* Otherwise, if the HC is running, reschedule.
-* If not, leave it on the list for further dequeues.
+* If the HC isn't running, add ED back to the
+* start of the list for later processing.
*/
if (list_empty(ed-td_list)) {
- *last = ed-ed_next;
- ed-ed_next = NULL;
ed-state = ED_IDLE;
list_del(ed-in_use_list);
} else if (ohci-rh_state == OHCI_RH_RUNNING) {
- *last = ed-ed_next;
- ed-ed_next = NULL;
ed_schedule(ohci, ed);
} else {
- last = ed-ed_next;
+ ed-ed_next = ohci-ed_rm_list;
+ ohci-ed_rm_list = ed;
+ /* Don't loop on the same ED */
+ if (last == ohci-ed_rm_list)
+ last = ed-ed_next;
}
if (modified)
--
1.7.9.5
[PATCH v3 1/1] USB:option:add ZTE PIDs
This is intended to add ZTE device PIDs on kernel.
Signed-off-by: Liu.Zhao lzsos...@163.com
---
drivers/usb/serial/option.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 876423b..c17004b 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -278,13 +278,17 @@ static void option_instat_callback(struct urb *urb);
#define ZTE_PRODUCT_MF622 0x0001
#define ZTE_PRODUCT_MF628 0x0015
#define ZTE_PRODUCT_MF626 0x0031
+#define ZTE_PRODUCT_ZM8620_X 0x0396
+#define ZTE_PRODUCT_ME3620_MBIM0x0426
+#define ZTE_PRODUCT_ME3620_X 0x1432
+#define ZTE_PRODUCT_ME3620_L 0x1433
+#define ZTE_PRODUCT_MC2718 0xffe8
+#define ZTE_PRODUCT_AD3812 0xffeb
+#define ZTE_PRODUCT_MC2716 0xffed
#define ZTE_PRODUCT_AC2726 0xfff1
#define ZTE_PRODUCT_MG880 0xfffd
#define ZTE_PRODUCT_CDMA_TECH 0xfffe
#define ZTE_PRODUCT_AC8710T0x
-#define ZTE_PRODUCT_MC2718 0xffe8
-#define ZTE_PRODUCT_AD3812 0xffeb
-#define ZTE_PRODUCT_MC2716 0xffed
#define BENQ_VENDOR_ID 0x04a5
#define BENQ_PRODUCT_H10 0x4068
@@ -544,6 +548,14 @@ static const struct option_blacklist_info
zte_mc2716_z_blacklist = {
.sendsetup = BIT(1) | BIT(2) | BIT(3),
};
+static const struct option_blacklist_info zte_me3620andzm8620_xl_blacklist = {
+ .reserved = BIT(3) | BIT(4) | BIT(5),
+};
+
+static const struct option_blacklist_info zte_me3620_mbim_blacklist = {
+ .reserved = BIT(2) | BIT(3) | BIT(4),
+};
+
static const struct option_blacklist_info huawei_cdc12_blacklist = {
.reserved = BIT(1) | BIT(2),
};
@@ -1099,8 +,6 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */
{ USB_DEVICE_INTERFACE_CLASS(SIERRA_VENDOR_ID, 0x68c0, 0xff),
.driver_info = (kernel_ulong_t)sierra_mc73xx_blacklist }, /* MC73xx
*/
- { USB_DEVICE_INTERFACE_CLASS(SIERRA_VENDOR_ID, 0x9041, 0xff),
- .driver_info = (kernel_ulong_t)sierra_mc73xx_blacklist }, /*
MC7305/MC7355 */
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6003),
@@ -1591,6 +1601,14 @@ static const struct usb_device_id option_ids[] = {
.driver_info = (kernel_ulong_t)zte_ad3812_z_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MC2716,
0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t)zte_mc2716_z_blacklist },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ZM8620_X),
+.driver_info = (kernel_ulong_t)zte_me3620andzm8620_xl_blacklist },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_X),
+.driver_info = (kernel_ulong_t)zte_me3620andzm8620_xl_blacklist },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_L),
+.driver_info = (kernel_ulong_t)zte_me3620andzm8620_xl_blacklist },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_MBIM),
+.driver_info = (kernel_ulong_t)zte_me3620_mbim_blacklist },
{ USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x01) },
{ USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x05) },
{ USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x86, 0x10) },
@@ -1767,7 +1785,6 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(0x2001, 0x7d03, 0xff, 0x00, 0x00) },
{ USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e01, 0xff, 0xff, 0xff) }, /*
D-Link DWM-152/C1 */
{ USB_DEVICE_AND_INTERFACE_INFO(0x07d1, 0x3e02, 0xff, 0xff, 0xff) }, /*
D-Link DWM-156/C1 */
- { USB_DEVICE_INTERFACE_CLASS(0x2020, 0x4000, 0xff) },/*
OLICARD300 - MT6225 */
{ USB_DEVICE(INOVIA_VENDOR_ID, INOVIA_SEW858) },
{ USB_DEVICE(VIATELECOM_VENDOR_ID, VIATELECOM_PRODUCT_CDS7) },
{ } /* Terminating entry */
--
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] usb: dwc2: rename all s3c_* to dwc2_*
this driver has long ago became dwc2.ko with
both peripheral and host roles, there's no point
in keeping the old function names.
Signed-off-by: Felipe Balbi ba...@ti.com
---
arch/arm/mach-s3c64xx/mach-crag6410.c | 4 +-
arch/arm/mach-s3c64xx/mach-smartq.c | 4 +-
arch/arm/mach-s3c64xx/mach-smdk6410.c | 4 +-
arch/arm/plat-samsung/devs.c| 6 +-
drivers/usb/dwc2/core.h | 52 +--
drivers/usb/dwc2/core_intr.c| 4 +-
drivers/usb/dwc2/debugfs.c | 20 +-
drivers/usb/dwc2/gadget.c | 696
drivers/usb/dwc2/hcd.c | 4 +-
drivers/usb/dwc2/platform.c | 8 +-
include/linux/platform_data/s3c-hsotg.h | 10 +-
11 files changed, 406 insertions(+), 406 deletions(-)
diff --git a/arch/arm/mach-s3c64xx/mach-crag6410.c
b/arch/arm/mach-s3c64xx/mach-crag6410.c
index 65c426bc45f7..14bd9ae3f476 100644
--- a/arch/arm/mach-s3c64xx/mach-crag6410.c
+++ b/arch/arm/mach-s3c64xx/mach-crag6410.c
@@ -809,7 +809,7 @@ static const struct gpio_led_platform_data gpio_leds_pdata
= {
.num_leds = ARRAY_SIZE(gpio_leds),
};
-static struct s3c_hsotg_plat crag6410_hsotg_pdata;
+static struct dwc2_hsotg_plat crag6410_hsotg_pdata;
static void __init crag6410_machine_init(void)
{
@@ -835,7 +835,7 @@ static void __init crag6410_machine_init(void)
s3c_i2c0_set_platdata(i2c0_pdata);
s3c_i2c1_set_platdata(i2c1_pdata);
s3c_fb_set_platdata(crag6410_lcd_pdata);
- s3c_hsotg_set_platdata(crag6410_hsotg_pdata);
+ dwc2_hsotg_set_platdata(crag6410_hsotg_pdata);
i2c_register_board_info(0, i2c_devs0, ARRAY_SIZE(i2c_devs0));
i2c_register_board_info(1, i2c_devs1, ARRAY_SIZE(i2c_devs1));
diff --git a/arch/arm/mach-s3c64xx/mach-smartq.c
b/arch/arm/mach-s3c64xx/mach-smartq.c
index b3d13537a7f0..719843dca510 100644
--- a/arch/arm/mach-s3c64xx/mach-smartq.c
+++ b/arch/arm/mach-s3c64xx/mach-smartq.c
@@ -189,7 +189,7 @@ static struct s3c_hwmon_pdata smartq_hwmon_pdata __initdata
= {
},
};
-static struct s3c_hsotg_plat smartq_hsotg_pdata;
+static struct dwc2_hsotg_plat smartq_hsotg_pdata;
static int __init smartq_lcd_setup_gpio(void)
{
@@ -382,7 +382,7 @@ void __init smartq_map_io(void)
void __init smartq_machine_init(void)
{
s3c_i2c0_set_platdata(NULL);
- s3c_hsotg_set_platdata(smartq_hsotg_pdata);
+ dwc2_hsotg_set_platdata(smartq_hsotg_pdata);
s3c_hwmon_set_platdata(smartq_hwmon_pdata);
s3c_sdhci1_set_platdata(smartq_internal_hsmmc_pdata);
s3c_sdhci2_set_platdata(smartq_internal_hsmmc_pdata);
diff --git a/arch/arm/mach-s3c64xx/mach-smdk6410.c
b/arch/arm/mach-s3c64xx/mach-smdk6410.c
index d590b88bd8a8..286c9bd676e1 100644
--- a/arch/arm/mach-s3c64xx/mach-smdk6410.c
+++ b/arch/arm/mach-s3c64xx/mach-smdk6410.c
@@ -628,7 +628,7 @@ static struct platform_pwm_backlight_data smdk6410_bl_data
= {
.enable_gpio = -1,
};
-static struct s3c_hsotg_plat smdk6410_hsotg_pdata;
+static struct dwc2_hsotg_plat smdk6410_hsotg_pdata;
static void __init smdk6410_map_io(void)
{
@@ -659,7 +659,7 @@ static void __init smdk6410_machine_init(void)
s3c_i2c0_set_platdata(NULL);
s3c_i2c1_set_platdata(NULL);
s3c_fb_set_platdata(smdk6410_lcd_pdata);
- s3c_hsotg_set_platdata(smdk6410_hsotg_pdata);
+ dwc2_hsotg_set_platdata(smdk6410_hsotg_pdata);
samsung_keypad_set_platdata(smdk6410_keypad_data);
diff --git a/arch/arm/plat-samsung/devs.c b/arch/arm/plat-samsung/devs.c
index 83c7d154bde0..82074625de5c 100644
--- a/arch/arm/plat-samsung/devs.c
+++ b/arch/arm/plat-samsung/devs.c
@@ -1042,11 +1042,11 @@ struct platform_device s3c_device_usb_hsotg = {
},
};
-void __init s3c_hsotg_set_platdata(struct s3c_hsotg_plat *pd)
+void __init dwc2_hsotg_set_platdata(struct dwc2_hsotg_plat *pd)
{
- struct s3c_hsotg_plat *npd;
+ struct dwc2_hsotg_plat *npd;
- npd = s3c_set_platdata(pd, sizeof(struct s3c_hsotg_plat),
+ npd = s3c_set_platdata(pd, sizeof(struct dwc2_hsotg_plat),
s3c_device_usb_hsotg);
if (!npd-phy_init)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 0ed87620941b..9655b1ec4f34 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -58,8 +58,8 @@ static inline void do_write(u32 value, void *addr)
/* Maximum number of Endpoints/HostChannels */
#define MAX_EPS_CHANNELS 16
-/* s3c-hsotg declarations */
-static const char * const s3c_hsotg_supply_names[] = {
+/* dwc2-hsotg declarations */
+static const char * const dwc2_hsotg_supply_names[] = {
vusb_d, /* digital USB supply, 1.2V */
vusb_a, /* analog USB supply, 1.1V */
};
@@ -85,10 +85,10 @@ static const char * const s3c_hsotg_supply_names[] = {
#define EP0_MPS_LIMIT 64
struct dwc2_hsotg;
-struct s3c_hsotg_req;
+struct dwc2_hsotg_req;
/**
- * struct
Re: [PATCH v5]USB:OHCI: BugFix:Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
On Tue, Aug 18, 2015 at 12:25:05PM +, AMAN DEEP wrote:
There is a race condition between
finish_unlinks-finish_urb() function and
usb_kill_urb() in ohci controller case. The finish_urb
calls spin_unlock(ohci-lock) before
usb_hcd_giveback_urb() function call, then if during
this time, usb_kill_urb is called for another endpoint,
then new ed will be added to ed_rm_list at beginning
for unlink. and ed_rm_list will point to newly added
ed.
When finish_urb() is completed in finish_unlinks() and
ed-td_list becomes empty as in below code (in finish_unlinks() function)
if (list_empty(ed-td_list)) {
*last = ed-ed_next;
ed-ed_next = NULL;
} else if (ohci-rh_state == OHCI_RH_RUNNING) {
*last = ed-ed_next;
ed-ed_next = NULL;
ed_schedule(ohci, ed);
}
*last = ed-ed_next will make ed_rm_list to point to ed-ed_next and
previously added ed by usb_kill_urb will be left unreferenced by
ed_rm_list. This causes usb_kill_urb() hang forever waiting for
finish_unlink to remove added ed from ed_rm_list.
The main reason for hang in this race condtion is addition and removal
of ed from ed_rm_list in the beginning during usb_kill_urb and later last*
is modified in finish_unlinks().
As suggested by Alan Stern, the solution for proper handling of
ohci-ed_rm_list is to remove ed from the ed_rm_list before finishing
any URBs. Then at the end, we can add ed back to the list if necessary.
This properly handle the updated ohci-ed_rm_list in
usb_kill_urb().
Fixes:977dcfdc6031(USB:OHCI:don't lose track of EDs when a
controller dies)
Acked-by: Alan Stern st...@rowland.harvard.edu
Signed-off-by: Aman Deep aman.d...@samsung.com
CC: sta...@vger.kernel.org
---
drivers/usb/host/ohci-q.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
This still doesn't apply at all, please work on sending the patch to
yourself and seeing if you can add it to my usb-next git branch.
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] usbhid: Fix the check for HID_RESET_PENDING in hid_io_error
On Mon, 10 Aug 2015, Don Zickus wrote: It was reported that after 10-20 reboots, a usb keyboard plugged into a docking station would not work unless it was replugged in. Using usbmon, it turns out the interrupt URBs were streaming with callback errors of -71 for some reason. The hid-core.c::hid_io_error was supposed to retry and then reset, but the reset wasn't really happening. The check for HID_NO_BANDWIDTH was inverted. Fix was simple. Tested by reporter and locally by me by unplugging a keyboard halfway until I could recreate a stream of errors but no disconnect. Signed-off-by: Don Zickus dzic...@redhat.com --- I mistyped the usb mailing list address, so this patch never made it there. Resending with the correct address. Sorry for the spam. Hmm, good catch. I've added Cc: stable and applied to for-4.3/upstream. Thanks, -- Jiri Kosina SUSE Labs -- 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: Fwd: [Bug 102101] USB 3 storage device disconnects after S3 resume,and re-enumerate it.
Thanks all. When I debug,I find that if I build-in the xHCI, (suspend to disk)STD is perform OK. But whatever I build-in xHCI, (suspend to ram)STR is bad. My experiment is in MIPS paltform with Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03), and I don't have the X86 experimental environment, Who can tell me, if the STS_SRE bit is set in X86 after S3 resume? It route the same way with MIPS? Aaron Chou On Tue, Aug 18, 2015 at 9:35 PM, Mathias Nyman mathias.ny...@linux.intel.com wrote: On 17.08.2015 12:18, Aaron Zhou wrote: Hi, all https://bugzilla.kernel.org/show_bug.cgi?id=102101 Bug ID: 102101 Summary: USB 3 storage device disconnects after S3 resume,and re-enumerate it. I debug this problem ,and I find that when I suspend to ram (STR), the STS_SRE bit is set. and re-initialize the HC during resume, In xhci_resume() function, after xhci_handshake() is called , I printk the xhci-op_regs-status, it is 0x401, means the STS_SRE bit is set. I can not understand. This is normal ? Hi Save Restore Error (STS_SRE) doesn't seem normal. Last time I saw it was when the driver didn't allocate enough scratchpad memory where it should save the state while suspending It could be something messing with the memory where xhci state is saved, or xhci being placed into run mode in between save and restore state. -Mathias -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: core: hub: Removed some warnings generated by checkpatch.pl
Removed some checkpatch.pl warnings saying there was an unwanted space
between function names and their arguments.
Signed-off-by: Chase Metzger chasemetzge...@gmail.com
---
drivers/usb/core/hub.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 431839b..169e3d8 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -4222,7 +4222,7 @@ static int hub_enable_device(struct usb_device *udev)
* but it is still necessary to lock the port.
*/
static int
-hub_port_init (struct usb_hub *hub, struct usb_device *udev, int port1,
+hub_port_init(struct usb_hub *hub, struct usb_device *udev, int port1,
int retry_counter)
{
struct usb_device *hdev = hub-hdev;
@@ -4526,7 +4526,7 @@ fail:
}
static void
-check_highspeed (struct usb_hub *hub, struct usb_device *udev, int port1)
+check_highspeed(struct usb_hub *hub, struct usb_device *udev, int port1)
{
struct usb_qualifier_descriptor *qual;
int status;
@@ -4534,11 +4534,11 @@ check_highspeed (struct usb_hub *hub, struct usb_device
*udev, int port1)
if (udev-quirks USB_QUIRK_DEVICE_QUALIFIER)
return;
- qual = kmalloc (sizeof *qual, GFP_KERNEL);
+ qual = kmalloc(sizeof *qual, GFP_KERNEL);
if (qual == NULL)
return;
- status = usb_get_descriptor (udev, USB_DT_DEVICE_QUALIFIER, 0,
+ status = usb_get_descriptor(udev, USB_DT_DEVICE_QUALIFIER, 0,
qual, sizeof *qual);
if (status == sizeof *qual) {
dev_info(udev-dev, not running at top speed;
@@ -4554,7 +4554,7 @@ check_highspeed (struct usb_hub *hub, struct usb_device
*udev, int port1)
}
static unsigned
-hub_power_remaining (struct usb_hub *hub)
+hub_power_remaining(struct usb_hub *hub)
{
struct usb_device *hdev = hub-hdev;
int remaining;
@@ -4741,7 +4741,7 @@ static void hub_port_connect(struct usb_hub *hub, int
port1, u16 portstatus,
if (le16_to_cpu(udev-descriptor.bcdUSB) = 0x0200
udev-speed == USB_SPEED_FULL
highspeed_hubs != 0)
- check_highspeed (hub, udev, port1);
+ check_highspeed(hub, udev, port1);
/* Store the parent's children[] pointer. At this point
* udev becomes globally accessible, although presumably
@@ -5115,7 +5115,7 @@ static const struct usb_device_id hub_id_table[] = {
{ }/* Terminating entry */
};
-MODULE_DEVICE_TABLE (usb, hub_id_table);
+MODULE_DEVICE_TABLE(usb, hub_id_table);
static struct usb_driver hub_driver = {
.name = hub,
@@ -5227,7 +5227,7 @@ static int descriptors_changed(struct usb_device *udev,
changed = 1;
break;
}
- if (memcmp (buf, udev-rawdescriptors[index], old_length)
+ if (memcmp(buf, udev-rawdescriptors[index], old_length)
!= 0) {
dev_dbg(udev-dev, config index %d changed (#%d)\n,
index,
--
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] usbnet: Fix two races between usbnet_stop() and the BH
From: Eugene Shatokhin eugene.shatok...@rosalab.ru Date: Fri, 14 Aug 2015 19:58:36 +0300 2. The second race is on dev-flags. dev-flags is set to 0 here: *0 usbnet_stop (usbnet.c:816) /* deferred work (task, timer, softirq) must also stop. * can't flush_scheduled_work() until we drop rtnl (later), * else workers could deadlock; so make workers a NOP. */ dev-flags = 0; del_timer_sync (dev-delay); tasklet_kill (dev-bh); And here, the code clears EVENT_RX_KILL bit in dev-flags, which may execute concurrently with the above operation: *0 clear_bit (bitops.h:113, inlined) *1 usbnet_bh (usbnet.c:1475) /* restart RX again after disabling due to high error rate */ clear_bit(EVENT_RX_KILL, dev-flags); It seems, setting dev-flags to 0 is not necessarily atomic w.r.t. clear_bit() and other bit operations with dev-flags. It is safer to make it atomic and this way, make the race harmless. While at it, the checking of EVENT_NO_RUNTIME_PM bit of dev-flags in usbnet_stop() was fixed too: the bit should be checked before dev-flags is cleared. The fix for this is excessive. Instead of all of this madness, looping over expensive clear_bit() atomics, just do whatever it takes to make sure that usbnet_bh() is quiesced and cannot execute any more. Then you can safely clear dev-flags normally. -- 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] usb: dwc2: reset dwc2 core before dwc2_get_hwparams()
On 8/18/2015 2:41 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 | 6 ++
3 files changed, 8 insertions(+), 1 deletion(-)
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..8d3be4a 100644
--- a/drivers/usb/dwc2/platform.c
+++ b/drivers/usb/dwc2/platform.c
@@ -243,6 +243,12 @@ 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.
+ */
+ dwc2_core_reset(hsotg);
+
/* Detect config values from hardware */
retval = dwc2_get_hwparams(hsotg);
if (retval)
Hi Yunzhi,
My concern is with the delays due to calling the dwc2_core_reset
during probe. You could factor out the assertion of the core
soft reset from the dwc2_core_reset and just use that before
calling dwc2_get_hwparams().
You had previously addressed the lengthy probe time issue here:
http://marc.info/?l=linux-usbm=142357721304377
This reducing delays patch looks reasonable to me and I think it
should get merged also. I'll do some testing with it later this
week.
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 Tue, Aug 18, 2015 at 09:12:00AM -0700, Mark Brown wrote:
On Tue, Aug 18, 2015 at 01:20:12PM +0800, Peter Chen wrote:
ok, I just had suspected below function's correctness, after looking
it again, it always set 1800 as charging limit, does it be expected?
+ /* Find the highest supported limit */
+ best = 0;
+ for (i = 0; i ARRAY_SIZE(wm831x_usb_limits); i++) {
+ if (limit wm831x_usb_limits[i]
+/* In miliamps */
+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;
+}
+
The above check is intended to ensure that we don't go over the limit
that was passed in in the callback. The goal is to select the highest
option that is less than the limit passed in.
Please correct me if I was wrong, If there is SDP (PC), the current
limit is 500mA, then when the i = 4, (500 900) (0 900) is true,
the best is 4. When the i goes to 5, (500 1500) (900 1500) is
true, the best is 5. At last, the best will be 1800, which is not our
expectation.
Below code may be correct for the goal you expressed.
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;
}
--
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: [PATCH v2] usb: dwc2: reset dwc2 core before dwc2_get_hwparams()
lyz, On Tue, Aug 18, 2015 at 2:40 AM, Yunzhi Li l...@rock-chips.com 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 | 6 ++ 3 files changed, 8 insertions(+), 1 deletion(-) This seems reasonable to me. Reviewed-by: Douglas Anderson diand...@chromium.org -- 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 1/3] gadget: Support for the usb charger framework
On 19 August 2015 at 00:04, Greg KH gre...@linuxfoundation.org wrote: On Tue, Aug 18, 2015 at 07:14:19PM +0800, Baolin Wang wrote: The usb charger framework is based on usb gadget, and each usb gadget can be one usb charger to set the current limitation. This patch adds a notifier mechanism for usb charger to report to usb charger when the usb gadget state is changed. Also we 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 | 41 - include/linux/usb/gadget.h| 20 ++ 2 files changed, 60 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/udc/udc-core.c b/drivers/usb/gadget/udc/udc-core.c index f660afb..1971218 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 You just broke the build, which proves you did not properly test this patch series, so why should we even consider it? Oh, I'm very sorry about that. I'll re-check my patch and test it carefully. Thanks for your comments. greg k-h -- 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
[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),
.bInCollection =F_AUDIO_NUM_INTERFACES,
.baInterfaceNr = {
/* Interface number of the first AudioStream interface */
@@ -186,7 +186,7 @@ static struct uac_iso_endpoint_descriptor as_iso_out_desc =
{
.bDescriptorSubtype = UAC_EP_GENERAL,
.bmAttributes = 1,
.bLockDelayUnits = 1,
- .wLockDelay = __constant_cpu_to_le16(1),
+ .wLockDelay = cpu_to_le16(1),
};
static struct usb_descriptor_header *f_audio_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] usbip: vhci_hcd: 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/usbip/vhci_hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/usbip/vhci_hcd.c b/drivers/usb/usbip/vhci_hcd.c index e9ef1ec..42c8231 100644 --- a/drivers/usb/usbip/vhci_hcd.c +++ b/drivers/usb/usbip/vhci_hcd.c @@ -218,7 +218,7 @@ static inline void hub_descriptor(struct usb_hub_descriptor *desc) memset(desc, 0, sizeof(*desc)); desc-bDescriptorType = USB_DT_HUB; desc-bDescLength = 9; - desc-wHubCharacteristics = __constant_cpu_to_le16( + desc-wHubCharacteristics = cpu_to_le16( HUB_CHAR_INDV_PORT_LPSM | HUB_CHAR_COMMON_OCPM); desc-bNbrPorts = VHCI_NPORTS; desc-u.hs.DeviceRemovable[0] = 0xff; -- 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] usb: dwc3: pci: passing forward the ACPI companion
HI, On Tue, Aug 18, 2015 at 04:31:17PM +0300, Heikki Krogerus wrote: On Mon, Aug 17, 2015 at 12:59:52PM -0500, Felipe Balbi wrote: On Mon, Aug 17, 2015 at 10:26:53AM -0700, David Cohen wrote: On Mon, Aug 17, 2015 at 08:41:19AM -0500, Felipe Balbi wrote: On Mon, Aug 17, 2015 at 02:32:06PM +0300, Heikki Krogerus wrote: Sharing the APCI companion with the core platforms device so ACPI :-) it has access to all DWC3's resources. and which resources are these ? and why can't they be abstrated out in dwc3-pci ? I could think about USB phy devices on legacy BYT-CR products. But since we got Heikki's ULPI bus we are able to move ACPI companion to their own phy device on future. we need a better commit log explaining why this is really needed. OK. I'm also thinking about the properties with this. If we convert core.c to use the unified device property interface (check the attached diff), like we ultimately will need to do, the driver is then ready to pick those properties also from ACPI tables. fair enough. It does not actually have any functional affect on DT platforms. It only makes it possible to read the property also from ACPI (and later from build-in property), so I'll prepare a patch from that diff and send it together with this one if you guys are OK with that? I'm fine with it. I would just turn device_read_property() into the default the pdata/DT the fallback. -- balbi signature.asc Description: Digital signature
[PATCH] 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.
Make behaviour consistent by filling bcdUSB for the other two cases of
USB 2.0 and USB 1.1 capable gadgets.
Given that legacy gadget drivers set bcdUSB manually, it makes sense to
place the entire logic in the composite gadget driver.
Signed-off-by: Igor Kotrasinski i.kotrasi...@samsung.com
---
drivers/usb/gadget/composite.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 58b4657..6eac055 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1499,6 +1499,10 @@ composite_setup(struct usb_gadget *gadget, const struct
usb_ctrlrequest *ctrl)
} else {
cdev-desc.bcdUSB = cpu_to_le16(0x0210);
}
+ } else if (gadget_is_dualspeed(gadget)) {
+ cdev-desc.bcdUSB = cpu_to_le16(0x0200);
+ } else {
+ cdev-desc.bcdUSB = cpu_to_le16(0x0110);
}
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
Re: [PATCH] usb: dwc3: pci: passing forward the ACPI companion
On Mon, Aug 17, 2015 at 12:59:52PM -0500, Felipe Balbi wrote:
On Mon, Aug 17, 2015 at 10:26:53AM -0700, David Cohen wrote:
On Mon, Aug 17, 2015 at 08:41:19AM -0500, Felipe Balbi wrote:
On Mon, Aug 17, 2015 at 02:32:06PM +0300, Heikki Krogerus wrote:
Sharing the APCI companion with the core platforms device so
ACPI :-)
it has access to all DWC3's resources.
and which resources are these ? and why can't they be abstrated out in
dwc3-pci ?
I could think about USB phy devices on legacy BYT-CR products. But since
we got Heikki's ULPI bus we are able to move ACPI companion to their own
phy device on future.
we need a better commit log explaining why this is really needed.
OK.
I'm also thinking about the properties with this. If we convert core.c
to use the unified device property interface (check the attached
diff), like we ultimately will need to do, the driver is then ready to
pick those properties also from ACPI tables.
It does not actually have any functional affect on DT platforms. It
only makes it possible to read the property also from ACPI (and
later from build-in property), so I'll prepare a patch from that
diff and send it together with this one if you guys are OK with that?
Cheers,
--
heikki
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 064123e..8221ad8 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -844,49 +844,10 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
- dwc-has_lpm_erratum = of_property_read_bool(node,
- snps,has-lpm-erratum);
- of_property_read_u8(node, snps,lpm-nyet-threshold,
- lpm_nyet_threshold);
- dwc-is_utmi_l1_suspend = of_property_read_bool(node,
- snps,is-utmi-l1-suspend);
- of_property_read_u8(node, snps,hird-threshold,
- hird_threshold);
- dwc-usb3_lpm_capable = of_property_read_bool(node,
- snps,usb3_lpm_capable);
-
- dwc-needs_fifo_resize = of_property_read_bool(node,
- tx-fifo-resize);
dwc-dr_mode = of_usb_get_dr_mode(node);
+ }
- dwc-disable_scramble_quirk = of_property_read_bool(node,
- snps,disable_scramble_quirk);
- dwc-u2exit_lfps_quirk = of_property_read_bool(node,
- snps,u2exit_lfps_quirk);
- dwc-u2ss_inp3_quirk = of_property_read_bool(node,
- snps,u2ss_inp3_quirk);
- dwc-req_p1p2p3_quirk = of_property_read_bool(node,
- snps,req_p1p2p3_quirk);
- dwc-del_p1p2p3_quirk = of_property_read_bool(node,
- snps,del_p1p2p3_quirk);
- dwc-del_phy_power_chg_quirk = of_property_read_bool(node,
- snps,del_phy_power_chg_quirk);
- dwc-lfps_filter_quirk = of_property_read_bool(node,
- snps,lfps_filter_quirk);
- dwc-rx_detect_poll_quirk = of_property_read_bool(node,
- snps,rx_detect_poll_quirk);
- dwc-dis_u3_susphy_quirk = of_property_read_bool(node,
- snps,dis_u3_susphy_quirk);
- dwc-dis_u2_susphy_quirk = of_property_read_bool(node,
- snps,dis_u2_susphy_quirk);
-
- dwc-tx_de_emphasis_quirk = of_property_read_bool(node,
- snps,tx_de_emphasis_quirk);
- of_property_read_u8(node, snps,tx_de_emphasis,
- tx_de_emphasis);
- of_property_read_string(node, snps,hsphy_interface,
- dwc-hsphy_interface);
- } else if (pdata) {
+ if (pdata) {
dwc-maximum_speed = pdata-maximum_speed;
dwc-has_lpm_erratum = pdata-has_lpm_erratum;
if (pdata-lpm_nyet_threshold)
@@ -915,6 +876,48 @@ static int dwc3_probe(struct platform_device *pdev)
tx_de_emphasis = pdata-tx_de_emphasis;
dwc-hsphy_interface = pdata-hsphy_interface;
+ } else {
+ dwc-has_lpm_erratum = device_property_read_bool(dev,
+ snps,has-lpm-erratum);
+ of_property_read_u8(node, snps,lpm-nyet-threshold,
+ lpm_nyet_threshold);
+ dwc-is_utmi_l1_suspend = device_property_read_bool(dev,
+ snps,is-utmi-l1-suspend);
+ of_property_read_u8(node, snps,hird-threshold,
+ hird_threshold);
+
Re: [PATCH v3 3/3] power: wm831x_power: Support USB charger current limit management
On Tue, 18 Aug 2015, Charles Keepax wrote: On Tue, Aug 18, 2015 at 07:14:21PM +0800, Baolin Wang wrote: 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: Charles Keepax ckee...@opensource.wolfsonmicro.com Sorry if you guys got a bunch of bounces, we had a bit of an email fiasco at this end. Hopefully all fixed now. Yes, I sent you guys a mail about that. Glad it's all sorted now. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 3/3] power: wm831x_power: Support USB charger current limit management
On Tue, Aug 18, 2015 at 07:14:21PM +0800, Baolin Wang wrote: 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: Charles Keepax ckee...@opensource.wolfsonmicro.com Sorry if you guys got a bunch of bounces, we had a bit of an email fiasco at this end. Hopefully all fixed now. Thanks, Charles -- 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 Mon, Aug 17, 2015 at 10:04:05PM -0700, Mark Brown wrote:
On Mon, Aug 17, 2015 at 06:58:16PM -0500, Felipe Balbi wrote:
On Mon, Aug 17, 2015 at 10:26:23AM -0700, Mark Brown wrote:
On Mon, Aug 17, 2015 at 09:07:08AM +0800, Peter Chen wrote:
On Fri, Aug 14, 2015 at 05:47:46PM +0800, Baolin Wang wrote:
+ if (wm831x_pdata wm831x_pdata-usb_gadget) {
Where the wm831x_pdata-usb_gadget is initialized?
It's platform data, it will be initialised by whatever registers the
platform data.
passing pointers through pdata ?
It's a char * to a name, not a pointer to struct.
aha, fair enough.
--
balbi
signature.asc
Description: Digital signature
Re: MUSB dual-role on AM335x behaving weirdly
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. -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: gadget: composite: fill bcdUSB for any gadget max speed
On Tue, Aug 18, 2015 at 11:06:32AM -0400, Alan Stern wrote:
On Tue, 18 Aug 2015, Igor Kotrasinski wrote:
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.
Make behaviour consistent by filling bcdUSB for the other two cases of
USB 2.0 and USB 1.1 capable gadgets.
Given that legacy gadget drivers set bcdUSB manually, it makes sense to
place the entire logic in the composite gadget driver.
Signed-off-by: Igor Kotrasinski i.kotrasi...@samsung.com
---
drivers/usb/gadget/composite.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 58b4657..6eac055 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1499,6 +1499,10 @@ composite_setup(struct usb_gadget *gadget, const
struct usb_ctrlrequest *ctrl)
} else {
cdev-desc.bcdUSB = cpu_to_le16(0x0210);
}
+ } else if (gadget_is_dualspeed(gadget)) {
+ cdev-desc.bcdUSB = cpu_to_le16(0x0200);
+ } else {
+ cdev-desc.bcdUSB = cpu_to_le16(0x0110);
}
I would argue that there's no need to check gadget_is_dualspeed();
bcdUSB should always be set to 0x0200. After all, the spec explicitly
permits USB-2.0 devices to run only at full speed.
we should actually set it to 0x0210 so we get to send BOS descriptors
:-)
--
balbi
signature.asc
Description: Digital signature
[PATCH 0/1] USB DWC2 parity fix in isochronous mode
This patch contains a fix for a real world interop problem found when using the Synopsis DWC2 USB controller with isochronous audio as detailed in the commit message. Roman Bacik (1): usb: dwc2: gadget: parity fix in isochronous mode drivers/usb/dwc2/core.h | 1 + drivers/usb/dwc2/gadget.c | 48 ++- drivers/usb/dwc2/hw.h | 1 + 3 files changed, 49 insertions(+), 1 deletion(-) -- 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
Re: [PATCH v3 1/3] gadget: Support for the usb charger framework
On Tue, Aug 18, 2015 at 07:14:19PM +0800, Baolin Wang wrote: The usb charger framework is based on usb gadget, and each usb gadget can be one usb charger to set the current limitation. This patch adds a notifier mechanism for usb charger to report to usb charger when the usb gadget state is changed. Also we 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 | 41 - include/linux/usb/gadget.h| 20 ++ 2 files changed, 60 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/udc/udc-core.c b/drivers/usb/gadget/udc/udc-core.c index f660afb..1971218 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 You just broke the build, which proves you did not properly test this patch series, so why should we even consider it? greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/3] power: wm831x_power: Support USB charger current limit management
On Tue, Aug 18, 2015 at 01:20:12PM +0800, Peter Chen wrote:
ok, I just had suspected below function's correctness, after looking
it again, it always set 1800 as charging limit, does it be expected?
+ /* Find the highest supported limit */
+ best = 0;
+ for (i = 0; i ARRAY_SIZE(wm831x_usb_limits); i++) {
+ if (limit wm831x_usb_limits[i]
The above check is intended to ensure that we don't go over the limit
that was passed in in the callback. The goal is to select the highest
option that is less than the limit passed in.
signature.asc
Description: Digital signature
[PATCH 1/1] usb: dwc2: gadget: parity fix in isochronous mode
From: Roman Bacik rba...@broadcom.com
USB OTG driver in isochronous mode has to set the parity of the receiving
microframe. The parity is set to even by default. This causes problems for
an audio gadget, if the host starts transmitting on odd microframes.
This fix uses Incomplete Periodic Transfer interrupt to toggle between
even and odd parity until the Transfer Complete interrupt is received.
Signed-off-by: Roman Bacik rba...@broadcom.com
Reviewed-by: Abhinav Ratna ara...@broadcom.com
Reviewed-by: Srinath Mannam srinath.man...@broadcom.com
Reviewed-by: Scott Branden sbran...@broadcom.com
Signed-off-by: Scott Branden sbran...@broadcom.com
---
drivers/usb/dwc2/core.h | 1 +
drivers/usb/dwc2/gadget.c | 48 ++-
drivers/usb/dwc2/hw.h | 1 +
3 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 0ed87620..954d1cd 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -150,6 +150,7 @@ struct s3c_hsotg_ep {
unsigned intperiodic:1;
unsigned intisochronous:1;
unsigned intsend_zlp:1;
+ unsigned intparity_set:1;
charname[10];
};
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 4d47b7c..28e4393 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1954,6 +1954,8 @@ static void s3c_hsotg_epint(struct dwc2_hsotg *hsotg,
unsigned int idx,
ints = ~DXEPINT_XFERCOMPL;
if (ints DXEPINT_XFERCOMPL) {
+ if (hs_ep-isochronous !hs_ep-parity_set)
+ hs_ep-parity_set = 1;
if (hs_ep-isochronous hs_ep-interval == 1) {
if (ctrl DXEPCTL_EOFRNUM)
ctrl |= DXEPCTL_SETEVENFR;
@@ -2316,7 +2318,8 @@ void s3c_hsotg_core_init_disconnected(struct dwc2_hsotg
*hsotg,
GINTSTS_CONIDSTSCHNG | GINTSTS_USBRST |
GINTSTS_RESETDET | GINTSTS_ENUMDONE |
GINTSTS_OTGINT | GINTSTS_USBSUSP |
- GINTSTS_WKUPINT,
+ GINTSTS_WKUPINT |
+ GINTSTS_INCOMPL_SOIN | GINTSTS_INCOMPL_SOOUT,
hsotg-regs + GINTMSK);
if (using_dma(hsotg))
@@ -2581,6 +2584,48 @@ irq_retry:
s3c_hsotg_dump(hsotg);
}
+ if (gintsts GINTSTS_INCOMPL_SOIN) {
+ u32 idx;
+ struct s3c_hsotg_ep *hs_ep;
+
+ dev_dbg(hsotg-dev, %s: GINTSTS_INCOMPL_SOIN\n, __func__);
+ for (idx = 1; idx MAX_EPS_CHANNELS; idx++) {
+ hs_ep = hsotg-eps_in[idx];
+ if (hs_ep-isochronous !hs_ep-parity_set) {
+ u32 epctl_reg = DIEPCTL(idx);
+ u32 ctrl = readl(hsotg-regs + epctl_reg);
+
+ if (ctrl DXEPCTL_EOFRNUM)
+ ctrl |= DXEPCTL_SETEVENFR;
+ else
+ ctrl |= DXEPCTL_SETODDFR;
+ writel(ctrl, hsotg-regs + epctl_reg);
+ }
+ }
+ writel(GINTSTS_INCOMPL_SOIN, hsotg-regs + GINTSTS);
+ }
+
+ if (gintsts GINTSTS_INCOMPL_SOOUT) {
+ u32 idx;
+ struct s3c_hsotg_ep *hs_ep;
+
+ dev_dbg(hsotg-dev, %s: GINTSTS_INCOMPL_SOOUT\n, __func__);
+ for (idx = 1; idx MAX_EPS_CHANNELS; idx++) {
+ hs_ep = hsotg-eps_out[idx];
+ if (hs_ep-isochronous !hs_ep-parity_set) {
+ u32 epctl_reg = DOEPCTL(idx);
+ u32 ctrl = readl(hsotg-regs + epctl_reg);
+
+ if (ctrl DXEPCTL_EOFRNUM)
+ ctrl |= DXEPCTL_SETEVENFR;
+ else
+ ctrl |= DXEPCTL_SETODDFR;
+ writel(ctrl, hsotg-regs + epctl_reg);
+ }
+ }
+ writel(GINTSTS_INCOMPL_SOOUT, hsotg-regs + GINTSTS);
+ }
+
/*
* if we've had fifo events, we should try and go around the
* loop again to see if there's any point in returning yet.
@@ -2667,6 +2712,7 @@ static int s3c_hsotg_ep_enable(struct usb_ep *ep,
hs_ep-periodic = 0;
hs_ep-halted = 0;
hs_ep-interval = desc-bInterval;
+ hs_ep-parity_set = 0;
if (hs_ep-interval 1 hs_ep-mc 1)
dev_err(hsotg-dev, MC 1 when interval is not 1\n);
diff --git a/drivers/usb/dwc2/hw.h b/drivers/usb/dwc2/hw.h
index d0a5ed8..553f246 100644
--- a/drivers/usb/dwc2/hw.h
+++ b/drivers/usb/dwc2/hw.h
@@ -142,6 +142,7 @@
#define GINTSTS_RESETDET (1 23)
#define GINTSTS_FET_SUSP
Re: [PATCH RESEND] usbhid: Fix the check for HID_RESET_PENDING in hid_io_error
Bump. :-)
On Mon, Aug 10, 2015 at 12:06:53PM -0400, Don Zickus wrote:
It was reported that after 10-20 reboots, a usb keyboard plugged
into a docking station would not work unless it was replugged in.
Using usbmon, it turns out the interrupt URBs were streaming with
callback errors of -71 for some reason. The hid-core.c::hid_io_error was
supposed to retry and then reset, but the reset wasn't really happening.
The check for HID_NO_BANDWIDTH was inverted. Fix was simple.
Tested by reporter and locally by me by unplugging a keyboard halfway until I
could recreate a stream of errors but no disconnect.
Signed-off-by: Don Zickus dzic...@redhat.com
---
I mistyped the usb mailing list address, so this patch never made it there.
Resending with the correct address. Sorry for the spam.
drivers/hid/usbhid/hid-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
index b37d944..9935a64 100644
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -164,7 +164,7 @@ static void hid_io_error(struct hid_device *hid)
if (time_after(jiffies, usbhid-stop_retry)) {
/* Retries failed, so do a port reset unless we lack bandwidth*/
- if (test_bit(HID_NO_BANDWIDTH, usbhid-iofl)
+ if (!test_bit(HID_NO_BANDWIDTH, usbhid-iofl)
!test_and_set_bit(HID_RESET_PENDING, usbhid-iofl)) {
schedule_work(usbhid-reset_work);
--
1.8.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
--
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
