[PATCH] snd-usb-audio: Add support for Akai MPC Element MIDI controller
This device incorrectly reports its bInterfaceClass as 255, when it
should really be 1 (USB_CLASS_AUDIO).
Signed-off-by: Paul Bonser
---
diff --git a/sound/usb/quirks-table.h b/sound/usb/quirks-table.h
index 8590a32..42ccd76 100644
--- a/sound/usb/quirks-table.h
+++ b/sound/usb/quirks-table.h
@@ -2515,6 +2515,11 @@ YAMAHA_DEVICE(0x7010, "UB99"),
.type = QUIRK_MIDI_AKAI,
}
},
+{
+ /* Akai MPC Element */
+ USB_DEVICE(0x09e8, 0x0021),
+ .bInterfaceClass = USB_CLASS_AUDIO,
+},
/* TerraTec devices */
{
--
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: query on DWC3
Hi, On Mon, Dec 22, 2014 at 9:42 PM, Felipe Balbi wrote: > Hi again, > > On Mon, Dec 22, 2014 at 10:11:23AM -0600, Felipe Balbi wrote: >> (please don't top-post) Sure. >> >> On Sun, Dec 14, 2014 at 08:39:18AM +0530, sundeep subbaraya wrote: >> > Hi Paul, >> > >> > As per my understanding, for BULK OUT we do queue a request with 512 >> > bytes length since we do not >> >> sometimes we _do_ know the size. In case of Mass Storage, we _know_ that >> the first bulk out transfer will be 31-bytes (CBW), if we were to start >> a 31-byte transfer, we would't receive anything. >> >> > know the length of the transfer Host is going to send. For Control OUT >> > we know the length in wLength of >> > Setup packet, hence I assumed there is no difference in programming >> > model of Control IN and OUT. >> >> there is _no_ difference. It's just that it was agreed that for anything >> other than control ep, the function drivers would take care of it. See >> the uses of quirk_ep_out_aligned_size. got it..:) > > btw, why are you reimplementing the driver when there's a perfectly good > driver to use in mainline kernel ? I am writing a bare metal driver and it didn't work without alignment check mentioned above. > > -- > balbi Thanks, Sundeep.B.S. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] usb: dwc3: gadget: Stop TRB preparation after limit is reached
I can certainly provide the dwc3 specific kernel bootup logs, full regdump and any loglevel you want me to, if that helps Yeah, if you can provide those, then that'll help me verifying. Full logs from boot to failure point with VERBOSE_DEBUG enabled (considering you're not running on anything recent). Okay. I'll provide full verbose logs, along with the register dump, when I'm back to the office next week, for the working and non-working case, but how - as attachment or as inline? Either way will do but I have a feeling mailing list attachment size will bite you, so maybe it's best to make a tarball of both logs and send that as attachment. Compressed text will be very small. Attached are the dwc3 verbose logs and register dump without and with the fixes in this patchset. dwc3_fixes_logs.tar.gz Description: GNU Zip compressed data
RE: [PATCH v2 00/30] usb: updates for dwc2 gadget driver
On Mon, 5 Jan 2015, Paul Zimmerman wrote: > Adding Dinh to CC. > > Robert, Dinh, I would like to have your tested-bys for this series, please. > I'll try to test this by the end of this week. Dinh > > > From: Mian Yousaf Kaukab [mailto:yousaf.kau...@intel.com] > > Sent: Friday, January 02, 2015 6:42 AM > > > > Hi, > > This patchset consists of various bug fixes and feature enhancements for the > > dwc2 gadget driver. All the patches are verified on dwc2 v3.0a with > > dedicated > > fifos. Main focus of testing was with dma enabled. Although basic testing > > without dma was also done. > > > > It is based on testing/next branch in Felipe's git with > > https://lkml.org/lkml/2014/12/16/135 applied on top. > > > > Thank you, > > > > Best regards, > > Yousaf > > > > History: > > v2: > > - Rebased to Felipe's testing/next with > > https://lkml.org/lkml/2014/12/16/135 > >applied on top. > > - Fixed comments from Robert Baldyga > > - Some cosmetic changes > > - Replaced usb: dwc2: gadget: process setup packet on transfer complete > >with > >usb: dwc2: gadget: don't process XferCompl on setup packet > > - Updated usb: dwc2: gadget: provide gadget handle to the phy > >so that otg_set_peripheral is called in both udc_start and udc_stop. > > > > v1: > > - Addressed comments from Sergei Shtylyov > > > > Gregory Herrero (13): > > usb: dwc2: gadget: register gadget handle to the phy > > usb: dwc2: gadget: write correct value in ahbcfg register > > usb: dwc2: gadget: don't erase gahbcfg register when enabling dma > > usb: dwc2: gadget: add device tree property to enable dma > > Documentation: dt-bindings: add dt binding info for dwc2 g-use-dma > > usb: dwc2: gadget: configure fifos from device tree > > Documentation: dt-bindings: add dt binding info for dwc2 fifo resizing > > usb: dwc2: gadget: don't block after fifo flush timeout > > usb: dwc2: gadget: add vbus_session support > > usb: dwc2: gadget: reset fifo_map when initializing fifos > > usb: dwc2: gadget: fix pullup handling > > usb: dwc2: gadget: add vbus_draw support > > usb: dwc2: gadget: force gadget initialization in dev mode > > > > Mian Yousaf Kaukab (17): > > usb: dwc2: gadget: mask fifo empty irq with dma > > usb: dwc2: gadget: don't process XferCompl on setup packet > > usb: dwc2: gadget: don't embed ep0 buffers > > usb: dwc2: gadget: fix error path in dwc2_gadget_init > > usb: dwc2: gadget: add bi-directional endpoint support > > usb: dwc2: gadget: check interrupts for all endpoints > > usb: dwc2: gadget: remove unused members from hsotg_req > > usb: dwc2: gadget: fix debug loop limits > > usb: dwc2: gadget: consider all tx fifos > > usb: dwc2: gadget: kill requests after disabling ep > > usb: dwc2: gadget: manage ep0 state in software > > usb: dwc2: gadget: fix zero length packet transfers > > usb: dwc2: gadget: dont warn if endpoint is not enabled > > usb: dwc2: gadget: rename sent_zlp to send_zlp > > usb: dwc2: gadget: pick smallest acceptable fifo > > usb: dwc2: gadget: fix fifo allocation leak > > usb: dwc2: gadget: report disconnection after reset > > > > Documentation/devicetree/bindings/usb/dwc2.txt | 4 + > > drivers/usb/dwc2/core.h| 46 +- > > drivers/usb/dwc2/gadget.c | 786 > > - > > drivers/usb/dwc2/hw.h | 1 + > > 4 files changed, 550 insertions(+), 287 deletions(-) > > > > -- > > 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 > BR, Dinh -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3] usb: dwc2: add bus suspend/resume for dwc2
> From: Kever Yang [mailto:kever.y...@rock-chips.com] > Sent: Monday, January 05, 2015 5:42 PM > > Hi Paul, > > I think you need this patch to fix the problem: > > usb: dwc2: resume root hub when device detect with suspend state > https://patchwork.kernel.org/patch/5325111/ > > Thanks, > > - Kever > On 01/06/2015 09:23 AM, Paul Zimmerman wrote: > >> From: Kever Yang [mailto:kever.y...@rock-chips.com] > >> Sent: Wednesday, November 12, 2014 4:42 PM > >> > >> On 11/13/2014 07:22 AM, Doug Anderson wrote: > >>> Kever, > >>> > >>> On Mon, Nov 10, 2014 at 5:09 AM, Kever Yang > >>> wrote: > Hcd controller needs bus_suspend/resume, dwc2 controller make > root hub generate suspend/resume signal with hprt0 register > when work in host mode. > After the root hub enter suspend, we can make controller enter > low power state with PCGCTL register. > > We also update the lx_state for hsotg state. > > This patch has tested on rk3288 with suspend/resume. > > Signed-off-by: Kever Yang > Acked-by: Paul Zimmerman > --- > > Changes in v3: > - remove CONFIG_PM macro for bus_suspend/resume > - add PCGCTL operation for no device connect case > > Changes in v2: > - update commit message > - make dwc2 suspend/resume sourcecode work > > drivers/usb/dwc2/hcd.c | 88 > +++--- > 1 file changed, 77 insertions(+), 11 deletions(-) > >>> I would certainly appreciate confirmation, but my inclination is to > >>> NAK this change due to the fact that it regresses functionality. I > >>> haven't done any serious review of it, but I've been testing it and it > >>> appears to break hotplug. > >>> > >>> Said another way, I did this: > >>> > >>> 1. Without this patch, I booted with a USB stick in. It was detected. > >>> I unplugged it, waited 5 seconds, and then plugged it back in. The > >>> USB stick was redetcted. > >>> > >>> 2. With this patch, I did the same thing. The USB not redected after > >>> plugging it back in. > >> With this patch, the dwc2 hcd/root hub will be auto suspend after device > >> on port is disconnected, and it can't detect the device connect any more, > >> I think that's the problem. > >> > >> I will figure out how to make dwc2 detect the device connect after auto > >> suspend, > >> or disable the auto suspend feature for the dwc2 hcd. > > Kever, > > > > This patch has made it into Linus' kernel as commit 0cf884e819e0, and > > it breaks disconnect/connect on at least the Altera SOCFPGA platform. > > I haven't been able to test it on any other platforms. > > > > You need to submit a patch to either fix this, or to only enable this > > feature for the Rock-chip platform. Otherwise the patch has to be > > reverted. Unfortunately, after applying that patch there is another problem. If I connect a device that causes an overcurrent condition to the root port, then the port is dead after that. No further devices are detected until after I reboot. I tried adding another call to usb_hcd_resume_root_hub() in the "if (hprt0 & HPRT0_OVRCURRCHG)" branch, but then an overcurrent condition causes a continuous stream of these messages: [ 133.348776] dwc2 ffb4.usb: GetPortStatus wIndex=0x0001 flags=0x0022 [ 133.355717] dwc2 ffb4.usb: Overcurrent change detected [ 133.361179] dwc2 ffb4.usb: HPRT0: 0x0002 [ 133.365960] dwc2 ffb4.usb: port_status=0008 [ 133.373236] hub 1-0:1.0: state 7 ports 1 chg evt [ 133.380038] hub 1-0:1.0: hub_suspend [ 133.384237] usb usb1: bus auto-suspend, wakeup 1 [ 133.393631] dwc2 ffb4.usb: DWC OTG HCD HUB STATUS DATA: Root port status changed [ 133.401341] dwc2 ffb4.usb: port_connect_status_change: 0 [ 133.407157] dwc2 ffb4.usb: port_reset_change: 0 [ 133.412186] dwc2 ffb4.usb: port_enable_change: 0 [ 133.417310] dwc2 ffb4.usb: port_suspend_change: 0 [ 133.422519] dwc2 ffb4.usb: port_over_current_change: 1 [ 133.428154] usb usb1: suspend raced with wakeup event [ 133.433191] usb usb1: usb auto-resume [ 133.441522] hub 1-0:1.0: hub_resume [ 133.455505] dwc2 ffb4.usb: GetPortStatus wIndex=0x0001 flags=0x0022 [ 133.462443] dwc2 ffb4.usb: Overcurrent change detected [ 133.467907] dwc2 ffb4.usb: HPRT0: 0x0002 [ 133.472684] dwc2 ffb4.usb: port_status=0008 [ 133.480088] hub 1-0:1.0: state 7 ports 1 chg evt [ 133.485578] hub 1-0:1.0: hub_suspend [ 133.489157] usb usb1: bus auto-suspend, wakeup 1 [ 133.493768] dwc2 ffb4.usb: _dwc2_hcd_suspend() [ 133.498540] dwc2 ffb4.usb: DWC OTG HCD HUB STATUS DATA: Root port status changed [ 133.506257] dwc2 ffb4.usb: port_connect_status_change: 0 [ 133.512065] dwc2 ffb4.usb: port_reset_change: 0 [ 133.517102] dwc2 ffb4.usb: port_enable_change: 0 [ 133.522218] dwc2 ffb4.usb: port_suspend_change: 0 [ 133.527428] dwc2 ffb4.u
[PATCH] xhci: remove unused parameter 'xhci' in function xhci_handshake().
Parameter 'xhci' is no longer be used in function xhci_handshake(),
just remove it.
Signed-off-by: Lin Wang
---
drivers/usb/host/xhci-ring.c |2 +-
drivers/usb/host/xhci.c | 19 +--
drivers/usb/host/xhci.h |3 +--
3 files changed, 11 insertions(+), 13 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index e692e76..c84a959 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -299,7 +299,7 @@ static int xhci_abort_cmd_ring(struct xhci_hcd *xhci)
* seconds), then it should assume that the there are
* larger problems with the xHC and assert HCRST.
*/
- ret = xhci_handshake(xhci, &xhci->op_regs->cmd_ring,
+ ret = xhci_handshake(&xhci->op_regs->cmd_ring,
CMD_RING_RUNNING, 0, 5 * 1000 * 1000);
if (ret < 0) {
xhci_err(xhci, "Stopped the command ring failed, "
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 01fcbb5..2d1e73a 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -60,8 +60,7 @@ MODULE_PARM_DESC(quirks, "Bit flags for quirks to be enabled
as default");
* handshake done). There are two failure modes: "usec" have passed (major
* hardware flakeout), or the register reads as all-ones (hardware removed).
*/
-int xhci_handshake(struct xhci_hcd *xhci, void __iomem *ptr,
- u32 mask, u32 done, int usec)
+int xhci_handshake(void __iomem *ptr, u32 mask, u32 done, int usec)
{
u32 result;
@@ -111,7 +110,7 @@ int xhci_halt(struct xhci_hcd *xhci)
xhci_dbg_trace(xhci, trace_xhci_dbg_init, "// Halt the HC");
xhci_quiesce(xhci);
- ret = xhci_handshake(xhci, &xhci->op_regs->status,
+ ret = xhci_handshake(&xhci->op_regs->status,
STS_HALT, STS_HALT, XHCI_MAX_HALT_USEC);
if (!ret) {
xhci->xhc_state |= XHCI_STATE_HALTED;
@@ -140,7 +139,7 @@ static int xhci_start(struct xhci_hcd *xhci)
* Wait for the HCHalted Status bit to be 0 to indicate the host is
* running.
*/
- ret = xhci_handshake(xhci, &xhci->op_regs->status,
+ ret = xhci_handshake(&xhci->op_regs->status,
STS_HALT, 0, XHCI_MAX_HALT_USEC);
if (ret == -ETIMEDOUT)
xhci_err(xhci, "Host took too long to start, "
@@ -175,7 +174,7 @@ int xhci_reset(struct xhci_hcd *xhci)
command |= CMD_RESET;
writel(command, &xhci->op_regs->command);
- ret = xhci_handshake(xhci, &xhci->op_regs->command,
+ ret = xhci_handshake(&xhci->op_regs->command,
CMD_RESET, 0, 10 * 1000 * 1000);
if (ret)
return ret;
@@ -186,7 +185,7 @@ int xhci_reset(struct xhci_hcd *xhci)
* xHCI cannot write to any doorbells or operational registers other
* than status until the "Controller Not Ready" flag is cleared.
*/
- ret = xhci_handshake(xhci, &xhci->op_regs->status,
+ ret = xhci_handshake(&xhci->op_regs->status,
STS_CNR, 0, 10 * 1000 * 1000);
for (i = 0; i < 2; ++i) {
@@ -929,7 +928,7 @@ int xhci_suspend(struct xhci_hcd *xhci, bool do_wakeup)
/* Some chips from Fresco Logic need an extraordinary delay */
delay *= (xhci->quirks & XHCI_SLOW_SUSPEND) ? 10 : 1;
- if (xhci_handshake(xhci, &xhci->op_regs->status,
+ if (xhci_handshake(&xhci->op_regs->status,
STS_HALT, STS_HALT, delay)) {
xhci_warn(xhci, "WARN: xHC CMD_RUN timeout\n");
spin_unlock_irq(&xhci->lock);
@@ -944,7 +943,7 @@ int xhci_suspend(struct xhci_hcd *xhci, bool do_wakeup)
command = readl(&xhci->op_regs->command);
command |= CMD_CSS;
writel(command, &xhci->op_regs->command);
- if (xhci_handshake(xhci, &xhci->op_regs->status,
+ if (xhci_handshake(&xhci->op_regs->status,
STS_SAVE, 0, 10 * 1000)) {
xhci_warn(xhci, "WARN: xHC save state timeout\n");
spin_unlock_irq(&xhci->lock);
@@ -1011,7 +1010,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
command = readl(&xhci->op_regs->command);
command |= CMD_CRS;
writel(command, &xhci->op_regs->command);
- if (xhci_handshake(xhci, &xhci->op_regs->status,
+ if (xhci_handshake(&xhci->op_regs->status,
STS_RESTORE, 0, 10 * 1000)) {
xhci_warn(xhci, "WARN: xHC restore state timeout\n");
spin_unlock_irq(&xhci->lock);
@@ -1082,7 +1081,7 @@ int xhci_resume(struct xhci_hcd *xhci, bool hibernated)
command = readl(&xhci->op_regs->command);
command |= CMD_RUN;
writel(command, &xhci->op_regs->command);
- xhci_handshake(xhci, &xhci->op_regs->status, STS_HALT,
+ xhci_handshake(
[PATCH] xhci: clean up work to remove unused parameters for functions in xhci-mem.c
Some parameters are not used by functions in xhci-mem.c, just
remove it.
Signed-off-by: Lin Wang
---
drivers/usb/host/xhci-dbg.c |2 +-
drivers/usb/host/xhci-mem.c | 21 +
drivers/usb/host/xhci-ring.c |6 +++---
drivers/usb/host/xhci.c | 34 +-
drivers/usb/host/xhci.h |7 +++
5 files changed, 33 insertions(+), 37 deletions(-)
diff --git a/drivers/usb/host/xhci-dbg.c b/drivers/usb/host/xhci-dbg.c
index bb89175..745717e 100644
--- a/drivers/usb/host/xhci-dbg.c
+++ b/drivers/usb/host/xhci-dbg.c
@@ -552,7 +552,7 @@ void xhci_dbg_ctx(struct xhci_hcd *xhci,
if (ctx->type == XHCI_CTX_TYPE_INPUT) {
struct xhci_input_control_ctx *ctrl_ctx =
- xhci_get_input_control_ctx(xhci, ctx);
+ xhci_get_input_control_ctx(ctx);
if (!ctrl_ctx) {
xhci_warn(xhci, "Could not get input context, bad
type.\n");
return;
diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 5cb3d7a..2e6eaf4 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -535,7 +535,7 @@ static void xhci_free_container_ctx(struct xhci_hcd *xhci,
kfree(ctx);
}
-struct xhci_input_control_ctx *xhci_get_input_control_ctx(struct xhci_hcd
*xhci,
+struct xhci_input_control_ctx *xhci_get_input_control_ctx(
struct xhci_container_ctx *ctx)
{
if (ctx->type != XHCI_CTX_TYPE_INPUT)
@@ -784,8 +784,7 @@ void xhci_setup_streams_ep_input_ctx(struct xhci_hcd *xhci,
* Reinstalls the "normal" endpoint ring (at its previous dequeue mark,
* not at the beginning of the ring).
*/
-void xhci_setup_no_streams_ep_input_ctx(struct xhci_hcd *xhci,
- struct xhci_ep_ctx *ep_ctx,
+void xhci_setup_no_streams_ep_input_ctx(struct xhci_ep_ctx *ep_ctx,
struct xhci_virt_ep *ep)
{
dma_addr_t addr;
@@ -1342,8 +1341,7 @@ static u32 xhci_get_endpoint_mult(struct usb_device *udev,
return ep->ss_ep_comp.bmAttributes;
}
-static u32 xhci_get_endpoint_type(struct usb_device *udev,
- struct usb_host_endpoint *ep)
+static u32 xhci_get_endpoint_type(struct usb_host_endpoint *ep)
{
int in;
u32 type;
@@ -1376,8 +1374,7 @@ static u32 xhci_get_endpoint_type(struct usb_device *udev,
* Basically, this is the maxpacket size, multiplied by the burst size
* and mult size.
*/
-static u32 xhci_get_max_esit_payload(struct xhci_hcd *xhci,
- struct usb_device *udev,
+static u32 xhci_get_max_esit_payload(struct usb_device *udev,
struct usb_host_endpoint *ep)
{
int max_burst;
@@ -1418,7 +1415,7 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,
ep_index = xhci_get_endpoint_index(&ep->desc);
ep_ctx = xhci_get_ep_ctx(xhci, virt_dev->in_ctx, ep_index);
- endpoint_type = xhci_get_endpoint_type(udev, ep);
+ endpoint_type = xhci_get_endpoint_type(ep);
if (!endpoint_type)
return -EINVAL;
ep_ctx->ep_info2 = cpu_to_le32(endpoint_type);
@@ -1484,7 +1481,7 @@ int xhci_endpoint_init(struct xhci_hcd *xhci,
}
ep_ctx->ep_info2 |= cpu_to_le32(MAX_PACKET(max_packet) |
MAX_BURST(max_burst));
- max_esit_payload = xhci_get_max_esit_payload(xhci, udev, ep);
+ max_esit_payload = xhci_get_max_esit_payload(udev, ep);
ep_ctx->tx_info =
cpu_to_le32(MAX_ESIT_PAYLOAD_FOR_EP(max_esit_payload));
/*
@@ -1773,7 +1770,7 @@ struct xhci_command *xhci_alloc_command(struct xhci_hcd
*xhci,
return command;
}
-void xhci_urb_free_priv(struct xhci_hcd *xhci, struct urb_priv *urb_priv)
+void xhci_urb_free_priv(struct urb_priv *urb_priv)
{
if (urb_priv) {
kfree(urb_priv->td[0]);
@@ -1926,7 +1923,7 @@ static int xhci_test_trb_in_td(struct xhci_hcd *xhci,
}
/* TRB math checks for xhci_trb_in_td(), using the command and event rings. */
-static int xhci_check_trb_in_td_math(struct xhci_hcd *xhci, gfp_t mem_flags)
+static int xhci_check_trb_in_td_math(struct xhci_hcd *xhci)
{
struct {
dma_addr_t input_dma;
@@ -2452,7 +2449,7 @@ int xhci_mem_init(struct xhci_hcd *xhci, gfp_t flags)
flags);
if (!xhci->event_ring)
goto fail;
- if (xhci_check_trb_in_td_math(xhci, flags) < 0)
+ if (xhci_check_trb_in_td_math(xhci) < 0)
goto fail;
xhci->erst.entries = dma_alloc_coherent(dev,
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index e692e76..5e1090a 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -609,7 +609,7 @@ static void xhci_giveback_urb_in_irq(struct xhci_hcd *xhci,
spin_unlock(&xhci->lock);
usb_hcd_giveback_urb(hcd, ur
[PATCH] xhci: Clean up work to xhci_add_endpoint().
This patch removes unused variable "out_ctx" and avoid multiple calls
to function xhci_get_endpoint_flag().
Signed-off-by: Lin Wang
---
drivers/usb/host/xhci.c |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 01fcbb5..93200db 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1714,7 +1714,7 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
struct usb_host_endpoint *ep)
{
struct xhci_hcd *xhci;
- struct xhci_container_ctx *in_ctx, *out_ctx;
+ struct xhci_container_ctx *in_ctx;
unsigned int ep_index;
struct xhci_input_control_ctx *ctrl_ctx;
u32 added_ctxs;
@@ -1745,7 +1745,6 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
virt_dev = xhci->devs[udev->slot_id];
in_ctx = virt_dev->in_ctx;
- out_ctx = virt_dev->out_ctx;
ctrl_ctx = xhci_get_input_control_ctx(xhci, in_ctx);
if (!ctrl_ctx) {
xhci_warn(xhci, "%s: Could not get input context, bad type.\n",
@@ -1758,8 +1757,7 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
* to add it again without dropping it, reject the addition.
*/
if (virt_dev->eps[ep_index].ring &&
- !(le32_to_cpu(ctrl_ctx->drop_flags) &
- xhci_get_endpoint_flag(&ep->desc))) {
+ !(le32_to_cpu(ctrl_ctx->drop_flags) & added_ctxs)) {
xhci_warn(xhci, "Trying to add endpoint 0x%x "
"without dropping it.\n",
(unsigned int) ep->desc.bEndpointAddress);
@@ -1769,8 +1767,7 @@ int xhci_add_endpoint(struct usb_hcd *hcd, struct
usb_device *udev,
/* If the HCD has already noted the endpoint is enabled,
* ignore this request.
*/
- if (le32_to_cpu(ctrl_ctx->add_flags) &
- xhci_get_endpoint_flag(&ep->desc)) {
+ if (le32_to_cpu(ctrl_ctx->add_flags) & added_ctxs) {
xhci_warn(xhci, "xHCI %s called with enabled ep %p\n",
__func__, ep);
return 0;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: kernel panic with USB3+DVB+ARM
On Mon, Jan 05, 2015 at 05:13:48PM +0100, JPT wrote: > Hi, > > would you like to trouble-shoot the kernel USB3/xhci code? > > I had a lot of struggle with the following set up: > - Netgear ReadyNAS rn104 (ARMv7) running plain debian > - Fresco Logic FL1009 USB3 controller > - selfbuilt kernel.org kernel 3.18.1 > - Technisat SkyStar USB HD (DVB-S/S2) - USB 2.0 Highspeed device > > more hardware details can be found here: > http://natisbad.org/NAS2/index.html#hw > > > if it worked, it crashed the system every hour with kernel panic in > dvb_demux.c/dvb_dmx_crc32() > > if it did not crash the system, the whole USB/DVB-S hard- and software > got instable soon, causing the device to stop working. > > The solution was plugging the DVB device into USB2 port (front) instead > of USB3 (rear). > So this makes me believe the problem is in USB3 code. Is that where the kernel panics show the problem happens? Without them, there's nothing we can do to help out except randomly guess, sorry. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] usb: dwc2: add bus suspend/resume for dwc2
Hi Paul, I think you need this patch to fix the problem: usb: dwc2: resume root hub when device detect with suspend state https://patchwork.kernel.org/patch/5325111/ Thanks, - Kever On 01/06/2015 09:23 AM, Paul Zimmerman wrote: From: Kever Yang [mailto:kever.y...@rock-chips.com] Sent: Wednesday, November 12, 2014 4:42 PM On 11/13/2014 07:22 AM, Doug Anderson wrote: Kever, On Mon, Nov 10, 2014 at 5:09 AM, Kever Yang wrote: Hcd controller needs bus_suspend/resume, dwc2 controller make root hub generate suspend/resume signal with hprt0 register when work in host mode. After the root hub enter suspend, we can make controller enter low power state with PCGCTL register. We also update the lx_state for hsotg state. This patch has tested on rk3288 with suspend/resume. Signed-off-by: Kever Yang Acked-by: Paul Zimmerman --- Changes in v3: - remove CONFIG_PM macro for bus_suspend/resume - add PCGCTL operation for no device connect case Changes in v2: - update commit message - make dwc2 suspend/resume sourcecode work drivers/usb/dwc2/hcd.c | 88 +++--- 1 file changed, 77 insertions(+), 11 deletions(-) I would certainly appreciate confirmation, but my inclination is to NAK this change due to the fact that it regresses functionality. I haven't done any serious review of it, but I've been testing it and it appears to break hotplug. Said another way, I did this: 1. Without this patch, I booted with a USB stick in. It was detected. I unplugged it, waited 5 seconds, and then plugged it back in. The USB stick was redetcted. 2. With this patch, I did the same thing. The USB not redected after plugging it back in. With this patch, the dwc2 hcd/root hub will be auto suspend after device on port is disconnected, and it can't detect the device connect any more, I think that's the problem. I will figure out how to make dwc2 detect the device connect after auto suspend, or disable the auto suspend feature for the dwc2 hcd. Kever, This patch has made it into Linus' kernel as commit 0cf884e819e0, and it breaks disconnect/connect on at least the Altera SOCFPGA platform. I haven't been able to test it on any other platforms. You need to submit a patch to either fix this, or to only enable this feature for the Rock-chip platform. Otherwise the patch has to be reverted. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3] usb: dwc2: add bus suspend/resume for dwc2
> From: Kever Yang [mailto:kever.y...@rock-chips.com]
> Sent: Wednesday, November 12, 2014 4:42 PM
>
> On 11/13/2014 07:22 AM, Doug Anderson wrote:
> > Kever,
> >
> > On Mon, Nov 10, 2014 at 5:09 AM, Kever Yang
> > wrote:
> >> Hcd controller needs bus_suspend/resume, dwc2 controller make
> >> root hub generate suspend/resume signal with hprt0 register
> >> when work in host mode.
> >> After the root hub enter suspend, we can make controller enter
> >> low power state with PCGCTL register.
> >>
> >> We also update the lx_state for hsotg state.
> >>
> >> This patch has tested on rk3288 with suspend/resume.
> >>
> >> Signed-off-by: Kever Yang
> >> Acked-by: Paul Zimmerman
> >> ---
> >>
> >> Changes in v3:
> >> - remove CONFIG_PM macro for bus_suspend/resume
> >> - add PCGCTL operation for no device connect case
> >>
> >> Changes in v2:
> >> - update commit message
> >> - make dwc2 suspend/resume sourcecode work
> >>
> >> drivers/usb/dwc2/hcd.c | 88
> >> +++---
> >> 1 file changed, 77 insertions(+), 11 deletions(-)
> > I would certainly appreciate confirmation, but my inclination is to
> > NAK this change due to the fact that it regresses functionality. I
> > haven't done any serious review of it, but I've been testing it and it
> > appears to break hotplug.
> >
> > Said another way, I did this:
> >
> > 1. Without this patch, I booted with a USB stick in. It was detected.
> > I unplugged it, waited 5 seconds, and then plugged it back in. The
> > USB stick was redetcted.
> >
> > 2. With this patch, I did the same thing. The USB not redected after
> > plugging it back in.
> With this patch, the dwc2 hcd/root hub will be auto suspend after device
> on port is disconnected, and it can't detect the device connect any more,
> I think that's the problem.
>
> I will figure out how to make dwc2 detect the device connect after auto
> suspend,
> or disable the auto suspend feature for the dwc2 hcd.
Kever,
This patch has made it into Linus' kernel as commit 0cf884e819e0, and
it breaks disconnect/connect on at least the Altera SOCFPGA platform.
I haven't been able to test it on any other platforms.
You need to submit a patch to either fix this, or to only enable this
feature for the Rock-chip platform. Otherwise the patch has to be
reverted.
--
Paul
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
Re: Difference between run time and normal suspend
2015-01-05 23:40 GMT+08:00 Alan Stern : > On Mon, 5 Jan 2015, vichy wrote: > >> hi all: >> after tracing and reading kernel usb source code about run time and >> normal suspend. >> 1. how could we check the rum time suspend is work on some device? >> By plugging in devices and check whether >> /sys/bus/usb/devices/.../power/ is empty or not? > > No. That directory will never be empty. > > You can check whether runtime suspend works by enabling it: > > echo auto >/sys/bus/usb/devices/.../power/control > > You can see whether the device has been suspended by looking at the > runtime_status and runtime_suspended_time files in the .../power > directory. > >> 2. I plug in one mouse and found the device will auto disconnect every >> 2 secs, the default value of usb_autosuspend_delay. >> But I have some questions >> a. how kernel judge the device is idle, from usb spec, the idle >> mean there is no any bus traffic, including sof, over 3ms and host >> will always firing sof even there is no transaction on the bus. > > The kernel judges a device to be idle if it hasn't been used in some > time. The bus traffic has nothing to do with it. > >> b. I think dynamic suspend is used for saving power when device is >> idle for a specific time, but why the mouse will dynamic resume when >> suspend for a while. it should resume when user or external event >> trigger it for resume right? > > That's right. If your mouse is resuming, it must be because some event > has triggered the resume. The mouse will reconnect even I just kept it connected and not moving it. is there any method or debug message we can tell what is going on to make it resume? sincere appreciate your help, -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] usb: storage: adjust module reference for scsi host
2015-01-06 0:27 GMT+09:00 Alan Stern : > On Mon, 5 Jan 2015, Akinobu Mita wrote: > >> While accessing a unusual usb storage (ums-alauda, ums-cypress, ...), >> the module reference count is not incremented. Because these drivers >> allocate scsi hosts with usb_stor_host_template defined in usb-storage >> module. So these drivers always can be unloaded. >> >> This fixes it by adjusting module reference after scsi host allocation. > >> diff --git a/drivers/usb/storage/alauda.c b/drivers/usb/storage/alauda.c >> index 62c2d9d..77660d6 100644 >> --- a/drivers/usb/storage/alauda.c >> +++ b/drivers/usb/storage/alauda.c >> @@ -1242,6 +1242,7 @@ static int alauda_probe(struct usb_interface *intf, >> us->transport = alauda_transport; >> us->transport_reset = usb_stor_Bulk_reset; >> us->max_lun = 1; >> + us_to_host(us)->module = THIS_MODULE; >> >> result = usb_stor_probe2(us); >> return result; > > ... etc. > > An easier and more foolproof approach would be to change > usb_store_probe2 to take an extra argument for the owner: > > int _usb_stor_probe2(struct us_data *us, struct module *owner) > ... > us_to_host(us)->module = owner; > ... > > Then in usb.h: > > extern int _usb_stor_probe2(struct us_data *us, struct module *owner); > #define usb_stor_probe2(us) _usb_stor_probe2(us, THIS_MODULE) > > This pattern is already used in several other places in the kernel. Sounds good. I'll take this idea and update this patch. -- 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: qcserial: AT unsolicited response codes missing with Sierra Wireless MC7304
Johan Hovold wrote:
> On Sat, Dec 27, 2014 at 10:54:09PM +0100, Reinhard Speyerer wrote:
> > Reinhard Speyerer wrote:
> > > Johan Hovold wrote:
> > > > On Sun, Dec 21, 2014 at 11:25:45PM +0100, Reinhard Speyerer wrote:
>
> > With the qcserial.c patch below (for Linux kernel 3.16.3) I was able to
> > verify that adding the send_setup code fixes the missing URCs for the
> > MC7304. To avoid potential side effects for other ports of the MC7304
> > the send_setup code is only used for the AT port (USB interface 3).
>
> Thanks for verifying this.
>
> After looking at this some more, and depending on whether you can find
> out if the vendor driver sends these requests for all devices, I think
> your original proposal of simply moving this device over to option might
> be the best solution after all.
Sorry,
I don't know whether the vendor GobiSerial driver does this.
>
> What is the "lsusb -v" output for this device?
>
Please see below (for a MC7304 without USB audio interfaces).
> Perhaps you can use USB_DEVICE_AND_INTERFACE_INFO so you don't have to
> blacklist so many interfaces explicitly (e.g. the AUDIO interfaces)?
>
Since the DM/DIAG interface uses bInterfaceSubClass/bInterfaceProtocol
values which differ from the values for the NMEA and AT interfaces this
seems to require two USB_DEVICE_AND_INTERFACE_INFO entries and might no
longer work if the vendor decides to uses different value e.g. with newer
firmware versions.
My preference would be to use USB_DEVICE_INTERFACE_CLASS with 0xff instead:
--- drivers/usb/serial/option.c-std 2014-08-04 00:25:02.0 +0200
+++ drivers/usb/serial/option.c 2015-01-05 17:27:32.581915787 +0100
@@ -236,2 +236,4 @@
+#define SIERRA_VENDOR_ID 0x1199
+
#define CMOTECH_VENDOR_ID 0x16d8
@@ -503,3 +505,3 @@
-#define MAX_BL_NUM 8
+#define MAX_BL_NUM 11
struct option_blacklist_info {
@@ -579,2 +581,7 @@
+static const struct option_blacklist_info sierra_mc73xx_blacklist = {
+ .sendsetup = BIT(0) | BIT(2),
+ .reserved = BIT(8) | BIT(10) | BIT(11),
+};
+
static const struct usb_device_id option_ids[] = {
@@ -1075,2 +1082,4 @@
{ USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */
+ { USB_DEVICE_INTERFACE_CLASS(SIERRA_VENDOR_ID, 0x68c0, 0xff),
+ .driver_info = (kernel_ulong_t)&sierra_mc73xx_blacklist }, /* MC73xx
*/
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
Regards,
Reinhard
Bus 001 Device 014: ID 1199:68c0 Sierra Wireless, Inc.
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize064
idVendor 0x1199 Sierra Wireless, Inc.
idProduct 0x68c0
bcdDevice0.06
iManufacturer 1 Sierra Wireless, Incorporated
iProduct2 MC7304
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 220
bNumInterfaces 6
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass255 Vendor Specific Subclass
bInterfaceProtocol255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes2
Transfer TypeBulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber2
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
** UNRECOGNIZED: 05 24 00 10 01
** UNRECOGNIZED: 05 24 01 00 00
** UNRECOGNIZED: 04 24 02 02
** UNRECOGNIZED: 05 24 06 00 00
Endpoint Descripto
Re: Issues with commit 34b48db6 ("block: remove artifical max_hw_sectors cap")
I will later tonight. For now, I'm using 3.18.x (for another reason), which doesn't have this commit. My Linus-latest tree has a "fix" that imposed a hard limit of 32767, which worked for me then. On January 5, 2015 12:07:56 PM PST, Alan Stern wrote: >On Mon, 5 Jan 2015, Christoph Hellwig wrote: > >> On Tue, Dec 30, 2014 at 08:36:34AM -0800, Kenneth R. Crudup wrote: >> > OP here. FWIW, this is what I get when running that command on the >SCSI >> > generic device that corresponds to the USB-3 (non-UAS) disk[1] that >had the >> > issue: >> >> So it looks like this one actually provides sane values, but we don't >> we never even look at EVPD pages for usb devices due to the wrong >SCSI >> level? > >According to James Bottomley, it doesn't matter much what the EVPD >pages say. The limitation is imposed by the USB _bridge_, whereas the >EVPD data indicates what the _drive_ is capable of. So we can't rely >on that data anyway. (Although if the EVPD data indicates a limit >smaller than the bridge can handle, then we'd need to pay attention to >it.) > >The patch I posted sets a general limit of 32 MB for USB drives that >don't have a quirk flag for a smaller limit. > >Kenneth, have you tried that patch? Does it fix your problem? > >Alan Stern -- Sent from my 2014 Galaxy Note 10.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: Issues with commit 34b48db6 ("block: remove artifical max_hw_sectors cap")
On Mon, 5 Jan 2015, Christoph Hellwig wrote: > On Tue, Dec 30, 2014 at 08:36:34AM -0800, Kenneth R. Crudup wrote: > > OP here. FWIW, this is what I get when running that command on the SCSI > > generic device that corresponds to the USB-3 (non-UAS) disk[1] that had the > > issue: > > So it looks like this one actually provides sane values, but we don't > we never even look at EVPD pages for usb devices due to the wrong SCSI > level? According to James Bottomley, it doesn't matter much what the EVPD pages say. The limitation is imposed by the USB _bridge_, whereas the EVPD data indicates what the _drive_ is capable of. So we can't rely on that data anyway. (Although if the EVPD data indicates a limit smaller than the bridge can handle, then we'd need to pay attention to it.) The patch I posted sets a general limit of 32 MB for USB drives that don't have a quirk flag for a smaller limit. Kenneth, have you tried that patch? Does it fix your problem? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] drivers: usb: dwc2: remove 'force' parameter from kill_all_requests()
> From: Robert Baldyga [mailto:r.bald...@samsung.com]
> Sent: Tuesday, December 16, 2014 2:52 AM
>
> This patch fixes in simpler way the bug described in [1] and [2]. It
> looks like DWC2 is the only UDC driver that doesn't force usb requests
> to complete in ep_disable() function. This causes described problem,
> because we have no guarantee that all requests will be completed before
> unbind of usb function.
>
> To fix this problem we force all requests of disabled endpoint to complete.
> Also currently running request is not handled. This allowed to simplify
> code of kill_all_requests() function, because 'force' parameter is always
> set to true, so we don't need it anymore.
>
> In s3c_hsotg_rx_data() we change function used to print message when active
> request is NULL from dev_warn() to dev_dbg(), because such situation is
> harmless for driver and now it can take place during normal endpoint
> disabling.
>
> [1] https://lkml.org/lkml/2014/12/9/283
> [2] https://lkml.org/lkml/2014/12/12/360
>
> Signed-off-by: Robert Baldyga
> ---
> drivers/usb/dwc2/gadget.c | 23 ---
> 1 file changed, 8 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
> index 200168e..fee0ad5 100644
> --- a/drivers/usb/dwc2/gadget.c
> +++ b/drivers/usb/dwc2/gadget.c
> @@ -1305,7 +1305,7 @@ static void s3c_hsotg_rx_data(struct dwc2_hsotg *hsotg,
> int ep_idx, int size)
> u32 epctl = readl(hsotg->regs + DOEPCTL(ep_idx));
> int ptr;
>
> - dev_warn(hsotg->dev,
> + dev_dbg(hsotg->dev,
>"%s: FIFO %d bytes on ep%d but no req
> (DXEPCTl=0x%08x)\n",
>__func__, size, ep_idx, epctl);
>
> @@ -1988,30 +1988,23 @@ static void s3c_hsotg_irq_enumdone(struct dwc2_hsotg
> *hsotg)
> * @hsotg: The device state.
> * @ep: The endpoint the requests may be on.
> * @result: The result code to use.
> - * @force: Force removal of any current requests
> *
> * Go through the requests on the given endpoint and mark them
> * completed with the given result code.
> */
> static void kill_all_requests(struct dwc2_hsotg *hsotg,
> struct s3c_hsotg_ep *ep,
> - int result, bool force)
> + int result)
> {
> struct s3c_hsotg_req *req, *treq;
> unsigned size;
>
> - list_for_each_entry_safe(req, treq, &ep->queue, queue) {
> - /*
> - * currently, we can't do much about an already
> - * running request on an in endpoint
> - */
> -
> - if (ep->req == req && ep->dir_in && !force)
> - continue;
> + ep->req = NULL;
>
> + list_for_each_entry_safe(req, treq, &ep->queue, queue)
> s3c_hsotg_complete_request(hsotg, ep, req,
> result);
> - }
> +
> if (!hsotg->dedicated_fifos)
> return;
> size = (readl(hsotg->regs + DTXFSTS(ep->index)) & 0x) * 4;
> @@ -2036,7 +2029,7 @@ void s3c_hsotg_disconnect(struct dwc2_hsotg *hsotg)
>
> hsotg->connected = 0;
> for (ep = 0; ep < hsotg->num_of_eps; ep++)
> - kill_all_requests(hsotg, &hsotg->eps[ep], -ESHUTDOWN, true);
> + kill_all_requests(hsotg, &hsotg->eps[ep], -ESHUTDOWN);
>
> call_gadget(hsotg, disconnect);
> }
> @@ -2334,7 +2327,7 @@ irq_retry:
> msecs_to_jiffies(200))) {
>
> kill_all_requests(hsotg, &hsotg->eps[0],
> - -ECONNRESET, true);
> + -ECONNRESET);
>
> s3c_hsotg_core_init_disconnected(hsotg);
> s3c_hsotg_core_connect(hsotg);
> @@ -2588,7 +2581,7 @@ static int s3c_hsotg_ep_disable(struct usb_ep *ep)
>
> spin_lock_irqsave(&hsotg->lock, flags);
> /* terminate all requests with shutdown */
> - kill_all_requests(hsotg, hs_ep, -ESHUTDOWN, false);
> + kill_all_requests(hsotg, hs_ep, -ESHUTDOWN);
>
> hsotg->fifo_map &= ~(1 hs_ep->fifo_index = 0;
> --
> 1.9.1
Acked-by: Paul Zimmerman
--
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: dwc2: add support for initial state for dual-role mode
> From: Marek Szyprowski [mailto:m.szyprow...@samsung.com]
> Sent: Wednesday, December 17, 2014 5:50 AM
>
> DWC2 module on Exynos SoCs is used only as peripheral controller (UDC),
> so add support for selecting default initial state for dual-role mode. The
> default init mode can be overridden by device tree 'dr_mode' property.
> This patch enables to use usb gadget on Exynos SoCs, when DWC2 driver has
> been compiled as 'dual-role driver'.
>
> Signed-off-by: Marek Szyprowski
Hi Marek,
Why can't you just set dr_mode=USB_DR_MODE_PERIPHERAL in your platform's
device tree data?
--
Paul
> ---
> drivers/usb/dwc2/core.h | 3 +++
> drivers/usb/dwc2/platform.c | 62
> ++---
> 2 files changed, 56 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/usb/dwc2/core.h b/drivers/usb/dwc2/core.h
> index 7a70a13..b0fed4e 100644
> --- a/drivers/usb/dwc2/core.h
> +++ b/drivers/usb/dwc2/core.h
> @@ -354,6 +354,7 @@ struct dwc2_core_params {
> int reload_ctl;
> int ahbcfg;
> int uframe_sched;
> + int default_dr_mode;
> };
>
> /**
> @@ -570,6 +571,8 @@ struct dwc2_hsotg {
> struct dwc2_core_params *core_params;
> enum usb_otg_state op_state;
> enum usb_dr_mode dr_mode;
> + unsigned int hcd_enabled:1;
> + unsigned int gadget_enabled:1;
>
> struct phy *phy;
> struct usb_phy *uphy;
> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
> index 6a795aa..8abf437 100644
> --- a/drivers/usb/dwc2/platform.c
> +++ b/drivers/usb/dwc2/platform.c
> @@ -76,6 +76,7 @@ static const struct dwc2_core_params params_bcm2835 = {
> .reload_ctl = 0,
> .ahbcfg = 0x10,
> .uframe_sched = 0,
> + .default_dr_mode= USB_DR_MODE_OTG,
> };
>
> static const struct dwc2_core_params params_rk3066 = {
> @@ -104,6 +105,36 @@ static const struct dwc2_core_params params_rk3066 = {
> .reload_ctl = -1,
> .ahbcfg = 0x7, /* INCR16 */
> .uframe_sched = -1,
> + .default_dr_mode= USB_DR_MODE_OTG,
> +};
> +
> +static const struct dwc2_core_params params_s3c_hsotg = {
> + .otg_cap= -1,
> + .otg_ver= -1,
> + .dma_enable = 0,
> + .dma_desc_enable= 0,
> + .speed = -1,
> + .enable_dynamic_fifo= -1,
> + .en_multiple_tx_fifo= -1,
> + .host_rx_fifo_size = -1,
> + .host_nperio_tx_fifo_size = -1,
> + .host_perio_tx_fifo_size= -1,
> + .max_transfer_size = -1,
> + .max_packet_count = -1,
> + .host_channels = -1,
> + .phy_type = -1,
> + .phy_utmi_width = -1,
> + .phy_ulpi_ddr = -1,
> + .phy_ulpi_ext_vbus = -1,
> + .i2c_enable = -1,
> + .ulpi_fs_ls = -1,
> + .host_support_fs_ls_low_power = -1,
> + .host_ls_low_power_phy_clk = -1,
> + .ts_dline = -1,
> + .reload_ctl = -1,
> + .ahbcfg = -1,
> + .uframe_sched = -1,
> + .default_dr_mode= USB_DR_MODE_PERIPHERAL,
> };
>
> /**
> @@ -121,8 +152,10 @@ static int dwc2_driver_remove(struct platform_device
> *dev)
> {
> struct dwc2_hsotg *hsotg = platform_get_drvdata(dev);
>
> - dwc2_hcd_remove(hsotg);
> - s3c_hsotg_remove(hsotg);
> + if (hsotg->hcd_enabled)
> + dwc2_hcd_remove(hsotg);
> + if (hsotg->gadget_enabled)
> + s3c_hsotg_remove(hsotg);
>
> return 0;
> }
> @@ -131,7 +164,7 @@ static const struct of_device_id dwc2_of_match_table[] = {
> { .compatible = "brcm,bcm2835-usb", .data = ¶ms_bcm2835 },
> { .compatible = "rockchip,rk3066-usb", .data = ¶ms_rk3066 },
> { .compatible = "snps,dwc2", .data = NULL },
> - { .compatible = "samsung,s3c6400-hsotg", .data = NULL},
> + { .compatible = "samsung,s3c6400-hsotg", .data = ¶ms_s3c_hsotg },
> {},
> };
> MODULE_DEVICE_TABLE(of, dwc2_of_match_table);
> @@ -211,15 +244,26 @@ static int dwc2_driver_probe(struct platform_device
> *dev)
> (unsigned long)res->start, hsotg->regs);
>
> hsotg->dr_mode = of_usb_get_dr_mode(dev->dev.of_node);
> + if (hsotg->dr_mode == USB_DR_MODE_UNKNOWN &&
> + params->default_dr_mode > USB_DR_MODE_UNKNOWN)
> + hsotg->dr_mode = params->default_dr_mode;
>
> spin_lock_init(&hsotg->lock);
> mutex_init(&hsotg->init_mutex);
> - retval = dwc2_gadget_init(hsotg, irq);
> - if (retval)
> - return retval;
> - retval = dwc2_hcd_init(hsotg, irq, params);
> - if (r
Re: [PATCH] usb: phy: Restore deferred probing path
On 12/23/2014 11:36 AM, Felipe Balbi wrote:
On Thu, Dec 04, 2014 at 01:06:07PM +0100, Thierry Reding wrote:
From: Thierry Reding
Commit 1290a958d48e ("usb: phy: propagate __of_usb_find_phy()'s error on
failure") broke platforms that rely on deferred probing to order probing
of PHY and host controller drivers. The reason is that the commit simply
propagates errors from __of_usb_find_phy(), which returns -ENODEV if no
PHY has been registered yet for a given device tree node. The only case
in which -EPROBE_DEFER would now be returned is if try_module_get() did
fail, which does not make sense.
The correct thing to do is to return -EPROBE_DEFER if a PHY hasn't been
registered yet. The only condition under which it makes sense to return
-ENODEV is if the device tree node representing the PHY has been
disabled (via the status property) because in that case the PHY will
never be registered.
This patch addresses the problem by making __of_usb_find_phy() return an
appropriate error code while keeping in line with the above-mentioned
commit to propagate error codes rather than overwriting them. At the
same time the check for a valid PHY is decoupled from the check for the
try_module_get() call and a separate error code is returned if the
latter fails.
Signed-off-by: Thierry Reding
you forgot to add the magic "Fixes: foo bar" here, I'll add it this
time, but I've already sent my -rc2 pull request, so this will only show
up on -rc3.
Presumably also add the following, since the patch fixes a regression in
a previous kernel release:
Cc: stable # v3.18
?
--
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 00/30] usb: updates for dwc2 gadget driver
Adding Dinh to CC. Robert, Dinh, I would like to have your tested-bys for this series, please. -- Paul > From: Mian Yousaf Kaukab [mailto:yousaf.kau...@intel.com] > Sent: Friday, January 02, 2015 6:42 AM > > Hi, > This patchset consists of various bug fixes and feature enhancements for the > dwc2 gadget driver. All the patches are verified on dwc2 v3.0a with dedicated > fifos. Main focus of testing was with dma enabled. Although basic testing > without dma was also done. > > It is based on testing/next branch in Felipe's git with > https://lkml.org/lkml/2014/12/16/135 applied on top. > > Thank you, > > Best regards, > Yousaf > > History: > v2: > - Rebased to Felipe's testing/next with https://lkml.org/lkml/2014/12/16/135 >applied on top. > - Fixed comments from Robert Baldyga > - Some cosmetic changes > - Replaced usb: dwc2: gadget: process setup packet on transfer complete >with >usb: dwc2: gadget: don't process XferCompl on setup packet > - Updated usb: dwc2: gadget: provide gadget handle to the phy >so that otg_set_peripheral is called in both udc_start and udc_stop. > > v1: > - Addressed comments from Sergei Shtylyov > > Gregory Herrero (13): > usb: dwc2: gadget: register gadget handle to the phy > usb: dwc2: gadget: write correct value in ahbcfg register > usb: dwc2: gadget: don't erase gahbcfg register when enabling dma > usb: dwc2: gadget: add device tree property to enable dma > Documentation: dt-bindings: add dt binding info for dwc2 g-use-dma > usb: dwc2: gadget: configure fifos from device tree > Documentation: dt-bindings: add dt binding info for dwc2 fifo resizing > usb: dwc2: gadget: don't block after fifo flush timeout > usb: dwc2: gadget: add vbus_session support > usb: dwc2: gadget: reset fifo_map when initializing fifos > usb: dwc2: gadget: fix pullup handling > usb: dwc2: gadget: add vbus_draw support > usb: dwc2: gadget: force gadget initialization in dev mode > > Mian Yousaf Kaukab (17): > usb: dwc2: gadget: mask fifo empty irq with dma > usb: dwc2: gadget: don't process XferCompl on setup packet > usb: dwc2: gadget: don't embed ep0 buffers > usb: dwc2: gadget: fix error path in dwc2_gadget_init > usb: dwc2: gadget: add bi-directional endpoint support > usb: dwc2: gadget: check interrupts for all endpoints > usb: dwc2: gadget: remove unused members from hsotg_req > usb: dwc2: gadget: fix debug loop limits > usb: dwc2: gadget: consider all tx fifos > usb: dwc2: gadget: kill requests after disabling ep > usb: dwc2: gadget: manage ep0 state in software > usb: dwc2: gadget: fix zero length packet transfers > usb: dwc2: gadget: dont warn if endpoint is not enabled > usb: dwc2: gadget: rename sent_zlp to send_zlp > usb: dwc2: gadget: pick smallest acceptable fifo > usb: dwc2: gadget: fix fifo allocation leak > usb: dwc2: gadget: report disconnection after reset > > Documentation/devicetree/bindings/usb/dwc2.txt | 4 + > drivers/usb/dwc2/core.h| 46 +- > drivers/usb/dwc2/gadget.c | 786 > - > drivers/usb/dwc2/hw.h | 1 + > 4 files changed, 550 insertions(+), 287 deletions(-) > > -- > 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: PROBLEM: USB isochronous urb leak on EHCI driver
On Mon, Jan 5, 2015 at 1:12 PM, Michael Tessier wrote: > If sound is ok when using only 1 codec and becomes choppy when adding a > second codec, then it means that this issue is still in the 3.x kernel. This > answer will tell me if it is worth working on using a newer kernel or not. > I have to say that I'm not a linux expert, so I see the migration to a newer > kernel as a quite big amount of work... We have support for mx51 on the latest kernel. All you need to do is to describe your hardware on a device tree file. You can refer to arch/arm/boot/dts/imx51-babbage.dts as an example. Should be simple for you to make such test with the latest kernel. -- 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: Issues with commit 34b48db6 ("block: remove artifical max_hw_sectors cap")
On Tue, Dec 30, 2014 at 08:36:34AM -0800, Kenneth R. Crudup wrote: > OP here. FWIW, this is what I get when running that command on the SCSI > generic device that corresponds to the USB-3 (non-UAS) disk[1] that had the > issue: So it looks like this one actually provides sane values, but we don't we never even look at EVPD pages for usb devices due to the wrong SCSI level? -- 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: Issues with commit 34b48db6 ("block: remove artifical max_hw_sectors cap")
On Tue, Dec 30, 2014 at 11:19:07AM -0500, Douglas Gilbert wrote: > In SCSI, the VPD page 0xb0 (Block limits) has a "Maximum transfer > length" field (32 bits long). Its units are logical blocks. Useful > if >0 as 0 means "unreported". > > USB to SATA bridges should comply with SAT. However SAT and SAT-2 > don't even mention that VPD page. SAT-3 and SAT-4 mention that page > but have "unspecified" next to that field. Basically useless. Maybe we need to cap the max sectors value to something fairly low unless we have the block limits VPD page and it contains useful information. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] usb: dwc3: add a quirk for device disconnection issue in Synopsis dwc3 core
Hi,
On Sun, Jan 04, 2015 at 08:55:01PM +0800, Sneeker Yeh wrote:
> > > So far Fujitsu Semiconductor got Synopsys internal case id , that is "
> > > Case: 8000679552".
> > > However the contents belongs this id cannot be referred except Fujitsu
> > > Semiconductor and Synopsys.
> > > Synopsis decide the official errata (STAR information) will be disclosed
> > > next February.
> > >
> > > Would you suggest if this quirk can be accepted with this case ID, or can
> > > only be accepted with STARS ticket number?
> >
> > The thing is that without the STARS number I can't really verify which
> > versions of the IP would be affected. Clearly, it's not only your setup
> > and I think it's pretty unfair to have "is_compatible("fujitsu")" to
> >
>
> just found some way of quirk injection i miss,
> does it looks more reasonable if i have to decide to use it via Kconfig? :
> 20f6fdd01c2c0de9cc1109083222edded24c5350
> b2f463e1300016785d63475c56f5807e2be00934
We will only use Kconfig for those which can't be detected in runtime.
LPM is one such case as there's no way for SW to detect that core was
configured with LPM Errata, IIRC.
> > enable the quirk only for you. Isn't there a better way of enabling the
> > quirk based off of revision detection couple with a look on GHWPARAMS*
> > registers ?
> >
> > What's tricking me is this claim that only config-free PHYs would be
> > affected, why ?
> >
>
> i'm still struggling now to try to get more information about this.
> some security policy inside Fujitsu make me unable to access full
> information of this errata today.
>
> Someday after i get enough information,
> i shall take your suggestion here that seems better to incur quirk
> dynamically via GHWPARAMS,
> and then send it here again.
ok, hopefully you'll find a way ;-)
--
balbi
signature.asc
Description: Digital signature
kernel panic with USB3+DVB+ARM
Hi, would you like to trouble-shoot the kernel USB3/xhci code? I had a lot of struggle with the following set up: - Netgear ReadyNAS rn104 (ARMv7) running plain debian - Fresco Logic FL1009 USB3 controller - selfbuilt kernel.org kernel 3.18.1 - Technisat SkyStar USB HD (DVB-S/S2) - USB 2.0 Highspeed device more hardware details can be found here: http://natisbad.org/NAS2/index.html#hw if it worked, it crashed the system every hour with kernel panic in dvb_demux.c/dvb_dmx_crc32() if it did not crash the system, the whole USB/DVB-S hard- and software got instable soon, causing the device to stop working. The solution was plugging the DVB device into USB2 port (front) instead of USB3 (rear). So this makes me believe the problem is in USB3 code. My question is: *is anyone interested in finding out the problem with USB3 code?* I have got several logs of kernel panics. If you give advice I can try anything you like to track down the problem. thanks, Jan ps. please CC, I am not subscribed to the list. -- 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: PROBLEM: USB isochronous urb leak on EHCI driver
On Mon, 5 Jan 2015, Michael Tessier wrote: > > > Hi, > > > > > > I am dealing with a USB EHCI driver bug. Here is the info: > > > > > > My configuration: > > > - > > > > > > Host: Freescale i.MX512 with ARM Cortex A8 (USB 2.0 host controller) > > > Linux kernel: 2.6.31, using EHCI USB driver > > > > As mentioned by other people, the age of that kernel makes any bug report > > completely irrelevant. It's hard to count the number of non-trivial > > changes that have > been made to the isochronous code in ehci-hcd since > > 2.6.31, but there have been quite a few. > > > > > Hub: 4-PORT USB 1.1 HUB (Texas Instruments PN: tusb2046b) > > > Devices: 4 USB 1.1 audio codecs (Texas Instruments PN: pcm2901) > > > > > > Note: each codec is being used in R/W access, so with 4 codecs, I have > > > 4 playback and 4 capture streams. > > > > > > My problem: > > > --- > > > > > > I have usb urb leaks when connecting more than 1 codec to the USB 1.1 > > > Hub. > > > > What do you mean by "urb leak"? Normally, people use the word "leak" > > to refer to memory that is dynamically allocated and never deallocated, but > > you seem to mean something else. > > You are right. What I mean by leak is the following: At application level, > all my calls to "Read" or "Write" operation to the codec driver will return > with the correct amount of bytes read/written, with a "choppy" sound. Then > when looking at lower levels: > > snd_pcm_oss_write (pcm_oss.c) -> OK > snd_pcm_lib_write (pcm_lib.c) -> OK > usb_submit_urb(urb.c) -> FAIL with 3 codecs > > The "FAIL" here indicates that the total amount of bytes transferred does > not correspond to what was expected. And indeed the sound is "choppy" when > using more than a certain amount of bandwidth. However this amount of > bandwidth is higher when connecting only 1 codec with different settings > (48khz-stereo 16-bits instead of 32 khz-mono 16-bits).So at some point it > looks like the bug is in the scheduler, only with several isochronous links. Agreed. > > The amount of bandwidth available is usually not as much of an issue as the > > ability of the scheduling alogorithm to divide the bandwidth among the > > streams. The > > algorithm is not very smart and it often runs into a wall even when lots of > > physical bandwidth is still available. > > That is interresting, however, I have an older kernel running an OHCI > driver which is able to handle 4 codecs. Same usb hardware (codecs and > hub), but older kernel on a different CPU, with much less power. This makes > me believe that there's a solution to make it work... Of course there is: Install an OHCI host controller and use it to drive your codecs. It should work fine. The periodic scheduling algorithm for OHCI is very different from the algorithm for EHCI. > > How does your hardware connect the host controller to a full-speed device? > > Is there an internal hub (Intel motherboards have used this approach)? Is > > there a > > companion USB-1.1 controller (older motherboards from Intel and other > > companys have used this approach)? Does the EHCI controller have a > > built-in Transaction > > Translator (some SOC systems use this approach)? > > The CPU is a Freescale i.MX512, with 3 USB 2.0 Host controllers. My hub > is connected to the main CPU board with a standard USB cable, so it's easy > to swap my 4-port hub from a USB 1.1 to a USB 2.0. My codecs are always > the same: USB 1.1 Texas Instruments PN# pcm2901. I don't believe there's > a built-in Transaction Translator. How can I check that? You can tell by seeing what shows up in the "lsusb -t" output when you plug in the USB-1.1 hub. If the hub's parent is the EHCI controller then there must be a built-in TT. Also, if you enable CONFIG_USB_DEBUG in your kernel then the dmesg log for boot-up should say whether or not the controller has a built-in TT. > > > Question: > > > - > > > > > > Before attempting to upgrade to an earlier kernel driver (this is > > > > "upgrade to an earlier kernel driver" is a contradiction in terms. > > Moving to an earlier driver would be a _downgrade_. > > Sorry, I meant to say "newer"... > > > > a fairly big amount of work), I would really like to know if this > > > problem would still be in the 3.x kernels. Has anyone seen that issue > > > in 3.x kernels? > > > > It depends a lot on the system hardware. Many people are using USB audio > > in 3.x kernels with no problem. On the other hand, some people have > > reported a bug > > (quite different from yours) so recently that the patch to fix it has not > > yet been merged. > > I understand. However, if one could test the following with a 3.x kernel: > - CPU with USB 2.0 Host controller (using EHCI-hcd driver) > - 4-port USB 1.1 Hub > - 4x USB codecs (configured at 32khz-mono, 16-bits audio) > > Then try to stream audio on each of the 4 codecs at the same time (this > includes one R
Re: [PATCH 2/3] usb: dwc3: add Fujitsu Specific Glue layer
Hi, On Sun, Jan 04, 2015 at 09:16:01PM +0800, Sneeker Yeh wrote: > > > Then dwc3 core won't be always created via sub node in platform glue > > node, > > > and vendors like us can just drop platform glue which don't have any > > > specific platform code to wrap dwc3 core, and just directly use dwc3 core > > > via device tree. > > > > If your core is really just xhci, why don't just use xhci-plat.c > > > > I've tried using xhci-plat.c, but our controller won't work today in > 3.19-rc1. > Seems I still need the dwc3 initialization code. probably missing PHY initialization, that should be easy to patch on xhci-plat.c > > directly ? You don't need dwc3 at all. In any case, I refrain from > > allowing people to use dwc3.ko directly because that has bitten me in > > the past with MUSB, so sorry but I'll always force people to use the > > glue layer as that helps me keep dwc3 clean of platform-specific > > details. > > > > > Of course here dwc3 core won't process clock if he got null one, so this > > > won't affect other vendor's platform which only pass clock phandle to > > their > > > dwc3 platform glue driver. > > > > right > > > > > Just wondering if it's better to write a platform glue only did clock > > > on/off, or to do the same improvement people ever did for > > > ehci-platform driver and just drop this platform glue driver? > > > > I'll always the sour taste in my mouth due to MUSB. The thing is a > > complete mess of platform-specific hacks all over the place. > > > > > Super thanks for sharing this, for me it's quite an honor to know that > story behond. > and I'll take these suggestion here to revise our platform glue layer. hey, no problem. Cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH 2/3] usb: dwc3: add Fujitsu Specific Glue layer
Hi,
On Mon, Jan 05, 2015 at 04:28:34PM +0100, Arnd Bergmann wrote:
> On Friday 02 January 2015 19:21:28 Felipe Balbi wrote:
> >
> > On Tue, Dec 30, 2014 at 11:12:51AM +0100, Arnd Bergmann wrote:
> > > On Monday 29 December 2014 01:52:04 Sneeker Yeh wrote:
> > > > > > +static int dwc3_mb86s70_remove_child(struct device *dev, void
> > > > > > *unused)
> > > > > > +{
> > > > > > + struct platform_device *pdev = to_platform_device(dev);
> > > > > > +
> > > > > > + of_device_unregister(pdev);
> > > > > > +
> > > > > > + return 0;
> > > > > > +}
> > > > > > +
> > > > > > +static u64 dwc3_mb86s70_dma_mask = DMA_BIT_MASK(32);
> > > > >
> > > > > why ? Use dma_coerce_mask_and_coherent().
> > > > >
> > > >
> > > > okay.
> > >
> > > Actually that is still wrong: we use dma_coerce_mask_and_coherent() to
> > > annotate drivers that have traditionally been forcing their own dma mask
> > > by some other means and that need to be changed to something proper (after
> > > finding out why they did it in the first place).
> > >
> > > Since this is about a child device, the correct interface is to use
> > > platform_device_register_full().
> >
> > no, that's wrong. He's essentially fixing the default set by OF core,
> > which is always 32-bits anyway, so this can actually be removed. Your
> > suggestion would just make it worse.
>
> Ah, so this was for a device that gets probed from DT? Yes, then no
> change is needed here at all.
right.
> Note that I'm working on a patch set to change the DT initialization to
> be a little smarter about the mask. Specifically any device whose parent
> has a smaller dma-ranges window than 4GB needs to start out with the
> smaller mask, and the dma_set_mask function that is called to allow 64-bit
> DMA on a device will check if the bus can actually support it.
please make sure have that patch soaking in linux-next for weeks before
attempting to merge it upstream. I would target v3.21 with such a patch.
At least keystone might be a little weird about what you describe
considering the thing boots from HIGHMEM. Also needs to consider LPAE,
etc.
--
balbi
signature.asc
Description: Digital signature
Re: Difference between run time and normal suspend
On Mon, 5 Jan 2015, vichy wrote: > hi all: > after tracing and reading kernel usb source code about run time and > normal suspend. > 1. how could we check the rum time suspend is work on some device? > By plugging in devices and check whether > /sys/bus/usb/devices/.../power/ is empty or not? No. That directory will never be empty. You can check whether runtime suspend works by enabling it: echo auto >/sys/bus/usb/devices/.../power/control You can see whether the device has been suspended by looking at the runtime_status and runtime_suspended_time files in the .../power directory. > 2. I plug in one mouse and found the device will auto disconnect every > 2 secs, the default value of usb_autosuspend_delay. > But I have some questions > a. how kernel judge the device is idle, from usb spec, the idle > mean there is no any bus traffic, including sof, over 3ms and host > will always firing sof even there is no transaction on the bus. The kernel judges a device to be idle if it hasn't been used in some time. The bus traffic has nothing to do with it. > b. I think dynamic suspend is used for saving power when device is > idle for a specific time, but why the mouse will dynamic resume when > suspend for a while. it should resume when user or external event > trigger it for resume right? That's right. If your mouse is resuming, it must be because some event has triggered the resume. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] usb: dwc3: add Fujitsu Specific Glue layer
On Friday 02 January 2015 19:21:28 Felipe Balbi wrote:
>
> On Tue, Dec 30, 2014 at 11:12:51AM +0100, Arnd Bergmann wrote:
> > On Monday 29 December 2014 01:52:04 Sneeker Yeh wrote:
> > > > > +static int dwc3_mb86s70_remove_child(struct device *dev, void
> > > > > *unused)
> > > > > +{
> > > > > + struct platform_device *pdev = to_platform_device(dev);
> > > > > +
> > > > > + of_device_unregister(pdev);
> > > > > +
> > > > > + return 0;
> > > > > +}
> > > > > +
> > > > > +static u64 dwc3_mb86s70_dma_mask = DMA_BIT_MASK(32);
> > > >
> > > > why ? Use dma_coerce_mask_and_coherent().
> > > >
> > >
> > > okay.
> >
> > Actually that is still wrong: we use dma_coerce_mask_and_coherent() to
> > annotate drivers that have traditionally been forcing their own dma mask
> > by some other means and that need to be changed to something proper (after
> > finding out why they did it in the first place).
> >
> > Since this is about a child device, the correct interface is to use
> > platform_device_register_full().
>
> no, that's wrong. He's essentially fixing the default set by OF core,
> which is always 32-bits anyway, so this can actually be removed. Your
> suggestion would just make it worse.
Ah, so this was for a device that gets probed from DT? Yes, then no
change is needed here at all.
Note that I'm working on a patch set to change the DT initialization to
be a little smarter about the mask. Specifically any device whose parent
has a smaller dma-ranges window than 4GB needs to start out with the
smaller mask, and the dma_set_mask function that is called to allow 64-bit
DMA on a device will check if the bus can actually support it.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] usb: storage: adjust module reference for scsi host
On Mon, 5 Jan 2015, Akinobu Mita wrote: > While accessing a unusual usb storage (ums-alauda, ums-cypress, ...), > the module reference count is not incremented. Because these drivers > allocate scsi hosts with usb_stor_host_template defined in usb-storage > module. So these drivers always can be unloaded. > > This fixes it by adjusting module reference after scsi host allocation. > diff --git a/drivers/usb/storage/alauda.c b/drivers/usb/storage/alauda.c > index 62c2d9d..77660d6 100644 > --- a/drivers/usb/storage/alauda.c > +++ b/drivers/usb/storage/alauda.c > @@ -1242,6 +1242,7 @@ static int alauda_probe(struct usb_interface *intf, > us->transport = alauda_transport; > us->transport_reset = usb_stor_Bulk_reset; > us->max_lun = 1; > + us_to_host(us)->module = THIS_MODULE; > > result = usb_stor_probe2(us); > return result; ... etc. An easier and more foolproof approach would be to change usb_store_probe2 to take an extra argument for the owner: int _usb_stor_probe2(struct us_data *us, struct module *owner) ... us_to_host(us)->module = owner; ... Then in usb.h: extern int _usb_stor_probe2(struct us_data *us, struct module *owner); #define usb_stor_probe2(us) _usb_stor_probe2(us, THIS_MODULE) This pattern is already used in several other places in the kernel. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB-serial console and lockdep
On 01/03/2015 11:26 AM, Johan Hovold wrote:
> On Wed, Dec 31, 2014 at 09:07:59PM -0500, Peter Hurley wrote:
>> Hi Johan,
>>
>> On 11/18/2014 11:18 AM, Johan Hovold wrote:
>>> 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.").
>>
>> Sorry it took me so long to finally look at this -- at least I'm looking
>> at it in the same year ;) (in my tzone anyway)
>
> No worries. Wasn't a top prio of mine either. :)
>
> Thanks for taking a look.
>
>> Is this easily reproducible?
>
> Yes, happens on every boot with the pl2303 driver.
>
>> Because for lockdep to be trying to register the ldsem lock class
>> from the tty_ldisc_ref() means that no tty has yet been opened [see 1].
>> So how did the call to tty_port_tty_get() in pl2303_update_line_status()
>> return a tty?
>
> Because the USB console driver is using a only partially initialised,
> "fake" tty struct to pass terminal settings to the underlying driver.
> So no wonder things can blow up.
Ahh, I did not know that.
> This particular issue can be fixed by making sure to initialise the
> ldisc semaphore, but there are likely more potential problems here,
> including use-after-free as the fake tty wasn't released using the
> kref. I'll post two fixes as a follow up.
>
> A more long term solution might be to rewrite all usb-serial drivers to
> handle a NULL termios and pass a ktermios to set_termios similar to how
> serial-core does this.
I agree that this definitely needs a more robust solution.
FWIW, I don't think serial-core is a particularly good model.
Regards,
Peter Hurley
--
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: ehci: fix port power enable when override present
On Mon, 5 Jan 2015, Lucas Stach wrote: > Some controllers need to have external power supplied before toggling > the internal PORT_POWER bit. > > Fixes: 11a7e5940514 (usb: ehci: add ehci_port_power interface) on i.MX51 > where the controller would hang the machine when trying to enable PORT_POWER. > > Signed-off-by: Lucas Stach > Cc: sta...@vger.kernel.org [3.18+] > --- > drivers/usb/host/ehci-hub.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c > index 118edb7bdca2..aad5b3b32d0e 100644 > --- a/drivers/usb/host/ehci-hub.c > +++ b/drivers/usb/host/ehci-hub.c > @@ -1306,13 +1306,13 @@ static int ehci_port_power(struct ehci_hcd *ehci, int > portnum, bool enable) > u32 __iomem *status_reg = &ehci->regs->port_status[portnum]; > u32 temp = ehci_readl(ehci, status_reg) & ~PORT_RWC_BITS; > > + if (hcd->driver->port_power) > + hcd->driver->port_power(hcd, portnum, enable); > + > if (enable) > ehci_writel(ehci, temp | PORT_POWER, status_reg); > else > ehci_writel(ehci, temp & ~PORT_POWER, status_reg); > > - if (hcd->driver->port_power) > - hcd->driver->port_power(hcd, portnum, enable); > - > return 0; > } This comment may not be relevant any more, but... It seems to me that what you really want to do is call the driver's override routine _before_ turning _on_ the PORT_POWER bit and _after_ turning that bit _off_. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: PROBLEM: USB isochronous urb leak on EHCI driver
> > On Mon, 15 Dec 2014, Michael Tessier wrote: > > > Hi, > > > > I am dealing with a USB EHCI driver bug. Here is the info: > > > > My configuration: > > - > > > > Host: Freescale i.MX512 with ARM Cortex A8 (USB 2.0 host controller) > > Linux kernel: 2.6.31, using EHCI USB driver > > As mentioned by other people, the age of that kernel makes any bug report > completely irrelevant. It's hard to count the number of non-trivial changes > that have > been made to the isochronous code in ehci-hcd since 2.6.31, but > there have been quite a few. > > > Hub: 4-PORT USB 1.1 HUB (Texas Instruments PN: tusb2046b) > > Devices: 4 USB 1.1 audio codecs (Texas Instruments PN: pcm2901) > > > > Note: each codec is being used in R/W access, so with 4 codecs, I have > > 4 playback and 4 capture streams. > > > > My problem: > > --- > > > > I have usb urb leaks when connecting more than 1 codec to the USB 1.1 > > Hub. > > What do you mean by "urb leak"? Normally, people use the word "leak" > to refer to memory that is dynamically allocated and never deallocated, but > you seem to mean something else. You are right. What I mean by leak is the following: At application level, all my calls to "Read" or "Write" operation to the codec driver will return with the correct amount of bytes read/written, with a "choppy" sound. Then when looking at lower levels: snd_pcm_oss_write (pcm_oss.c) -> OK snd_pcm_lib_write (pcm_lib.c) -> OK usb_submit_urb (urb.c) -> FAIL with 3 codecs The "FAIL" here indicates that the total amount of bytes transferred does not correspond to what was expected. And indeed the sound is "choppy" when using more than a certain amount of bandwidth. However this amount of bandwidth is higher when connecting only 1 codec with different settings (48khz-stereo 16-bits instead of 32 khz-mono 16-bits).So at some point it looks like the bug is in the scheduler, only with several isochronous links. > > > (the result is that some of the audio data is not transferred, part of > > the sound is simply missing) No problem when using only 1 of the 4 > > codecs connected to the hub; When I connect a second codec, the sound > > quality starts to degrade. With 3 codecs, we just cannot recognize a > > speach. > > > > Tests and observations: > > --- > > > > Since I have 3 usb ports available on the i.MX512, I tried to connect > > 3 codecs directly on USB ports: the sound is perfect on each of the > > three ports. > > > > I bought a consumer USB 2.0 Hub: no problem when using 3 codecs > > connected to that Hub, however, the audio will completly stop on all > > channels when connecting the 4th codec. > > Above you said the sound started to degrade when the second codec was > connected; here you say there is no problem when using 3 of them. > Which is it? Do you mean that the high-speed hub works better than the > full-speed hub? > Yes, that's it. Using the high-speed hub will allow for more data throughput before starting to "miss" some usb packets (and result in a choppy sound). > > I checked the communication between the Hub (USB 1.1) and the Host > > controller (USB 2.0) with a scope and concluded that the communication > > speed is 1.5 MBytes/s has expected (so the communication is downgraded > > to USB 1.1, since codecs and hub are USB > > 1.1 devices). > > > > Also, I know that there is physically enough bandwidth to transfer the > > data for two reasons: > > 1) I have an older CPU with a USB 1.1 host controller (using the OHCI > > driver), using the same hub and the same codecs: works like a champ, > > using less than 50% of the available bandwidth (observed with a > > scope) > > 2) 1 audio stream is 32khz-mono, 16 bits = 64 kB/s, > > 4 codecs = 8 streams(R/W) x 64 kB/s = 512 kB/s (out of 1.5MB/s) > > The amount of bandwidth available is usually not as much of an issue as the > ability of the scheduling alogorithm to divide the bandwidth among the > streams. The > algorithm is not very smart and it often runs into a wall even when lots of > physical bandwidth is still available. That is interresting, however, I have an older kernel running an OHCI driver which is able to handle 4 codecs. Same usb hardware (codecs and hub), but older kernel on a different CPU, with much less power. This makes me believe that there's a solution to make it work... > > I noticed that my sound problem starts happening with only 2 codecs > > (4 streams, 256 kB/s). I first thought that it was a bandwidth > > limitation, so I decided to connect only 1 codec using more bandwidth. > > I configured it to 48khz-stereo (16-bits), using 384 kB/s for both > > read and write streams: no problem. With that configuration, the scope > > shows about 30% of total bandwidth usage (300us used out of 1ms > > periods). Then, I added a second codec (48khz-stereo-16bits): very > > strange, now the total bandwidth usage felt down to about 200us, which > > seems to
[PATCH v2 2/2] USB: console: fix potential use after free
Use tty kref to release the fake tty in usb_console_setup to avoid use
after free if the underlying serial driver has acquired a reference.
Note that using the tty destructor release_one_tty requires some more
state to be initialised.
Fixes: 4a90f09b20f4 ("tty: usb-serial krefs")
Cc: stable
Signed-off-by: Johan Hovold
---
Changes since v1:
- Use tty_kref_put to release tty also in setup()
- Some more state must be initialised to avoid NULL derefs when the tty
destructor is run after the underlying driver puts its reference.
drivers/usb/serial/console.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/serial/console.c b/drivers/usb/serial/console.c
index e56f394b58d8..29fa1c3d0089 100644
--- a/drivers/usb/serial/console.c
+++ b/drivers/usb/serial/console.c
@@ -46,6 +46,8 @@ static struct console usbcons;
*
*/
+static const struct tty_operations usb_console_fake_tty_ops = {
+};
/*
* The parsing of the command line works exactly like the
@@ -137,14 +139,17 @@ static int usb_console_setup(struct console *co, char
*options)
goto reset_open_count;
}
kref_init(&tty->kref);
- tty_port_tty_set(&port->port, tty);
tty->driver = usb_serial_tty_driver;
tty->index = co->index;
init_ldsem(&tty->ldisc_sem);
+ INIT_LIST_HEAD(&tty->tty_files);
+ kref_get(&tty->driver->kref);
+ tty->ops = &usb_console_fake_tty_ops;
if (tty_init_termios(tty)) {
retval = -ENOMEM;
- goto free_tty;
+ goto put_tty;
}
+ tty_port_tty_set(&port->port, tty);
}
/* only call the device specific open if this
@@ -162,7 +167,7 @@ static int usb_console_setup(struct console *co, char
*options)
serial->type->set_termios(tty, port, &dummy);
tty_port_tty_set(&port->port, NULL);
- kfree(tty);
+ tty_kref_put(tty);
}
set_bit(ASYNCB_INITIALIZED, &port->port.flags);
}
@@ -178,8 +183,8 @@ static int usb_console_setup(struct console *co, char
*options)
fail:
tty_port_tty_set(&port->port, NULL);
- free_tty:
- kfree(tty);
+ put_tty:
+ tty_kref_put(tty);
reset_open_count:
port->port.count = 0;
usb_autopm_put_interface(serial->interface);
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] USB: console: fix uninitialised ldisc semaphore
The USB console currently allocates a temporary fake tty which is used
to pass terminal settings to the underlying serial driver.
The tty struct is not fully initialised, something which can lead to a
lockdep warning (or worse) if a serial driver tries to acquire a
line-discipline reference:
usbserial: USB Serial support registered for pl2303
pl2303 1-2.1:1.0: pl2303 converter detected
usb 1-2.1: pl2303 converter now attached to ttyUSB0
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 68 Comm: udevd Tainted: GW 3.18.0-rc5 #10
[] (unwind_backtrace) from [] (show_stack+0x20/0x24)
[] (show_stack) from [] (dump_stack+0x24/0x28)
[] (dump_stack) from []
(__lock_acquire+0x1e50/0x2004)
[] (__lock_acquire) from []
(lock_acquire+0xe4/0x18c)
[] (lock_acquire) from []
(ldsem_down_read_trylock+0x78/0x90)
[] (ldsem_down_read_trylock) from []
(tty_ldisc_ref+0x24/0x58)
[] (tty_ldisc_ref) from []
(usb_serial_handle_dcd_change+0x48/0xe8)
[] (usb_serial_handle_dcd_change) from []
(pl2303_read_int_callback+0x210/0x220 [pl2303])
[] (pl2303_read_int_callback [pl2303]) from []
(__usb_hcd_giveback_urb+0x80/0x140)
[] (__usb_hcd_giveback_urb) from []
(usb_giveback_urb_bh+0x98/0xd4)
[] (usb_giveback_urb_bh) from []
(tasklet_hi_action+0x9c/0x108)
[] (tasklet_hi_action) from []
(__do_softirq+0x148/0x42c)
[] (__do_softirq) from [] (irq_exit+0xd8/0x114)
[] (irq_exit) from []
(__handle_domain_irq+0x84/0xdc)
[] (__handle_domain_irq) from []
(omap_intc_handle_irq+0xd8/0xe0)
[] (omap_intc_handle_irq) from []
(__irq_svc+0x44/0x7c)
Exception stack(0xdf4e7f08 to 0xdf4e7f50)
7f00: debc0b80 df4e7f5c debc0b80
be8da96c
7f20: 0128 c000fc84 df4e6000 df4e7f94 0004
df4e7f50
7f40: c038ebc0 c038d74c 600f0013
[] (__irq_svc) from []
(___sys_sendmsg.part.29+0x0/0x2e0)
[] (___sys_sendmsg.part.29) from []
(SyS_sendmsg+0x18/0x1c)
[] (SyS_sendmsg) from [] (ret_fast_syscall+0x0/0x48)
console [ttyUSB0] enabled
Fixes: 36697529b5bb ("tty: Replace ldisc locking with ldisc_sem")
Cc: stable
Signed-off-by: Johan Hovold
---
drivers/usb/serial/console.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/usb/serial/console.c b/drivers/usb/serial/console.c
index 8d7fc48b1f30..e56f394b58d8 100644
--- a/drivers/usb/serial/console.c
+++ b/drivers/usb/serial/console.c
@@ -140,6 +140,7 @@ static int usb_console_setup(struct console *co, char
*options)
tty_port_tty_set(&port->port, tty);
tty->driver = usb_serial_tty_driver;
tty->index = co->index;
+ init_ldsem(&tty->ldisc_sem);
if (tty_init_termios(tty)) {
retval = -ENOMEM;
goto free_tty;
--
2.0.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] scsi: add ability to adjust module reference for scsi host
While accessing a scsi_device, the use count of the underlying LLDD module
is incremented. The module reference is retrieved through .module field of
struct scsi_host_template.
This mapping between scsi_device and underlying LLDD module works well
except some scsi drivers (ufs and unusual usb storage drivers). These
drivers consist with core driver and actual LLDDs, and scsi_host_template
is defined in the core driver. So the actual LLDDs can be unloaded even if
the scsi_device is being accessed.
This adds .module field in struct Scsi_Host and let the module reference
be retrieved though it instead of struct scsi_host_template. This allows
the actual LLDDs adjust module reference.
Signed-off-by: Akinobu Mita
Cc: Vinayak Holikatti
Cc: Dolev Raviv
Cc: Sujit Reddy Thumma
Cc: Subhash Jadavani
Cc: Christoph Hellwig
Cc: "James E.J. Bottomley"
Cc: Matthew Dharm
Cc: Greg Kroah-Hartman
Cc: linux-usb@vger.kernel.org
Cc: usb-stor...@lists.one-eyed-alien.net
Cc: linux-s...@vger.kernel.org
---
drivers/scsi/hosts.c | 1 +
drivers/scsi/scsi.c | 4 ++--
include/scsi/scsi_host.h | 1 +
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c
index 8bb173e..21f1442 100644
--- a/drivers/scsi/hosts.c
+++ b/drivers/scsi/hosts.c
@@ -411,6 +411,7 @@ struct Scsi_Host *scsi_host_alloc(struct scsi_host_template
*sht, int privsize)
*/
shost->max_cmd_len = 12;
shost->hostt = sht;
+ shost->module = sht->module;
shost->this_id = sht->this_id;
shost->can_queue = sht->can_queue;
shost->sg_tablesize = sht->sg_tablesize;
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index e028854..5905b83 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -988,7 +988,7 @@ int scsi_device_get(struct scsi_device *sdev)
return -ENXIO;
/* We can fail this if we're doing SCSI operations
* from module exit (like cache flush) */
- try_module_get(sdev->host->hostt->module);
+ try_module_get(sdev->host->module);
return 0;
}
@@ -1005,7 +1005,7 @@ EXPORT_SYMBOL(scsi_device_get);
void scsi_device_put(struct scsi_device *sdev)
{
#ifdef CONFIG_MODULE_UNLOAD
- struct module *module = sdev->host->hostt->module;
+ struct module *module = sdev->host->module;
/* The module refcount will be zero if scsi_device_get()
* was called from a module removal routine */
diff --git a/include/scsi/scsi_host.h b/include/scsi/scsi_host.h
index 019e668..5133f2f 100644
--- a/include/scsi/scsi_host.h
+++ b/include/scsi/scsi_host.h
@@ -617,6 +617,7 @@ struct Scsi_Host {
*/
unsigned short max_cmd_len;
+ struct module *module;
int this_id;
int can_queue;
short cmd_per_lun;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] usb: storage: adjust module reference for scsi host
While accessing a unusual usb storage (ums-alauda, ums-cypress, ...), the module reference count is not incremented. Because these drivers allocate scsi hosts with usb_stor_host_template defined in usb-storage module. So these drivers always can be unloaded. This fixes it by adjusting module reference after scsi host allocation. Signed-off-by: Akinobu Mita Cc: Matthew Dharm Cc: Greg Kroah-Hartman Cc: Christoph Hellwig Cc: "James E.J. Bottomley" Cc: linux-usb@vger.kernel.org Cc: usb-stor...@lists.one-eyed-alien.net Cc: linux-s...@vger.kernel.org --- drivers/usb/storage/alauda.c| 1 + drivers/usb/storage/cypress_atacb.c | 2 ++ drivers/usb/storage/datafab.c | 1 + drivers/usb/storage/ene_ub6250.c| 1 + drivers/usb/storage/freecom.c | 1 + drivers/usb/storage/isd200.c| 1 + drivers/usb/storage/jumpshot.c | 1 + drivers/usb/storage/karma.c | 1 + drivers/usb/storage/onetouch.c | 2 ++ drivers/usb/storage/realtek_cr.c| 2 ++ drivers/usb/storage/sddr09.c| 2 ++ drivers/usb/storage/sddr55.c| 1 + drivers/usb/storage/shuttle_usbat.c | 1 + 13 files changed, 17 insertions(+) diff --git a/drivers/usb/storage/alauda.c b/drivers/usb/storage/alauda.c index 62c2d9d..77660d6 100644 --- a/drivers/usb/storage/alauda.c +++ b/drivers/usb/storage/alauda.c @@ -1242,6 +1242,7 @@ static int alauda_probe(struct usb_interface *intf, us->transport = alauda_transport; us->transport_reset = usb_stor_Bulk_reset; us->max_lun = 1; + us_to_host(us)->module = THIS_MODULE; result = usb_stor_probe2(us); return result; diff --git a/drivers/usb/storage/cypress_atacb.c b/drivers/usb/storage/cypress_atacb.c index 8514a2d..d603d04 100644 --- a/drivers/usb/storage/cypress_atacb.c +++ b/drivers/usb/storage/cypress_atacb.c @@ -255,6 +255,8 @@ static int cypress_probe(struct usb_interface *intf, if (result) return result; + us_to_host(us)->module = THIS_MODULE; + /* Among CY7C68300 chips, the A revision does not support Cypress ATACB * Filter out this revision from EEPROM default descriptor values */ diff --git a/drivers/usb/storage/datafab.c b/drivers/usb/storage/datafab.c index 7b17c21..4193caf 100644 --- a/drivers/usb/storage/datafab.c +++ b/drivers/usb/storage/datafab.c @@ -736,6 +736,7 @@ static int datafab_probe(struct usb_interface *intf, us->transport = datafab_transport; us->transport_reset = usb_stor_Bulk_reset; us->max_lun = 1; + us_to_host(us)->module = THIS_MODULE; result = usb_stor_probe2(us); return result; diff --git a/drivers/usb/storage/ene_ub6250.c b/drivers/usb/storage/ene_ub6250.c index 56f782b..c4656bd 100644 --- a/drivers/usb/storage/ene_ub6250.c +++ b/drivers/usb/storage/ene_ub6250.c @@ -2331,6 +2331,7 @@ static int ene_ub6250_probe(struct usb_interface *intf, us->transport_name = "ene_ub6250"; us->transport = ene_transport; us->max_lun = 0; + us_to_host(us)->module = THIS_MODULE; result = usb_stor_probe2(us); if (result) diff --git a/drivers/usb/storage/freecom.c b/drivers/usb/storage/freecom.c index ef16068..c66ee7a 100644 --- a/drivers/usb/storage/freecom.c +++ b/drivers/usb/storage/freecom.c @@ -538,6 +538,7 @@ static int freecom_probe(struct usb_interface *intf, us->transport = freecom_transport; us->transport_reset = usb_stor_freecom_reset; us->max_lun = 0; + us_to_host(us)->module = THIS_MODULE; result = usb_stor_probe2(us); return result; diff --git a/drivers/usb/storage/isd200.c b/drivers/usb/storage/isd200.c index 599d8bf..dcd2a10 100644 --- a/drivers/usb/storage/isd200.c +++ b/drivers/usb/storage/isd200.c @@ -1550,6 +1550,7 @@ static int isd200_probe(struct usb_interface *intf, us->protocol_name = "ISD200 ATA/ATAPI"; us->proto_handler = isd200_ata_command; + us_to_host(us)->module = THIS_MODULE; result = usb_stor_probe2(us); return result; diff --git a/drivers/usb/storage/jumpshot.c b/drivers/usb/storage/jumpshot.c index 563078b..80e14be 100644 --- a/drivers/usb/storage/jumpshot.c +++ b/drivers/usb/storage/jumpshot.c @@ -662,6 +662,7 @@ static int jumpshot_probe(struct usb_interface *intf, us->transport = jumpshot_transport; us->transport_reset = usb_stor_Bulk_reset; us->max_lun = 1; + us_to_host(us)->module = THIS_MODULE; result = usb_stor_probe2(us); return result; diff --git a/drivers/usb/storage/karma.c b/drivers/usb/storage/karma.c index 94d16ee..ccfae96 100644 --- a/drivers/usb/storage/karma.c +++ b/drivers/usb/storage/karma.c @@ -214,6 +214,7 @@ static int karma_probe(struct usb_interface *intf, us->transport_name = "Rio Karma/Bulk"; us->transport = rio_karma_transport; us->transport_reset = usb_stor_Bulk_reset; + us_to_host(us)->module = THIS_MODULE; res
[PATCH 0/3] scsi: ufs & ums-*: fix module reference counting
While accessing a scsi_device, the use count of the underlying LLDD module is incremented. The module reference is retrieved through .module field of struct scsi_host_template. This mapping between scsi_device and underlying LLDD module works well except some scsi drivers (ufs and unusual usb storage drivers). These drivers consist with core driver and actual LLDDs, and scsi_host_template is defined in the core driver. So the actual LLDDs can be unloaded even if the scsi_device is being accessed. This patch series first adds ability to adjust module reference for scsi host by LLDDs and then fixes ufs and unusual usb storage drivers by adjusting module reference after scsi host allocation. Akinobu Mita (3): scsi: add ability to adjust module reference for scsi host scsi: ufs: adjust module reference for scsi host usb: storage: adjust module reference for scsi host drivers/scsi/hosts.c| 1 + drivers/scsi/scsi.c | 4 ++-- drivers/scsi/ufs/ufshcd-pci.c | 1 + drivers/scsi/ufs/ufshcd-pltfrm.c| 1 + drivers/scsi/ufs/ufshcd.c | 1 - drivers/usb/storage/alauda.c| 1 + drivers/usb/storage/cypress_atacb.c | 2 ++ drivers/usb/storage/datafab.c | 1 + drivers/usb/storage/ene_ub6250.c| 1 + drivers/usb/storage/freecom.c | 1 + drivers/usb/storage/isd200.c| 1 + drivers/usb/storage/jumpshot.c | 1 + drivers/usb/storage/karma.c | 1 + drivers/usb/storage/onetouch.c | 2 ++ drivers/usb/storage/realtek_cr.c| 2 ++ drivers/usb/storage/sddr09.c| 2 ++ drivers/usb/storage/sddr55.c| 1 + drivers/usb/storage/shuttle_usbat.c | 1 + include/scsi/scsi_host.h| 1 + 19 files changed, 23 insertions(+), 3 deletions(-) Cc: Vinayak Holikatti Cc: Dolev Raviv Cc: Sujit Reddy Thumma Cc: Subhash Jadavani Cc: Christoph Hellwig Cc: "James E.J. Bottomley" Cc: Matthew Dharm Cc: Greg Kroah-Hartman Cc: linux-usb@vger.kernel.org Cc: usb-stor...@lists.one-eyed-alien.net Cc: linux-s...@vger.kernel.org -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: ehci: fix port power enable when override present
On Mon, Jan 5, 2015 at 9:02 AM, Lucas Stach wrote: > Some controllers need to have external power supplied before toggling > the internal PORT_POWER bit. > > Fixes: 11a7e5940514 (usb: ehci: add ehci_port_power interface) on i.MX51 > where the controller would hang the machine when trying to enable PORT_POWER. > > Signed-off-by: Lucas Stach > Cc: sta...@vger.kernel.org [3.18+] Patch looks good, but it doesn't need to have the stable 3.18+ tag as 11a7e5940514 landed in 3.19-rc1. Regards, Fabio Estevam -- 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: host: ehci-tegra: request deferred probe when failing to get phy
On 24 December 2014 at 11:16, Vince Hsu wrote:
> The commit 1290a958d48e ("usb: phy: propagate __of_usb_find_phy()'s error on
> failure") changed the condition to return -EPROBE_DEFER to host driver.
> Originally the Tegra host driver depended on the returned -EPROBE_DEFER to
> get the phy device later when booting. Now we have to do that explicitly.
With this patch, USB works again on this nyan-blaze board.
Tested-by: Tomeu Vizoso
Thanks,
Tomeu
> Signed-off-by: Vince Hsu
> ---
> Hi,
>
> This fixes a regression found on 3.19-rc1. The USB host can't be probed and
> the USB failed on Jetson TK1.
>
> Thanks,
> Vince
>
>
> drivers/usb/host/ehci-tegra.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/host/ehci-tegra.c b/drivers/usb/host/ehci-tegra.c
> index 19a9af1b4d74..ff9af29b4e9f 100644
> --- a/drivers/usb/host/ehci-tegra.c
> +++ b/drivers/usb/host/ehci-tegra.c
> @@ -451,7 +451,7 @@ static int tegra_ehci_probe(struct platform_device *pdev)
>
> u_phy = devm_usb_get_phy_by_phandle(&pdev->dev, "nvidia,phy", 0);
> if (IS_ERR(u_phy)) {
> - err = PTR_ERR(u_phy);
> + err = -EPROBE_DEFER;
> goto cleanup_clk_en;
> }
> hcd->usb_phy = u_phy;
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-tegra" 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
Re: [PATCH] usb: ehci: fix port power enable when override present
On Mon, Jan 5, 2015 at 11:06 AM, Lucas Stach wrote: > Am Montag, den 05.01.2015, 10:12 -0200 schrieb Fabio Estevam: >> Hi Lucas, >> >> On Mon, Jan 5, 2015 at 9:02 AM, Lucas Stach wrote: >> > Some controllers need to have external power supplied before toggling >> > the internal PORT_POWER bit. >> > >> > Fixes: 11a7e5940514 (usb: ehci: add ehci_port_power interface) on i.MX51 >> > where the controller would hang the machine when trying to enable >> > PORT_POWER. >> >> I tested your patch and the hang does not happen anymore, but the USB >> host port on my imx51-babbage is no longer functional: attaching a USB >> thumb on the host port is not detected. >> >> If I apply the following patch then I am able to get USB host port >> functional again: >> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/310705.html > > Urgh, I looked at this again and it's a complete mess. According to the > schematics I have the "reg_usbh1_vbus" isn't a regulator, but a ULPI PHY > reset GPIO. So the devicetree description is completely wrong here. > Sorry to say, but git blame points to you. Yes, I know. Besides that, there is also the problem that we currently don't have a way for providing a reset for USB hub via dt. > Marking the regulator as always-on may fix it for you, but that doesn't > guarantee proper reset of the PHY if the bootloader already set it up. > This really needs a separate PHY reset GPIO property to fix it properly, > same thing as is done tegra20-usb-phy. I will try to provide a proper fix for imx51-babbage. Regards, Fabio Estevam > > Regards, > Lucas > -- > Pengutronix e.K. | Lucas Stach | > Industrial Linux Solutions | http://www.pengutronix.de/ | > -- 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: ehci: fix port power enable when override present
Am Montag, den 05.01.2015, 10:12 -0200 schrieb Fabio Estevam: > Hi Lucas, > > On Mon, Jan 5, 2015 at 9:02 AM, Lucas Stach wrote: > > Some controllers need to have external power supplied before toggling > > the internal PORT_POWER bit. > > > > Fixes: 11a7e5940514 (usb: ehci: add ehci_port_power interface) on i.MX51 > > where the controller would hang the machine when trying to enable > > PORT_POWER. > > I tested your patch and the hang does not happen anymore, but the USB > host port on my imx51-babbage is no longer functional: attaching a USB > thumb on the host port is not detected. > > If I apply the following patch then I am able to get USB host port > functional again: > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/310705.html Urgh, I looked at this again and it's a complete mess. According to the schematics I have the "reg_usbh1_vbus" isn't a regulator, but a ULPI PHY reset GPIO. So the devicetree description is completely wrong here. Sorry to say, but git blame points to you. Marking the regulator as always-on may fix it for you, but that doesn't guarantee proper reset of the PHY if the bootloader already set it up. This really needs a separate PHY reset GPIO property to fix it properly, same thing as is done tegra20-usb-phy. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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
Difference between run time and normal suspend
hi all: after tracing and reading kernel usb source code about run time and normal suspend. 1. how could we check the rum time suspend is work on some device? By plugging in devices and check whether /sys/bus/usb/devices/.../power/ is empty or not? 2. I plug in one mouse and found the device will auto disconnect every 2 secs, the default value of usb_autosuspend_delay. But I have some questions a. how kernel judge the device is idle, from usb spec, the idle mean there is no any bus traffic, including sof, over 3ms and host will always firing sof even there is no transaction on the bus. b. I think dynamic suspend is used for saving power when device is idle for a specific time, but why the mouse will dynamic resume when suspend for a while. it should resume when user or external event trigger it for resume right? appreciate your help in advance, -- 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: ehci: fix port power enable when override present
Hi Lucas, On Mon, Jan 5, 2015 at 9:02 AM, Lucas Stach wrote: > Some controllers need to have external power supplied before toggling > the internal PORT_POWER bit. > > Fixes: 11a7e5940514 (usb: ehci: add ehci_port_power interface) on i.MX51 > where the controller would hang the machine when trying to enable PORT_POWER. I tested your patch and the hang does not happen anymore, but the USB host port on my imx51-babbage is no longer functional: attaching a USB thumb on the host port is not detected. If I apply the following patch then I am able to get USB host port functional again: http://lists.infradead.org/pipermail/linux-arm-kernel/2014-December/310705.html Regards, Fabio Estevam -- 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] renesas_usbhs: fix platform init error message
Hi Shimoda-san,
On Wed, Dec 24, 2014 at 11:02 AM, yoshihiro shimoda
wrote:
>> > > Er, OK. Could you update MAINTAINERS?
>> > there is no entry for renesas driver in MAINTAINERS.
>> > Shimoda-san, care to send a patch adding yourself or Morimoto-san as
>> > maintainers for Renesas driver and pointing to my tree in kernel.org ?
> By the way, about a renesas_usbhs maintainer, I don't know clearly.
> If I do as a renesas_usbhs maintainer:
> - what should I do as the maintainer?
> - I think I should check patches of renesas_usbhs
> - And, do I just return ACK or NACK to the patches?
As a maintainer, you review all patches for renesas_usbhs, and of these patches
will have to go through you.
There are three ways to achieve that:
1. You collect all accepted patches, and forward them to GregKH with your
Signed-off-by added,
2. You collect all accepted ls -lpatches, publish them in a git tree, and
ask GregKH to pull a branch or tag from your git tree,
3. You ack all accepted patches, so GregKH knows which patches to apply.
Which way to choose depends on the volume of patches.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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: ehci: fix port power enable when override present
Some controllers need to have external power supplied before toggling the internal PORT_POWER bit. Fixes: 11a7e5940514 (usb: ehci: add ehci_port_power interface) on i.MX51 where the controller would hang the machine when trying to enable PORT_POWER. Signed-off-by: Lucas Stach Cc: sta...@vger.kernel.org [3.18+] --- drivers/usb/host/ehci-hub.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c index 118edb7bdca2..aad5b3b32d0e 100644 --- a/drivers/usb/host/ehci-hub.c +++ b/drivers/usb/host/ehci-hub.c @@ -1306,13 +1306,13 @@ static int ehci_port_power(struct ehci_hcd *ehci, int portnum, bool enable) u32 __iomem *status_reg = &ehci->regs->port_status[portnum]; u32 temp = ehci_readl(ehci, status_reg) & ~PORT_RWC_BITS; + if (hcd->driver->port_power) + hcd->driver->port_power(hcd, portnum, enable); + if (enable) ehci_writel(ehci, temp | PORT_POWER, status_reg); else ehci_writel(ehci, temp & ~PORT_POWER, status_reg); - if (hcd->driver->port_power) - hcd->driver->port_power(hcd, portnum, enable); - return 0; } -- 2.1.3 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] gpio: dln2: fix issue when an IRQ is unmasked then enabled
On Mon, Jan 5, 2015 at 6:55 PM, Linus Walleij wrote: > > On Wed, Dec 31, 2014 at 9:55 PM, Linus Walleij > wrote: > > On Thu, Dec 11, 2014 at 2:02 PM, Octavian Purdila > > wrote: > > > >> As noticed during suspend/resume operations, the IRQ can be unmasked > >> then disabled in suspend and eventually enabled in resume, but without > >> being unmasked. > >> > >> The current implementation does not take into account interactions > >> between mask/unmask and enable/disable interrupts, and thus in the > >> above scenarios the IRQs remain unactive. > >> > >> To fix this we removed the enable/disable operations as they fallback > >> to mask/unmask anyway. > >> > >> We also remove the pending bitmaks as it is already done in irq_data > >> (i.e. IRQS_PENDING). > >> > >> Signed-off-by: Octavian Purdila > > > > Patch applied for fixes. > > Bah now that I see there are several versions of the patch set > floating around and also MFD patches I don't quite understand > how acute this is or how it's to be applied. Hi Linus, Oops I did not noticed you applied the first version. It should not matter anyway since I did not make any modifications to the GPIO patches in the second version - I just doubled checked it now. > > - Are these regression fixes or nice to have for next kernel > release? > The first patch is a fix. The second is more of a cleanup patch. > - Are the GPIO patches independent of the MFD patch? > Yes, the GPIO patches are independent of the MFD patches. -- 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] tools: ffs-aio-example: add missing wMaxPacketSize for HS descs
It's needed, to have more than 64 bytes of maxpacketsize.
Signed-off-by: Robert Baldyga
---
tools/usb/ffs-aio-example/simple/device_app/aio_simple.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/usb/ffs-aio-example/simple/device_app/aio_simple.c
b/tools/usb/ffs-aio-example/simple/device_app/aio_simple.c
index adc310a..1f44a29 100644
--- a/tools/usb/ffs-aio-example/simple/device_app/aio_simple.c
+++ b/tools/usb/ffs-aio-example/simple/device_app/aio_simple.c
@@ -103,12 +103,14 @@ static const struct {
.bDescriptorType = USB_DT_ENDPOINT,
.bEndpointAddress = 1 | USB_DIR_IN,
.bmAttributes = USB_ENDPOINT_XFER_BULK,
+ .wMaxPacketSize = htole16(512),
},
.bulk_source = {
.bLength = sizeof(descriptors.hs_descs.bulk_source),
.bDescriptorType = USB_DT_ENDPOINT,
.bEndpointAddress = 2 | USB_DIR_OUT,
.bmAttributes = USB_ENDPOINT_XFER_BULK,
+ .wMaxPacketSize = htole16(512),
},
},
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] usb: dwc2: fix the uncompleted requests problem
Hi Felipe, I prepared this patchset in response to our discussion: https://lkml.org/lkml/2014/12/29/193 It reverts of unproper patch and adds working solution of the problem described in commit messages. Best regards, Robert Baldyga Robert Baldyga (2): Revert "usb: dwc2: gadget: kill requests with 'force' in s3c_hsotg_udc_stop()" drivers: usb: dwc2: remove 'force' parameter from kill_all_requests() drivers/usb/dwc2/gadget.c | 31 ++- 1 file changed, 10 insertions(+), 21 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] drivers: usb: dwc2: remove 'force' parameter from kill_all_requests()
This patch fixes in simpler way the bug described in [1] and [2]. It
looks like DWC2 is the only UDC driver that doesn't force usb requests
to complete in ep_disable() function. This causes described problem,
because we have no guarantee that all requests will be completed before
unbind of usb function.
To fix this problem we force all requests of disabled endpoint to complete.
Also currently running request is not handled. This allowed to simplify
code of kill_all_requests() function, because 'force' parameter is always
set to true, so we don't need it anymore.
In s3c_hsotg_rx_data() we change function used to print message when active
request is NULL from dev_warn() to dev_dbg(), because such situation is
harmless for driver and now it can take place during normal endpoint
disabling.
[1] https://lkml.org/lkml/2014/12/9/283
[2] https://lkml.org/lkml/2014/12/12/360
Signed-off-by: Robert Baldyga
---
drivers/usb/dwc2/gadget.c | 23 ---
1 file changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 200168e..fee0ad5 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -1305,7 +1305,7 @@ static void s3c_hsotg_rx_data(struct dwc2_hsotg *hsotg,
int ep_idx, int size)
u32 epctl = readl(hsotg->regs + DOEPCTL(ep_idx));
int ptr;
- dev_warn(hsotg->dev,
+ dev_dbg(hsotg->dev,
"%s: FIFO %d bytes on ep%d but no req
(DXEPCTl=0x%08x)\n",
__func__, size, ep_idx, epctl);
@@ -1988,30 +1988,23 @@ static void s3c_hsotg_irq_enumdone(struct dwc2_hsotg
*hsotg)
* @hsotg: The device state.
* @ep: The endpoint the requests may be on.
* @result: The result code to use.
- * @force: Force removal of any current requests
*
* Go through the requests on the given endpoint and mark them
* completed with the given result code.
*/
static void kill_all_requests(struct dwc2_hsotg *hsotg,
struct s3c_hsotg_ep *ep,
- int result, bool force)
+ int result)
{
struct s3c_hsotg_req *req, *treq;
unsigned size;
- list_for_each_entry_safe(req, treq, &ep->queue, queue) {
- /*
-* currently, we can't do much about an already
-* running request on an in endpoint
-*/
-
- if (ep->req == req && ep->dir_in && !force)
- continue;
+ ep->req = NULL;
+ list_for_each_entry_safe(req, treq, &ep->queue, queue)
s3c_hsotg_complete_request(hsotg, ep, req,
result);
- }
+
if (!hsotg->dedicated_fifos)
return;
size = (readl(hsotg->regs + DTXFSTS(ep->index)) & 0x) * 4;
@@ -2036,7 +2029,7 @@ void s3c_hsotg_disconnect(struct dwc2_hsotg *hsotg)
hsotg->connected = 0;
for (ep = 0; ep < hsotg->num_of_eps; ep++)
- kill_all_requests(hsotg, &hsotg->eps[ep], -ESHUTDOWN, true);
+ kill_all_requests(hsotg, &hsotg->eps[ep], -ESHUTDOWN);
call_gadget(hsotg, disconnect);
}
@@ -2334,7 +2327,7 @@ irq_retry:
msecs_to_jiffies(200))) {
kill_all_requests(hsotg, &hsotg->eps[0],
- -ECONNRESET, true);
+ -ECONNRESET);
s3c_hsotg_core_init_disconnected(hsotg);
s3c_hsotg_core_connect(hsotg);
@@ -2588,7 +2581,7 @@ static int s3c_hsotg_ep_disable(struct usb_ep *ep)
spin_lock_irqsave(&hsotg->lock, flags);
/* terminate all requests with shutdown */
- kill_all_requests(hsotg, hs_ep, -ESHUTDOWN, false);
+ kill_all_requests(hsotg, hs_ep, -ESHUTDOWN);
hsotg->fifo_map &= ~(1fifo_index = 0;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] Revert "usb: dwc2: gadget: kill requests with 'force' in s3c_hsotg_udc_stop()"
This reverts commit 62f4f0651ce8ef966a0e5b6db6a7a524c268fdd2.
This patch is incomplete solution. It won't work without changes in udc-core,
which were considered as unacceptable (discussion [1]).
[1] https://lkml.org/lkml/2014/12/12/360
Signed-off-by: Robert Baldyga
---
drivers/usb/dwc2/gadget.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/dwc2/gadget.c b/drivers/usb/dwc2/gadget.c
index 7924200..200168e 100644
--- a/drivers/usb/dwc2/gadget.c
+++ b/drivers/usb/dwc2/gadget.c
@@ -2567,7 +2567,7 @@ error:
* s3c_hsotg_ep_disable - disable given endpoint
* @ep: The endpoint to disable.
*/
-static int s3c_hsotg_ep_disable_force(struct usb_ep *ep, bool force)
+static int s3c_hsotg_ep_disable(struct usb_ep *ep)
{
struct s3c_hsotg_ep *hs_ep = our_ep(ep);
struct dwc2_hsotg *hsotg = hs_ep->parent;
@@ -2588,7 +2588,7 @@ static int s3c_hsotg_ep_disable_force(struct usb_ep *ep,
bool force)
spin_lock_irqsave(&hsotg->lock, flags);
/* terminate all requests with shutdown */
- kill_all_requests(hsotg, hs_ep, -ESHUTDOWN, force);
+ kill_all_requests(hsotg, hs_ep, -ESHUTDOWN, false);
hsotg->fifo_map &= ~(1fifo_index = 0;
@@ -2609,10 +2609,6 @@ static int s3c_hsotg_ep_disable_force(struct usb_ep *ep,
bool force)
return 0;
}
-static int s3c_hsotg_ep_disable(struct usb_ep *ep)
-{
- return s3c_hsotg_ep_disable_force(ep, false);
-}
/**
* on_list - check request is on the given endpoint
* @ep: The endpoint to check.
@@ -2928,7 +2924,7 @@ static int s3c_hsotg_udc_stop(struct usb_gadget *gadget)
/* all endpoints should be shutdown */
for (ep = 1; ep < hsotg->num_of_eps; ep++)
- s3c_hsotg_ep_disable_force(&hsotg->eps[ep].ep, true);
+ s3c_hsotg_ep_disable(&hsotg->eps[ep].ep);
spin_lock_irqsave(&hsotg->lock, flags);
--
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 1/3] gpio: dln2: fix issue when an IRQ is unmasked then enabled
On Wed, Dec 31, 2014 at 9:55 PM, Linus Walleij wrote: > On Thu, Dec 11, 2014 at 2:02 PM, Octavian Purdila > wrote: > >> As noticed during suspend/resume operations, the IRQ can be unmasked >> then disabled in suspend and eventually enabled in resume, but without >> being unmasked. >> >> The current implementation does not take into account interactions >> between mask/unmask and enable/disable interrupts, and thus in the >> above scenarios the IRQs remain unactive. >> >> To fix this we removed the enable/disable operations as they fallback >> to mask/unmask anyway. >> >> We also remove the pending bitmaks as it is already done in irq_data >> (i.e. IRQS_PENDING). >> >> Signed-off-by: Octavian Purdila > > Patch applied for fixes. Bah now that I see there are several versions of the patch set floating around and also MFD patches I don't quite understand how acute this is or how it's to be applied. - Are these regression fixes or nice to have for next kernel release? - Are the GPIO patches independent of the MFD patch? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
