Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5
Hi Tony, 2014-11-17 19:04 GMT+01:00 Tony Lindgren t...@atomide.com: * Enric Balletbo Serra eballe...@gmail.com [141117 07:15]: Hi all, I'm trying to use the USB OTG driver of OMAP3 processor in HOST mode when it's configured in dual role mode (CONFIG_USB_MUSB_DUAL_ROLE=y) The test case that I'm trying to solve is as follows. 1) Boot the board. 2) Put the USB ID pin to ground 3) Connect a pendrive. In such case doesn't work as expected and pendrive is never detected. Enabling debug information, I see that the phyter (twl4030) is constantly polling the STS_HW_CONDITIONS register, who reports: twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1 The STS_HW_CONDITIONS register reports: Bit 2: STS_USB : 1: USB is plugged in. Bit 4: STS_WAKEUP1: Level status of WAKEUP1 pad (active high) = nSLEEP1 Bit 6: STS_WAKEUP3: Level status of WAKEUP3 pad (active high) = CLKREQ I guess that in this case the state machine is waiting for VBUS, and looks for bit 7 STS_VBUS (Level status of VBUS port), but this never occurs. Using an oscilloscope I checked VBUS level and I can confirm that it's a 0 level. My understand is that in this case the driver should enable VBUS but I didn't find where is the best place to do this and why is not doing this already. Any clue on this? Just tested v3.18-rc5 with beagleboard xm, and the host mode enumerates the devices, then may fail with insufficient bus power at least for the WLAN device I tried with. Is this with following options ? CONFIG_USB_MUSB_DUAL_ROLE=y # CONFIG_USB_MUSB_HOST is not set # CONFIG_USB_MUSB_GADGET is not set Because with these options doesn't work for me. It only works if I don't use dual role mode CONFIG_USB_MUSB_HOST=y CONFIG_USB_MUSB_DUAL_ROLE is not set I noticed that this only works with CONFIG_USB_MUSB_HDRC and CONFIG_TWL4030_USB built into the kernel. No luck so far with them as loadable modules for some reason. Looks like also USB gadgets fail with MUSB as modules. It's weird, for me fails in both cases, built-in and with loadable modules. Connecting the OTG Cable Adapter with a pendrive reports [ 51.462432] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1 [ 51.470916] twl4030_usb 4807.i2c:twl@48:twl4030-usb: twl4030_usb_runtime_resume [ 51.487274] musb-hdrc musb-hdrc.0.auto: ID GND [ 52.480712] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1 [ 53.489044] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1 And then polls until I disconnect the OTG Cable Adapter with the pendrive. [ 71.488983] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1 [ 71.778930] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x50/80; link 4 [ 71.787536] musb-hdrc musb-hdrc.0.auto: VBUS Disconnect [ 72.489044] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x50/80; link 4 [ 74.088714] twl4030_usb 4807.i2c:twl@48:twl4030-usb: twl4030_usb_runtime_suspend And on the 37xx EVM, I've never had any luck getting any twl4030_usb interrupts for some reason. Regards, Enric Regards, Tony -- 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: [PATCHv2 1/4] xhci: don't start a halted endpoint before its new dequeue is set
On 17.11.2014 16:52, David Laight wrote:
From: Mathias Nyman
A halted endpoint ring must first be reset, then move the ring
dequeue pointer past the problematic TRB. If we start the ring too
early after reset, but before moving the dequeue pointer we
will end up executing the same problematic TRB again.
As we always issue a set transfer dequeue command after a reset
endpoint command we can skip starting endpoint rings at reset endpoint
command completion.
Without this fix we end up trying to handle the same faulty TD for
contol endpoints. causing timeout, and failing testusb ctrl_out write
tests.
Fixes: e9df17e (USB: xhci: Correct assumptions about number of rings per
endpoint.)
Cc: sta...@vger.kernel.org #v2.6.35
Tested-by: Felipe Balbi ba...@ti.com
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci-ring.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index bc6fcbc..d6646db 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1069,7 +1069,6 @@ static void xhci_handle_cmd_reset_ep(struct xhci_hcd
*xhci, int slot_id,
} else {
/* Clear our internal halted state and restart the ring(s) */
xhci-devs[slot_id]-eps[ep_index].ep_state = ~EP_HALTED;
-ring_doorbell_for_active_rings(xhci, slot_id, ep_index);
The comment is now wrong - you aren't restarting the ring(s) here.
Thats right, comment is still wrong, thanks.
I'll resend.
Also I'm not at all certain that delaying 'ringing the doorbell' is in anyway
guaranteed to stop the xhci hardware from processing the next ring entry.
It might be true if the ring is absolutely known to be inactive, and that
the controller isn't polling the rings on timeout.
But if the controller is still processing the previous ring entry it
will process the next one without the bell being rung.
Plausibly some other driver path might also ring the bell.
The ring is known to be inactive. The only use for reset endpoint command is to
revocer a halted endpoint ring. A reset endpoint on a non-halted endpoint will
fail.
A reset endpoint command will move the ring from a halted to a stopped state.
Ringing the doorbell will restart the stopped ring. But we don't want to ring
the doorbell
until we moved past the problematic TRB with a set dq pointer command.
xhci 4.6.8:
The Reset Endpoint Command is issued by software to recover from a halted
condition on an endpoint.
...
If the endpoint is not in the Halted state when an Reset Endpoint Command is
executed:
The xHC shall reject the command and generate a Command Completion Event with
the
Completion Code set to Context State Error.
For safety you shouldn't change the 'cycle' bit until it is safe
for the controller to process the ring(s).
It won't, as said, reset endpoint will only work if endpoint is halted.
-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
[PATCHv3 0/4] xhci fixes for 3.18-rc
Hi Greg third try v3: fix code comment to be in line with what the code does v2: correcting a wrong fixes commit ID, and missing stable version These patches for usb-linus solve two xhci issues, fixing xhci halted endpoint handling to now follow the specification, and pass testusb control message tests The other one reverts a faulty xhci controller wakeup solution, and writes a new proper solution. Lu Baolu (2): Revert xhci: clear root port wake on bits if controller isn't wake-up capable usb: xhci: rework root port wake bits if controller isn't allowed to wakeup Mathias Nyman (2): xhci: don't start a halted endpoint before its new dequeue is set xhci: Reset a halted endpoint immediately when we encounter a stall. drivers/usb/host/xhci-hub.c | 5 +- drivers/usb/host/xhci-pci.c | 2 +- drivers/usb/host/xhci-plat.c | 10 +++- drivers/usb/host/xhci-ring.c | 43 + drivers/usb/host/xhci.c | 107 ++- drivers/usb/host/xhci.h | 2 +- 6 files changed, 79 insertions(+), 90 deletions(-) -- 1.8.3.2 -- 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
[PATCHv3 4/4] usb: xhci: rework root port wake bits if controller isn't allowed to wakeup
From: Lu Baolu baolu...@linux.intel.com
When system is being suspended, if host device is not allowed to do wakeup,
xhci_suspend() needs to clear all root port wake on bits. Otherwise, some
platforms may generate spurious wakeup, even if PCI PME# is disabled.
The initial commit ff8cbf250b44 (xhci: clear root port wake on bits),
which also got into stable, turned out to not work correctly and had to
be reverted, and is now rewritten.
Cc: stable sta...@vger.kernel.org # v3.2+
Signed-off-by: Lu Baolu baolu...@linux.intel.com
Suggested-by: Alan Stern st...@rowland.harvard.edu
Acked-by: Alan Stern st...@rowland.harvard.edu
[Mathias Nyman: reword commit message]
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci-pci.c | 2 +-
drivers/usb/host/xhci-plat.c | 10 +-
drivers/usb/host/xhci.c | 42 +-
drivers/usb/host/xhci.h | 2 +-
4 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 9a69b1f..142b601 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -281,7 +281,7 @@ static int xhci_pci_suspend(struct usb_hcd *hcd, bool
do_wakeup)
if (xhci-quirks XHCI_COMP_MODE_QUIRK)
pdev-no_d3cold = true;
- return xhci_suspend(xhci);
+ return xhci_suspend(xhci, do_wakeup);
}
static int xhci_pci_resume(struct usb_hcd *hcd, bool hibernated)
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 3d78b0c..646300c 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -204,7 +204,15 @@ static int xhci_plat_suspend(struct device *dev)
struct usb_hcd *hcd = dev_get_drvdata(dev);
struct xhci_hcd *xhci = hcd_to_xhci(hcd);
- return xhci_suspend(xhci);
+ /*
+* xhci_suspend() needs `do_wakeup` to know whether host is allowed
+* to do wakeup during suspend. Since xhci_plat_suspend is currently
+* only designed for system suspend, device_may_wakeup() is enough
+* to dertermine whether host is allowed to do wakeup. Need to
+* reconsider this when xhci_plat_suspend enlarges its scope, e.g.,
+* also applies to runtime suspend.
+*/
+ return xhci_suspend(xhci, device_may_wakeup(dev));
}
static int xhci_plat_resume(struct device *dev)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 4d0d240..033b46c 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -35,6 +35,8 @@
#define DRIVER_AUTHOR Sarah Sharp
#define DRIVER_DESC 'eXtensible' Host Controller (xHC) Driver
+#definePORT_WAKE_BITS (PORT_WKOC_E | PORT_WKDISC_E | PORT_WKCONN_E)
+
/* Some 0.95 hardware can't handle the chain bit on a Link TRB being cleared */
static int link_quirk;
module_param(link_quirk, int, S_IRUGO | S_IWUSR);
@@ -851,13 +853,47 @@ static void xhci_clear_command_ring(struct xhci_hcd *xhci)
xhci_set_cmd_ring_deq(xhci);
}
+static void xhci_disable_port_wake_on_bits(struct xhci_hcd *xhci)
+{
+ int port_index;
+ __le32 __iomem **port_array;
+ unsigned long flags;
+ u32 t1, t2;
+
+ spin_lock_irqsave(xhci-lock, flags);
+
+ /* disble usb3 ports Wake bits*/
+ port_index = xhci-num_usb3_ports;
+ port_array = xhci-usb3_ports;
+ while (port_index--) {
+ t1 = readl(port_array[port_index]);
+ t1 = xhci_port_state_to_neutral(t1);
+ t2 = t1 ~PORT_WAKE_BITS;
+ if (t1 != t2)
+ writel(t2, port_array[port_index]);
+ }
+
+ /* disble usb2 ports Wake bits*/
+ port_index = xhci-num_usb2_ports;
+ port_array = xhci-usb2_ports;
+ while (port_index--) {
+ t1 = readl(port_array[port_index]);
+ t1 = xhci_port_state_to_neutral(t1);
+ t2 = t1 ~PORT_WAKE_BITS;
+ if (t1 != t2)
+ writel(t2, port_array[port_index]);
+ }
+
+ spin_unlock_irqrestore(xhci-lock, flags);
+}
+
/*
* Stop HC (not bus-specific)
*
* This is called when the machine transition into S3/S4 mode.
*
*/
-int xhci_suspend(struct xhci_hcd *xhci)
+int xhci_suspend(struct xhci_hcd *xhci, bool do_wakeup)
{
int rc = 0;
unsigned intdelay = XHCI_MAX_HALT_USEC;
@@ -868,6 +904,10 @@ int xhci_suspend(struct xhci_hcd *xhci)
xhci-shared_hcd-state != HC_STATE_SUSPENDED)
return -EINVAL;
+ /* Clear root port wake on bits if wakeup not allowed. */
+ if (!do_wakeup)
+ xhci_disable_port_wake_on_bits(xhci);
+
/* Don't poll the roothubs on bus suspend. */
xhci_dbg(xhci, %s: stopping port polling.\n, __func__);
clear_bit(HCD_FLAG_POLL_RH, hcd-flags);
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index
[PATCHv3 3/4] Revert xhci: clear root port wake on bits if controller isn't wake-up capable
From: Lu Baolu baolu...@linux.intel.com
commit ff8cbf250b44 (xhci: clear root port wake on bits if controller isn't)
can cause device detection error if runtime PM is enabled, and S3 wake
is disabled. Revert it.
https://bugzilla.kernel.org/show_bug.cgi?id=85701
This commit got into stable and should be reverted from there as well.
Cc: stable sta...@vger.kernel.org # v3.2+
Signed-off-by: Lu Baolu baolu...@linux.intel.com
Reported-by: Dmitry Nezhevenko d...@inhex.net
[Mathias Nyman: reword commit message]
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci-hub.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c
index 696160d..388cfd8 100644
--- a/drivers/usb/host/xhci-hub.c
+++ b/drivers/usb/host/xhci-hub.c
@@ -22,7 +22,6 @@
#include linux/slab.h
-#include linux/device.h
#include asm/unaligned.h
#include xhci.h
@@ -1149,9 +1148,7 @@ int xhci_bus_suspend(struct usb_hcd *hcd)
* including the USB 3.0 roothub, but only if CONFIG_PM_RUNTIME
* is enabled, so also enable remote wake here.
*/
- if (hcd-self.root_hub-do_remote_wakeup
-device_may_wakeup(hcd-self.controller)) {
-
+ if (hcd-self.root_hub-do_remote_wakeup) {
if (t1 PORT_CONNECT) {
t2 |= PORT_WKOC_E | PORT_WKDISC_E;
t2 = ~PORT_WKCONN_E;
--
1.8.3.2
--
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
[PATCHv3 2/4] xhci: Reset a halted endpoint immediately when we encounter a stall.
If a device is halted and reuturns a STALL, then the halted endpoint
needs to be cleared both on the host and device side. The host
side halt is cleared by issueing a xhci reset endpoint command. The device side
is cleared with a ClearFeature(ENDPOINT_HALT) request, which should
be issued by the device driver if a URB reruen -EPIPE.
Previously we cleared the host side halt after the device side was cleared.
To make sure the host side halt is cleared in time we want to issue the
reset endpoint command immedialtely when a STALL status is encountered.
Otherwise we end up not following the specs and not returning -EPIPE
several times in a row when trying to transfer data to a halted endpoint.
Fixes: bcef3fd (USB: xhci: Handle errors that cause endpoint halts.)
Cc: sta...@vger.kernel.org # v2.6.33+
Tested-by: Felipe Balbi ba...@ti.com
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci-ring.c | 40 +++
drivers/usb/host/xhci.c | 65 ++--
2 files changed, 25 insertions(+), 80 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index fbd0342..06433ae 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1822,22 +1822,13 @@ static int finish_td(struct xhci_hcd *xhci, struct
xhci_td *td,
ep-stopped_td = td;
return 0;
} else {
- if (trb_comp_code == COMP_STALL) {
- /* The transfer is completed from the driver's
-* perspective, but we need to issue a set dequeue
-* command for this stalled endpoint to move the dequeue
-* pointer past the TD. We can't do that here because
-* the halt condition must be cleared first. Let the
-* USB class driver clear the stall later.
-*/
- ep-stopped_td = td;
- ep-stopped_stream = ep_ring-stream_id;
- } else if (xhci_requires_manual_halt_cleanup(xhci,
- ep_ctx, trb_comp_code)) {
- /* Other types of errors halt the endpoint, but the
-* class driver doesn't call usb_reset_endpoint() unless
-* the error is -EPIPE. Clear the halted status in the
-* xHCI hardware manually.
+ if (trb_comp_code == COMP_STALL ||
+ xhci_requires_manual_halt_cleanup(xhci, ep_ctx,
+ trb_comp_code)) {
+ /* Issue a reset endpoint command to clear the host side
+* halt, followed by a set dequeue command to move the
+* dequeue pointer past the TD.
+* The class driver clears the device side halt later.
*/
xhci_cleanup_halted_endpoint(xhci,
slot_id, ep_index, ep_ring-stream_id,
@@ -1957,9 +1948,7 @@ static int process_ctrl_td(struct xhci_hcd *xhci, struct
xhci_td *td,
else
td-urb-actual_length = 0;
- xhci_cleanup_halted_endpoint(xhci,
- slot_id, ep_index, 0, td, event_trb);
- return finish_td(xhci, td, event_trb, event, ep, status, true);
+ return finish_td(xhci, td, event_trb, event, ep, status, false);
}
/*
* Did we transfer any data, despite the errors that might have
@@ -2518,17 +2507,8 @@ cleanup:
if (ret) {
urb = td-urb;
urb_priv = urb-hcpriv;
- /* Leave the TD around for the reset endpoint function
-* to use(but only if it's not a control endpoint,
-* since we already queued the Set TR dequeue pointer
-* command for stalled control endpoints).
-*/
- if (usb_endpoint_xfer_control(urb-ep-desc) ||
- (trb_comp_code != COMP_STALL
- trb_comp_code != COMP_BABBLE))
- xhci_urb_free_priv(xhci, urb_priv);
- else
- kfree(urb_priv);
+
+ xhci_urb_free_priv(xhci, urb_priv);
usb_hcd_unlink_urb_from_ep(bus_to_hcd(urb-dev-bus),
urb);
if ((urb-actual_length != urb-transfer_buffer_length
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 2a5d45b..4d0d240 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -2912,68 +2912,33 @@ void xhci_cleanup_stalled_ring(struct xhci_hcd *xhci,
}
}
-/* Deal with
[PATCHv3 1/4] xhci: don't start a halted endpoint before its new dequeue is set
A halted endpoint ring must first be reset, then move the ring
dequeue pointer past the problematic TRB. If we start the ring too
early after reset, but before moving the dequeue pointer we
will end up executing the same problematic TRB again.
As we always issue a set transfer dequeue command after a reset
endpoint command we can skip starting endpoint rings at reset endpoint
command completion.
Without this fix we end up trying to handle the same faulty TD for
contol endpoints. causing timeout, and failing testusb ctrl_out write
tests.
Fixes: e9df17e (USB: xhci: Correct assumptions about number of rings per
endpoint.)
Cc: sta...@vger.kernel.org #v2.6.35
Tested-by: Felipe Balbi ba...@ti.com
Signed-off-by: Mathias Nyman mathias.ny...@linux.intel.com
---
drivers/usb/host/xhci-ring.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index bc6fcbc..fbd0342 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -1067,9 +1067,8 @@ static void xhci_handle_cmd_reset_ep(struct xhci_hcd
*xhci, int slot_id,
false);
xhci_ring_cmd_db(xhci);
} else {
- /* Clear our internal halted state and restart the ring(s) */
+ /* Clear our internal halted state */
xhci-devs[slot_id]-eps[ep_index].ep_state = ~EP_HALTED;
- ring_doorbell_for_active_rings(xhci, slot_id, ep_index);
}
}
--
1.8.3.2
--
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/3] USB: keyspan: fix overrun-error reporting
Fix reporting of overrun errors, which are not associated with a
character. Instead insert a null character and report only once.
Fixes: 1da177e4c3f4 (Linux-2.6.12-rc2)
Cc: stable sta...@vger.kernel.org
Signed-off-by: Johan Hovold jo...@kernel.org
---
drivers/usb/serial/keyspan.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/serial/keyspan.c b/drivers/usb/serial/keyspan.c
index 7799d8bc4a63..077c714f1285 100644
--- a/drivers/usb/serial/keyspan.c
+++ b/drivers/usb/serial/keyspan.c
@@ -311,12 +311,13 @@ static void usa26_indat_callback(struct urb *urb)
if ((data[0] 0x80) == 0) {
/* no errors on individual bytes, only
possible overrun err */
- if (data[0] RXERROR_OVERRUN)
- err = TTY_OVERRUN;
- else
- err = 0;
+ if (data[0] RXERROR_OVERRUN) {
+ tty_insert_flip_char(port-port, 0,
+ TTY_OVERRUN);
+ }
for (i = 1; i urb-actual_length ; ++i)
- tty_insert_flip_char(port-port, data[i], err);
+ tty_insert_flip_char(port-port, data[i],
+ TTY_NORMAL);
} else {
/* some bytes had errors, every byte has status */
dev_dbg(port-dev, %s - RX error\n, __func__);
@@ -787,13 +788,13 @@ static void usa90_indat_callback(struct urb *urb)
if ((data[0] 0x80) == 0) {
/* no errors on individual bytes, only
possible overrun err*/
- if (data[0] RXERROR_OVERRUN)
- err = TTY_OVERRUN;
- else
- err = 0;
+ if (data[0] RXERROR_OVERRUN) {
+ tty_insert_flip_char(port-port, 0,
+ TTY_OVERRUN);
+ }
for (i = 1; i urb-actual_length ; ++i)
tty_insert_flip_char(port-port,
- data[i], err);
+ data[i], TTY_NORMAL);
} else {
/* some bytes had errors, every byte has status */
dev_dbg(port-dev, %s - RX error\n,
__func__);
--
2.0.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/3] USB: ssu100: fix overrun-error reporting
Fix reporting of overrun errors, which should only be reported once
using the inserted null character.
Fixes: 6b8f1ca5581b (USB: ssu100: set tty_flags in ssu100_process_packet)
Cc: stable sta...@vger.kernel.org
Signed-off-by: Johan Hovold jo...@kernel.org
---
drivers/usb/serial/ssu100.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/serial/ssu100.c b/drivers/usb/serial/ssu100.c
index a7fe664b6b7d..70a098de429f 100644
--- a/drivers/usb/serial/ssu100.c
+++ b/drivers/usb/serial/ssu100.c
@@ -490,10 +490,9 @@ static void ssu100_update_lsr(struct usb_serial_port
*port, u8 lsr,
if (*tty_flag == TTY_NORMAL)
*tty_flag = TTY_FRAME;
}
- if (lsr UART_LSR_OE){
+ if (lsr UART_LSR_OE) {
port-icount.overrun++;
- if (*tty_flag == TTY_NORMAL)
- *tty_flag = TTY_OVERRUN;
+ tty_insert_flip_char(port-port, 0, TTY_OVERRUN);
}
}
@@ -511,12 +510,8 @@ static void ssu100_process_read_urb(struct urb *urb)
if ((len = 4)
(packet[0] == 0x1b) (packet[1] == 0x1b)
((packet[2] == 0x00) || (packet[2] == 0x01))) {
- if (packet[2] == 0x00) {
+ if (packet[2] == 0x00)
ssu100_update_lsr(port, packet[3], flag);
- if (flag == TTY_OVERRUN)
- tty_insert_flip_char(port-port, 0,
- TTY_OVERRUN);
- }
if (packet[2] == 0x01)
ssu100_update_msr(port, packet[3]);
--
2.0.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 1/3] USB: keyspan: fix tty line-status reporting
Fix handling of TTY error flags, which are not bitmasks and must
specifically not be ORed together as this prevents the line discipline
from recognising them.
Also insert null characters when reporting overrun errors as these are
not associated with the received character.
Fixes: 1da177e4c3f4 (Linux-2.6.12-rc2)
Cc: stable sta...@vger.kernel.org
Signed-off-by: Johan Hovold jo...@kernel.org
---
drivers/usb/serial/keyspan.c | 76
1 file changed, 48 insertions(+), 28 deletions(-)
diff --git a/drivers/usb/serial/keyspan.c b/drivers/usb/serial/keyspan.c
index 93cb7cebda62..7799d8bc4a63 100644
--- a/drivers/usb/serial/keyspan.c
+++ b/drivers/usb/serial/keyspan.c
@@ -321,14 +321,19 @@ static void usa26_indat_callback(struct urb *urb)
/* some bytes had errors, every byte has status */
dev_dbg(port-dev, %s - RX error\n, __func__);
for (i = 0; i + 1 urb-actual_length; i += 2) {
- int stat = data[i], flag = 0;
- if (stat RXERROR_OVERRUN)
- flag |= TTY_OVERRUN;
- if (stat RXERROR_FRAMING)
- flag |= TTY_FRAME;
- if (stat RXERROR_PARITY)
- flag |= TTY_PARITY;
+ int stat = data[i];
+ int flag = TTY_NORMAL;
+
+ if (stat RXERROR_OVERRUN) {
+ tty_insert_flip_char(port-port, 0,
+ TTY_OVERRUN);
+ }
/* XXX should handle break (0x10) */
+ if (stat RXERROR_PARITY)
+ flag = TTY_PARITY;
+ else if (stat RXERROR_FRAMING)
+ flag = TTY_FRAME;
+
tty_insert_flip_char(port-port, data[i+1],
flag);
}
@@ -649,14 +654,19 @@ static void usa49_indat_callback(struct urb *urb)
} else {
/* some bytes had errors, every byte has status */
for (i = 0; i + 1 urb-actual_length; i += 2) {
- int stat = data[i], flag = 0;
- if (stat RXERROR_OVERRUN)
- flag |= TTY_OVERRUN;
- if (stat RXERROR_FRAMING)
- flag |= TTY_FRAME;
- if (stat RXERROR_PARITY)
- flag |= TTY_PARITY;
+ int stat = data[i];
+ int flag = TTY_NORMAL;
+
+ if (stat RXERROR_OVERRUN) {
+ tty_insert_flip_char(port-port, 0,
+ TTY_OVERRUN);
+ }
/* XXX should handle break (0x10) */
+ if (stat RXERROR_PARITY)
+ flag = TTY_PARITY;
+ else if (stat RXERROR_FRAMING)
+ flag = TTY_FRAME;
+
tty_insert_flip_char(port-port, data[i+1],
flag);
}
@@ -713,15 +723,19 @@ static void usa49wg_indat_callback(struct urb *urb)
*/
for (x = 0; x + 1 len
i + 1 urb-actual_length; x += 2) {
- int stat = data[i], flag = 0;
+ int stat = data[i];
+ int flag = TTY_NORMAL;
- if (stat RXERROR_OVERRUN)
- flag |= TTY_OVERRUN;
- if (stat RXERROR_FRAMING)
- flag |= TTY_FRAME;
- if (stat RXERROR_PARITY)
- flag |= TTY_PARITY;
+ if (stat RXERROR_OVERRUN) {
+ tty_insert_flip_char(port-port, 0,
+ TTY_OVERRUN);
+ }
/* XXX should handle break (0x10) */
+ if (stat RXERROR_PARITY)
+ flag = TTY_PARITY;
+ else if (stat RXERROR_FRAMING)
+
Re: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5
2014-11-18 10:02 GMT+01:00 Enric Balletbo Serra eballe...@gmail.com: Hi Tony, 2014-11-17 19:04 GMT+01:00 Tony Lindgren t...@atomide.com: * Enric Balletbo Serra eballe...@gmail.com [141117 07:15]: Hi all, I'm trying to use the USB OTG driver of OMAP3 processor in HOST mode when it's configured in dual role mode (CONFIG_USB_MUSB_DUAL_ROLE=y) The test case that I'm trying to solve is as follows. 1) Boot the board. 2) Put the USB ID pin to ground 3) Connect a pendrive. In such case doesn't work as expected and pendrive is never detected. Enabling debug information, I see that the phyter (twl4030) is constantly polling the STS_HW_CONDITIONS register, who reports: twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1 The STS_HW_CONDITIONS register reports: Bit 2: STS_USB : 1: USB is plugged in. Bit 4: STS_WAKEUP1: Level status of WAKEUP1 pad (active high) = nSLEEP1 Bit 6: STS_WAKEUP3: Level status of WAKEUP3 pad (active high) = CLKREQ I guess that in this case the state machine is waiting for VBUS, and looks for bit 7 STS_VBUS (Level status of VBUS port), but this never occurs. Using an oscilloscope I checked VBUS level and I can confirm that it's a 0 level. My understand is that in this case the driver should enable VBUS but I didn't find where is the best place to do this and why is not doing this already. Any clue on this? Just tested v3.18-rc5 with beagleboard xm, and the host mode enumerates the devices, then may fail with insufficient bus power at least for the WLAN device I tried with. Is this with following options ? CONFIG_USB_MUSB_DUAL_ROLE=y # CONFIG_USB_MUSB_HOST is not set # CONFIG_USB_MUSB_GADGET is not set Because with these options doesn't work for me. It only works if I don't use dual role mode CONFIG_USB_MUSB_HOST=y CONFIG_USB_MUSB_DUAL_ROLE is not set Sorry this is not true, it only works if I set mode = 1 in my device tree, either it's CONFIG_USB_MUSB_DUAL_ROLE=y or CONFIG_USB_MUSB_HOST=y configured. I noticed that this only works with CONFIG_USB_MUSB_HDRC and CONFIG_TWL4030_USB built into the kernel. No luck so far with them as loadable modules for some reason. Looks like also USB gadgets fail with MUSB as modules. It's weird, for me fails in both cases, built-in and with loadable modules. Connecting the OTG Cable Adapter with a pendrive reports [ 51.462432] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1 [ 51.470916] twl4030_usb 4807.i2c:twl@48:twl4030-usb: twl4030_usb_runtime_resume [ 51.487274] musb-hdrc musb-hdrc.0.auto: ID GND [ 52.480712] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1 [ 53.489044] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1 And then polls until I disconnect the OTG Cable Adapter with the pendrive. [ 71.488983] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1 [ 71.778930] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x50/80; link 4 [ 71.787536] musb-hdrc musb-hdrc.0.auto: VBUS Disconnect [ 72.489044] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x50/80; link 4 [ 74.088714] twl4030_usb 4807.i2c:twl@48:twl4030-usb: twl4030_usb_runtime_suspend And on the 37xx EVM, I've never had any luck getting any twl4030_usb interrupts for some reason. Regards, Enric Regards, Tony -- 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 5/5] mfd: tc6387xb: prepare/unprepare clocks
On Mon, 17 Nov 2014, Dmitry Eremin-Solenikov wrote: Change clk_enable/disable() calls to clk_prepare_enable() and clk_disable_unprepare(). Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com --- drivers/mfd/tc6387xb.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) Looks good. Applied, thanks. diff --git a/drivers/mfd/tc6387xb.c b/drivers/mfd/tc6387xb.c index e71f880..85fab37 100644 --- a/drivers/mfd/tc6387xb.c +++ b/drivers/mfd/tc6387xb.c @@ -52,7 +52,7 @@ static int tc6387xb_suspend(struct platform_device *dev, pm_message_t state) if (pdata pdata-suspend) pdata-suspend(dev); - clk_disable(tc6387xb-clk32k); + clk_disable_unprepare(tc6387xb-clk32k); return 0; } @@ -62,7 +62,7 @@ static int tc6387xb_resume(struct platform_device *dev) struct tc6387xb *tc6387xb = platform_get_drvdata(dev); struct tc6387xb_platform_data *pdata = dev_get_platdata(dev-dev); - clk_enable(tc6387xb-clk32k); + clk_prepare_enable(tc6387xb-clk32k); if (pdata pdata-resume) pdata-resume(dev); @@ -100,7 +100,7 @@ static int tc6387xb_mmc_enable(struct platform_device *mmc) struct platform_device *dev = to_platform_device(mmc-dev.parent); struct tc6387xb *tc6387xb = platform_get_drvdata(dev); - clk_enable(tc6387xb-clk32k); + clk_prepare_enable(tc6387xb-clk32k); tmio_core_mmc_enable(tc6387xb-scr + 0x200, 0, tc6387xb_mmc_resources[0].start 0xfffe); @@ -113,7 +113,7 @@ static int tc6387xb_mmc_disable(struct platform_device *mmc) struct platform_device *dev = to_platform_device(mmc-dev.parent); struct tc6387xb *tc6387xb = platform_get_drvdata(dev); - clk_disable(tc6387xb-clk32k); + clk_disable_unprepare(tc6387xb-clk32k); return 0; } @@ -214,7 +214,7 @@ static int tc6387xb_remove(struct platform_device *dev) mfd_remove_devices(dev-dev); iounmap(tc6387xb-scr); release_resource(tc6387xb-rscr); - clk_disable(tc6387xb-clk32k); + clk_disable_unprepare(tc6387xb-clk32k); clk_put(tc6387xb-clk32k); kfree(tc6387xb); -- 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 v7 1/2] usb: host: xhci-plat: Get PHYs for xhci's hcds
On Mon, Nov 17, 2014 at 9:46 PM, Sergei Shtylyov sergei.shtyl...@cogentembedded.com wrote: Hello. On 11/17/2014 9:36 AM, Vivek Gautam wrote: The host controller by itself may sometimes need to handle PHY and re-initialize it to re-configure some of the PHY parameters to get full support out of the PHY controller. Therefore, facilitate getting the two possible PHYs, viz. USB 2.0 type (UTMI+) and USB 3.0 type (PIPE3), and initialize them. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- drivers/usb/host/xhci-plat.c | 74 ++ 1 file changed, 74 insertions(+) diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c index 3d78b0c..5207d5b 100644 --- a/drivers/usb/host/xhci-plat.c +++ b/drivers/usb/host/xhci-plat.c [...] @@ -204,6 +271,8 @@ static int xhci_plat_suspend(struct device *dev) struct usb_hcd *hcd = dev_get_drvdata(dev); struct xhci_hcd *xhci = hcd_to_xhci(hcd); + phy_exit(hcd-phy); Hm, in the suspend() method? phy_exit() should eventually be suspending the PHY and put it to low power state. I thought it's a role that the power_off() mothod should play, considering that the power_on() method gets called after the init() method phy_power_off() should be cutting the clocks and power from PHY completely, no ? In that case one may not be able to wakeup the system from USB. So phy_exit() gets the responsibility to put the PHY into low power state. Ccing Kishon also to get his opinion on actual role of the two callbacks - phy_init/exit() and phy_power_on/off(). phy_init() in resume() will then take up the task of activating the PHY again. phy_power_on() and phy_power_off() are called at xhci_probe() and remove() time. Of course. Does this makes sense ? Not much, really. WBR, Sergei -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- 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] usbnet: rtl8150: remove unused variable
we were just returning the initial value of res, instead now
we are returning the value directly.
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
drivers/net/usb/rtl8150.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
index 6e87e57..d37b7dc 100644
--- a/drivers/net/usb/rtl8150.c
+++ b/drivers/net/usb/rtl8150.c
@@ -753,14 +753,13 @@ static int rtl8150_open(struct net_device *netdev)
static int rtl8150_close(struct net_device *netdev)
{
rtl8150_t *dev = netdev_priv(netdev);
- int res = 0;
netif_stop_queue(netdev);
if (!test_bit(RTL8150_UNPLUG, dev-flags))
disable_net_traffic(dev);
unlink_all_urbs(dev);
- return res;
+ return 0;
}
static void rtl8150_get_drvinfo(struct net_device *netdev, struct
ethtool_drvinfo *info)
--
1.8.1.2
--
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 4/5] mfd: t7l66xb: prepare/unprepare clocks
On Mon, 17 Nov 2014, Dmitry Eremin-Solenikov wrote: Change clk_enable/disable() calls to clk_prepare_enable() and clk_disable_unprepare(). Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com --- drivers/mfd/t7l66xb.c | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) Applied, thanks. diff --git a/drivers/mfd/t7l66xb.c b/drivers/mfd/t7l66xb.c index 9e04a74..439d905 100644 --- a/drivers/mfd/t7l66xb.c +++ b/drivers/mfd/t7l66xb.c @@ -87,7 +87,7 @@ static int t7l66xb_mmc_enable(struct platform_device *mmc) unsigned long flags; u8 dev_ctl; - clk_enable(t7l66xb-clk32k); + clk_prepare_enable(t7l66xb-clk32k); spin_lock_irqsave(t7l66xb-lock, flags); @@ -118,7 +118,7 @@ static int t7l66xb_mmc_disable(struct platform_device *mmc) spin_unlock_irqrestore(t7l66xb-lock, flags); - clk_disable(t7l66xb-clk32k); + clk_disable_unprepare(t7l66xb-clk32k); return 0; } @@ -285,7 +285,7 @@ static int t7l66xb_suspend(struct platform_device *dev, pm_message_t state) if (pdata pdata-suspend) pdata-suspend(dev); - clk_disable(t7l66xb-clk48m); + clk_disable_unprepare(t7l66xb-clk48m); return 0; } @@ -295,7 +295,7 @@ static int t7l66xb_resume(struct platform_device *dev) struct t7l66xb *t7l66xb = platform_get_drvdata(dev); struct t7l66xb_platform_data *pdata = dev_get_platdata(dev-dev); - clk_enable(t7l66xb-clk48m); + clk_prepare_enable(t7l66xb-clk48m); if (pdata pdata-resume) pdata-resume(dev); @@ -369,7 +369,7 @@ static int t7l66xb_probe(struct platform_device *dev) goto err_ioremap; } - clk_enable(t7l66xb-clk48m); + clk_prepare_enable(t7l66xb-clk48m); if (pdata pdata-enable) pdata-enable(dev); @@ -414,9 +414,9 @@ static int t7l66xb_remove(struct platform_device *dev) int ret; ret = pdata-disable(dev); - clk_disable(t7l66xb-clk48m); + clk_disable_unprepare(t7l66xb-clk48m); clk_put(t7l66xb-clk48m); - clk_disable(t7l66xb-clk32k); + clk_disable_unprepare(t7l66xb-clk32k); clk_put(t7l66xb-clk32k); t7l66xb_detach_irq(dev); iounmap(t7l66xb-scr); -- 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
[PATCH] usb: gadget: USB3 support to the legacy printer driver
Hi Felipe/Greg Thanks for your comments on my previous attempt. I think I addressed them here. I added some logs of a run captured on a recent kernel, fixed the indentations, replaced the if/else with a switch statement and removed the copyright. Note that the tests seem to indicate a performance issue on the net2280 driver: the exact same tests using the usb338x.c driver from PLX allows for transfer speeds of 1Gbps. cheers Jorge File transfer test using g_printer on 10b5:3380 The host will transfer a file to the device using the g_printer driver. 0) enable the net2280 on the g_printer: -- From 8e306693839a77bfe3411a842d4d20acb9dae9e3 Mon Sep 17 00:00:00 2001 From: Jorge Ramirez-Ortiz jorge.ramirez-or...@linaro.org Date: Mon, 17 Nov 2014 22:31:59 -0500 Subject: [PATCH] use the 338x --- drivers/usb/gadget/legacy/printer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/legacy/printer.c b/drivers/usb/gadget/legacy/printer.c index 456730b..ba919a0 100644 --- a/drivers/usb/gadget/legacy/printer.c +++ b/drivers/usb/gadget/legacy/printer.c @@ -99,8 +99,8 @@ static struct printer_dev usb_printer_gadget; /* Thanks to NetChip Technologies for donating this product ID. */ -#define PRINTER_VENDOR_NUM 0x0525 /* NetChip */ -#define PRINTER_PRODUCT_NUM0xa4a8 /* Linux-USB Printer Gadget */ +#define PRINTER_VENDOR_NUM 0x10B5 +#define PRINTER_PRODUCT_NUM0x3380 /* Some systems will want different product identifiers published in the * device descriptor, either numbers or strings or both. These string -- 1.9.1 1) Host logs: - [jramirez@miro ~]$ lsusb Bus 002 Device 006: ID 05ac:1303 Apple, Inc. iPod Shuffle 4.Gen Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 007: ID 10b5:3380 Comodo (PLX?) Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Bus 001 Device 003: ID 046d:0990 Logitech, Inc. QuickCam Pro 9000 Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub [jramirez@miro ~]$ lsusb -s 004:007 -v Bus 004 Device 007: ID 10b5:3380 Comodo (PLX?) Couldn't open device, some information will be missing Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x10b5 Comodo (PLX?) idProduct 0x3380 bcdDevice3.18 iManufacturer 1 iProduct2 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 44 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 7 Printer bInterfaceSubClass 1 Printer bInterfaceProtocol 2 Bidirectional iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 [jramirez@miro host.git (master%)]$ sudo ./usbhost file.wav [sudo] password for jramirez: Opening device 10B5:3380... Device properties: bus number: 4 port path: 2 (from root hub) device speed: 5000 Mbit/s (USB SuperSpeed) Reading device descriptor: length: 18 device
Re: Huawei E173 USB modem
On 2014-11-18 14:48, Jesse van der Berg wrote: Hi, uname -a Linux Firen4ALL 3.17.3-031703-generic #201411141335 SMP Fri Nov 14 18:36:40 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux Gives me the following in the syslog when I attach a Huawei E173 3G USB modem to my computer. I don't know if it's relevant but the modem supports storage though there is no SD card inserted in it. Nov 18 08:07:43 Firen4ALL kernel: [70171.770676] usb 1-1.2: new high-speed USB device number 11 using ehci-pci Nov 18 08:07:43 Firen4ALL kernel: [70171.865310] usb 1-1.2: New USB device found, idVendor=12d1, idProduct=1446 12d1:1446 is the usb id of a dongle in Windows install mode (virtual cd-rom) where it only has interfaces of storage type, forcing the usbserial driver onto such interfaces will produce the errors you see in the log. Install usb_modeswitch which will switch the dongle to modem mode and make sure you have the serial driver named option in your system. Lars -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: USB3 support to the legacy printer driver
Hi, On Tue, Nov 18, 2014 at 09:19:36AM -0500, Jorge Ramirez-Ortiz wrote: Hi Felipe/Greg Thanks for your comments on my previous attempt. I think I addressed them here. no you haven't. Read Documentation/SubmittingPatches, read the mailing list archives and you'll see your basic mistake. I added some logs of a run captured on a recent kernel, fixed the indentations, replaced the if/else with a switch statement and removed the copyright. Note that the tests seem to indicate a performance issue on the net2280 driver: the exact same tests using the usb338x.c driver from PLX allows for transfer speeds of 1Gbps. cheers Jorge File transfer test using g_printer on 10b5:3380 The host will transfer a file to the device using the g_printer driver. 0) enable the net2280 on the g_printer: -- From 8e306693839a77bfe3411a842d4d20acb9dae9e3 Mon Sep 17 00:00:00 2001 From: Jorge Ramirez-Ortiz jorge.ramirez-or...@linaro.org Date: Mon, 17 Nov 2014 22:31:59 -0500 Subject: [PATCH] use the 338x --- drivers/usb/gadget/legacy/printer.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/legacy/printer.c b/drivers/usb/gadget/legacy/printer.c index 456730b..ba919a0 100644 --- a/drivers/usb/gadget/legacy/printer.c +++ b/drivers/usb/gadget/legacy/printer.c @@ -99,8 +99,8 @@ static struct printer_dev usb_printer_gadget; /* Thanks to NetChip Technologies for donating this product ID. */ -#define PRINTER_VENDOR_NUM 0x0525 /* NetChip */ -#define PRINTER_PRODUCT_NUM0xa4a8 /* Linux-USB Printer Gadget */ +#define PRINTER_VENDOR_NUM 0x10B5 +#define PRINTER_PRODUCT_NUM0x3380 you have no clue what these mean, do you ? How about reading the USB specification of even http://www.beyondlogic.org/usbnutshell/usb1.shtml Changing these will not cause you to use usb338x driver, you're just using a vendor/product ID you don't own. /* Some systems will want different product identifiers published in the * device descriptor, either numbers or strings or both. These string -- 1.9.1 1) Host logs: - [jramirez@miro ~]$ lsusb Bus 002 Device 006: ID 05ac:1303 Apple, Inc. iPod Shuffle 4.Gen Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 007: ID 10b5:3380 Comodo (PLX?) Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Bus 001 Device 003: ID 046d:0990 Logitech, Inc. QuickCam Pro 9000 Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub [jramirez@miro ~]$ lsusb -s 004:007 -v Bus 004 Device 007: ID 10b5:3380 Comodo (PLX?) Couldn't open device, some information will be missing Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 3.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 9 idVendor 0x10b5 Comodo (PLX?) idProduct 0x3380 bcdDevice3.18 iManufacturer 1 iProduct2 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 44 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 7 Printer bInterfaceSubClass 1 Printer bInterfaceProtocol 2 Bidirectional iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0400 1x 1024 bytes bInterval 0 bMaxBurst 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT
Re: [PATCH v2 1/3] usb: chipidea: add controller reset API
On Mon, Nov 17, 2014 at 10:19:49AM +0800, Peter Chen wrote: On Fri, Nov 14, 2014 at 09:06:47AM -0600, Felipe Balbi wrote: On Fri, Nov 14, 2014 at 03:33:44PM +0800, Peter Chen wrote: On Thu, Nov 13, 2014 at 09:55:34PM -0600, Felipe Balbi wrote: Hi, On Fri, Nov 14, 2014 at 08:03:15AM +0800, Peter Chen wrote: Add controller reset API, it may be used for host/otg driver in future. you need a better commit log here. How would it be used ? when ? And, more importantly, why ? I will add more information Why would we need to reset the IP outside of -probe() ? I don't oppose to the refactoring, but why would we ever need to reset this IP ? Usually, we need to below reset controller at below situations: - Role switch, host-device and device-host - Return from hibernation, which the controller will lost its power, and the content of the register are lost. resetting is probably not the best solution in either case, though. It might be the easiest, but not the best. For suspend/resume, you would be better off saving/restoring contenxt and for role switch, you could just reprogram the few registers which need to change when role swapping. For safe reason, it is better to do reset controller at above two situations. Why we need to do reset at probe, it may also work if we program register directly. safety ? That's marketting parlance for I don't know how this works :-) In any case, it has been there for such a long time anyway so I won't block $subject. Still something to add to your TODO list. -- balbi signature.asc Description: Digital signature
Re: [PATCHv4 2/6] phy: improved lookup method
On Tue, Nov 18, 2014 at 10:49:18AM +0530, Kishon Vijay Abraham I wrote: On Monday 17 November 2014 09:10 PM, Heikki Krogerus wrote: On Thu, Nov 13, 2014 at 07:03:01PM +0530, Vivek Gautam wrote: How about adding the change in attached patch [1] on top of this patch. Just introduced the phy pointer in phy_lookup structure, and modified phy_find() accordingly. I would be fine if we used the phy pointer to match, but if we have the pointer to the phy in the lookup, then I would say we need to remove the phy_name member. Otherwise we would have to support two ways of finding the lookups (one for the static lookups where we match to the phy_name and other where we match to the pointer). That means we will also not be able to create static lookups, but those would be only needed if we wanted to create them in board files. I don't think there will ever be need to create the lookups in board files, so I'm more then happy to remove the static way of creating the lookups. Just using the phy pointer sounds good. But interested to know where the phy pointer will be added to the lookup table. I'm making assumption that there will not be any (new) platforms where the bindings are not provided in HW descriptions like dt or ACPI tables. That leaves the lookups to be useful only in cases where a driver has to, for whatever reason, pass it's phy's forward, like dwc3 host. ULPI will be an other case where we will need to use them. Now the only user for the lookups is twl4030-usb, but since it's actually just ULPI type PHY in cases where we have platform data to deal with (please correct me if I'm wrong), I think we could later remove it's need for platform data completely with the help of the ULPI bus I'm working with. Cheers, -- heikki -- 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: USB OTG doesn't work in HOST mode on OMAP3 processor on 3.18-rc5
* Enric Balletbo Serra eballe...@gmail.com [141118 01:04]: Hi Tony, 2014-11-17 19:04 GMT+01:00 Tony Lindgren t...@atomide.com: Just tested v3.18-rc5 with beagleboard xm, and the host mode enumerates the devices, then may fail with insufficient bus power at least for the WLAN device I tried with. Is this with following options ? CONFIG_USB_MUSB_DUAL_ROLE=y # CONFIG_USB_MUSB_HOST is not set # CONFIG_USB_MUSB_GADGET is not set Because with these options doesn't work for me. It only works if I don't use dual role mode CONFIG_USB_MUSB_HOST=y CONFIG_USB_MUSB_DUAL_ROLE is not set Weird. Yes I have CONFIG_USB_MUSB_DUAL_ROLE. AFAIK there's actually no way to disable the role switching in MUSB hardware, the hardware tries to do things on it's own anyways. So it's probably best to always set it to CONFIG_USB_MUSB_DUAL_ROLE=y unless size of the code is an issue. I noticed that this only works with CONFIG_USB_MUSB_HDRC and CONFIG_TWL4030_USB built into the kernel. No luck so far with them as loadable modules for some reason. Looks like also USB gadgets fail with MUSB as modules. I found the core issue with loadable modules, we currently need to have just one platform glue layer module compiled in. I have a fix coming up for that.. It's weird, for me fails in both cases, built-in and with loadable modules. Connecting the OTG Cable Adapter with a pendrive reports [ 51.462432] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1 [ 51.470916] twl4030_usb 4807.i2c:twl@48:twl4030-usb: twl4030_usb_runtime_resume [ 51.487274] musb-hdrc musb-hdrc.0.auto: ID GND [ 52.480712] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1 [ 53.489044] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1 And then polls until I disconnect the OTG Cable Adapter with the pendrive. [ 71.488983] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x54/84; link 1 [ 71.778930] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x50/80; link 4 [ 71.787536] musb-hdrc musb-hdrc.0.auto: VBUS Disconnect [ 72.489044] twl4030_usb 4807.i2c:twl@48:twl4030-usb: HW_CONDITIONS 0x50/80; link 4 [ 74.088714] twl4030_usb 4807.i2c:twl@48:twl4030-usb: twl4030_usb_runtime_suspend Looks like the twl4030-usb is producing interrupts alright. Maybe check your MUSB configuration one more time. See the attached patch, but note you need to only select the glue layer for the CONFIG_USB_MUSB_OMAP2PLUS option and disable other glue layer module options. Also, you may want to monitor the VBUS line in host mode. If the VBUS does not come up fast enough, MUSB hardware will give up as it's again trying to do things on its own. And on the 37xx EVM, I've never had any luck getting any twl4030_usb interrupts for some reason. Turns out the 37xx EVM is using an isp1507 phy instead of the twl4030 phy. The proper fix for that will be to start using the usb-nop-xceiv or phy-ulpi when we have drivers/phy/ driver for it. Right now trying to use it seems to fail with the following error: HS USB OTG: no PHY configured Regards, Tony 8 - From: Tony Lindgren t...@atomide.com Date: Mon, 17 Nov 2014 07:53:59 -0800 Subject: [PATCH] ARM: omap2plus_defconfig: Enable USB as loadable modules NOTE: Currently only one MUSB glue layer can be selected below because of the ifdefs, I'll do a fix for that. --- a/arch/arm/configs/omap2plus_defconfig +++ b/arch/arm/configs/omap2plus_defconfig @@ -270,17 +270,92 @@ CONFIG_SND_OMAP_SOC_OMAP_ABE_TWL6040=m CONFIG_SND_OMAP_SOC_OMAP3_PANDORA=m CONFIG_USB=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y +CONFIG_USB_DYNAMIC_MINORS=y +CONFIG_USB_OTG=y CONFIG_USB_MON=y CONFIG_USB_WDM=y CONFIG_USB_STORAGE=y +CONFIG_USB_MUSB_HDRC=m +CONFIG_USB_MUSB_TUSB6010=m +CONFIG_USB_MUSB_OMAP2PLUS=m +CONFIG_USB_MUSB_AM35X=m +CONFIG_USB_MUSB_DSPS=m CONFIG_USB_DWC3=m -CONFIG_USB_TEST=y -CONFIG_AM335X_PHY_USB=y +CONFIG_USB_SERIAL=m +CONFIG_USB_SERIAL_GENERIC=y +CONFIG_USB_SERIAL_SIMPLE=m +CONFIG_USB_SERIAL_FTDI_SIO=m +CONFIG_USB_SERIAL_PL2303=m +CONFIG_USB_EMI62=m +CONFIG_USB_EMI26=m +CONFIG_USB_ADUTUX=m +CONFIG_USB_SEVSEG=m +CONFIG_USB_RIO500=m +CONFIG_USB_LEGOTOWER=m +CONFIG_USB_LCD=m +CONFIG_USB_LED=m +CONFIG_USB_CYPRESS_CY7C63=m +CONFIG_USB_CYTHERM=m +CONFIG_USB_IDMOUSE=m +CONFIG_USB_FTDI_ELAN=m +CONFIG_USB_APPLEDISPLAY=m +CONFIG_USB_SISUSBVGA=m +CONFIG_USB_SISUSBVGA_CON=y +CONFIG_USB_LD=m +CONFIG_USB_TRANCEVIBRATOR=m +CONFIG_USB_IOWARRIOR=m +CONFIG_USB_TEST=m +CONFIG_USB_EHSET_TEST_FIXTURE=m +CONFIG_USB_ISIGHTFW=m +CONFIG_USB_YUREX=m +CONFIG_USB_EZUSB_FX2=m +CONFIG_USB_HSIC_USB3503=m +CONFIG_USB_LINK_LAYER_TEST=m +CONFIG_NOP_USB_XCEIV=y +CONFIG_AM335X_PHY_USB=m +CONFIG_TWL6030_USB=m +CONFIG_USB_GPIO_VBUS=m +CONFIG_USB_ISP1301=m +CONFIG_USB_ULPI=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_DEBUG=y CONFIG_USB_GADGET_DEBUG_FILES=y CONFIG_USB_GADGET_DEBUG_FS=y +CONFIG_USB_CONFIGFS=m
Re: [PATCH V2 3/5] usb: gadget: pxa25x_udc: prepare/unprepare clocks in pxa-ssp
On Tue, Nov 18, 2014 at 12:05:45AM +0400, Dmitry Eremin-Solenikov wrote:
Hello,
2014-11-17 21:44 GMT+03:00 Robert Jarzmik robert.jarz...@free.fr:
Dmitry Eremin-Solenikov dbarysh...@gmail.com writes:
Change clk_enable/disable() calls to clk_prepare_enable() and
clk_disable_unprepare().
Signed-off-by: Dmitry Eremin-Solenikov dbarysh...@gmail.com
---
drivers/usb/gadget/udc/pxa25x_udc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/udc/pxa25x_udc.c
b/drivers/usb/gadget/udc/pxa25x_udc.c
index 42f7eeb..e4964ee 100644
--- a/drivers/usb/gadget/udc/pxa25x_udc.c
+++ b/drivers/usb/gadget/udc/pxa25x_udc.c
@@ -103,8 +103,8 @@ static const char ep0name [] = ep0;
/* IXP doesn't yet support linux/clk.h */
#define clk_get(dev,name)NULL
-#define clk_enable(clk) do { } while (0)
-#define clk_disable(clk) do { } while (0)
+#define clk_prepare_enable(clk) do { } while (0)
+#define clk_disable_unprepare(clk) do { } while (0)
#define clk_put(clk) do { } while (0)
#endif
@@ -932,7 +932,7 @@ static int pullup(struct pxa25x_udc *udc)
if (!udc-active) {
udc-active = 1;
/* Enable clock for USB device */
- clk_enable(udc-clk);
+ clk_prepare_enable(udc-clk);
Guess what, Russell's remark on i2c and serial made me cross-check. And
there
is a case where this will be called in irq context too ...
See :
- do_IRQ
- lubbock_vbus_irq()
- pxa25x_udc_vbus_session()
- pullup()
- clk_prepare_enable()
- CRACK
Note that your patch is not really the faulty one, I think a threaded irq
instead of the raw irq should do the trick. And it is granted on UDC api
that
vbus function is called in a sleeping context (Felipe correct me if I'm
wrong), so a patch to fix this before your current code would be fine.
Well, from the framework point of view, -pullup() is only called
outside of IRQ context. But I see you're calling it from vbus_irq(), so
you brought this upon yourself :-)
--
balbi
signature.asc
Description: Digital signature
Re: [RFC v6 3/3] usb: phy: hold wakeupsource when USB is enumerated in peripheral mode
Hi,
On Wed, Nov 12, 2014 at 12:11:19PM +0530, Kiran Kumar Raparthy wrote:
From: Todd Poynor toddpoy...@google.com
usb: phy: hold wakeupsource when USB is enumerated in peripheral mode
Some systems require a mechanism to prevent system to enter into suspend
state when USB is connected and enumerated in peripheral mode.
This patch provides an interface to hold a wakeupsource to prevent suspend.
PHY drivers can use this interface when USB is connected and enumerated in
peripheral mode.
A timed wakeupsource is temporarily held on USB disconnect events, to allow
the rest of the system to react to the USB disconnection (dropping host
sessions, updating charger status, etc.) prior to re-allowing suspend.
Cc: Felipe Balbi ba...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: Android Kernel Team kernel-t...@android.com
Cc: John Stultz john.stu...@linaro.org
Cc: Sumit Semwal sumit.sem...@linaro.org
Cc: Arve Hj�nnev�g a...@android.com
Cc: Benoit Goby ben...@android.com
Signed-off-by: Todd Poynor toddpoy...@google.com
[kiran: Added context to commit message, squished build fixes
from Benoit Goby and Arve Hjønnevåg, changed wakelocks usage
to wakeupsource, merged Todd's refactoring logic and simplified
the structures and code and addressed community feedback]
Signed-off-by: Kiran Raparthy kiran.ku...@linaro.org
---
drivers/usb/phy/phy.c | 29 +++--
include/linux/usb/phy.h | 5 +
2 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index 2b1039e..b5c5fd3 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -329,6 +329,7 @@ int usb_add_phy(struct usb_phy *x, enum usb_phy_type type)
int ret = 0;
unsigned long flags;
struct usb_phy *phy;
+ char wsource_name[40];
if (x-type != USB_PHY_TYPE_UNDEFINED) {
dev_err(x-dev, not accepting initialized PHY %s\n, x-label);
@@ -351,6 +352,10 @@ int usb_add_phy(struct usb_phy *x, enum usb_phy_type
type)
x-type = type;
list_add_tail(x-head, phy_list);
+ snprintf(wsource_name, sizeof(wsource_name), vbus-%s,
+ dev_name(x-dev));
+ wakeup_source_init(x-wsource, wsource_name);
do you really need the device name on the wakeup source or would
usb-vbus suffice ? Hmm, I guess we could have several of these in the
same system, so maybe there's no other way.
@@ -446,13 +452,32 @@ int usb_bind_phy(const char *dev_name, u8 index,
EXPORT_SYMBOL_GPL(usb_bind_phy);
/**
- * usb_phy_set_event - set event to phy event
+ * usb_phy_set_event - set event to phy event and
+ * hold/temporarily hold wakeupsource
* @x: the phy returned by usb_get_phy();
*
- * This sets event to phy event
+ * This holds per-PHY wakeupsource/timed wakeupsource
*/
void usb_phy_set_event(struct usb_phy *x, unsigned long event)
{
+
x-last_event = event;
+
+ switch (event) {
+ case USB_EVENT_ENUMERATED:
+ __pm_stay_awake(x-wsource);
+ break;
+
+ case USB_EVENT_NONE:
+ case USB_EVENT_ID:
+ case USB_EVENT_VBUS:
+ case USB_EVENT_CHARGER:
+ __pm_wakeup_event(x-wsource,
+ msecs_to_jiffies(TEMPORARY_HOLD_TIME));
+ break;
+
+ default:
+ break;
+ }
much, much better. Completely hidden from PHY drivers.
}
EXPORT_SYMBOL_GPL(usb_phy_set_event);
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 3c713ff..bc58fb8 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -12,6 +12,8 @@
#include linux/notifier.h
#include linux/usb.h
+#define TEMPORARY_HOLD_TIME2000
minor nit:
Let's call this:
#define USB_PHY_DEFAULT_WAKEUP_SRC_TIMEOUT 2000 /* ms */
When resending, please drop that RFC from subject and make sure your
series is sent as a single thread, instead of three separate patches.
cheers
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] usbnet: rtl8150: remove unused variable
On 14-11-18 18:29:59, Sudip Mukherjee wrote:
we were just returning the initial value of res, instead now
we are returning the value directly.
Looks OK, but could you please fix the wording of the commit message to
something like:
Remove unused variable.
This is a tiny patch and the code speaks for itself.
Petko
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
drivers/net/usb/rtl8150.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
index 6e87e57..d37b7dc 100644
--- a/drivers/net/usb/rtl8150.c
+++ b/drivers/net/usb/rtl8150.c
@@ -753,14 +753,13 @@ static int rtl8150_open(struct net_device *netdev)
static int rtl8150_close(struct net_device *netdev)
{
rtl8150_t *dev = netdev_priv(netdev);
- int res = 0;
netif_stop_queue(netdev);
if (!test_bit(RTL8150_UNPLUG, dev-flags))
disable_net_traffic(dev);
unlink_all_urbs(dev);
- return res;
+ return 0;
}
static void rtl8150_get_drvinfo(struct net_device *netdev, struct
ethtool_drvinfo *info)
--
1.8.1.2
--
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: resume root hub when device detect with suspend state
On Tue, 18 Nov 2014, Kever Yang wrote:
After we implement the bus_suspend/resume, auto suspend id enabled.
The root hub will be auto suspend if there is no device connected,
we need to resume the root hub when a device connect detect.
This patch tested on rk3288.
Signed-off-by: Roy Li roy...@rock-chips.com
Signed-off-by: Kever Yang kever.y...@rock-chips.com
---
Changes in v2:
- add definition for hcd structure
- remove check for bus-root_hub
drivers/usb/dwc2/hcd_intr.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
index 551ba87..680206f 100644
--- a/drivers/usb/dwc2/hcd_intr.c
+++ b/drivers/usb/dwc2/hcd_intr.c
@@ -329,6 +329,7 @@ static void dwc2_port_intr(struct dwc2_hsotg *hsotg)
{
u32 hprt0;
u32 hprt0_modify;
+ struct usb_hcd *hcd = (struct usb_hcd *)hsotg-priv;
dev_vdbg(hsotg-dev, --Port Interrupt--\n);
@@ -354,6 +355,10 @@ static void dwc2_port_intr(struct dwc2_hsotg *hsotg)
hsotg-flags.b.port_connect_status = 1;
hprt0_modify |= HPRT0_CONNDET;
+ /* resume root hub? */
+ if (hcd-state == HC_STATE_SUSPENDED)
+ usb_hcd_resume_root_hub(hcd);
You should be aware that it's not safe to use hcd-state for anything
in a host controller driver. That field is owned by usbcore, not by
the HCD, and it is not protected by any locks.
Thus, for example, hcd-state does not get set to HC_STATE_SUSPENDED
until some time after the bus_suspend routine has returned. A
port-change interrupt might occur during that time interval.
Alan Stern
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
USB-serial console and lockdep
Hi Peter, I get this missing-lockdep-annotation warning which I haven't seen before when booting with a usb-serial console on 3.18-rc5. It's been a while since I last tested this, though, and the tty_ldisc_ref wasn't introduced until 833efc0ed19c (USB: serial: invoke dcd_change ldisc's handler.). [ 10.575225] usbserial: USB Serial support registered for pl2303 [ 10.575561] pl2303 1-2.1:1.0: pl2303 converter detected [ 10.627563] usb 1-2.1: pl2303 converter now attached to ttyUSB0 [ 10.650939] INFO: trying to register non-static key. [ 10.651000] the code is fine but needs lockdep annotation. [ 10.651000] turning off the locking correctness validator. [ 10.651031] CPU: 0 PID: 68 Comm: udevd Tainted: GW 3.18.0-rc5 #10 [ 10.651092] [c0016f04] (unwind_backtrace) from [c0013978] (show_stack+0x20/0x24) [ 10.651123] [c0013978] (show_stack) from [c0449794] (dump_stack+0x24/0x28) [ 10.651184] [c0449794] (dump_stack) from [c006f730] (__lock_acquire+0x1e50/0x2004) [ 10.651214] [c006f730] (__lock_acquire) from [c0070128] (lock_acquire+0xe4/0x18c) [ 10.651245] [c0070128] (lock_acquire) from [c027c6f8] (ldsem_down_read_trylock+0x78/0x90) [ 10.651275] [c027c6f8] (ldsem_down_read_trylock) from [c027a1cc] (tty_ldisc_ref+0x24/0x58) [ 10.651306] [c027a1cc] (tty_ldisc_ref) from [c0340760] (usb_serial_handle_dcd_change+0x48/0xe8) [ 10.651367] [c0340760] (usb_serial_handle_dcd_change) from [bf000484] (pl2303_read_int_callback+0x210/0x220 [pl2303]) [ 10.651428] [bf000484] (pl2303_read_int_callback [pl2303]) from [c031624c] (__usb_hcd_giveback_urb+0x80/0x140) [ 10.651458] [c031624c] (__usb_hcd_giveback_urb) from [c0316fc0] (usb_giveback_urb_bh+0x98/0xd4) [ 10.651489] [c0316fc0] (usb_giveback_urb_bh) from [c0042e44] (tasklet_hi_action+0x9c/0x108) [ 10.651519] [c0042e44] (tasklet_hi_action) from [c0042380] (__do_softirq+0x148/0x42c) [ 10.651550] [c0042380] (__do_softirq) from [c00429cc] (irq_exit+0xd8/0x114) [ 10.651580] [c00429cc] (irq_exit) from [c007ae58] (__handle_domain_irq+0x84/0xdc) [ 10.651611] [c007ae58] (__handle_domain_irq) from [c000879c] (omap_intc_handle_irq+0xd8/0xe0) [ 10.651641] [c000879c] (omap_intc_handle_irq) from [c0014544] (__irq_svc+0x44/0x7c) [ 10.651641] Exception stack(0xdf4e7f08 to 0xdf4e7f50) [ 10.651672] 7f00: debc0b80 df4e7f5c debc0b80 be8da96c [ 10.651702] 7f20: 0128 c000fc84 df4e6000 df4e7f94 0004 df4e7f50 [ 10.651702] 7f40: c038ebc0 c038d74c 600f0013 [ 10.651733] [c0014544] (__irq_svc) from [c038d74c] (___sys_sendmsg.part.29+0x0/0x2e0) [ 10.651763] [c038d74c] (___sys_sendmsg.part.29) from [c038ec08] (SyS_sendmsg+0x18/0x1c) [ 10.651794] [c038ec08] (SyS_sendmsg) from [c000fa00] (ret_fast_syscall+0x0/0x48) [ 10.692871] console [ttyUSB0] enabled Johan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] usbnet: rtl8150: remove unused variable
remove unused variable
Signed-off-by: Sudip Mukherjee su...@vectorindia.org
---
change in v2: changed the commit message
drivers/net/usb/rtl8150.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
index 6e87e57..d37b7dc 100644
--- a/drivers/net/usb/rtl8150.c
+++ b/drivers/net/usb/rtl8150.c
@@ -753,14 +753,13 @@ static int rtl8150_open(struct net_device *netdev)
static int rtl8150_close(struct net_device *netdev)
{
rtl8150_t *dev = netdev_priv(netdev);
- int res = 0;
netif_stop_queue(netdev);
if (!test_bit(RTL8150_UNPLUG, dev-flags))
disable_net_traffic(dev);
unlink_all_urbs(dev);
- return res;
+ return 0;
}
static void rtl8150_get_drvinfo(struct net_device *netdev, struct
ethtool_drvinfo *info)
--
1.8.1.2
--
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: resume root hub when device detect with suspend state
On Tue, Nov 18, 2014 at 11:07:34AM -0500, Alan Stern wrote:
On Tue, 18 Nov 2014, Kever Yang wrote:
After we implement the bus_suspend/resume, auto suspend id enabled.
The root hub will be auto suspend if there is no device connected,
we need to resume the root hub when a device connect detect.
This patch tested on rk3288.
Signed-off-by: Roy Li roy...@rock-chips.com
Signed-off-by: Kever Yang kever.y...@rock-chips.com
---
Changes in v2:
- add definition for hcd structure
- remove check for bus-root_hub
drivers/usb/dwc2/hcd_intr.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
index 551ba87..680206f 100644
--- a/drivers/usb/dwc2/hcd_intr.c
+++ b/drivers/usb/dwc2/hcd_intr.c
@@ -329,6 +329,7 @@ static void dwc2_port_intr(struct dwc2_hsotg *hsotg)
{
u32 hprt0;
u32 hprt0_modify;
+ struct usb_hcd *hcd = (struct usb_hcd *)hsotg-priv;
dev_vdbg(hsotg-dev, --Port Interrupt--\n);
@@ -354,6 +355,10 @@ static void dwc2_port_intr(struct dwc2_hsotg *hsotg)
hsotg-flags.b.port_connect_status = 1;
hprt0_modify |= HPRT0_CONNDET;
+ /* resume root hub? */
+ if (hcd-state == HC_STATE_SUSPENDED)
+ usb_hcd_resume_root_hub(hcd);
You should be aware that it's not safe to use hcd-state for anything
in a host controller driver. That field is owned by usbcore, not by
the HCD, and it is not protected by any locks.
Thus, for example, hcd-state does not get set to HC_STATE_SUSPENDED
until some time after the bus_suspend routine has returned. A
port-change interrupt might occur during that time interval.
In that case, XHCI has a bug :-) Mathias, care to add it to your TODO
list ?
--
balbi
signature.asc
Description: Digital signature
Re: [RFC v6 3/3] usb: phy: hold wakeupsource when USB is enumerated in peripheral mode
On 18 November 2014 21:25, Felipe Balbi ba...@ti.com wrote:
Hi,
On Wed, Nov 12, 2014 at 12:11:19PM +0530, Kiran Kumar Raparthy wrote:
From: Todd Poynor toddpoy...@google.com
usb: phy: hold wakeupsource when USB is enumerated in peripheral mode
Some systems require a mechanism to prevent system to enter into suspend
state when USB is connected and enumerated in peripheral mode.
This patch provides an interface to hold a wakeupsource to prevent suspend.
PHY drivers can use this interface when USB is connected and enumerated in
peripheral mode.
A timed wakeupsource is temporarily held on USB disconnect events, to allow
the rest of the system to react to the USB disconnection (dropping host
sessions, updating charger status, etc.) prior to re-allowing suspend.
Cc: Felipe Balbi ba...@ti.com
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: Android Kernel Team kernel-t...@android.com
Cc: John Stultz john.stu...@linaro.org
Cc: Sumit Semwal sumit.sem...@linaro.org
Cc: Arve Hj�nnev�g a...@android.com
Cc: Benoit Goby ben...@android.com
Signed-off-by: Todd Poynor toddpoy...@google.com
[kiran: Added context to commit message, squished build fixes
from Benoit Goby and Arve Hjønnevåg, changed wakelocks usage
to wakeupsource, merged Todd's refactoring logic and simplified
the structures and code and addressed community feedback]
Signed-off-by: Kiran Raparthy kiran.ku...@linaro.org
---
drivers/usb/phy/phy.c | 29 +++--
include/linux/usb/phy.h | 5 +
2 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index 2b1039e..b5c5fd3 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -329,6 +329,7 @@ int usb_add_phy(struct usb_phy *x, enum usb_phy_type
type)
int ret = 0;
unsigned long flags;
struct usb_phy *phy;
+ char wsource_name[40];
if (x-type != USB_PHY_TYPE_UNDEFINED) {
dev_err(x-dev, not accepting initialized PHY %s\n,
x-label);
@@ -351,6 +352,10 @@ int usb_add_phy(struct usb_phy *x, enum usb_phy_type
type)
x-type = type;
list_add_tail(x-head, phy_list);
+ snprintf(wsource_name, sizeof(wsource_name), vbus-%s,
+ dev_name(x-dev));
+ wakeup_source_init(x-wsource, wsource_name);
do you really need the device name on the wakeup source or would
usb-vbus suffice ? Hmm, I guess we could have several of these in the
same system, so maybe there's no other way.
yeah true.
@@ -446,13 +452,32 @@ int usb_bind_phy(const char *dev_name, u8 index,
EXPORT_SYMBOL_GPL(usb_bind_phy);
/**
- * usb_phy_set_event - set event to phy event
+ * usb_phy_set_event - set event to phy event and
+ * hold/temporarily hold wakeupsource
* @x: the phy returned by usb_get_phy();
*
- * This sets event to phy event
+ * This holds per-PHY wakeupsource/timed wakeupsource
*/
void usb_phy_set_event(struct usb_phy *x, unsigned long event)
{
+
x-last_event = event;
+
+ switch (event) {
+ case USB_EVENT_ENUMERATED:
+ __pm_stay_awake(x-wsource);
+ break;
+
+ case USB_EVENT_NONE:
+ case USB_EVENT_ID:
+ case USB_EVENT_VBUS:
+ case USB_EVENT_CHARGER:
+ __pm_wakeup_event(x-wsource,
+ msecs_to_jiffies(TEMPORARY_HOLD_TIME));
+ break;
+
+ default:
+ break;
+ }
much, much better. Completely hidden from PHY drivers.
}
EXPORT_SYMBOL_GPL(usb_phy_set_event);
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 3c713ff..bc58fb8 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -12,6 +12,8 @@
#include linux/notifier.h
#include linux/usb.h
+#define TEMPORARY_HOLD_TIME2000
minor nit:
Let's call this:
#define USB_PHY_DEFAULT_WAKEUP_SRC_TIMEOUT 2000 /* ms */
When resending, please drop that RFC from subject and make sure your
series is sent as a single thread, instead of three separate patches.
Sure Felipe,Thanks for your time.
cheers
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V5 09/12] usb: xhci: Add NVIDIA Tegra xHCI host-controller driver
On Mon, Nov 17, 2014 at 4:33 PM, Felipe Balbi ba...@ti.com wrote:
+static int tegra_xhci_load_firmware(struct tegra_xhci_hcd *tegra)
+{
+ struct device *dev = tegra-dev;
+ struct tegra_xhci_fw_cfgtbl *cfg_tbl;
+ struct tm fw_tm;
+ u32 val, code_tag_blocks, code_size_blocks;
+ u64 fw_base;
+ time_t fw_time;
+ unsigned long timeout;
+
+ if (csb_readl(tegra, XUSB_CSB_MP_ILOAD_BASE_LO) != 0) {
+ dev_info(dev, Firmware already loaded, Falcon state
0x%x\n,
+ csb_readl(tegra, XUSB_FALC_CPUCTL));
+ return 0;
+ }
won't this prevent rmmod insmod from succeeding ? Maybe not, as you
return 0 anyway, but if the firmware side craps out, it might be useful
to reload the firmware and reset that block. I wonder if this prevents
that.
rmmod insmod does work with the above since, as you mentioned, we
return successfully if the controller is already running. Attempting
to re-load the firmware if the controller is already running won't
work - it requires a full power-gate/ungate sequence of the
controller. Unfortunately, that sequence is rather complicated and I
haven't had a chance to implement it yet. it will hopefully be coming
later, though.
Alright, could you add a comment on the source code stating that ?
Perhaps a REVISIT note or FIXME ?
Sure, will do.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: USB3 support to the legacy printer driver
On 11/18/2014 10:17 AM, Felipe Balbi wrote:
Hi,
On Tue, Nov 18, 2014 at 09:19:36AM -0500, Jorge Ramirez-Ortiz wrote:
Hi Felipe/Greg
Thanks for your comments on my previous attempt.
I think I addressed them here.
no you haven't. Read Documentation/SubmittingPatches, read the mailing
list archives and you'll see your basic mistake.
For this fundamental mistake, could you not just share with me what I am
missing?
I don't see anything wrong other than maybe adding more maintainers to the DL
as per the scripts since the feature itself is self explanatory.
you have no clue what these mean, do you ? How about reading the USB
specification of even http://www.beyondlogic.org/usbnutshell/usb1.shtml
Unfortunately I do.
It was easier to temporarily hack the driver code for a test - while I was at
it - rather than modifying the host code.
Since you asked for them, I though you would read the logs and wonder where the
funny ids where coming from.
That hack above would have given you an answer: so I kind of know what the ids
are for. honestly.
anyway, will send the new logs - it took me a while to find and modify the host
test code.
do you want to debug that and find the culprit since you're already at
it ?
probably: I still need to get used to this process, thanks for bearing with me
on this.
I spoke to Ricardo Ribalda three months ago while I was doing this stuff.
but yes, I might work on this -after I finish with this patch!- since I have
access to the hardware locally.
3) Patch:
-
From 9b5ee9330c5c02cf51328c350036c1dac998b732 Mon Sep 17 00:00:00 2001
From: Jorge Ramirez-Ortiz jorge.ramirez-or...@linaro.org
Date: Thu, 25 Sep 2014 16:17:20 -0400
Subject: [PATCH 2/3] usb: gadget: add USB3 support to the printer driver
Add SS descriptors to support the capabilities provided by USB3 controller
drivers; unit tests run using a PLX 3380 [max transfer speed measured of
1Gbps]
This driver shall fallback to lower operating modes when the higher ones are
not available.
Signed-off-by: Jorge Ramirez-Ortiz jorge.ramirez-or...@linaro.org
---
drivers/usb/gadget/legacy/printer.c | 65
+
1 file changed, 59 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/legacy/printer.c
b/drivers/usb/gadget/legacy/printer.c
index 6474081..456730b 100644
--- a/drivers/usb/gadget/legacy/printer.c
+++ b/drivers/usb/gadget/legacy/printer.c
@@ -208,6 +208,43 @@ static struct usb_descriptor_header
*hs_printer_function[] = {
NULL
};
+/*
+ * Added endpoint descriptors for 3.0 devices
+ */
+
+static struct usb_endpoint_descriptor ss_ep_in_desc = {
+.bLength = USB_DT_ENDPOINT_SIZE,
+.bDescriptorType = USB_DT_ENDPOINT,
+.bmAttributes = USB_ENDPOINT_XFER_BULK,
+.wMaxPacketSize = cpu_to_le16(1024),
+};
As mentioned above, using the usb338x driver from PLX instead of the net2280
from
kernel.org, the effective file transfer rate increases 1Gbps.
all your tabs have been converted into spaces. Perhaps try:
$ git help send-email
and figure out how to use that ?
crap. really sorry about this!
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: USB3 support to the legacy printer driver
Hi,
(fix your mailer, lines should be broken at 80-characters.
Documentation/email-clients.txt has tips)
On Tue, Nov 18, 2014 at 12:52:11PM -0500, Jorge Ramirez-Ortiz wrote:
On 11/18/2014 10:17 AM, Felipe Balbi wrote:
Hi,
On Tue, Nov 18, 2014 at 09:19:36AM -0500, Jorge Ramirez-Ortiz wrote:
Hi Felipe/Greg
Thanks for your comments on my previous attempt.
I think I addressed them here.
no you haven't. Read Documentation/SubmittingPatches, read the mailing
list archives and you'll see your basic mistake.
For this fundamental mistake, could you not just share with me what I
am missing?
I don't see anything wrong other than maybe adding more maintainers to
the DL as per the scripts since the feature itself is self
explanatory.
Try to save your email from the mailing list and apply it with git am,
it should be very easy to see the problem.
If you also look at the mailing list archives for other patch
submissions (as I suggested) you'll easily see what your mistake is.
you have no clue what these mean, do you ? How about reading the USB
specification of even http://www.beyondlogic.org/usbnutshell/usb1.shtml
Unfortunately I do.
It was easier to temporarily hack the driver code for a test - while I
was at it - rather than modifying the host code.
Since you asked for them, I though you would read the logs and wonder
where the funny ids where coming from.
why do you even need to hack the host driver for these ? The driver
shows a Printer Class interface and the linux host side driver should
bind to it without any issues.
That hack above would have given you an answer: so I kind of know what
the ids are for. honestly. anyway, will send the new logs - it took
me a while to find and modify the host test code.
Which host test code ? Why don't you just use lpr or even cat file
/dev/lp0 or something like that ?
do you want to debug that and find the culprit since you're already at
it ?
probably: I still need to get used to this process, thanks for bearing
with me on this.
no problem.
I spoke to Ricardo Ribalda three months ago while I was doing this
stuff. but yes, I might work on this -after I finish with this
patch!- since I have access to the hardware locally.
cool, that'll help.
3) Patch:
-
From 9b5ee9330c5c02cf51328c350036c1dac998b732 Mon Sep 17 00:00:00 2001
From: Jorge Ramirez-Ortiz jorge.ramirez-or...@linaro.org
Date: Thu, 25 Sep 2014 16:17:20 -0400
Subject: [PATCH 2/3] usb: gadget: add USB3 support to the printer driver
Add SS descriptors to support the capabilities provided by USB3 controller
drivers; unit tests run using a PLX 3380 [max transfer speed measured of
1Gbps]
This driver shall fallback to lower operating modes when the higher ones
are
not available.
Signed-off-by: Jorge Ramirez-Ortiz jorge.ramirez-or...@linaro.org
hint:
Everything up until this point will go to commit log.
---
drivers/usb/gadget/legacy/printer.c | 65
+
1 file changed, 59 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/legacy/printer.c
b/drivers/usb/gadget/legacy/printer.c
index 6474081..456730b 100644
--- a/drivers/usb/gadget/legacy/printer.c
+++ b/drivers/usb/gadget/legacy/printer.c
@@ -208,6 +208,43 @@ static struct usb_descriptor_header
*hs_printer_function[] = {
NULL
};
+/*
+ * Added endpoint descriptors for 3.0 devices
+ */
+
+static struct usb_endpoint_descriptor ss_ep_in_desc = {
+.bLength = USB_DT_ENDPOINT_SIZE,
+.bDescriptorType = USB_DT_ENDPOINT,
+.bmAttributes = USB_ENDPOINT_XFER_BULK,
+.wMaxPacketSize = cpu_to_le16(1024),
+};
As mentioned above, using the usb338x driver from PLX instead of the
net2280 from
kernel.org, the effective file transfer rate increases 1Gbps.
all your tabs have been converted into spaces. Perhaps try:
$ git help send-email
and figure out how to use that ?
crap. really sorry about this!
np
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH v8 10/13] ARM: dts: berlin: add BG2Q nodes for USB support
On 17.11.2014 14:35, Antoine Tenart wrote:
Adds nodes describing the Marvell Berlin BG2Q USB PHY and USB. The BG2Q
SoC has 3 USB host controller, compatible with ChipIdea.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
Applied to berlin/dt with the whitespace removed that Sergei pointed
out.
Thanks!
---
arch/arm/boot/dts/berlin2q.dtsi | 55 +
1 file changed, 55 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index 2de8d6f8973c..834142bdfbb1 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -114,6 +114,40 @@
#interrupt-cells = 3;
};
+ usb_phy2: phy@a2f400 {
+ compatible = marvell,berlin2-usb-phy;
+ reg = 0xa2f400 0x128;
+ #phy-cells = 0;
+ resets = chip 0x104 14;
+ status = disabled;
+ };
+
+ usb2: usb@a3 {
+ compatible = chipidea,usb2;
+ reg = 0xa3 0x1;
+ interrupts = GIC_SPI 52 IRQ_TYPE_LEVEL_HIGH;
+ clocks = chip CLKID_USB2;
+ phys = usb_phy2;
+ phy-names = usb-phy;
+ status = disabled;
+ };
+
+ usb_phy0: phy@b74000 {
+ compatible = marvell,berlin2-usb-phy;
+ reg = 0xb74000 0x128;
+ #phy-cells = 0;
+ resets = chip 0x104 12;
+ status = disabled;
+ };
+
+ usb_phy1: phy@b78000 {
+ compatible = marvell,berlin2-usb-phy;
+ reg = 0xb78000 0x128;
+ #phy-cells = 0;
+ resets = chip 0x104 13;
+ status = disabled;
+ };
+
eth0: ethernet@b9 {
compatible = marvell,pxa168-eth;
reg = 0xb9 0x1;
@@ -365,6 +399,26 @@
};
};
+ usb0: usb@ed {
+ compatible = chipidea,usb2;
+ reg = 0xed 0x1;
+ interrupts = GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH;
+ clocks = chip CLKID_USB0;
+ phys = usb_phy0;
+ phy-names = usb-phy;
+ status = disabled;
+ };
+
+ usb1: usb@ee {
+ compatible = chipidea,usb2;
+ reg = 0xee 0x1;
+ interrupts = GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH;
+ clocks = chip CLKID_USB1;
+ phys = usb_phy1;
+ phy-names = usb-phy;
+ status = disabled;
+ };
+
apb@fc {
compatible = simple-bus;
#address-cells = 1;
@@ -457,5 +511,6 @@
interrupts = GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH;
};
};
+
};
};
--
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 v8 11/13] ARM: dts: Berlin: enable USB on the BG2Q DMP
On 17.11.2014 14:35, Antoine Tenart wrote:
Enable the 2 available USB PHY and USB nodes on the Marvell Berlin BG2Q
DMP.
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
Applied to berlin/dt.
Thanks!
---
arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 53 ++
1 file changed, 53 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
index ea1f99b8eed6..f7c25580e122 100644
--- a/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
+++ b/arch/arm/boot/dts/berlin2q-marvell-dmp.dts
@@ -7,6 +7,8 @@
*/
/dts-v1/;
+
+#include dt-bindings/gpio/gpio.h
#include berlin2q.dtsi
/ {
@@ -21,6 +23,39 @@
choosen {
bootargs = console=ttyS0,115200 earlyprintk;
};
+
+ regulators {
+ compatible = simple-bus;
+ #address-cells = 1;
+ #size-cells = 0;
+
+ reg_usb0_vbus: regulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = usb0_vbus;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = portb 8 GPIO_ACTIVE_HIGH;
+ enable-active-high;
+ };
+
+ reg_usb1_vbus: regulator@1 {
+ compatible = regulator-fixed;
+ regulator-name = usb1_vbus;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = portb 10 GPIO_ACTIVE_HIGH;
+ enable-active-high;
+ };
+
+ reg_usb2_vbus: regulator@2 {
+ compatible = regulator-fixed;
+ regulator-name = usb2_vbus;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = portb 12 GPIO_ACTIVE_HIGH;
+ enable-active-high;
+ };
+ };
};
sdhci1 {
@@ -46,6 +81,24 @@
status = okay;
};
+usb_phy0 {
+ status = okay;
+};
+
+usb_phy2 {
+ status = okay;
+};
+
+usb0 {
+ vbus-supply = reg_usb0_vbus;
+ status = okay;
+};
+
+usb2 {
+ vbus-supply = reg_usb2_vbus;
+ status = okay;
+};
+
eth0 {
status = okay;
};
--
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 v8 12/13] ARM: dts: berlin: add BG2CD nodes for USB support
On 17.11.2014 14:35, Antoine Tenart wrote:
From: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Adds nodes describing the Marvell Berlin BG2CD USB PHY and USB. The BG2CD
SoC has 2 USB ChipIdea controllers, with usb0 host-only and usb1 dual-role
capable.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
Applied to berlin/dt with usb-phy nodes reordered correctly (ethernet
nodes came in between in the meantime).
Thanks!
---
arch/arm/boot/dts/berlin2cd.dtsi | 36
1 file changed, 36 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2cd.dtsi b/arch/arm/boot/dts/berlin2cd.dtsi
index 68f7032b4686..af5e628547ce 100644
--- a/arch/arm/boot/dts/berlin2cd.dtsi
+++ b/arch/arm/boot/dts/berlin2cd.dtsi
@@ -66,6 +66,22 @@
clocks = chip CLKID_TWD;
};
+ usb_phy0: usb-phy@b74000 {
+ compatible = marvell,berlin2cd-usb-phy;
+ reg = 0xb74000 0x128;
+ #phy-cells = 0;
+ resets = chip 0x178 23;
+ status = disabled;
+ };
+
+ usb_phy1: usb-phy@b78000 {
+ compatible = marvell,berlin2cd-usb-phy;
+ reg = 0xb78000 0x128;
+ #phy-cells = 0;
+ resets = chip 0x178 24;
+ status = disabled;
+ };
+
apb@e8 {
compatible = simple-bus;
#address-cells = 1;
@@ -242,6 +258,26 @@
};
};
+ usb0: usb@ed {
+ compatible = chipidea,usb2;
+ reg = 0xed 0x200;
+ interrupts = GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH;
+ clocks = chip CLKID_USB0;
+ phys = usb_phy0;
+ phy-names = usb-phy;
+ status = disabled;
+ };
+
+ usb1: usb@ee {
+ compatible = chipidea,usb2;
+ reg = 0xee 0x200;
+ interrupts = GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH;
+ clocks = chip CLKID_USB1;
+ phys = usb_phy1;
+ phy-names = usb-phy;
+ status = disabled;
+ };
+
apb@fc {
compatible = simple-bus;
#address-cells = 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 v8 13/13] ARM: dts: berlin: enable USB on the Google Chromecast
On 17.11.2014 14:35, Antoine Tenart wrote:
From: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Enable usb1 on Google Chromecast which is connected to micro-USB
plug used for external power supply, too.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
Signed-off-by: Antoine Tenart antoine.ten...@free-electrons.com
Applied to berlin/dt.
Thanks!
---
arch/arm/boot/dts/berlin2cd-google-chromecast.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
index bcd81ffc495d..5c42c3bfb613 100644
--- a/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
+++ b/arch/arm/boot/dts/berlin2cd-google-chromecast.dts
@@ -27,3 +27,7 @@
};
uart0 { status = okay; };
+
+usb_phy1 { status = okay; };
+
+usb1 { status = okay; };
--
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 v8 00/13] ARM: berlin: USB support
On 17.11.2014 14:35, Antoine Tenart wrote: This series adds the support for ChipIdea USB2 (ci13xxx) controllers, the USB PHYs of the Marvell Berlin SoCs and also adds a reset controller for these SoCs. The reset controller is used by the PHY driver and shares the existing chip controller node with the clocks and one pin controller. The Marvell Berlin USB controllers are host only on the BG2Q and are compatible with USB ChipIdea. We here add a glue to use the available common functions for this kind of controllers, and add a generic USB2 ChipIdea driver. A PHY driver is also added to control the USB PHY. This series applies on top of Peter Chen's ci-for-usb-next branch[1] containing the generic PHY support in the USB framework[2]. Patches 1-4 should already have been taken by Sebastian. Antoine, I just took the DT patches, too. Thanks for the patience and that you sticked with the idea of reusing chipidea driver! Thanks to the others reviewing/suggesting too! Sebastian Changes since v7: - rebased on top of the latest CI for-next branch of Peter[1] - removed CI_HDRC_REQUIRE_TRANSCEIVER - added a missing tested-by - some cosmetic fixes and a commit message reword Changes since v6: - removed ci_hdrc_usb2_dt_probe - fixed a bug in the ChipIdea core for PHY handling - called unconditionally dma_set_mask_and_coherent() Changes since v5: - added a missing header in ci_hdrc_usb2 Changes since v4: - fixed the error handling of ci_hdrc_usb2_probe() Changes since v3: - removed the DMA mask property - moved the clock handling in the common probe function - fixed the documentation for the USB2 ChipIdea USB PHY binding - made sure the reset bit is 0-31 in the reset driver Changes since v2: - moved the PHY driver to the generic PHY framework - changed the compatible to 'chipidea,usb2' - added a property to set the DMA mask in the USB2 CI driver - separated dt specific calls in the CI probing function - rebased on top of the generic PHY support for CI[2] Changes since v1: - made the Berlin CI USB driver a generic one - added support to custom offset for the reset register - added fixed regulators to support supply the VBUS - modified the PHY driver to support the one one the BG2CD as well - documented the reset properties - added bindings for the BG2CD - cosmetic fixes [1] https://github.com/hzpeterchen/linux-usb.git ci-for-usb-next [2] git://git.free-electrons.com:users/antoine-tenart/linux.git usb-phy Antoine Tenart (11): reset: add the Berlin reset controller driver Documentation: bindings: add reset bindings docs for Marvell Berlin SoCs ARM: Berlin: select the reset controller ARM: dts: berlin: add a required reset property in the chip controller node phy: add the Berlin USB PHY driver Documentation: bindings: add doc for the Berlin USB PHY usb: chipidea: fix phy handling usb: chipidea: add a usb2 driver for ci13xxx Documentation: bindings: add doc for the USB2 ChipIdea USB driver ARM: dts: berlin: add BG2Q nodes for USB support ARM: dts: Berlin: enable USB on the BG2Q DMP Sebastian Hesselbarth (2): ARM: dts: berlin: add BG2CD nodes for USB support ARM: dts: berlin: enable USB on the Google Chromecast .../devicetree/bindings/arm/marvell,berlin.txt | 10 + .../devicetree/bindings/phy/berlin-usb-phy.txt | 16 ++ .../devicetree/bindings/usb/ci-hdrc-usb2.txt | 24 +++ arch/arm/boot/dts/berlin2.dtsi | 1 + arch/arm/boot/dts/berlin2cd-google-chromecast.dts | 4 + arch/arm/boot/dts/berlin2cd.dtsi | 37 arch/arm/boot/dts/berlin2q-marvell-dmp.dts | 53 + arch/arm/boot/dts/berlin2q.dtsi| 56 ++ arch/arm/mach-berlin/Kconfig | 2 + drivers/phy/Kconfig| 7 + drivers/phy/Makefile | 1 + drivers/phy/phy-berlin-usb.c | 224 + drivers/reset/Makefile | 1 + drivers/reset/reset-berlin.c | 131 drivers/usb/chipidea/Makefile | 1 + drivers/usb/chipidea/ci_hdrc_usb2.c| 116 +++ drivers/usb/chipidea/core.c| 4 +- 17 files changed, 686 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/phy/berlin-usb-phy.txt create mode 100644 Documentation/devicetree/bindings/usb/ci-hdrc-usb2.txt create mode 100644 drivers/phy/phy-berlin-usb.c create mode 100644 drivers/reset/reset-berlin.c create mode 100644 drivers/usb/chipidea/ci_hdrc_usb2.c -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a
Re: [PATCH v2 2/2] [usb] add support for ACPI identification to xhci-platform
On Thu, Nov 13, 2014 at 10:36 AM, Mark Langsdorf mlang...@redhat.com wrote:
On 11/04/2014 11:12 AM, Greg KH wrote:
On Tue, Nov 04, 2014 at 10:50:33AM -0600, Mark Langsdorf wrote:
#endif
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id usb_xhci_acpi_match[] = {
+ /* APM X-Gene USB Controller */
+ { PNP0D10, },
Mark, would it be better to use PRP0001 instead as in this patch?
https://lkml.org/lkml/2014/9/16/230
+ { }
+};
+MODULE_DEVICE_TABLE(acpi, usb_xhci_acpi_match);
+#endif
That looks like a very generic PNP value, are you sure it is assigned
only to this specific device?
Although this is a generic PNP device, the specific implementation
I'm testing has issues with USB3. Is there a flag or function
call that will disable the USB3 host while keeping the USB2
host?? My naive attempts in finding one mostly hung the machine.
--Mark Langsdorf
--
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
[PATCH] usb: gadget: add USB3 support to the printer driver
This patch adds USB3 support to the printer driver. Tests used two binaries (host/device) to handle the file transfer [gadget] $ dmesg net2280 :02:00.0: usb_reset_338x: Defect 7374 FsmValue 0xf000 net2280 :02:00.0: usb_reinit_338x: Defect 7374 FsmValue f000 net2280 :02:00.0: irq 35 for MSI/MSI-X net2280 :02:00.0: PLX NET228x/USB338x USB Peripheral Controller net2280 :02:00.0: irq 35, pci mem c90005574000, chip rev 00ab net2280 :02:00.0: version: 2005 Sept 27/v3.0; dma enabled legacy mode printer gadget: Printer Gadget, version: 2007 OCT 06 printer gadget: printer ready net2280 :02:00.0: Operate Defect 7374 workaround soft this time net2280 :02:00.0: It will operate on cold-reboot and SS connect net2280 :02:00.0: ep0_start_338x: Defect 7374 FsmValue 1000 net2280 :02:00.0: INFO: Defect 7374 workaround waited about 40uSec for Control Read Data Phase ACK printer gadget: super-speed config #1: printer printer gadget: Using interface 0 [gadget]$ sudo ./usbdevice [sudo] password for jramirez: Receive file: ..done Transfer rate = 461 Mbits/sec [57MB/sec] - file size : 58 MB - time : 1.15 sec Dump file: /tmp/dump.txt ..done [host]$ sudo ./usbhost file.txt Opening device 0525:A4A8... Device properties: bus number: 4 port path: 2 (from root hub) device speed: 5000 Mbit/s (USB SuperSpeed) Reading device descriptor: length: 18 device class: 0 S/N: 3 VID:PID: 0525:A4A8 bcdDevice: 0318 iMan:iProd:iSer: 1:2:3 nb confs: 1 Reading BOS descriptor: 2 caps USB 2.0 extension: attributes : 06 USB 3.0 capabilities: attributes : 00 supported speeds : 000F supported functionality: 01 Reading first configuration descriptor: nb interfaces: 1 interface[0]: id = 0 interface[0].altsetting[0]: num endpoints = 2 Class.SubClass.Protocol: 07.01.02 endpoint[0].address: 81 max packet size: 0400 polling interval: 00 max burst: 00 (USB 3.0) bytes per interval: (USB 3.0) endpoint[1].address: 01 max packet size: 0400 polling interval: 00 max burst: 00 (USB 3.0) bytes per interval: (USB 3.0) Claiming interface 0... Reading string descriptors: String (0x01): Linux 3.18.0-rc5+ with net2280 String (0x02): Printer Gadget Transfering: endpoint_out 1, size 61387314 - number of bulk transfers : 7494 - max user transfer size : 8192 bytes - max usb transfer size: 1024 bytes [host]$ lsusb Bus 002 Device 006: ID 05ac:1303 Apple, Inc. iPod Shuffle 4.Gen Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 009: ID 0525:a4a8 Netchip Technology, Inc. Linux-USB Printer Gadget Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Bus 001 Device 003: ID 046d:0990 Logitech, Inc. QuickCam Pro 9000 Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub -- 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: add USB3 support to the printer driver
Add SS descriptors to support the capabilities provided by USB3 controller
drivers; unit tests run using a PLX 3380 [max transfer speed measured of 1Gbps]
This driver shall fallback to lower operating modes when the higher ones are
not available.
Signed-off-by: Jorge Ramirez-Ortiz jorge.ramirez-or...@linaro.org
---
drivers/usb/gadget/legacy/printer.c | 65 +
1 file changed, 59 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/legacy/printer.c
b/drivers/usb/gadget/legacy/printer.c
index 6474081..456730b 100644
--- a/drivers/usb/gadget/legacy/printer.c
+++ b/drivers/usb/gadget/legacy/printer.c
@@ -208,6 +208,43 @@ static struct usb_descriptor_header *hs_printer_function[]
= {
NULL
};
+/*
+ * Added endpoint descriptors for 3.0 devices
+ */
+
+static struct usb_endpoint_descriptor ss_ep_in_desc = {
+ .bLength = USB_DT_ENDPOINT_SIZE,
+ .bDescriptorType = USB_DT_ENDPOINT,
+ .bmAttributes = USB_ENDPOINT_XFER_BULK,
+ .wMaxPacketSize = cpu_to_le16(1024),
+};
+
+struct usb_ss_ep_comp_descriptor ss_ep_in_comp_desc = {
+ .bLength = sizeof(ss_ep_in_comp_desc),
+ .bDescriptorType = USB_DT_SS_ENDPOINT_COMP,
+};
+
+static struct usb_endpoint_descriptor ss_ep_out_desc = {
+ .bLength = USB_DT_ENDPOINT_SIZE,
+ .bDescriptorType = USB_DT_ENDPOINT,
+ .bmAttributes = USB_ENDPOINT_XFER_BULK,
+ .wMaxPacketSize = cpu_to_le16(1024),
+};
+
+struct usb_ss_ep_comp_descriptor ss_ep_out_comp_desc = {
+ .bLength = sizeof(ss_ep_out_comp_desc),
+ .bDescriptorType = USB_DT_SS_ENDPOINT_COMP,
+};
+
+static struct usb_descriptor_header *ss_printer_function[] = {
+ (struct usb_descriptor_header *) intf_desc,
+ (struct usb_descriptor_header *) ss_ep_in_desc,
+ (struct usb_descriptor_header *) ss_ep_in_comp_desc,
+ (struct usb_descriptor_header *) ss_ep_out_desc,
+ (struct usb_descriptor_header *) ss_ep_out_comp_desc,
+ NULL
+};
+
static struct usb_otg_descriptor otg_descriptor = {
.bLength = sizeof otg_descriptor,
.bDescriptorType = USB_DT_OTG,
@@ -220,7 +257,20 @@ static const struct usb_descriptor_header *otg_desc[] = {
};
/* maxpacket and other transfer characteristics vary by speed. */
-#define ep_desc(g, hs, fs) (((g)-speed == USB_SPEED_HIGH)?(hs):(fs))
+static inline struct usb_endpoint_descriptor *ep_desc(struct usb_gadget
*gadget,
+ struct usb_endpoint_descriptor *fs,
+ struct usb_endpoint_descriptor *hs,
+ struct usb_endpoint_descriptor *ss)
+{
+ switch(gadget-speed) {
+ case USB_SPEED_SUPER:
+ return ss;
+ case USB_SPEED_HIGH:
+ return hs;
+ default:
+ return fs;
+ }
+}
/*-*/
@@ -793,11 +843,12 @@ set_printer_interface(struct printer_dev *dev)
{
int result = 0;
- dev-in_ep-desc = ep_desc(dev-gadget, hs_ep_in_desc, fs_ep_in_desc);
+ dev-in_ep-desc = ep_desc(dev-gadget, fs_ep_in_desc, hs_ep_in_desc,
+ ss_ep_in_desc);
dev-in_ep-driver_data = dev;
- dev-out_ep-desc = ep_desc(dev-gadget, hs_ep_out_desc,
- fs_ep_out_desc);
+ dev-out_ep-desc = ep_desc(dev-gadget, fs_ep_out_desc,
+ hs_ep_out_desc, ss_ep_out_desc);
dev-out_ep-driver_data = dev;
result = usb_ep_enable(dev-in_ep);
@@ -1016,9 +1067,11 @@ autoconf_fail:
/* assumes that all endpoints are dual-speed */
hs_ep_in_desc.bEndpointAddress = fs_ep_in_desc.bEndpointAddress;
hs_ep_out_desc.bEndpointAddress = fs_ep_out_desc.bEndpointAddress;
+ ss_ep_in_desc.bEndpointAddress = fs_ep_in_desc.bEndpointAddress;
+ ss_ep_out_desc.bEndpointAddress = fs_ep_out_desc.bEndpointAddress;
ret = usb_assign_descriptors(f, fs_printer_function,
- hs_printer_function, NULL);
+ hs_printer_function, ss_printer_function);
if (ret)
return ret;
@@ -1253,7 +1306,7 @@ static __refdata struct usb_composite_driver
printer_driver = {
.name = shortname,
.dev= device_desc,
.strings= dev_strings,
- .max_speed = USB_SPEED_HIGH,
+ .max_speed = USB_SPEED_SUPER,
.bind = printer_bind,
.unbind = printer_unbind,
};
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] [usb] add support for ACPI identification to xhci-platform
On 11/18/2014 02:05 PM, Feng Kan wrote:
On Thu, Nov 13, 2014 at 10:36 AM, Mark Langsdorf mlang...@redhat.com wrote:
On 11/04/2014 11:12 AM, Greg KH wrote:
On Tue, Nov 04, 2014 at 10:50:33AM -0600, Mark Langsdorf wrote:
#endif
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id usb_xhci_acpi_match[] = {
+ /* APM X-Gene USB Controller */
+ { PNP0D10, },
Mark, would it be better to use PRP0001 instead as in this patch?
https://lkml.org/lkml/2014/9/16/230
Quoting Arnd,
In this case, the device does have an official ACPI ID PNP0D10,
so we should use that for compatibility with other operating
systems and with BIOS versions that provide the standard IDs.
--Mark Langsdorf
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: USB3 support to the legacy printer driver
On 11/18/2014 01:00 PM, Felipe Balbi wrote:
Hi,
(fix your mailer, lines should be broken at 80-characters.
Documentation/email-clients.txt has tips)
On Tue, Nov 18, 2014 at 12:52:11PM -0500, Jorge Ramirez-Ortiz wrote:
On 11/18/2014 10:17 AM, Felipe Balbi wrote:
Hi,
On Tue, Nov 18, 2014 at 09:19:36AM -0500, Jorge Ramirez-Ortiz wrote:
Hi Felipe/Greg
Thanks for your comments on my previous attempt.
I think I addressed them here.
no you haven't. Read Documentation/SubmittingPatches, read the mailing
list archives and you'll see your basic mistake.
For this fundamental mistake, could you not just share with me what I
am missing?
I don't see anything wrong other than maybe adding more maintainers to
the DL as per the scripts since the feature itself is self
explanatory.
Try to save your email from the mailing list and apply it with git am,
it should be very easy to see the problem.
If you also look at the mailing list archives for other patch
submissions (as I suggested) you'll easily see what your mistake is.
thanks, I get it now.
you have no clue what these mean, do you ? How about reading the USB
specification of even http://www.beyondlogic.org/usbnutshell/usb1.shtml
Unfortunately I do.
It was easier to temporarily hack the driver code for a test - while I
was at it - rather than modifying the host code.
Since you asked for them, I though you would read the logs and wonder
where the funny ids where coming from.
why do you even need to hack the host driver for these ? The driver
shows a Printer Class interface and the linux host side driver should
bind to it without any issues.
the hack was on the gadget side.
the usbhost test code in charge of sending the file to the device had the wrong
ids.
to save time -since I was modifying the gadget driver code and only for the
tests (it is not part of the final patch) - I hacked those ids on the printer.c
file.
but anyway. lets move on. I removed those, recompiled the usb host code and sent
the new traces.
That hack above would have given you an answer: so I kind of know what
the ids are for. honestly. anyway, will send the new logs - it took
me a while to find and modify the host test code.
Which host test code ? Why don't you just use lpr or even cat file
/dev/lp0 or something like that ?
it is some proprietary code that links libusb -part of a different project: it
was useful as it generated some metrics I was interested in.
do you want to debug that and find the culprit since you're already at
it ?
probably: I still need to get used to this process, thanks for bearing
with me on this.
no problem.
I spoke to Ricardo Ribalda three months ago while I was doing this
stuff. but yes, I might work on this -after I finish with this
patch!- since I have access to the hardware locally.
cool, that'll help.
notice that the original PLX driver was still far from the theoretical 5Gbps
target (I was expecting to measure at least 3Gbps and could only get 1Gbps).
So 1Gbps should be the target to meet on the kernel.org net2280 - do you agree?
3) Patch:
-
From 9b5ee9330c5c02cf51328c350036c1dac998b732 Mon Sep 17 00:00:00 2001
From: Jorge Ramirez-Ortiz jorge.ramirez-or...@linaro.org
Date: Thu, 25 Sep 2014 16:17:20 -0400
Subject: [PATCH 2/3] usb: gadget: add USB3 support to the printer driver
Add SS descriptors to support the capabilities provided by USB3 controller
drivers; unit tests run using a PLX 3380 [max transfer speed measured of
1Gbps]
This driver shall fallback to lower operating modes when the higher ones
are
not available.
Signed-off-by: Jorge Ramirez-Ortiz jorge.ramirez-or...@linaro.org
hint:
Everything up until this point will go to commit log.
---
drivers/usb/gadget/legacy/printer.c | 65
+
1 file changed, 59 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/gadget/legacy/printer.c
b/drivers/usb/gadget/legacy/printer.c
index 6474081..456730b 100644
--- a/drivers/usb/gadget/legacy/printer.c
+++ b/drivers/usb/gadget/legacy/printer.c
@@ -208,6 +208,43 @@ static struct usb_descriptor_header
*hs_printer_function[] = {
NULL
};
+/*
+ * Added endpoint descriptors for 3.0 devices
+ */
+
+static struct usb_endpoint_descriptor ss_ep_in_desc = {
+.bLength = USB_DT_ENDPOINT_SIZE,
+.bDescriptorType = USB_DT_ENDPOINT,
+.bmAttributes = USB_ENDPOINT_XFER_BULK,
+.wMaxPacketSize = cpu_to_le16(1024),
+};
As mentioned above, using the usb338x driver from PLX instead of the
net2280 from
kernel.org, the effective file transfer rate increases 1Gbps.
all your tabs have been converted into spaces. Perhaps try:
$ git help send-email
and figure out how to use that ?
crap. really sorry about this!
np
it should be fine now.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More
Re: [PATCH] usb: gadget: USB3 support to the legacy printer driver
Hi, On Tue, Nov 18, 2014 at 03:41:43PM -0500, Jorge Ramirez-Ortiz wrote: you have no clue what these mean, do you ? How about reading the USB specification of even http://www.beyondlogic.org/usbnutshell/usb1.shtml Unfortunately I do. It was easier to temporarily hack the driver code for a test - while I was at it - rather than modifying the host code. Since you asked for them, I though you would read the logs and wonder where the funny ids where coming from. why do you even need to hack the host driver for these ? The driver shows a Printer Class interface and the linux host side driver should bind to it without any issues. the hack was on the gadget side. the usbhost test code in charge of sending the file to the device had the wrong ids. to save time -since I was modifying the gadget driver code and only for the tests (it is not part of the final patch) - I hacked those ids on the printer.c file. but anyway. lets move on. I removed those, recompiled the usb host code and sent the new traces. then the host side needs a fix because it shouldn't really care about the device ID, rather it should care about the class being printer. That hack above would have given you an answer: so I kind of know what the ids are for. honestly. anyway, will send the new logs - it took me a while to find and modify the host test code. Which host test code ? Why don't you just use lpr or even cat file /dev/lp0 or something like that ? it is some proprietary code that links libusb -part of a different project: it was useful as it generated some metrics I was interested in. I would be surprised if lpr doesn't work for the same purpose. do you want to debug that and find the culprit since you're already at it ? probably: I still need to get used to this process, thanks for bearing with me on this. no problem. I spoke to Ricardo Ribalda three months ago while I was doing this stuff. but yes, I might work on this -after I finish with this patch!- since I have access to the hardware locally. cool, that'll help. notice that the original PLX driver was still far from the theoretical 5Gbps target (I was expecting to measure at least 3Gbps and could only get 1Gbps). So 1Gbps should be the target to meet on the kernel.org net2280 - do you agree? this depends on a whole bunch of things. Mainline is a lot different from PLX's kernel tree, I'm sure. It also depends on how many PCIe lanes you're using. Just because USB3 guarantees 5Gbps bandwidth, if you use a 1x PCIe connector, you'll never get that ;-) -- balbi signature.asc Description: Digital signature
RE: [PATCH v5] usb: dwc2/gadget: rework disconnect event handling
From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
Sent: Monday, November 17, 2014 1:00 AM
This patch adds a call to s3c_hsotg_disconnect() from 'end session'
interrupt (GOTGINT_SES_END_DET) to correctly notify gadget subsystem
about unplugged usb cable. DISCONNINT interrupt cannot be used for this
purpose, because it is asserted only in host mode.
To avoid reporting disconnect event more than once, a disconnect call has
been moved from USB_REQ_SET_ADDRESS handling function to SESSREQINT
interrupt. This way driver ensures that disconnect event is reported
either when usb cable is unplugged or every time the host starts a new
session. To handle devices which has been synthesized without
SRP support, connected state is set in ENUMDONE interrupt.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/usb/dwc2/core.h | 1 +
drivers/usb/dwc2/gadget.c | 16 ++--
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 55c90c53f2d6..e54c3c50cd48 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -210,6 +210,7 @@ struct s3c_hsotg {
u8 ctrl_buff[8];
struct usb_gadget gadget;
+ unsigned intconnected:1;
unsigned intsetup;
unsigned long last_rst;
struct s3c_hsotg_ep *eps;
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index fcd2bb55ccca..89b1bea50ee3 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1029,7 +1029,6 @@ static int s3c_hsotg_process_req_feature(struct
s3c_hsotg *hsotg,
}
static void s3c_hsotg_enqueue_setup(struct s3c_hsotg *hsotg);
-static void s3c_hsotg_disconnect(struct s3c_hsotg *hsotg);
/**
* s3c_hsotg_stall_ep0 - stall ep0
@@ -1107,7 +1106,6 @@ static void s3c_hsotg_process_control(struct s3c_hsotg
*hsotg,
if ((ctrl-bRequestType USB_TYPE_MASK) == USB_TYPE_STANDARD) {
switch (ctrl-bRequest) {
case USB_REQ_SET_ADDRESS:
- s3c_hsotg_disconnect(hsotg);
dcfg = readl(hsotg-regs + DCFG);
dcfg = ~DCFG_DEVADDR_MASK;
dcfg |= (le16_to_cpu(ctrl-wValue)
@@ -2031,6 +2029,10 @@ static void s3c_hsotg_disconnect(struct s3c_hsotg
*hsotg)
{
unsigned ep;
+ if (!hsotg-connected)
+ return;
+
+ hsotg-connected = 0;
for (ep = 0; ep hsotg-num_of_eps; ep++)
kill_all_requests(hsotg, hsotg-eps[ep], -ESHUTDOWN, true);
@@ -2290,17 +2292,27 @@ irq_retry:
dev_info(hsotg-dev, OTGInt: %08x\n, otgint);
writel(otgint, hsotg-regs + GOTGINT);
+
+ if (otgint GOTGINT_SES_END_DET) {
+ s3c_hsotg_disconnect(hsotg);
+ hsotg-gadget.speed = USB_SPEED_UNKNOWN;
+ }
}
if (gintsts GINTSTS_SESSREQINT) {
dev_dbg(hsotg-dev, %s: SessReqInt\n, __func__);
writel(GINTSTS_SESSREQINT, hsotg-regs + GINTSTS);
+ /*
+ * Report disconnect if there is any previous session
established
+ */
+ s3c_hsotg_disconnect(hsotg);
}
if (gintsts GINTSTS_ENUMDONE) {
writel(GINTSTS_ENUMDONE, hsotg-regs + GINTSTS);
s3c_hsotg_irq_enumdone(hsotg);
+ hsotg-connected = 1;
}
if (gintsts GINTSTS_CONIDSTSCHNG) {
Acked-by: Paul Zimmerman pa...@synopsys.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 v3 1/2] usb: dwc2/gadget: add mutex to serialize init/deinit calls
From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
Sent: Friday, October 31, 2014 3:13 AM
This patch adds mutex, which protects initialization and
deinitialization procedures against suspend/resume methods.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
drivers/usb/dwc2/core.h | 1 +
drivers/usb/dwc2/gadget.c | 20
2 files changed, 21 insertions(+)
diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
index 9f77b4d1c5ff..58732a9a0019 100644
--- a/drivers/usb/dwc2/core.h
+++ b/drivers/usb/dwc2/core.h
@@ -187,6 +187,7 @@ struct s3c_hsotg {
struct s3c_hsotg_plat*plat;
spinlock_t lock;
+ struct mutexinit_mutex;
void __iomem*regs;
int irq;
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index d8dda39c9e16..a2e4272a904e 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -21,6 +21,7 @@
#include linux/platform_device.h
#include linux/dma-mapping.h
#include linux/debugfs.h
+#include linux/mutex.h
#include linux/seq_file.h
#include linux/delay.h
#include linux/io.h
@@ -2908,6 +2909,7 @@ static int s3c_hsotg_udc_start(struct usb_gadget
*gadget,
return -EINVAL;
}
+ mutex_lock(hsotg-init_mutex);
WARN_ON(hsotg-driver);
driver-driver.bus = NULL;
@@ -2933,9 +2935,12 @@ static int s3c_hsotg_udc_start(struct usb_gadget
*gadget,
dev_info(hsotg-dev, bound driver %s\n, driver-driver.name);
+ mutex_unlock(hsotg-init_mutex);
+
return 0;
err:
+ mutex_unlock(hsotg-init_mutex);
hsotg-driver = NULL;
return ret;
}
@@ -2957,6 +2962,8 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget,
if (!hsotg)
return -ENODEV;
+ mutex_lock(hsotg-init_mutex);
+
/* all endpoints should be shutdown */
for (ep = 1; ep hsotg-num_of_eps; ep++)
s3c_hsotg_ep_disable(hsotg-eps[ep].ep);
@@ -2974,6 +2981,8 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget,
clk_disable(hsotg-clk);
+ mutex_unlock(hsotg-init_mutex);
+
return 0;
}
@@ -3002,6 +3011,7 @@ static int s3c_hsotg_pullup(struct usb_gadget *gadget,
int is_on)
dev_dbg(hsotg-dev, %s: is_on: %d\n, __func__, is_on);
+ mutex_lock(hsotg-init_mutex);
spin_lock_irqsave(hsotg-lock, flags);
if (is_on) {
clk_enable(hsotg-clk);
@@ -3013,6 +3023,7 @@ static int s3c_hsotg_pullup(struct usb_gadget *gadget,
int is_on)
hsotg-gadget.speed = USB_SPEED_UNKNOWN;
spin_unlock_irqrestore(hsotg-lock, flags);
+ mutex_unlock(hsotg-init_mutex);
return 0;
}
@@ -3507,6 +3518,7 @@ static int s3c_hsotg_probe(struct platform_device *pdev)
}
spin_lock_init(hsotg-lock);
+ mutex_init(hsotg-init_mutex);
hsotg-irq = ret;
@@ -3652,6 +3664,8 @@ static int s3c_hsotg_suspend(struct platform_device
*pdev, pm_message_t state)
unsigned long flags;
int ret = 0;
+ mutex_lock(hsotg-init_mutex);
+
if (hsotg-driver)
dev_info(hsotg-dev, suspending usb gadget %s\n,
hsotg-driver-driver.name);
@@ -3674,6 +3688,8 @@ static int s3c_hsotg_suspend(struct platform_device
*pdev, pm_message_t state)
clk_disable(hsotg-clk);
}
+ mutex_unlock(hsotg-init_mutex);
+
return ret;
}
@@ -3683,7 +3699,9 @@ static int s3c_hsotg_resume(struct platform_device
*pdev)
unsigned long flags;
int ret = 0;
+ mutex_lock(hsotg-init_mutex);
if (hsotg-driver) {
+
dev_info(hsotg-dev, resuming usb gadget %s\n,
hsotg-driver-driver.name);
@@ -3699,6 +3717,8 @@ static int s3c_hsotg_resume(struct platform_device
*pdev)
s3c_hsotg_core_connect(hsotg);
spin_unlock_irqrestore(hsotg-lock, flags);
+ mutex_unlock(hsotg-init_mutex);
+
return ret;
}
Acked-by: Paul Zimmerman pa...@synopsys.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 v2 2/2] [usb] add support for ACPI identification to xhci-platform
On Tue, Nov 18, 2014 at 12:33 PM, Mark Langsdorf mlang...@redhat.com wrote:
On 11/18/2014 02:05 PM, Feng Kan wrote:
On Thu, Nov 13, 2014 at 10:36 AM, Mark Langsdorf mlang...@redhat.com
wrote:
On 11/04/2014 11:12 AM, Greg KH wrote:
On Tue, Nov 04, 2014 at 10:50:33AM -0600, Mark Langsdorf wrote:
#endif
+#ifdef CONFIG_ACPI
+static const struct acpi_device_id usb_xhci_acpi_match[] = {
+ /* APM X-Gene USB Controller */
+ { PNP0D10, },
Mark, would it be better to use PRP0001 instead as in this patch?
https://lkml.org/lkml/2014/9/16/230
Quoting Arnd,
In this case, the device does have an official ACPI ID PNP0D10,
so we should use that for compatibility with other operating
systems and with BIOS versions that provide the standard IDs.
Yes, thanks. I missed that part, sorry for the spam then.
--Mark Langsdorf
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
On Fri, Nov 14, 2014 at 01:54:46PM +0530, George Cherian wrote:
Disable the MUSB interrupts till MUSB is recovered fully from BABBLE
condition. There are chances that we could get multiple interrupts
till the time the babble recover work gets scheduled. Sometimes
this could even end up in an endless loop making MUSB itself unusable.
Reported-by: Felipe Balbi ba...@ti.com
Signed-off-by: George Cherian george.cher...@ti.com
while this helps the situation it doesn't solve the problem I'm having
with testusb on BBB when host port is connected to peripheral port on
the same BBB.
I still have:
# ./testusb -t 13 -c 10 -s 2048 -a
unknown speed /dev/bus/usb/002/0040
[ 114.811407] usbtest 2-1:3.0: set altsetting to 0 failed, -71
/dev/bus/usb/002/004 test 13 -- 71 (error 71)
[ 114.862387] CAUTION: musb: Babble Interrupt Occurred
[ 114.868132] usb 2-1: USB disconnect, device number 4
[ 114.961491] musb-hdrc musb-hdrc.1.auto: Restarting MUSB to recover from
Babble
[ 115.430829] usb 2-1: new high-speed USB device number 5 using musb-hdrc
[ 115.573471] zero gadget: high-speed config #3: source/sink
[ 115.584014] usbtest 2-1:3.0: Linux gadget zero
[ 115.588682] usbtest 2-1:3.0: high-speed {control in/out bulk-in bulk-out}
tests (+alt)
I think the driver is mis-detecting Babble. A babble only occurs when
the device side tries to move data without the host asking for anything.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] usb: gadget: USB3 support to the legacy printer driver
On 11/18/2014 03:47 PM, Felipe Balbi wrote: Hi, On Tue, Nov 18, 2014 at 03:41:43PM -0500, Jorge Ramirez-Ortiz wrote: you have no clue what these mean, do you ? How about reading the USB specification of even http://www.beyondlogic.org/usbnutshell/usb1.shtml Unfortunately I do. It was easier to temporarily hack the driver code for a test - while I was at it - rather than modifying the host code. Since you asked for them, I though you would read the logs and wonder where the funny ids where coming from. why do you even need to hack the host driver for these ? The driver shows a Printer Class interface and the linux host side driver should bind to it without any issues. the hack was on the gadget side. the usbhost test code in charge of sending the file to the device had the wrong ids. to save time -since I was modifying the gadget driver code and only for the tests (it is not part of the final patch) - I hacked those ids on the printer.c file. but anyway. lets move on. I removed those, recompiled the usb host code and sent the new traces. then the host side needs a fix because it shouldn't really care about the device ID, rather it should care about the class being printer. absolutely. however if you use libusb_open_device_with_vid_pid then well, these things happen... That hack above would have given you an answer: so I kind of know what the ids are for. honestly. anyway, will send the new logs - it took me a while to find and modify the host test code. Which host test code ? Why don't you just use lpr or even cat file /dev/lp0 or something like that ? it is some proprietary code that links libusb -part of a different project: it was useful as it generated some metrics I was interested in. I would be surprised if lpr doesn't work for the same purpose. do you want to debug that and find the culprit since you're already at it ? probably: I still need to get used to this process, thanks for bearing with me on this. no problem. I spoke to Ricardo Ribalda three months ago while I was doing this stuff. but yes, I might work on this -after I finish with this patch!- since I have access to the hardware locally. cool, that'll help. notice that the original PLX driver was still far from the theoretical 5Gbps target (I was expecting to measure at least 3Gbps and could only get 1Gbps). So 1Gbps should be the target to meet on the kernel.org net2280 - do you agree? this depends on a whole bunch of things. Mainline is a lot different from PLX's kernel tree, I'm sure. It also depends on how many PCIe lanes you're using. Just because USB3 guarantees 5Gbps bandwidth, if you use a 1x PCIe connector, you'll never get that ;-) yes, that is why I purchased a Lenovo ThinkServer TS140 just for this integration. it has one x16 Gen3 PCIe slot, one x1 Gen2 PCIe and one x16 Gen2 PCIe (x4 signal). so this should be enough. on the host side, I have good server as well. So really, there is no excuse to not get this right unless there is a problem in the plx silicon but from the Windows based metrics that I saw I dont think so. The only think I am missing is the USB3 analyzer I used to have in my previous company. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: gadget: USB3 support to the legacy printer driver
From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Felipe Balbi Sent: Tuesday, November 18, 2014 12:47 PM On Tue, Nov 18, 2014 at 03:41:43PM -0500, Jorge Ramirez-Ortiz wrote: notice that the original PLX driver was still far from the theoretical 5Gbps target (I was expecting to measure at least 3Gbps and could only get 1Gbps). So 1Gbps should be the target to meet on the kernel.org net2280 - do you agree? this depends on a whole bunch of things. Mainline is a lot different from PLX's kernel tree, I'm sure. It also depends on how many PCIe lanes you're using. Just because USB3 guarantees 5Gbps bandwidth, if you use a 1x PCIe connector, you'll never get that ;-) Being pedantic, USB3 runs at 4Gbps, not 5Gbps. The signal transitions on the bus are at 5GT/s (5 giga-transitions per second), but due to the 8b/10b encoding, that equates to 4Gbps data rate. -- Paul -- 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: gagdet: f_midi: fix parameter assignment
f_midi_register_card() uses midi-id and midi-index, so they need to be assigned before the function is called from f_midi_bind_config(). Move the assigment of midi-buflen and midi-qlen as well so they are all grouped. Compile tested only. Signed-off-by: Daniel Mack dan...@zonque.org --- drivers/usb/gadget/function/f_midi.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/usb/gadget/function/f_midi.c b/drivers/usb/gadget/function/f_midi.c index 807b31c..a83f129 100644 --- a/drivers/usb/gadget/function/f_midi.c +++ b/drivers/usb/gadget/function/f_midi.c @@ -954,6 +954,11 @@ int __init f_midi_bind_config(struct usb_configuration *c, /* set up ALSA midi devices */ midi-in_ports = in_ports; midi-out_ports = out_ports; + midi-id = kstrdup(id, GFP_KERNEL); + midi-index = index; + midi-buflen = buflen; + midi-qlen = qlen; + status = f_midi_register_card(midi); if (status 0) goto setup_fail; @@ -965,11 +970,6 @@ int __init f_midi_bind_config(struct usb_configuration *c, midi-func.set_alt = f_midi_set_alt; midi-func.disable = f_midi_disable; - midi-id = kstrdup(id, GFP_KERNEL); - midi-index = index; - midi-buflen = buflen; - midi-qlen = qlen; - status = usb_add_function(c, midi-func); if (status) goto setup_fail; -- 2.1.0 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
USB devices disappering on resume on pantherpoint chipset with dock
Hi, I'm having trouble with USB devices connected to a Thinkpad X230's dock disappearing after a few suspend/resume cycles. Devices connected directly to the laptop rather than the dock are not affected. The main symptom in the logs is a complaint about bandwidth, and comes from the bandwidth checking code in the xhci driver that is only used for Intel Pantherpoint chipsets, as far as I can tell. To give a controlled example, I booted the laptop running 3.17.1 with extra xhci logging, filled up the USB sockets on the dock with a flash drive, a keyboard and a couple of mice, then suspended and resumed it until the keyboard stopped working. Through the first two suspends everything works, but the reported bandwidth changes: [ 205.933357] xhci_hcd :00:14.0: Recalculating BW for rootport 3 [ 205.933360] xhci_hcd :00:14.0: Final bandwidth: 27, Limit: 1607, Reserved: 322, Available: 78 percent [ 409.192473] xhci_hcd :00:14.0: Recalculating BW for rootport 3 [ 409.192475] xhci_hcd :00:14.0: Final bandwidth: 402, Limit: 1607, Reserved: 322, Available: 54 percent [ 447.874989] xhci_hcd :00:14.0: Recalculating BW for rootport 3 [ 447.874991] xhci_hcd :00:14.0: Final bandwidth: 777, Limit: 1607, Reserved: 322, Available: 31 percent (It also reports bandwidth for some individual ports, but these don't change.) On the third resume it changes again, then later complains about the mice: [ 467.998687] xhci_hcd :00:14.0: Recalculating BW for rootport 3 [ 467.998689] xhci_hcd :00:14.0: Final bandwidth: 1152, Limit: 1607, Reserved: 322, Available: 8 percent ... [ 469.592653] xhci_hcd :00:14.0: Adding 1 ep ctxs, 11 now active. [ 469.592655] xhci_hcd :00:14.0: Recalculating BW for rootport 3 [ 469.592656] xhci_hcd :00:14.0: Not enough bandwidth on HS bus for newly activated TT. [ 469.592657] xhci_hcd :00:14.0: Removing 1 failed ep ctxs, 10 now active. [ 469.592658] xhci_hcd :00:14.0: Not enough bandwidth [ 469.592659] xhci_hcd :00:14.0: xhci_reset_bandwidth called for udev 880210693800 [ 469.592661] usb 3-3.4: Busted HC? Not enough HCD resources for old configuration. There are similar messages for another attempt at this mouse, and another pair for the other mouse. Then on the fourth resume the bandwidth is exhausted: [ 492.742794] xhci_hcd :00:14.0: Recalculating BW for rootport 3 [ 492.742796] xhci_hcd :00:14.0: Final bandwidth: 1277, Limit: 1607, Reserved: 322, Available: 0 percent And then the keyboard fails too. I originally had the problem with Ubuntu 14.04's stock kernel, so it's been around for a while, perhaps always. A bug filed with Ubuntu suggests that it also happens with some Dell machines, too (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1116525). I put more logs and system details up at http://www.z273.org.uk/tmp/2014-x230-usb-dock/ in case they're useful to someone. Cheers, Brian -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
Felipe,
On Tue, Nov 18, 2014 at 3:17 PM, Felipe Balbi ba...@ti.com wrote:
On Fri, Nov 14, 2014 at 01:54:46PM +0530, George Cherian wrote:
Disable the MUSB interrupts till MUSB is recovered fully from BABBLE
condition. There are chances that we could get multiple interrupts
till the time the babble recover work gets scheduled. Sometimes
this could even end up in an endless loop making MUSB itself unusable.
Reported-by: Felipe Balbi ba...@ti.com
Signed-off-by: George Cherian george.cher...@ti.com
while this helps the situation it doesn't solve the problem I'm having
with testusb on BBB when host port is connected to peripheral port on
the same BBB.
Try to find a BB white (which has rev 1.0 SoC) to see if babble still
happens, this could be PHY hw issue.
Regards,
-Bin.
I still have:
# ./testusb -t 13 -c 10 -s 2048 -a
unknown speed /dev/bus/usb/002/0040
[ 114.811407] usbtest 2-1:3.0: set altsetting to 0 failed, -71
/dev/bus/usb/002/004 test 13 -- 71 (error 71)
[ 114.862387] CAUTION: musb: Babble Interrupt Occurred
[ 114.868132] usb 2-1: USB disconnect, device number 4
[ 114.961491] musb-hdrc musb-hdrc.1.auto: Restarting MUSB to recover from
Babble
[ 115.430829] usb 2-1: new high-speed USB device number 5 using musb-hdrc
[ 115.573471] zero gadget: high-speed config #3: source/sink
[ 115.584014] usbtest 2-1:3.0: Linux gadget zero
[ 115.588682] usbtest 2-1:3.0: high-speed {control in/out bulk-in bulk-out}
tests (+alt)
I think the driver is mis-detecting Babble. A babble only occurs when
the device side tries to move data without the host asking for anything.
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: dwc2: resume root hub when device detect with suspend state
You should be aware that it's not safe to use hcd-state for anything in a host controller driver. That field is owned by usbcore, not by the HCD, and it is not protected by any locks. Thus, for example, hcd-state does not get set to HC_STATE_SUSPENDED until some time after the bus_suspend routine has returned. A port-change interrupt might occur during that time interval. Looks like there is explicit code in hcd_bus_suspend() to check for that race condition right after setting hcd-state, or do I misinterpret that (the Did we race with a root-hub wakeup event? part)? Also, it seems xhci_bus_suspend() explicitly sets 'hcd-state = HC_STATE_SUSPENDED' before giving up the spinlock for some undocumented reason, maybe to avoid exactly this problem. We could just copy that trick if the hcd.c solution isn't enough (although the DWC2 bus_suspend/bus_resume in the other patch don't grab that spinlock right now, where I'm also not so sure if that's a good idea...). -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: USB3 support to the legacy printer driver
On Tue, Nov 18, 2014 at 09:45:13PM +, Paul Zimmerman wrote: From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Felipe Balbi Sent: Tuesday, November 18, 2014 12:47 PM On Tue, Nov 18, 2014 at 03:41:43PM -0500, Jorge Ramirez-Ortiz wrote: notice that the original PLX driver was still far from the theoretical 5Gbps target (I was expecting to measure at least 3Gbps and could only get 1Gbps). So 1Gbps should be the target to meet on the kernel.org net2280 - do you agree? this depends on a whole bunch of things. Mainline is a lot different from PLX's kernel tree, I'm sure. It also depends on how many PCIe lanes you're using. Just because USB3 guarantees 5Gbps bandwidth, if you use a 1x PCIe connector, you'll never get that ;-) Being pedantic, USB3 runs at 4Gbps, not 5Gbps. The signal transitions on the bus are at 5GT/s (5 giga-transitions per second), but due to the 8b/10b encoding, that equates to 4Gbps data rate. I stand corrected :-) -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: musb: core: Disable the Interrupts till BABBLE is fully handled
On Tue, Nov 18, 2014 at 06:44:39PM -0600, Bin Liu wrote: Felipe, On Tue, Nov 18, 2014 at 3:17 PM, Felipe Balbi ba...@ti.com wrote: On Fri, Nov 14, 2014 at 01:54:46PM +0530, George Cherian wrote: Disable the MUSB interrupts till MUSB is recovered fully from BABBLE condition. There are chances that we could get multiple interrupts till the time the babble recover work gets scheduled. Sometimes this could even end up in an endless loop making MUSB itself unusable. Reported-by: Felipe Balbi ba...@ti.com Signed-off-by: George Cherian george.cher...@ti.com while this helps the situation it doesn't solve the problem I'm having with testusb on BBB when host port is connected to peripheral port on the same BBB. Try to find a BB white (which has rev 1.0 SoC) to see if babble still happens, this could be PHY hw issue. it only happens with my BBB when peripheral port is connected straight to host port. If I use another board as g_zero, then tests work just fine. If someone else can confirm this is the case with their board, I'd be happy. -- balbi signature.asc Description: Digital signature
Re: [PATCH] usb: gadget: USB3 support to the legacy printer driver
On Tue, Nov 18, 2014 at 04:33:42PM -0500, Jorge Ramirez-Ortiz wrote: On 11/18/2014 03:47 PM, Felipe Balbi wrote: Hi, On Tue, Nov 18, 2014 at 03:41:43PM -0500, Jorge Ramirez-Ortiz wrote: you have no clue what these mean, do you ? How about reading the USB specification of even http://www.beyondlogic.org/usbnutshell/usb1.shtml Unfortunately I do. It was easier to temporarily hack the driver code for a test - while I was at it - rather than modifying the host code. Since you asked for them, I though you would read the logs and wonder where the funny ids where coming from. why do you even need to hack the host driver for these ? The driver shows a Printer Class interface and the linux host side driver should bind to it without any issues. the hack was on the gadget side. the usbhost test code in charge of sending the file to the device had the wrong ids. to save time -since I was modifying the gadget driver code and only for the tests (it is not part of the final patch) - I hacked those ids on the printer.c file. but anyway. lets move on. I removed those, recompiled the usb host code and sent the new traces. then the host side needs a fix because it shouldn't really care about the device ID, rather it should care about the class being printer. absolutely. however if you use libusb_open_device_with_vid_pid then well, these things happen... heh :-) That hack above would have given you an answer: so I kind of know what the ids are for. honestly. anyway, will send the new logs - it took me a while to find and modify the host test code. Which host test code ? Why don't you just use lpr or even cat file /dev/lp0 or something like that ? it is some proprietary code that links libusb -part of a different project: it was useful as it generated some metrics I was interested in. I would be surprised if lpr doesn't work for the same purpose. do you want to debug that and find the culprit since you're already at it ? probably: I still need to get used to this process, thanks for bearing with me on this. no problem. I spoke to Ricardo Ribalda three months ago while I was doing this stuff. but yes, I might work on this -after I finish with this patch!- since I have access to the hardware locally. cool, that'll help. notice that the original PLX driver was still far from the theoretical 5Gbps target (I was expecting to measure at least 3Gbps and could only get 1Gbps). So 1Gbps should be the target to meet on the kernel.org net2280 - do you agree? this depends on a whole bunch of things. Mainline is a lot different from PLX's kernel tree, I'm sure. It also depends on how many PCIe lanes you're using. Just because USB3 guarantees 5Gbps bandwidth, if you use a 1x PCIe connector, you'll never get that ;-) yes, that is why I purchased a Lenovo ThinkServer TS140 just for this integration. it has one x16 Gen3 PCIe slot, one x1 Gen2 PCIe and one x16 Gen2 PCIe (x4 signal). so this should be enough. right, assuming PLX PCIe card actually supports that :-) on the host side, I have good server as well. So really, there is no excuse to not get this right unless there is a problem in the plx silicon but from the Windows based metrics that I saw I dont think so. The only think I am missing is the USB3 analyzer I used to have in my previous company. yeah, that helps a lot indeed. I'm always using my trusty beagle 5000. -- balbi signature.asc Description: Digital signature
[PATCH net-next v2 2/2] r8152: adjust rtl_start_rx
If there is a error for r8152_submit_rx(), add the remaining rx
buffers to the list. Then the remaining rx buffers could be
submitted later.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index df0868b..c7acadd 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2002,6 +2002,25 @@ static int rtl_start_rx(struct r8152 *tp)
break;
}
+ if (ret ++i RTL8152_MAX_RX) {
+ struct list_head rx_queue;
+ unsigned long flags;
+
+ INIT_LIST_HEAD(rx_queue);
+
+ do {
+ struct rx_agg *agg = tp-rx_info[i++];
+ struct urb *urb = agg-urb;
+
+ urb-actual_length = 0;
+ list_add_tail(agg-list, rx_queue);
+ } while (i RTL8152_MAX_RX);
+
+ spin_lock_irqsave(tp-rx_lock, flags);
+ list_splice_tail(rx_queue, tp-rx_done);
+ spin_unlock_irqrestore(tp-rx_lock, flags);
+ }
+
return ret;
}
--
1.9.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 net-next v2 1/2] r8152: adjust r8152_submit_rx
The behavior of handling the returned status from r8152_submit_rx()
is almost same, so let r8152_submit_rx() deal with the error
directly. This could avoid the duplicate code.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 41 +
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 0a30fd3..df0868b 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1032,7 +1032,6 @@ static void read_bulk_callback(struct urb *urb)
int status = urb-status;
struct rx_agg *agg;
struct r8152 *tp;
- int result;
agg = urb-context;
if (!agg)
@@ -1083,16 +1082,7 @@ static void read_bulk_callback(struct urb *urb)
break;
}
- result = r8152_submit_rx(tp, agg, GFP_ATOMIC);
- if (result == -ENODEV) {
- set_bit(RTL8152_UNPLUG, tp-flags);
- netif_device_detach(tp-netdev);
- } else if (result) {
- spin_lock(tp-rx_lock);
- list_add_tail(agg-list, tp-rx_done);
- spin_unlock(tp-rx_lock);
- tasklet_schedule(tp-tl);
- }
+ r8152_submit_rx(tp, agg, GFP_ATOMIC);
}
static void write_bulk_callback(struct urb *urb)
@@ -1680,7 +1670,6 @@ static void rx_bottom(struct r8152 *tp)
int len_used = 0;
struct urb *urb;
u8 *rx_data;
- int ret;
list_del_init(cursor);
@@ -1733,13 +1722,7 @@ find_next_rx:
}
submit:
- ret = r8152_submit_rx(tp, agg, GFP_ATOMIC);
- if (ret ret != -ENODEV) {
- spin_lock_irqsave(tp-rx_lock, flags);
- list_add_tail(agg-list, tp-rx_done);
- spin_unlock_irqrestore(tp-rx_lock, flags);
- tasklet_schedule(tp-tl);
- }
+ r8152_submit_rx(tp, agg, GFP_ATOMIC);
}
}
@@ -1806,11 +1789,29 @@ static void bottom_half(unsigned long data)
static
int r8152_submit_rx(struct r8152 *tp, struct rx_agg *agg, gfp_t mem_flags)
{
+ int ret = 0;
+
usb_fill_bulk_urb(agg-urb, tp-udev, usb_rcvbulkpipe(tp-udev, 1),
agg-head, agg_buf_sz,
(usb_complete_t)read_bulk_callback, agg);
- return usb_submit_urb(agg-urb, mem_flags);
+ ret = usb_submit_urb(agg-urb, mem_flags);
+
+ if (ret == -ENODEV) {
+ set_bit(RTL8152_UNPLUG, tp-flags);
+ netif_device_detach(tp-netdev);
+ } else if (ret) {
+ struct urb *urb = agg-urb;
+ unsigned long flags;
+
+ urb-actual_length = 0;
+ spin_lock_irqsave(tp-rx_lock, flags);
+ list_add_tail(agg-list, tp-rx_done);
+ spin_unlock_irqrestore(tp-rx_lock, flags);
+ tasklet_schedule(tp-tl);
+ }
+
+ return ret;
}
static void rtl_drop_queued_tx(struct r8152 *tp)
--
1.9.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 net-next v2 0/2] r8152: adjust rx functions
v2: For patch #1, set actual_length to 0 before adding the rx to the list, when a error occurs. For patch #2, change the flow. Stop submitting the rx if a error occurs, and add the remaining rx to the list for submitting later. v1: Adjust some flows and codes which are relative to r8152_submit_rx() and rtl_start_rx(). Hayes Wang (2): r8152: adjust r8152_submit_rx r8152: adjust rtl_start_rx drivers/net/usb/r8152.c | 60 - 1 file changed, 40 insertions(+), 20 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 2/6] phy: improved lookup method
Hi, On Tuesday 18 November 2014 09:06 PM, Heikki Krogerus wrote: On Tue, Nov 18, 2014 at 10:49:18AM +0530, Kishon Vijay Abraham I wrote: On Monday 17 November 2014 09:10 PM, Heikki Krogerus wrote: On Thu, Nov 13, 2014 at 07:03:01PM +0530, Vivek Gautam wrote: How about adding the change in attached patch [1] on top of this patch. Just introduced the phy pointer in phy_lookup structure, and modified phy_find() accordingly. I would be fine if we used the phy pointer to match, but if we have the pointer to the phy in the lookup, then I would say we need to remove the phy_name member. Otherwise we would have to support two ways of finding the lookups (one for the static lookups where we match to the phy_name and other where we match to the pointer). That means we will also not be able to create static lookups, but those would be only needed if we wanted to create them in board files. I don't think there will ever be need to create the lookups in board files, so I'm more then happy to remove the static way of creating the lookups. Just using the phy pointer sounds good. But interested to know where the phy pointer will be added to the lookup table. I'm making assumption that there will not be any (new) platforms where the bindings are not provided in HW descriptions like dt or ACPI tables. That leaves the lookups to be useful only in cases where a driver has to, for whatever reason, pass it's phy's forward, like dwc3 host. ULPI will be an other case where we will need to use them. right. Now the only user for the lookups is twl4030-usb, but since it's actually just ULPI type PHY in cases where we have platform data to deal with (please correct me if I'm wrong), I think we could later you mean passing consumer information using platform data? remove it's need for platform data completely with the help of the ULPI bus I'm working with. Sure. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 2/6] phy: improved lookup method
Hi, On Tuesday 18 November 2014 09:06 PM, Heikki Krogerus wrote: On Tue, Nov 18, 2014 at 10:49:18AM +0530, Kishon Vijay Abraham I wrote: On Monday 17 November 2014 09:10 PM, Heikki Krogerus wrote: On Thu, Nov 13, 2014 at 07:03:01PM +0530, Vivek Gautam wrote: How about adding the change in attached patch [1] on top of this patch. Just introduced the phy pointer in phy_lookup structure, and modified phy_find() accordingly. I would be fine if we used the phy pointer to match, but if we have the pointer to the phy in the lookup, then I would say we need to remove the phy_name member. Otherwise we would have to support two ways of finding the lookups (one for the static lookups where we match to the phy_name and other where we match to the pointer). That means we will also not be able to create static lookups, but those would be only needed if we wanted to create them in board files. I don't think there will ever be need to create the lookups in board files, so I'm more then happy to remove the static way of creating the lookups. Just using the phy pointer sounds good. But interested to know where the phy pointer will be added to the lookup table. I'm making assumption that there will not be any (new) platforms where the bindings are not provided in HW descriptions like dt or ACPI tables. That leaves the lookups to be useful only in cases where a driver has to, for whatever reason, pass it's phy's forward, like dwc3 host. ULPI will be an other case where we will need to use them. right. Now the only user for the lookups is twl4030-usb, but since it's actually just ULPI type PHY in cases where we have platform data to deal with (please correct me if I'm wrong), I think we could later You mean passing the consumer info using platform data? remove it's need for platform data completely with the help of the ULPI bus I'm working with. Sure. I'll be closing my phy tree by friday, so would be great if you can send your patches before that with Tested-by from Vivek. Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
