[PATCH Resend 1/2] usb: gadget: s3c2410_udc: Fix build error
Pass value instead of address as expected by 'usb_ep_set_maxpacket_limit'. Fixes the following compilation error introduced by commit e117e742d310 (usb: gadget: add maxpacket_limit field to struct usb_ep): drivers/usb/gadget/s3c2410_udc.c: In function ‘s3c2410_udc_reinit’: drivers/usb/gadget/s3c2410_udc.c:1632:3: error: cannot take address of bit-field ‘maxpacket’ usb_ep_set_maxpacket_limit(ep-ep, ep-ep.maxpacket); Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Reviewed-by: Robert Baldyga r.bald...@samsung.com --- drivers/usb/gadget/s3c2410_udc.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/gadget/s3c2410_udc.c b/drivers/usb/gadget/s3c2410_udc.c index f04b2c3154de..dd9678f85c58 100644 --- a/drivers/usb/gadget/s3c2410_udc.c +++ b/drivers/usb/gadget/s3c2410_udc.c @@ -1629,7 +1629,7 @@ static void s3c2410_udc_reinit(struct s3c2410_udc *dev) ep-ep.desc = NULL; ep-halted = 0; INIT_LIST_HEAD(ep-queue); - usb_ep_set_maxpacket_limit(ep-ep, ep-ep.maxpacket); + usb_ep_set_maxpacket_limit(ep-ep, ep-ep.maxpacket); } } -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH Resend 2/2] usb: gadget: s3c-hsudc: Remove unused label
Fixes the following compilation warning: drivers/usb/gadget/s3c-hsudc.c: In function ‘s3c_hsudc_probe’: drivers/usb/gadget/s3c-hsudc.c:1347:1: warning: label ‘err_add_device’ defined but not used [-Wunused-label] Signed-off-by: Sachin Kamat sachin.ka...@linaro.org --- drivers/usb/gadget/s3c-hsudc.c |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/usb/gadget/s3c-hsudc.c b/drivers/usb/gadget/s3c-hsudc.c index ea4bbfe72ec0..10c6a128250c 100644 --- a/drivers/usb/gadget/s3c-hsudc.c +++ b/drivers/usb/gadget/s3c-hsudc.c @@ -1344,7 +1344,6 @@ static int s3c_hsudc_probe(struct platform_device *pdev) return 0; err_add_udc: -err_add_device: clk_disable(hsudc-uclk); err_res: if (!IS_ERR_OR_NULL(hsudc-transceiver)) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH RFC 1/1] usb: Tell xhci when usb data might be misaligned
From: Mark Lord
On 14-02-01 09:18 AM, Ming Lei wrote:
Even real regressions are easily/often introduced, and we are discussing
how to fix that. I suggest to unset the flag only for the known buggy
controllers.
It is not the controllers that are particularly buggy here.
But rather the drivers and design of parts of the kernel.
I suspect that the documentation is describing the actual implementation
of a specific hardware implementation, not necessarily how the hardware was
intended to behave.
The requirement for two 32bit accesses to a 64bit register is very similar.
This also means that implementations of the hardware that claim conformance
to the 0.96 specification might have similar issues.
Given the small number of xhci controllers and the even smaller number of
VHDL (or similar) sources they will be based on, it really ought to be
possible to tabulate the controller versions and families to get a much
better idea of their behaviour.
I've got two systems with Intel USB3 controllers, linux reports one as
'panther point', the other as '7 Series/C210 Series' (seems to be a Xeon
chipset). I've no idea how the latter relates to the former.
David
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
Remove dependency on BROKEN from drives/usb/musb/da8xx.c glue
Hi, commit 787f5627bec80094db487bfcb401e9744f181aed usb: musb: make davinci and da8xx glues depend on BROKEN Signed-off-by: Felipe Balbi ba...@ti.com adds a dependency of the drivers/usb/musb/da8xx.c driver to BROKEN. I have successfully tested this driver with kernel 3.13 on a custom Texas Instruments AM1808 board in gadget mode, RNDIS network gadget. Therefore I would like to see this BROKEN dependency removed. What would be required for removing this dependency? Is removing the include of the mach/da8xx.h header sufficient? In the mailing list discussion on the patch, Sergei Shtylyov mentioned that this would mean duplicating the definitions. Would this be ok, just copying them to drivers/usb/musb/da8xx.c? Thanks, Christian -- 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
xhci and other woes
Hello guys, At this point it just looks like I have 2 problems: 1 The AX88179 won't initialize and operate properly when connected via the Asmedia 1042 (at least on my ASUS AMD 990FX based system) this appears to go back to at least kernel version 3.11.0 this issue. Perhaps this is BIOS version related. This is an obvious issue being experienced even by David and others who have reported it on the list. 2 The VIA VL800 is currently problematic under Linux with my system. It's not just an issue with the XHCI driver in Linux as VFIO also can't handle it and throws up a bunch of page faults just booting before the XHCI module is ever loaded, whereas the Asmedia 1042 can be passed through to guests without this issue. Sorry if I went off on the wrong tangents, I plan on grabbing a NEC based controller. Regards, Will Trives -- 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: xhci and other woes
One last thing. With the VL800, the thing that crashed the system was traffic being transmitted to a client wirelessly over a VPN with an MTU of 1300 I'm not sure if it was ip fragments or something causing the issue or what but everything else was pretty much ok in the end except for this, I could easily crash the whole system within minutes doing this. Regards, Will Trives On Monday 03 February 2014 23:19:09 renev...@internode.on.net wrote: Hello guys, At this point it just looks like I have 2 problems: 1 The AX88179 won't initialize and operate properly when connected via the Asmedia 1042 (at least on my ASUS AMD 990FX based system) this appears to go back to at least kernel version 3.11.0 this issue. Perhaps this is BIOS version related. This is an obvious issue being experienced even by David and others who have reported it on the list. 2 The VIA VL800 is currently problematic under Linux with my system. It's not just an issue with the XHCI driver in Linux as VFIO also can't handle it and throws up a bunch of page faults just booting before the XHCI module is ever loaded, whereas the Asmedia 1042 can be passed through to guests without this issue. Sorry if I went off on the wrong tangents, I plan on grabbing a NEC based controller. Regards, Will Trives -- 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: xhci and other woes
From: renev...@internode.on. Hello guys, At this point it just looks like I have 2 problems: 1 The AX88179 won't initialize and operate properly when connected via the Asmedia 1042 (at least on my ASUS AMD 990FX based system) this appears to go back to at least kernel version 3.11.0 this issue. Perhaps this is BIOS version related. This is an obvious issue being experienced even by David and others who have reported it on the list. You definitely need the patch that reverts readq and writeq back to use two 32bit accesses for the ASMedia controller to work at all. I'm also seeing a lot of 'odd' messages when the ax88179 card in plugged in (and it sometimes gets picked up at 480M). I'm not looking into those. But there are also further issues I'm about to look at. Short 'ping' requests work, but a 'netperf' tcp rr test with 8k blocks (which probably generates sg transmits) fails generating some 'TRB DMA ptr not part of current TD' errors. I think I've seem that when a 'TRB error' is reported (when I was using the wrong type of NOP). I'm about to investigate what is being errored here. 2 The VIA VL800 is currently problematic under Linux with my system. It's not just an issue with the XHCI driver in Linux as VFIO also can't handle it and throws up a bunch of page faults just booting before the XHCI module is ever loaded, whereas the Asmedia 1042 can be passed through to guests without this issue. Dunno ... David -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: xhci and other woes
From: David Laight From: renev...@internode.on. But there are also further issues I'm about to look at. Short 'ping' requests work, but a 'netperf' tcp rr test with 8k blocks (which probably generates sg transmits) fails generating some 'TRB DMA ptr not part of current TD' errors. I think I've seem that when a 'TRB error' is reported (when I was using the wrong type of NOP). I'm about to investigate what is being errored here. In this case they happen when receive buffers cross 64k boundaries and so are split into two TRBS. The controller is generating one event for the 'short transfer' and a second for the last TRB - by which time the TD and URB have already been cleared up. While the trace isn't ideal, I don't think this is responsible for the whole thing locking up - which it does under some load patterns. I'm not sure how the Intel 'panther point' handles these split rx buffers when they contain a LINK TRB. The splits are definitely not aligned to any reasonably boundary. David -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: s3c-hsotg: fix build on x86 and other architectures
The readsl and writesl I/O accessors are only defined on some architectures. The driver currently depends on CONFIG_ARM because the build breaks on x86, in particular. Switch to use of ioread32_rep and iowrite32_rep to fix build on all architectures and remove the CONFIG_ARM dependency. Also update printk formatting to handle a long long dma_addr_t to avoid warnings on !32-bit architectures. Signed-off-by: Matt Porter mpor...@linaro.org --- drivers/usb/gadget/Kconfig | 1 - drivers/usb/gadget/s3c-hsotg.c | 12 ++-- 2 files changed, 6 insertions(+), 7 deletions(-) diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig index 8154165..782f43a 100644 --- a/drivers/usb/gadget/Kconfig +++ b/drivers/usb/gadget/Kconfig @@ -301,7 +301,6 @@ config USB_PXA27X gadget drivers to also be dynamically linked. config USB_S3C_HSOTG - depends on ARM tristate Designware/S3C HS/OtG USB Device controller help The Designware USB2.0 high-speed gadget controller diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c index 1172eae..0449b76 100644 --- a/drivers/usb/gadget/s3c-hsotg.c +++ b/drivers/usb/gadget/s3c-hsotg.c @@ -617,7 +617,7 @@ static int s3c_hsotg_write_fifo(struct s3c_hsotg *hsotg, to_write = DIV_ROUND_UP(to_write, 4); data = hs_req-req.buf + buf_pos; - writesl(hsotg-regs + EPFIFO(hs_ep-index), data, to_write); + iowrite32_rep(hsotg-regs + EPFIFO(hs_ep-index), data, to_write); return (to_write = can_write) ? -ENOSPC : 0; } @@ -720,8 +720,8 @@ static void s3c_hsotg_start_req(struct s3c_hsotg *hsotg, ureq-length, ureq-actual); if (0) dev_dbg(hsotg-dev, - REQ buf %p len %d dma 0x%08x noi=%d zp=%d snok=%d\n, - ureq-buf, length, ureq-dma, + REQ buf %p len %d dma 0x%08llx noi=%d zp=%d snok=%d\n, + ureq-buf, length, (unsigned long long)ureq-dma, ureq-no_interrupt, ureq-zero, ureq-short_not_ok); maxreq = get_ep_limit(hs_ep); @@ -789,8 +789,8 @@ static void s3c_hsotg_start_req(struct s3c_hsotg *hsotg, dma_reg = dir_in ? DIEPDMA(index) : DOEPDMA(index); writel(ureq-dma, hsotg-regs + dma_reg); - dev_dbg(hsotg-dev, %s: 0x%08x = 0x%08x\n, - __func__, ureq-dma, dma_reg); + dev_dbg(hsotg-dev, %s: 0x%08llx = 0x%08x\n, + __func__, (unsigned long long)ureq-dma, dma_reg); } ctrl |= DxEPCTL_EPEna; /* ensure ep enabled */ @@ -1488,7 +1488,7 @@ static void s3c_hsotg_rx_data(struct s3c_hsotg *hsotg, int ep_idx, int size) * note, we might over-write the buffer end by 3 bytes depending on * alignment of the data. */ - readsl(fifo, hs_req-req.buf + read_ptr, to_read); + ioread32_rep(fifo, hs_req-req.buf + read_ptr, to_read); } /** -- 1.8.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: phy: Quiet unable to find transceiver message
Felipe Balbi schreef op ma 27-01-2014 om 09:30 [-0600]:
On Sat, Jan 25, 2014 at 03:24:55PM -0500, Josh Boyer wrote:
On Sat, Jan 25, 2014 at 10:37 AM, Alan Stern st...@rowland.harvard.edu
wrote:
On Sat, 25 Jan 2014, Josh Boyer wrote:
commit 1ae5799ef6317 (usb: hcd: Initialize USB phy if needed) allows
the USB layer to initialize external PHYs if needed. However, a PHY is
not needed in all cases. The usb_get_phy_device function will print
(Minor nit: that should have been usb_get_phy_dev.)
an error message, unable to find transceiver but everything still
functions normally.
Drop the severity of this message to pr_debug.
Signed-off-by: Josh Boyer jwbo...@fedoraproject.org
---
drivers/usb/phy/phy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index e6f61e4..c7fe880 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -228,7 +228,7 @@ struct usb_phy *usb_get_phy_dev(struct device *dev,
u8 index)
phy = __usb_find_phy_dev(dev, phy_bind_list, index);
if (IS_ERR(phy) || !try_module_get(phy-dev-driver-owner)) {
- pr_err(unable to find transceiver\n);
+ pr_debug(unable to find transceiver\n);
goto err0;
}
Wouldn't it make more sense to change this to dev_debug? As it stands,
the user has no idea which device is lacking a transceiver.
Quite possibly, yes. I'm not overly familiar with the subsystem and
was just writing up what Felipe suggested.
(The same is probably true for other log messages in this source file.)
I don't disagree, but I'd rather someone with more experience in the
USB subsystem do that kind of broader audit/change. I'd be happy to
test.
yeah, I just sent a patch where I forgot to switch over to dev_dbg(), if
you can do that for both messages and remove the out of memory message,
I'd be glad to take your patch instead of mine.
This message cab still be seen when booting v3.14-rc1. Is a patch to
downgrade this message to dev_dbg() - from Josh, Felipe or someone else
- queued somewhere?
Paul Bolle
--
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 Device stops working after 200001 interrupts
On Mon, 3 Feb 2014, Josh Bendavid wrote: The output you're in fact looking for is attached below (ending with the nobody cared error). [ 1121.572119] ohci-pci :00:06.0: IRQ 199900 status 24 enable 805a [ 1121.588793] ohci-pci :00:06.0: IRQ 199901 status 24 enable 805a [ 1121.605487] ohci-pci :00:06.0: IRQ 199902 status 24 enable 805a ... [ 1122.456301] ohci-pci :00:06.0: IRQ 200097 status 24 enable 805a [ 1122.472993] ohci-pci :00:06.0: IRQ 200098 status 24 enable 805a [ 1122.489678] ohci-pci :00:06.0: IRQ 200099 status 24 enable 805a [ 1132.382649] irq 21: nobody cared (try booting with the irqpoll option) This shows one of two things: Either your OHCI controller isn't working right (it's issuing IRQs when it's not supposed to) or some other hardware component in your PC is using IRQ 21 when it's not supposed to. Here's how to tell which is the case. Enable CONFIG_DUMMY_IRQ in the kernel. Then shortly after booting, before the nobody cared error occurs, do this: echo :00:06.0 /sys/bus/pci/drivers/ohci-pci/unbind modprobe dummy-irq irq=21 If the nobody cared error still occurs, this will prove that the OHCI controller isn't at fault; something else is. If it doesn't occur, this will prove that the OHCI controller is malfunctioning. (Incidentally, the output above shows that at least 200099 interrupts occurred before the nobody cared error. I don't know how this squares with your observation that the error always happened after 21 interrupts.) 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] usb: phy: Quiet unable to find transceiver message
On Mon, 3 Feb 2014, Paul Bolle wrote:
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -228,7 +228,7 @@ struct usb_phy *usb_get_phy_dev(struct device
*dev, u8 index)
phy = __usb_find_phy_dev(dev, phy_bind_list, index);
if (IS_ERR(phy) || !try_module_get(phy-dev-driver-owner)) {
- pr_err(unable to find transceiver\n);
+ pr_debug(unable to find transceiver\n);
goto err0;
}
Wouldn't it make more sense to change this to dev_debug? As it stands,
the user has no idea which device is lacking a transceiver.
Quite possibly, yes. I'm not overly familiar with the subsystem and
was just writing up what Felipe suggested.
(The same is probably true for other log messages in this source file.)
I don't disagree, but I'd rather someone with more experience in the
USB subsystem do that kind of broader audit/change. I'd be happy to
test.
yeah, I just sent a patch where I forgot to switch over to dev_dbg(), if
you can do that for both messages and remove the out of memory message,
I'd be glad to take your patch instead of mine.
This message cab still be seen when booting v3.14-rc1. Is a patch to
downgrade this message to dev_dbg() - from Josh, Felipe or someone else
- queued somewhere?
http://marc.info/?l=linux-usbm=139092084714232w=2
As far as I know, this hasn't been merged into anybody's tree yet. And
Felipe is on vacation for a few weeks. Still, it should get in before
3.14 is released.
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: xhci and other woes
From: David Laight From: David Laight From: renev...@internode.on. But there are also further issues I'm about to look at. Short 'ping' requests work, but a 'netperf' tcp rr test with 8k blocks (which probably generates sg transmits) fails generating some 'TRB DMA ptr not part of current TD' errors. I think I've seem that when a 'TRB error' is reported (when I was using the wrong type of NOP). I'm about to investigate what is being errored here. In this case they happen when receive buffers cross 64k boundaries and so are split into two TRBS. The controller is generating one event for the 'short transfer' and a second for the last TRB - by which time the TD and URB have already been cleared up. From the end of section 4.10.1.1 (Short transfers) - If the Short Packet occurred while processing a Transfer TRB with only an ISP flag set, then two events shall be generated for the transfer; one for the Transfer TRB that the short packet occurred on, and a second for the last TRB with the IOC flag set. - Software shall not interpret an Short Packet Event as indicating that the TD that it is associated with is “complete”, unless the TRB Pointer field of the Transfer Event references the last TRB of the TD. Which means that the controller is obeying the rules, and the software is wrong. David -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
usb interrupt storms from the ax88179 hardware
On one system (an amd motherboard with the ASMedia xhci controller)
I'm seeing almost back to back USB (7 or 8 a second) 'interrupt'
packets from an ax88179 Ge card.
It may be that other systems behave similarly.
I'm sure this hadn't used to happen!
I don't know what the interrupt status means, the value (as LE u32)
is 0x900a1 0xe1cd6d79
The only bit the driver looks at is the 0x1 bit in the first word.
This is the 'link up/down' flag.
The two halves of the second word are probably different fields, the
high bits appear after about a second.
Now I'd guess that the driver ought to be doing something about some
of these values. While in this mode transmits are delayed for anything
upto 100ms, at least for some time they do get sent.
However the processing of the 'link up/down' flag is clearly wrong.
The code currently does:
348 event = urb-transfer_buffer;
349 le32_to_cpus((void *)event-intdata1);
350
351 link = (((__force u32)event-intdata1) AX_INT_PPLS_LINK) 16;
352
353 if (netif_carrier_ok(dev-net) != link) {
354 usbnet_link_change(dev, link, 1);
355 netdev_info(dev-net, ax88179 - Link status is: %d\n,
link);
356 }
Which ends up doing repeated calls to usbnet_link_change() and confusing
that code a lot.
I presume there is some delay before the return value from netif_carrier_ok()
matches the set state.
I think the code should be remembering the link state locally.
It might also need to clear some other interrupt flags, only ASIX know
what they mean.
David
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: dwc2: Handle the Host Port Interrupt when it occurs in device mode
From: Dinh Nguyen dingu...@altera.com
According to the spec for the DWC2 controller, when the PRTINT interrupt fires,
the application must clear the appropriate status bit in the Host Port Control
and Status register to clear this bit.
When disconnecting an A-cable when the dwc2 host driver, the PRTINT fires, but
only the GINTSTS_PRTINT status is cleared, no action is done with the HPRT0
register. The HPRT0_ENACHG bit in the HPRT0 must also be poked to correctly
clear the GINTSTS_PRTINT interrupt.
I am seeing this behavoir on v2.93 of the DWC2 IP. When I disconnect an OTG
A-cable adapter, the PRTINT interrupt fires when the DWC2 is in device mode
and is never cleared.
This patch adds the function to read the HPRT0 register when the PRTINT fires
and the dwc2 IP has already transitioned to device mode. This function is only
clearing the HPRT0_ENACHG bit for now, but can be modified to handle more.
Signed-off-by: Dinh Nguyen dingu...@altera.com
Cc: Paul Zimmerman pa...@synopsys.com
Cc: Matt Porter mpor...@linaro.org
Cc: Matthijs Kooijman matth...@stdin.nl
---
drivers/usb/dwc2/core_intr.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
index 12dde73..64fee902 100644
--- a/drivers/usb/dwc2/core_intr.c
+++ b/drivers/usb/dwc2/core_intr.c
@@ -76,6 +76,24 @@ static const char *dwc2_op_state_str(struct dwc2_hsotg
*hsotg)
}
/**
+ * dwc2_handle_usb_port_intr - handles OTG PRTINT interrupts.
+ * When the PRTINT interrupt fires, there are certain status bits in the Host
+ * Port that needs to get cleared.
+ *
+ * @hsotg: Programming view of DWC_otg controller
+ */
+static void dwc2_handle_usb_port_intr(struct dwc2_hsotg *hsotg)
+{
+ u32 hprt0;
+
+ hprt0 = readl(hsotg-regs + HPRT0);
+ if (hprt0 HPRT0_ENACHG) {
+ hprt0 |= HPRT0_ENACHG;
+ writel(hprt0, hsotg-regs + HPRT0);
+ }
+}
+
+/**
* dwc2_handle_mode_mismatch_intr() - Logs a mode mismatch warning message
*
* @hsotg: Programming view of DWC_otg controller
@@ -583,8 +601,10 @@ irq_retry:
if (dwc2_is_device_mode(hsotg)) {
dev_dbg(hsotg-dev,
--Port interrupt received in Device
mode--\n);
+ dwc2_handle_usb_port_intr(hsotg);
gintsts = GINTSTS_PRTINT;
writel(gintsts, hsotg-regs + GINTSTS);
+ dwc2_handle_usb_port_intr(hsotg);
retval = 1;
}
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v4] Move DWC2 driver out of staging
From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Saturday, February 01, 2014 7:44 PM On 02/01/2014 03:00 AM, Andre Heider wrote: On Fri, Jan 31, 2014 at 11:48:37PM -0700, Stephen Warren wrote: On 01/31/2014 11:12 AM, Andre Heider wrote: On Mon, Jan 13, 2014 at 01:50:09PM -0800, Paul Zimmerman wrote: The DWC2 driver should now be in good enough shape to move out of staging. I have stress tested it overnight on RPI running mass storage and Ethernet transfers in parallel, and for several days on our proprietary PCI-based platform. ... this looks just fine, but for whatever reason it breaks sdhci on my rpi. With today's Linus' master the dwc2 controller seems to initialize fine, but I get this upon boot: [1.783316] sdhci-bcm2835 2030.sdhci: sdhci_pltfm_init failed -12 [1.794820] sdhci-bcm2835: probe of 2030.sdhci failed with error -12 ... This is due to the following code: ... What ends up happening, simply due to memory allocation order, is that the memory writes inside usb_settoggle() end up setting the SDHCI struct platform_device's num_resources to 0, so that it's call to platform_get_resource() fails. With the DWC2 move patch reverted, some other random piece of memory is being corrupted, which just happens not to cause any visible problem. Likely it's some other struct platform_device that's already had its resources read by the time DWC2 probes and corrupts them. (Yes, this was hard to find!) Nice work, but how did you pinpoint this? Am I missing some option/tool or did I just not stare for long enough? Well, there was a clear place where an issue was present; the resource lookup in sdhci_pltfm_init() was failing, so I put a bunch of printfs into that function to dump out the data platform_get_resource() used. This clearly pointed at num_resources==0 being the problem. Next, I dumped the same data from the code in drivers/of that sets it up, and it was OK there, so I knew it was getting over-written somewhere. I then basically added hundreds of calls to the same data dumping function throughout kernel functions like really_probe() to track down the location of the problem. Luckily, the behaviour was stable, so I wasn't chasing a race/timing condition. Eventually I narrowed the window to the few lines of code I mentioned in _dwc2_hcd_endpoint_reset(). It would have been much harder if it was e.g. the USB HW DMAing to memory that caused the corruption, so I was lucky:-) Nice work Stephen, thanks. I will try to come up with a patch to fix this ASAP, along the lines of what Alan suggested. -- Paul -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [DRIVER][WIP] Playstation controllers (DualShock 3/4, Navigation/Motion Controller, ...)
Great for me, I don't have to do any work then :-) As for the pre-built kernel, thanks but I REALLY should do it myself instead. For now I'm just hacking and learning my way through, but if I end up someday with something worth contributing back, I won't be able to just skip this step forever. I think I'll just wait for 3.15, then build it myself like a grown-up kernel developer :-) Hmm... I do have this 3rd party USB Playstation Memory Card reader that wasn't recognized last time I plugged it in... I'll just double-check if someone isn't already working on it BEFORE jumping straight into the code :-) Thanks, Jean-Baptiste Boric -- 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 RFC 1/1] usb: Tell xhci when usb data might be misaligned
On Sat, Feb 01, 2014 at 03:05:21PM -0500, Mark Lord wrote: On 14-02-01 09:18 AM, Ming Lei wrote: Even real regressions are easily/often introduced, and we are discussing how to fix that. I suggest to unset the flag only for the known buggy controllers. Ming, the regression cannot be easily fixed in this case. We tried the easy, quick fix and it broke USB storage and usbfs. The patches to paper over those issues started to creep into the upper layers, and I'm not willing to add more code to hack around the issues caused by the quick fix. We need to do this right, not wall-paper over the issues. It is not the controllers that are particularly buggy here. But rather the drivers and design of parts of the kernel. As Mark mentioned, the host controllers aren't buggy. The xHCI driver simply doesn't handle a 1.0 host controller requirement, TD fragments, very well. Only the USB ethernet layer triggers this bug, because the USB storage layer hands down scatter-gather lists in multiples of the max packet size. You tested on a 1.0 host controller, and it apparently didn't need the TD fragments requirement. It seems that Intel 1.0 xHCI host controllers do need that requirement. Perhaps we can add an xHCI driver quirk for an exception so that your host can allow any kind of scatter-gather? Sarah Sharp -- 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 RFC 1/1] usb: Tell xhci when usb data might be misaligned
On Mon, Feb 03, 2014 at 09:54:09AM +, David Laight wrote: From: Mark Lord On 14-02-01 09:18 AM, Ming Lei wrote: Even real regressions are easily/often introduced, and we are discussing how to fix that. I suggest to unset the flag only for the known buggy controllers. It is not the controllers that are particularly buggy here. But rather the drivers and design of parts of the kernel. I suspect that the documentation is describing the actual implementation of a specific hardware implementation, not necessarily how the hardware was intended to behave. You are speculating. Please stop speculating without evidence. It does not add to this conversation. Sarah Sharp -- 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 v4 00/14] port power control fixes
On Sun, Feb 2, 2014 at 1:35 AM, Greg KH gre...@linuxfoundation.org wrote:
On Sat, Feb 01, 2014 at 11:16:24AM -0800, Dan Williams wrote:
On Sat, Feb 1, 2014 at 10:44 AM, Alan Stern st...@rowland.harvard.edu
wrote:
On Fri, 31 Jan 2014, Dan Williams wrote:
Toggling port power currently leads to three unintended disconnect
scenarios that are addressed by this rework of port power recovery and
usb device resume:
1/ Superspeed devices downgrade to their hispeed connection: fix this by
preventing superspeed poweroff until the peer port is suspended.
This depends on the ability to identify peer ports (patches 1-4), and
then patch 5 implements the policy.
2/ khubd prematurely disconnects ports that are in the process of
being resumed or reset. khubd now ignores ports in the
pm-runtime-suspended state (patch 9) and holds a lock to synchronize
the port
status changes of usb_port_{suspend|resume} (patch 11).
3/ Superspeed devices fail to reconnect: Seen during repeated toggles of
the port power state. Fixed by forcing a full recovery cycle of the
usb_device before allowing the next suspend / khubd run (patch 12).
Also, for devices that live lock on reconnect the port runtime resume
path now has the capability to force a reset-resume to be a
warm-reset-resume (patch 13).
I haven't gone through all this in any detail. But a couple of things
stand out immediately, matters of style.
Although the USB stack still has plenty of old code with multiline
comments looking this this:
/* blah blah blah
* blah blah blah
*/
the accepted style is that all new code should appear like this:
/*
* blah blah blah
* blah blah blah
*/
Ah, the eternal debate. No worries.
Also, the style for indentation througout most of the USB stack is that
continuation lines are indented by two tab stops beyond the first line
of the statement. They are not aligned with opening parentheses of
function calls or anything like that.
Unfortunate that what goes for net/, or drivers/md/ doesn't go for
drivers/usb/... sounds like checkpatch needs subsystem specific style
rules to avoid this thrash.
If it's just the style I'll put those changes on a git branch and
spare the list if you're ok doing a pull... otherwise I'll hold off
until you have a chance to take a closer look.
I don't do git pulls except from a very few number of people, so you
will have to make these into real patches eventually if you want them
to be accepted.
Ok, that's the plan once Alan let's me know if v5 needs more than just
the style changes. Until then the git tree is just a convenience for
review.
--
Dan
--
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: [RFT] usb: Disable Link PM if setting device-initiated timeout fails.
On Fri, Jan 31, 2014 at 04:56:36PM +, David Laight wrote: From: Sarah Sharp Yoma, can you apply this patch and see if it helps your issue? Helped a lot on my amd system with the ASMedia controller. Your ASMedia host controller should not even have USB 3.0 link PM enabled, see this patch that I'm sending out shortly: https://git.kernel.org/cgit/linux/kernel/git/sarah/xhci.git/commit/?h=for-usb-linus-3.14id=140e3026a57ab7d830dab2f2c57796c222db0ea9 I really need Yoma to test this patch, since their xHCI host controller should have USB 3.0 Link PM enabled. Yoma, if you need instructions on how to apply the attached patch, please see this page: http://kernelnewbies.org/KernelBuild Sarah Sharp From d14b38edc3494c6299695624b4847445ebabe645 Mon Sep 17 00:00:00 2001 From: Sarah Sharp sarah.a.sh...@linux.intel.com Date: Wed, 22 Jan 2014 15:24:53 -0800 Subject: [PATCH] usb: Disable Link PM if setting device-initiated timeout fails. If the control transfer to set the device-initiated timeout fails for a particular link state (U1 or U2), disable that state. This may solve issues with a Seagate drive connected to an Intel Panther Point host controller: [ 432.191560] usb 4-1: Set SEL for device-initiated U2 failed. [ 432.191664] usb 4-1: USB disconnect, device number 12 [ 469.061694] xhci_hcd :00:14.0: Timeout while waiting for address device command [ 474.271626] xhci_hcd :00:14.0: Timeout while waiting for address device command [ 474.475859] usb 4-1: device not accepting address 13, error -62 [ 474.592197] usb 4-1: new SuperSpeed USB device number 14 using xhci_hcd [ 474.609564] usb 4-1: New USB device found, idVendor=0bc2, idProduct=a0a5 [ 474.609569] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 474.609572] usb 4-1: Product: Backup+ Desk [ 474.609574] usb 4-1: Manufacturer: Seagate [ 474.609576] usb 4-1: SerialNumber: NA5J3BMX [ 474.613800] usb 4-1: Enable of device-initiated U2 failed. [ 474.617303] usb 4-1: Disable of device-initiated U1 failed. [ 474.620807] usb 4-1: Disable of device-initiated U2 failed. [ 474.620840] usb-storage 4-1:1.0: USB Mass Storage device detected [ 474.620928] scsi17 : usb-storage 4-1:1.0 [ 474.624340] usb 4-1: Set SEL for device-initiated U1 failed. [ 479.629776] usb 4-1: Set SEL for device-initiated U2 failed. [ 479.798030] usb 4-1: USB disconnect, device number 14 00:14.0 USB controller: Intel Corporation Panther Point USB xHCI Host Controller (rev 04) (prog-if 30 [XHCI]) Subsystem: Lenovo Device 21f7 Flags: bus master, medium devsel, latency 0, IRQ 40 Memory at f260 (64-bit, non-prefetchable) [size=64K] Capabilities: [70] Power Management version 2 Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+ Kernel driver in use: xhci_hcd Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com Reported-by: Yoma Sophian sophian.y...@gmail.com --- drivers/usb/core/hub.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index 64ea21971be2..74a69b887346 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -3651,7 +3651,8 @@ static void usb_enable_link_state(struct usb_hcd *hcd, struct usb_device *udev, /* Only a configured device will accept the Set Feature U1/U2_ENABLE */ else if (udev-actconfig) - usb_set_device_initiated_lpm(udev, state, true); + if (usb_set_device_initiated_lpm(udev, state, true)) + hcd-driver-disable_usb3_lpm_timeout(hcd, udev, state); } -- 1.8.5.2
Re: [PATCH] usb: phy: Quiet unable to find transceiver message
On Mon, 2014-02-03 at 11:04 -0500, Alan Stern wrote: On Mon, 3 Feb 2014, Paul Bolle wrote: This message cab still be seen when booting v3.14-rc1. Is a patch to downgrade this message to dev_dbg() - from Josh, Felipe or someone else - queued somewhere? http://marc.info/?l=linux-usbm=139092084714232w=2 As far as I know, this hasn't been merged into anybody's tree yet. And Felipe is on vacation for a few weeks. Still, it should get in before 3.14 is released. Thanks. I'll add it to my local stack of patches, and if nothing is merged in a few weeks I might send a short reminder. Paul Bolle -- 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 0/9] xhci: Add support for URB_ZERO_PACKET
Hi David, I asked you to send a patchset that only contains critical bug fixes, and this isn't what I'm looking for. What I want is a patchset containing only fixes that should be marked for stable, e.g. bug fixes only. Patches marked for stable should fix a crash, or some issue that causes the xHCI driver to behave differently than the EHCI driver WRT the upper layers (i.e. device drivers). In general, when you create a patchset that contains both bug fixes that should be bound for stable, and cleanups or optimizations, you need to put the bug fix patches as the very first patches in the patchset. So, the patchset I was looking for should only contain: [7/9] xhci: Add support for URB_ZERO_PACKET to queue_bulk_sg_tx() Along with any bug fixes or critical patches you've sent me in the past. The rest of this patchset includes a mix of cleanups and optimizations: [1/9] xhci: Remove debug code [2/9] xhci: Minor cleanups to queue_bulk_sg_tx() [3/9] xhci: Use a fast upper bound for the number of TRB for a SG request. [4/9] xhci: Simplify setting of TRB type and flags in queue_bulk_sg_tx() [5/9] xhci: Move fragment length calculation to top of loop in queue_bulk_sg_tx() [6/9] xhci: Use a much simpler algorithm for td_size on 1.0 hosts [8/9] xhci: Common up setup of normal and scatter-gather transfers [9/9] xhci: Add num_trbs_for_buf() to count trbs needed for a buffer fragment Patch 1 is not a bug fix, as I've expressed before, although I still want to see it go into 3.14. I'm uninterested in optimizing the SG list TRB counting at this point in time, so I'm not interested in taking patches 3-5, and probably the rest of the patches as well. I'll be blunt here. The xHCI driver mostly Just Works. There's a few new features coming up, there's always going to be bugs to fix, and we're fixing some long-standing issues that cause a few devices to not work. But in general, the driver is pretty stable. I'm uninterested in making sweeping architectural changes to the driver at this point in time. That means I'm really not interested in your shadow ring idea, or trying to eliminate kmallocs in IRQ, etc. I'm allergic to any large driver cleanups at this point in time that have the potential to de-stablize the driver. I am interested in bug fixes, fixing long-standing issues, and supporting new features. I might be interested in performance patches, but they would have to come with hard numbers. Basically, I'm not interested in change for change sake. You seem to want to make large architectural changes, so maybe the xHCI driver isn't the right driver for you to work on. Sarah Sharp -- 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 v4 00/14] port power control fixes
On Mon, Feb 03, 2014 at 10:02:48AM -0800, Dan Williams wrote:
On Sun, Feb 2, 2014 at 1:35 AM, Greg KH gre...@linuxfoundation.org wrote:
On Sat, Feb 01, 2014 at 11:16:24AM -0800, Dan Williams wrote:
On Sat, Feb 1, 2014 at 10:44 AM, Alan Stern st...@rowland.harvard.edu
wrote:
On Fri, 31 Jan 2014, Dan Williams wrote:
Toggling port power currently leads to three unintended disconnect
scenarios that are addressed by this rework of port power recovery and
usb device resume:
1/ Superspeed devices downgrade to their hispeed connection: fix this by
preventing superspeed poweroff until the peer port is suspended.
This depends on the ability to identify peer ports (patches 1-4), and
then patch 5 implements the policy.
2/ khubd prematurely disconnects ports that are in the process of
being resumed or reset. khubd now ignores ports in the
pm-runtime-suspended state (patch 9) and holds a lock to synchronize
the port
status changes of usb_port_{suspend|resume} (patch 11).
3/ Superspeed devices fail to reconnect: Seen during repeated toggles of
the port power state. Fixed by forcing a full recovery cycle of the
usb_device before allowing the next suspend / khubd run (patch 12).
Also, for devices that live lock on reconnect the port runtime resume
path now has the capability to force a reset-resume to be a
warm-reset-resume (patch 13).
I haven't gone through all this in any detail. But a couple of things
stand out immediately, matters of style.
Although the USB stack still has plenty of old code with multiline
comments looking this this:
/* blah blah blah
* blah blah blah
*/
the accepted style is that all new code should appear like this:
/*
* blah blah blah
* blah blah blah
*/
Ah, the eternal debate. No worries.
Also, the style for indentation througout most of the USB stack is that
continuation lines are indented by two tab stops beyond the first line
of the statement. They are not aligned with opening parentheses of
function calls or anything like that.
Unfortunate that what goes for net/, or drivers/md/ doesn't go for
drivers/usb/... sounds like checkpatch needs subsystem specific style
rules to avoid this thrash.
If it's just the style I'll put those changes on a git branch and
spare the list if you're ok doing a pull... otherwise I'll hold off
until you have a chance to take a closer look.
I don't do git pulls except from a very few number of people, so you
will have to make these into real patches eventually if you want them
to be accepted.
Ok, that's the plan once Alan let's me know if v5 needs more than just
the style changes. Until then the git tree is just a convenience for
review.
git trees are a pain in the ass to review. You can't quote them easily
for actually giving review through email, and you just have to trust
that everything is ok when pulling them and running them yourself.
I don't recommend them at all for kernel patch review, 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: USB Device stops working after 200001 interrupts
Alan Stern stern@... writes: On Mon, 3 Feb 2014, Josh Bendavid wrote: The output you're in fact looking for is attached below (ending with the nobody cared error). [ 1121.572119] ohci-pci :00:06.0: IRQ 199900 status 24 enable 805a [ 1121.588793] ohci-pci :00:06.0: IRQ 199901 status 24 enable 805a [ 1121.605487] ohci-pci :00:06.0: IRQ 199902 status 24 enable 805a ... [ 1122.456301] ohci-pci :00:06.0: IRQ 200097 status 24 enable 805a [ 1122.472993] ohci-pci :00:06.0: IRQ 200098 status 24 enable 805a [ 1122.489678] ohci-pci :00:06.0: IRQ 200099 status 24 enable 805a [ 1132.382649] irq 21: nobody cared (try booting with the irqpoll option) This shows one of two things: Either your OHCI controller isn't working right (it's issuing IRQs when it's not supposed to) or some other hardware component in your PC is using IRQ 21 when it's not supposed to. Here's how to tell which is the case. Enable CONFIG_DUMMY_IRQ in the kernel. Then shortly after booting, before the nobody cared error occurs, do this: echo :00:06.0 /sys/bus/pci/drivers/ohci-pci/unbind modprobe dummy-irq irq=21 If the nobody cared error still occurs, this will prove that the OHCI controller isn't at fault; something else is. If it doesn't occur, this will prove that the OHCI controller is malfunctioning. (Incidentally, the output above shows that at least 200099 interrupts occurred before the nobody cared error. I don't know how this squares with your observation that the error always happened after 21 interrupts.) Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majordomo@... More majordomo info at http://vger.kernel.org/majordomo-info.html Indeed doing this the number of interrupts stops increasing, and no error occurs. The dmesg contains the output below. This therefore means that there is a problem with the controller? Would you suggest I try the possible workaround patch you had posted earlier? [ 33.871678] ohci-pci :00:06.0: remove, state 1 [ 33.871686] ohci-pci :00:06.0: roothub graceful disconnect [ 33.871693] usb usb4: USB disconnect, device number 1 [ 33.871696] usb 4-3: USB disconnect, device number 2 [ 33.871699] usb 4-3: unregistering device [ 33.871702] usb 4-3: unregistering interface 4-3:1.0 [ 33.871781] ohci-pci :00:06.0: shutdown urb 8800ab2e9240 ep2in-intr [ 34.140096] usb 4-3: usb_disable_device nuking all URBs [ 34.186771] usb usb4: unregistering device [ 34.186777] usb usb4: unregistering interface 4-0:1.0 [ 34.186826] ohci-pci :00:06.0: shutdown urb 8800bb04a600 ep1in-intr [ 34.187018] usb usb4: usb_disable_device nuking all URBs [ 34.206719] ohci-pci :00:06.0: OHCI controller state [ 34.206724] ohci-pci :00:06.0: OHCI 1.0, NO legacy support registers, rh state running [ 34.206727] ohci-pci :00:06.0: control 0x683 RWE RWC HCFS=operational CBSR=3 [ 34.206730] ohci-pci :00:06.0: cmdstatus 0x0 SOC=0 [ 34.206732] ohci-pci :00:06.0: intrstatus 0x0024 FNO SF [ 34.206735] ohci-pci :00:06.0: intrenable 0x805a MIE RHSC UE RD WDH [ 34.206738] ohci-pci :00:06.0: ed_controlhead bb11e000 [ 34.206741] ohci-pci :00:06.0: hcca frame #82d9 [ 34.206745] ohci-pci :00:06.0: roothub.a 01001206 POTPGT=1 NOCP NPS NDP=6(6) [ 34.206747] ohci-pci :00:06.0: roothub.b PPCM= DR= [ 34.206750] ohci-pci :00:06.0: roothub.status 8000 DRWE [ 34.206753] ohci-pci :00:06.0: roothub.portstatus [0] 0x0100 PPS [ 34.206756] ohci-pci :00:06.0: roothub.portstatus [1] 0x0100 PPS [ 34.206760] ohci-pci :00:06.0: roothub.portstatus [2] 0x0103 PPS PES CCS [ 34.206762] ohci-pci :00:06.0: roothub.portstatus [3] 0x0100 PPS [ 34.206765] ohci-pci :00:06.0: roothub.portstatus [4] 0x0100 PPS [ 34.206768] ohci-pci :00:06.0: roothub.portstatus [5] 0x0100 PPS [ 34.206794] ohci-pci :00:06.0: USB bus 4 deregistered -- 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 Device stops working after 200001 interrupts
On Mon, 3 Feb 2014, Josh Bendavid wrote: This shows one of two things: Either your OHCI controller isn't working right (it's issuing IRQs when it's not supposed to) or some other hardware component in your PC is using IRQ 21 when it's not supposed to. Here's how to tell which is the case. Enable CONFIG_DUMMY_IRQ in the kernel. Then shortly after booting, before the nobody cared error occurs, do this: echo :00:06.0 /sys/bus/pci/drivers/ohci-pci/unbind modprobe dummy-irq irq=21 If the nobody cared error still occurs, this will prove that the OHCI controller isn't at fault; something else is. If it doesn't occur, this will prove that the OHCI controller is malfunctioning. Indeed doing this the number of interrupts stops increasing, and no error occurs. The dmesg contains the output below. This therefore means that there is a problem with the controller? Would you suggest I try the possible workaround patch you had posted earlier? The dmesg output is normal. And yes, lack of any error does indicate that something is wrong with your controller. I don't think this problem can be fixed by a simple workaround. I've been considering adding an I/O watchdog to ohci-hcd, because it ought to help with some issues experienced by other people with buggy OHCI controllers. It's _possible_ that this might also help with your problem -- without knowing exactly what is going wrong in the hardware, I can't say for certain. For now, you may be able to bypass the problem by getting a USB-2 hub and plugging the infrared and Logitech receivers into it rather than directly into the computer. 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 v4] Move DWC2 driver out of staging
From: Paul Zimmerman Sent: Monday, February 03, 2014 9:36 AM From: Stephen Warren [mailto:swar...@wwwdotorg.org] Sent: Saturday, February 01, 2014 7:44 PM On 02/01/2014 03:00 AM, Andre Heider wrote: On Fri, Jan 31, 2014 at 11:48:37PM -0700, Stephen Warren wrote: On 01/31/2014 11:12 AM, Andre Heider wrote: On Mon, Jan 13, 2014 at 01:50:09PM -0800, Paul Zimmerman wrote: The DWC2 driver should now be in good enough shape to move out of staging. I have stress tested it overnight on RPI running mass storage and Ethernet transfers in parallel, and for several days on our proprietary PCI-based platform. ... this looks just fine, but for whatever reason it breaks sdhci on my rpi. With today's Linus' master the dwc2 controller seems to initialize fine, but I get this upon boot: [1.783316] sdhci-bcm2835 2030.sdhci: sdhci_pltfm_init failed -12 [1.794820] sdhci-bcm2835: probe of 2030.sdhci failed with error -12 ... This is due to the following code: ... What ends up happening, simply due to memory allocation order, is that the memory writes inside usb_settoggle() end up setting the SDHCI struct platform_device's num_resources to 0, so that it's call to platform_get_resource() fails. With the DWC2 move patch reverted, some other random piece of memory is being corrupted, which just happens not to cause any visible problem. Likely it's some other struct platform_device that's already had its resources read by the time DWC2 probes and corrupts them. (Yes, this was hard to find!) Nice work, but how did you pinpoint this? Am I missing some option/tool or did I just not stare for long enough? Well, there was a clear place where an issue was present; the resource lookup in sdhci_pltfm_init() was failing, so I put a bunch of printfs into that function to dump out the data platform_get_resource() used. This clearly pointed at num_resources==0 being the problem. Next, I dumped the same data from the code in drivers/of that sets it up, and it was OK there, so I knew it was getting over-written somewhere. I then basically added hundreds of calls to the same data dumping function throughout kernel functions like really_probe() to track down the location of the problem. Luckily, the behaviour was stable, so I wasn't chasing a race/timing condition. Eventually I narrowed the window to the few lines of code I mentioned in _dwc2_hcd_endpoint_reset(). It would have been much harder if it was e.g. the USB HW DMAing to memory that caused the corruption, so I was lucky:-) Nice work Stephen, thanks. I will try to come up with a patch to fix this ASAP, along the lines of what Alan suggested. Stephen, Andre, Can you test the attached patch, please? It works for my on the Synopsys PCIe-based FPGA board. Unfortunately my RPI board is currently broken, so I am unable to test it there to verify it actually fixes the problem you are seeing. The dwc2 driver doesn't use the usb_device toggle bits anywhere else, so the quickest fix is to just remove the problematic code from _dwc2_hcd_endpoint_reset(). If you give me your tested-bys, I will submit this as a proper patch to Greg. -- Paul dwc2-toggle.patch Description: dwc2-toggle.patch
Re: USB Device stops working after 200001 interrupts
Alan Stern stern@... writes: The dmesg output is normal. And yes, lack of any error does indicate that something is wrong with your controller. I don't think this problem can be fixed by a simple workaround. I've been considering adding an I/O watchdog to ohci-hcd, because it ought to help with some issues experienced by other people with buggy OHCI controllers. It's _possible_ that this might also help with your problem -- without knowing exactly what is going wrong in the hardware, I can't say for certain. For now, you may be able to bypass the problem by getting a USB-2 hub and plugging the infrared and Logitech receivers into it rather than directly into the computer. Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majordomo@... More majordomo info at http://vger.kernel.org/majordomo-info.html Is it all understood why/how I never had any problems using a 3.5 kernel?(under Ubuntu 12.10). I've only had this issue when running OpenElec with 3.13-rc8. If it's a hardware problem it must have been avoided or worked around either by virtue of the older kernel or by some ubuntu-specific setting... -- 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: Handle the Host Port Interrupt when it occurs in device mode
From: dingu...@altera.com [mailto:dingu...@altera.com]
Sent: Monday, February 03, 2014 9:00 AM
Hi Dinh,
According to the spec for the DWC2 controller, when the PRTINT interrupt
fires,
the application must clear the appropriate status bit in the Host Port Control
and Status register to clear this bit.
When disconnecting an A-cable when the dwc2 host driver, the PRTINT fires, but
only the GINTSTS_PRTINT status is cleared, no action is done with the HPRT0
register. The HPRT0_ENACHG bit in the HPRT0 must also be poked to correctly
clear the GINTSTS_PRTINT interrupt.
I am seeing this behavoir on v2.93 of the DWC2 IP. When I disconnect an OTG
A-cable adapter, the PRTINT interrupt fires when the DWC2 is in device mode
and is never cleared.
This patch adds the function to read the HPRT0 register when the PRTINT fires
and the dwc2 IP has already transitioned to device mode. This function is only
clearing the HPRT0_ENACHG bit for now, but can be modified to handle more.
Signed-off-by: Dinh Nguyen dingu...@altera.com
Cc: Paul Zimmerman pa...@synopsys.com
Cc: Matt Porter mpor...@linaro.org
Cc: Matthijs Kooijman matth...@stdin.nl
---
drivers/usb/dwc2/core_intr.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
index 12dde73..64fee902 100644
--- a/drivers/usb/dwc2/core_intr.c
+++ b/drivers/usb/dwc2/core_intr.c
@@ -76,6 +76,24 @@ static const char *dwc2_op_state_str(struct dwc2_hsotg
*hsotg)
}
/**
+ * dwc2_handle_usb_port_intr - handles OTG PRTINT interrupts.
+ * When the PRTINT interrupt fires, there are certain status bits in the Host
+ * Port that needs to get cleared.
+ *
+ * @hsotg: Programming view of DWC_otg controller
+ */
+static void dwc2_handle_usb_port_intr(struct dwc2_hsotg *hsotg)
+{
+ u32 hprt0;
+
+ hprt0 = readl(hsotg-regs + HPRT0);
+ if (hprt0 HPRT0_ENACHG) {
This would be a little cleaner like this:
u32 hprt0 = readl(hsotg-regs + HPRT0);
if (hprt0 HPRT0_ENACHG) {
+ hprt0 |= HPRT0_ENACHG;
+ writel(hprt0, hsotg-regs + HPRT0);
+ }
+}
+
+/**
* dwc2_handle_mode_mismatch_intr() - Logs a mode mismatch warning message
*
* @hsotg: Programming view of DWC_otg controller
@@ -583,8 +601,10 @@ irq_retry:
if (dwc2_is_device_mode(hsotg)) {
dev_dbg(hsotg-dev,
--Port interrupt received in Device
mode--\n);
+ dwc2_handle_usb_port_intr(hsotg);
gintsts = GINTSTS_PRTINT;
writel(gintsts, hsotg-regs + GINTSTS);
+ dwc2_handle_usb_port_intr(hsotg);
Why do you have two calls to dwc2_handle_usb_port_intr() here? Does it
still work if you remove the first call?
I don't see this problem on our internal FPGA platform, so I will just
have to take your word that this fixes a problem. If you resubmit the
patch with just a single call to dwc2_handle_usb_port_intr(), I will
ack it.
--
Paul
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: USB Device stops working after 200001 interrupts
On Mon, 3 Feb 2014, Josh Bendavid wrote: Is it all understood why/how I never had any problems using a 3.5 kernel?(under Ubuntu 12.10). I've only had this issue when running OpenElec with 3.13-rc8. No, you never mentioned this before. If it's a hardware problem it must have been avoided or worked around either by virtue of the older kernel or by some ubuntu-specific setting... If the problem was indeed caused by software, there's a good chance you can track it down by doing a bisection search. That's a time-consuming procedure but it doesn't require much intellectual effort. Have you verified that the controller still works okay under a 3.5 kernel (to rule out the possibility of some kind of recent hardware breakage)? 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 Device stops working after 200001 interrupts
If the problem was indeed caused by software, there's a good chance you can track it down by doing a bisection search. That's a time-consuming procedure but it doesn't require much intellectual effort. Have you verified that the controller still works okay under a 3.5 kernel (to rule out the possibility of some kind of recent hardware breakage)? Alan Stern Hi Alan, Yes, this hardware was in active use and working fine with 3.5. The usb/ir issue came up as soon as I moved to 3.13-rc8. (As I said, this was not the only change strictly speaking, given that I moved from Ubuntu to OpenElec, so there can well be other relevant distro-related changes) Unfortunately I prefer deep intellectual efforts which don't require much time... Is it possible to simply bypass the nobody cared error, given that the IR appears to work fine, despite the constant uptick in interrupts? (And indeed is it possible that older kernels were simply more forgiving about this sort of thing?) -- 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 Device stops working after 200001 interrupts
On Mon, 3 Feb 2014, Josh Bendavid wrote: Hi Alan, Yes, this hardware was in active use and working fine with 3.5. The usb/ir issue came up as soon as I moved to 3.13-rc8. (As I said, this was not the only change strictly speaking, given that I moved from Ubuntu to OpenElec, so there can well be other relevant distro-related changes) Unfortunately I prefer deep intellectual efforts which don't require much time... :-) Is it possible to simply bypass the nobody cared error, given that the IR appears to work fine, despite the constant uptick in interrupts? (And indeed is it possible that older kernels were simply more forgiving about this sort of thing?) I'm not sure what you mean by bypassing the error. Certainly you can _ignore_ it, if everything continues to work okay after the error occurs. Older kernels were not any more forgiving about interrupt storms, believe me. 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] usb: dwc2: Handle the Host Port Interrupt when it occurs in device mode
On Mon, 2014-02-03 at 21:13 +, Paul Zimmerman wrote:
From: dingu...@altera.com [mailto:dingu...@altera.com]
Sent: Monday, February 03, 2014 9:00 AM
Hi Dinh,
According to the spec for the DWC2 controller, when the PRTINT interrupt
fires,
the application must clear the appropriate status bit in the Host Port
Control
and Status register to clear this bit.
When disconnecting an A-cable when the dwc2 host driver, the PRTINT fires,
but
only the GINTSTS_PRTINT status is cleared, no action is done with the HPRT0
register. The HPRT0_ENACHG bit in the HPRT0 must also be poked to correctly
clear the GINTSTS_PRTINT interrupt.
I am seeing this behavoir on v2.93 of the DWC2 IP. When I disconnect an OTG
A-cable adapter, the PRTINT interrupt fires when the DWC2 is in device mode
and is never cleared.
This patch adds the function to read the HPRT0 register when the PRTINT
fires
and the dwc2 IP has already transitioned to device mode. This function is
only
clearing the HPRT0_ENACHG bit for now, but can be modified to handle more.
Signed-off-by: Dinh Nguyen dingu...@altera.com
Cc: Paul Zimmerman pa...@synopsys.com
Cc: Matt Porter mpor...@linaro.org
Cc: Matthijs Kooijman matth...@stdin.nl
---
drivers/usb/dwc2/core_intr.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/usb/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
index 12dde73..64fee902 100644
--- a/drivers/usb/dwc2/core_intr.c
+++ b/drivers/usb/dwc2/core_intr.c
@@ -76,6 +76,24 @@ static const char *dwc2_op_state_str(struct dwc2_hsotg
*hsotg)
}
/**
+ * dwc2_handle_usb_port_intr - handles OTG PRTINT interrupts.
+ * When the PRTINT interrupt fires, there are certain status bits in the
Host
+ * Port that needs to get cleared.
+ *
+ * @hsotg: Programming view of DWC_otg controller
+ */
+static void dwc2_handle_usb_port_intr(struct dwc2_hsotg *hsotg)
+{
+ u32 hprt0;
+
+ hprt0 = readl(hsotg-regs + HPRT0);
+ if (hprt0 HPRT0_ENACHG) {
This would be a little cleaner like this:
u32 hprt0 = readl(hsotg-regs + HPRT0);
if (hprt0 HPRT0_ENACHG) {
Ok...
+ hprt0 |= HPRT0_ENACHG;
+ writel(hprt0, hsotg-regs + HPRT0);
+ }
+}
+
+/**
* dwc2_handle_mode_mismatch_intr() - Logs a mode mismatch warning message
*
* @hsotg: Programming view of DWC_otg controller
@@ -583,8 +601,10 @@ irq_retry:
if (dwc2_is_device_mode(hsotg)) {
dev_dbg(hsotg-dev,
--Port interrupt received in Device
mode--\n);
+ dwc2_handle_usb_port_intr(hsotg);
gintsts = GINTSTS_PRTINT;
writel(gintsts, hsotg-regs + GINTSTS);
+ dwc2_handle_usb_port_intr(hsotg);
Why do you have two calls to dwc2_handle_usb_port_intr() here? Does it
still work if you remove the first call?
I don't see this problem on our internal FPGA platform, so I will just
have to take your word that this fixes a problem. If you resubmit the
patch with just a single call to dwc2_handle_usb_port_intr(), I will
ack it.
Yes, sorry for that. It must have been a merge error on my part between
my branches. Yes, a single call to dwc2_handle_usb_port_intr() is
enough.
will send out v2.
Thanks,
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 v4] Move DWC2 driver out of staging
On 02/03/2014 01:51 PM, Paul Zimmerman wrote: ... Stephen, Andre, Can you test the attached patch, please? It works for my on the Synopsys PCIe-based FPGA board. Unfortunately my RPI board is currently broken, so I am unable to test it there to verify it actually fixes the problem you are seeing. The dwc2 driver doesn't use the usb_device toggle bits anywhere else, so the quickest fix is to just remove the problematic code from _dwc2_hcd_endpoint_reset(). If you give me your tested-bys, I will submit this as a proper patch to Greg. I've tested a basically equivalent patch (link below), so I feel comfortable saying: Tested-by: Stephen Warren swar...@wwwdotorg.org https://github.com/swarren/linux-rpi/commit/f7b9c896153cc0501acecb58053db978ec00a5bf @@ -2579,9 +2579,11 @@ static void _dwc2_hcd_endpoint_reset(struct usb_hcd *hcd, spin_lock_irqsave(hsotg-lock, flags); +#if 0 usb_settoggle(udev, epnum, is_out, 0); if (is_control) usb_settoggle(udev, epnum, !is_out, 0); +#endif dwc2_hcd_endpoint_reset(hsotg, ep); spin_unlock_irqrestore(hsotg-lock, flags); -- 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
usb3 stopped working 3.13.0-rc3-g8d276377 → 3.13.0-g9b0cd304
Asus P8Z68-V PRO GEN3 [ bios-version 3402, bios-release-date 05/07/2012 ] dmesg-3.13.0-rc3-g8d276377+-1391075301.txt http://pastebin.com/peJJkXZV dmesg-3.13.0-g9b0cd304+-1391076985.txt http://pastebin.com/p0UQsEte some days ago I had connected mobile phones and microphone into HP ZR24w monitor's hub, and there was some glitch (got power but no data connection). Even earlier I once I got same kind of problem with this hub and I fixed it by power cycling the monitor, but this time it did not work, so I tried also with usbcore.autosuspend=-1 parameter (did not help). I have now power cycled the computer and I do not use suspend, anyways.. I have not yet tried if 3.13.0-rc3-g8d276377 would work now. these with 3.13.0-g9b0cd304: [ 296.401362] xhci_hcd :03:00.0: Timeout while waiting for a slot [ 312.015464] xhci_hcd :03:00.0: Stopped the command ring failed, maybe the host is dead [ 312.015477] xhci_hcd :03:00.0: Abort command ring failed [ 312.015571] xhci_hcd :03:00.0: HC died; cleaning up [ 317.010861] xhci_hcd :03:00.0: Timeout while waiting for a slot [ 317.010867] xhci_hcd :03:00.0: Abort the command ring, but the xHCI is dead. [ 322.006129] xhci_hcd :03:00.0: Timeout while waiting for a slot [ 322.006135] xhci_hcd :03:00.0: Abort the command ring, but the xHCI is dead. [ 327.001400] xhci_hcd :03:00.0: Timeout while waiting for a slot [ 327.001406] xhci_hcd :03:00.0: Abort the command ring, but the xHCI is dead. [ 442.124359] xhci_hcd :05:00.0: Timeout while waiting for a slot here I attached usb3 card reader into computer's usb3 port and usb2 keyboard stopped working while the reader was plugged in [ 457.679216] xhci_hcd :05:00.0: Stopped the command ring failed, maybe the host is dead [ 457.679230] xhci_hcd :05:00.0: Abort command ring failed [ 457.679329] xhci_hcd :05:00.0: HC died; cleaning up [ 462.673908] xhci_hcd :05:00.0: Timeout while waiting for a slot [ 462.673914] xhci_hcd :05:00.0: Abort the command ring, but the xHCI is dead. [ 467.669179] xhci_hcd :05:00.0: Timeout while waiting for a slot [ 467.669186] xhci_hcd :05:00.0: Abort the command ring, but the xHCI is dead. [ 472.664455] xhci_hcd :05:00.0: Timeout while waiting for a slot [ 472.664461] xhci_hcd :05:00.0: Abort the command ring, but the xHCI is dead. now when I plug any device into usb3 ports, no messages are produced. 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09) Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard Flags: bus master, fast devsel, latency 0 Capabilities: [e0] Vendor Specific Information: Len=0c ? 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Capabilities: [88] Subsystem: ASUSTeK Computer Inc. Device 844d Capabilities: [80] Power Management version 3 Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [a0] Express Root Port (Slot+), MSI 00 Capabilities: [100] Virtual Channel Capabilities: [140] Root Complex Link Kernel driver in use: pcieport 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device 844d Flags: bus master, fast devsel, latency 0, IRQ 55 Memory at f740 (64-bit, non-prefetchable) [size=4M] Memory at e000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] Expansion ROM at unassigned [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Capabilities: [d0] Power Management version 2 Capabilities: [a4] PCI Advanced Features Kernel driver in use: i915 00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04) Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard Flags: bus master, fast devsel, latency 0, IRQ 41 Memory at f7d2c000 (64-bit, non-prefetchable) [size=16] Capabilities: [50] Power Management version 3 Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+ Kernel driver in use: mei_me 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 05) Subsystem: ASUSTeK Computer Inc. P8P67 Deluxe Motherboard Flags: bus master, fast devsel, latency 0, IRQ 54 Memory at f7d0 (32-bit, non-prefetchable) [size=128K] Memory at f7d29000 (32-bit, non-prefetchable) [size=4K] I/O ports at f080 [size=32] Capabilities: [c8] Power Management version 2
Re: [BUGREPORT] Linux USB 3.0
Hi Sarah, On Mon, Jan 20, 2014 at 8:35 PM, Sarah Sharp sarah.a.sh...@linux.intel.com wrote: Hi Markus, I'm the xHCI driver maintainer, and it helps to Cc me on USB 3.0 bug reports. On Sat, Dec 28, 2013 at 07:24:20AM +0100, Markus Rechberger wrote: just received following log snippset: Please state which kernel version you (or your customer) is running. You've reported issues with several different kernel versions, so which kernel are you running for this particular snippet? Dec 27 23:23:50 solist kernel: [ 36.118245] xhci_hcd :00:14.0: ERROR Transfer event TRB DMA ptr These messages might be harmless. The 3.0 kernel contains a fix for Intel Panther Point xHCI hosts that suppresses those messages, commit ad808333d8201d53075a11bc8dd83b81f3d68f0b Intel xhci: Ignore spurious successful event. A later commit extends that to all xHCI 1.0 hosts, commit 07f3cb7c28bf3f4dd80bfb136cf45810c46ac474 usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0 That was queued for 3.11 and marked to be backported into stable kernels as old as 3.0. the previous bug report of that user: https://bugzilla.kernel.org/show_bug.cgi?id=65021 xhci: complete USB freeze Hmm, Greg didn't assign that bug to me, so I missed it, sorry. On Fri, Dec 27, 2013 at 8:59 PM, Markus Rechberger mrechber...@gmail.com wrote: Seems like DH87RL was working with 3.2.0-55-generic-pae unfortunately we don't have such a board for testing and customer patience is limited to bisect the kernel. Does anyone have a clue what modification could have killed USB 3.0 support within those releases? It does not seem to be SG support. 3.2 was the kernel where the Intel EHCI to xHCI port switchover code went in. Without that code, all ports will remain under the EHCI host, and USB 3.0 devices will work at USB 2.0 speeds. I suspect the USB device triggers an issue with the xHCI driver, and 3.2 only works because the device is on an EHCI port without the switchover code. On Fri, Dec 27, 2013 at 6:18 PM, Markus Rechberger mrechber...@gmail.com wrote: I just got another USB 3.0 bugreport, the entire system crashed. That particular customer already filed a bugreport in November 2013 that his system is in a bad state when using some USB 2.0 media devices which even have opensource drivers built into the kernel. USB 3.0 support with Linux seems to be a disaster with Linux 3.6.12. The affected board is an Intel DH87RL board. Why are they running 3.6.12 in particular? That's not a supported stable kernel. our customers are using any kind of linux kernel. The drivers are using USBFS (devio.c) for interfacing with USB. It seems like you are in contact with one customer who is using the DH87RL board. Just today we got another one in our forum using 3.12.9-2-ARCH. Also Synology NAS users seem to be affected by the USB 2.0 through USB 3.0 issue. On Wed, Dec 25, 2013 at 8:18 AM, Markus Rechberger mrechber...@gmail.com wrote: A customer using a device with USBDEVFS is reporting following backtrace (it seems to be a rather generic issue related to linux usb 3.0 in general): According to him this problem is reproducible as soon as he starts the data transfer, is there anything known about that? He is using 3.12.0-031200-generic So at this point you've reported three separate bugs, all with the same symptom, but different kernel versions? Are these all from the same bug reporter, or a different bug reporter? You've got me seriously confused right now. Please keep one bug report to one mail thread, and get the original bug reporter to start that thread. If this is from one bug reporter, please state the current kernel they are running, and send dmesg showing the issue with CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING turned on (you may also need to turn on CONFIG_DYNAMIC_DEBUG in later kernels). Please attach the dmesg as a file, since your mail client line-wraps. Dec 24 14:22:39 homenas kernel: [ 1469.818460] xhci_hcd :0f:00.0: ERROR Transfer event TRB DMA ptr not part of current TD Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: ERROR Transfer event TRB DMA ptr not part of current TD Dec 24 14:30:39 homenas kernel: last message repeated 16 times Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: WARN Successful completion on short TX Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: WARN Successful completion on short TX Dec 24 14:30:39 homenas kernel: [ 1469.822450] xhci_hcd :0f:00.0: URB transfer length is wrong, xHC issue? req. len = 46080, act. len = 1382400 Dec 24 14:30:39 homenas kernel: [ 1469.822450] BUG: unable to handle kernel NULL pointer dereference at 0004 Dec 24 14:30:39 homenas kernel: [ 1469.822450] IP: [] finish_td+0x13f/0x250 Dec 24 14:30:39 homenas kernel: [ 1469.822450] PGD 0 Dec 24
RE: dwc2: commit beb7e592bc is causing a disconnected device to not get detected again
From: Dinh Nguyen [mailto:dingu...@altera.com] Sent: Monday, February 03, 2014 2:53 PM While I was testing my patch to combine the dwc2/s3c-hsotg into a DRD driver, I found that after disconnecting a USB HDD from an OTG A-connector, then reconnecting it, the driver would no longer detect the USB device. I was able to track this issue down to this commit: commit beb7e592bcfd750951c47580494f13065f0fd44c Author: Julien DELACOU julien.dela...@st.com Date: Wed Nov 20 17:29:49 2013 +0100 staging: dwc2: add check on dwc2_core_reset return If the GRSTCTL_CSFTRST self-clearing bit never comes back to 0 for any reason, the controller is under reset state and cannot be used. It's preferable to abort initialization in such case. Signed-off-by: Julien Delacou julien.dela...@st.com Acked-by: Paul Zimmerman pa...@synopsys.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Has anyone else seen this issue with the dwc2 driver on 3.14-rc1? Hi Dinh, I haven't seen it. Do either of the HANG messages in dwc2_core_reset() show up in your dmesg when this happens? If so, what happens if you try increasing the timeout values in there? i.e. try changing the two if (++count 50) to if (++count 250) or so. -- Paul
RE: dwc2: commit beb7e592bc is causing a disconnected device to not get detected again
On Mon, 2014-02-03 at 23:10 +, Paul Zimmerman wrote: From: Dinh Nguyen [mailto:dingu...@altera.com] Sent: Monday, February 03, 2014 2:53 PM While I was testing my patch to combine the dwc2/s3c-hsotg into a DRD driver, I found that after disconnecting a USB HDD from an OTG A-connector, then reconnecting it, the driver would no longer detect the USB device. I was able to track this issue down to this commit: commit beb7e592bcfd750951c47580494f13065f0fd44c Author: Julien DELACOU julien.dela...@st.com Date: Wed Nov 20 17:29:49 2013 +0100 staging: dwc2: add check on dwc2_core_reset return If the GRSTCTL_CSFTRST self-clearing bit never comes back to 0 for any reason, the controller is under reset state and cannot be used. It's preferable to abort initialization in such case. Signed-off-by: Julien Delacou julien.dela...@st.com Acked-by: Paul Zimmerman pa...@synopsys.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org Has anyone else seen this issue with the dwc2 driver on 3.14-rc1? Hi Dinh, I haven't seen it. Do either of the HANG messages in dwc2_core_reset() show up in your dmesg when this happens? No, I do not see these messages when I re-insert the OTG adapter. Also, this is my setup. I am using an OTG Mini-A Male to Female A adapter, then I have a USB HDD connected to the Female A adapter. Disconnect/reconnecting the HDD to the adapter works. But if I disconnect the adapter connected to the board, then reconnecting fails. Thanks, Dinh If so, what happens if you try increasing the timeout values in there? i.e. try changing the two if (++count 50) to if (++count 250) or so. -- 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: dwc2: commit beb7e592bc is causing a disconnected device to not get detected again
On Mon, 2014-02-03 at 23:10 +, Paul Zimmerman wrote:
From: Dinh Nguyen [mailto:dingu...@altera.com]
Sent: Monday, February 03, 2014 2:53 PM
While I was testing my patch to combine the dwc2/s3c-hsotg into a DRD
driver, I found that after disconnecting a USB HDD from an OTG
A-connector, then reconnecting it, the driver would no longer detect the
USB device.
I was able to track this issue down to this commit:
commit beb7e592bcfd750951c47580494f13065f0fd44c
Author: Julien DELACOU julien.dela...@st.com
Date: Wed Nov 20 17:29:49 2013 +0100
staging: dwc2: add check on dwc2_core_reset return
If the GRSTCTL_CSFTRST self-clearing bit never comes
back to 0 for any reason, the controller is under reset
state and cannot be used. It's preferable to abort
initialization in such case.
Signed-off-by: Julien Delacou julien.dela...@st.com
Acked-by: Paul Zimmerman pa...@synopsys.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
Has anyone else seen this issue with the dwc2 driver on 3.14-rc1?
Hi Dinh,
I haven't seen it. Do either of the HANG messages in dwc2_core_reset()
show up in your dmesg when this happens?
If so, what happens if you try increasing the timeout values in there?
i.e. try changing the two if (++count 50) to if (++count 250)
or so.
I think it's because of this change:
static int dwc2_hs_phy_init(struct dwc2_hsotg *hsotg, bool select_phy)
{
u32 usbcfg;
+ int retval = 0;
if (!select_phy)
- return;
+ return -ENODEV;
My select_phy is NULL. Not sure why, but I'll debug it some more.
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: dwc2: commit beb7e592bc is causing a disconnected device to not get detected again
From: Dinh Nguyen [mailto:dingu...@altera.com]
Sent: Monday, February 03, 2014 3:42 PM
On Mon, 2014-02-03 at 23:10 +, Paul Zimmerman wrote:
From: Dinh Nguyen [mailto:dingu...@altera.com]
Sent: Monday, February 03, 2014 2:53 PM
While I was testing my patch to combine the dwc2/s3c-hsotg into a DRD
driver, I found that after disconnecting a USB HDD from an OTG
A-connector, then reconnecting it, the driver would no longer detect the
USB device.
I was able to track this issue down to this commit:
commit beb7e592bcfd750951c47580494f13065f0fd44c
Author: Julien DELACOU julien.dela...@st.com
Date: Wed Nov 20 17:29:49 2013 +0100
staging: dwc2: add check on dwc2_core_reset return
If the GRSTCTL_CSFTRST self-clearing bit never comes
back to 0 for any reason, the controller is under reset
state and cannot be used. It's preferable to abort
initialization in such case.
Signed-off-by: Julien Delacou julien.dela...@st.com
Acked-by: Paul Zimmerman pa...@synopsys.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
Has anyone else seen this issue with the dwc2 driver on 3.14-rc1?
Hi Dinh,
I haven't seen it. Do either of the HANG messages in dwc2_core_reset()
show up in your dmesg when this happens?
If so, what happens if you try increasing the timeout values in there?
i.e. try changing the two if (++count 50) to if (++count 250)
or so.
I think it's because of this change:
static int dwc2_hs_phy_init(struct dwc2_hsotg *hsotg, bool select_phy)
{
u32 usbcfg;
+ int retval = 0;
if (!select_phy)
- return;
+ return -ENODEV;
My select_phy is NULL. Not sure why, but I'll debug it some more.
Hi Dinh,
That looks like just a silly error in that patch. Does the attached
patch fix it?
--
Paul
dwc2-phy-init.patch
Description: dwc2-phy-init.patch
[PATCH v2] Phytec phyFLEX-i.MX6 : Added USB_OTG Support
This patch adds support for USB_OTG on Phytec phyFLEX-i.MX6 Quad module.
Signed-off-by: Ashutosh singh ashutos...@phytec.in
---
arch/arm/boot/dts/imx6q-phytec-pbab01.dts |4
arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi | 18 ++
2 files changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
index 7d37ec6..87c3702 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
+++ b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
@@ -25,6 +25,10 @@
status = okay;
};
+usbotg {
+ status = okay;
+};
+
usdhc2 {
status = okay;
};
diff --git a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
index 1a3b50d..e682bf8 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
+++ b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
@@ -18,6 +18,15 @@
memory {
reg = 0x1000 0x8000;
};
+
+ reg_usb_otg_vbus: regulator@0 {
+ compatible = regulator-fixed;
+ regulator-name = usb_otg_vbus;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = gpio4 15 0;
+ enable-active-low;
+ };
};
ecspi3 {
@@ -134,6 +143,7 @@
MX6QDL_PAD_EIM_D23__GPIO3_IO23 0x8000
MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x8000 /*
SPI NOR chipselect */
MX6QDL_PAD_DI0_PIN15__GPIO4_IO17 0x8000 /*
PMIC interrupt */
+ MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x8000 /*
USB_OTG_PWR_EN */
;
};
};
@@ -162,6 +172,14 @@
status = disabled;
};
+usbotg {
+ vbus-supply = reg_usb_otg_vbus;
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_usbotg_1;
+ disable-over-current;
+ status = disabled;
+};
+
usdhc2 {
pinctrl-names = default;
pinctrl-0 = pinctrl_usdhc2_2;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] usb: host: xhci-plat: Fix build warning when !CONFIG_PM
On Thu, Jan 30, 2014 at 8:29 PM, Fabio Estevam feste...@gmail.com wrote: From: Fabio Estevam fabio.este...@freescale.com Building keystone_defconfig leads to the following build warnings: drivers/usb/host/xhci-plat.c:203:12: warning: 'xhci_plat_suspend' defined but not used [-Wunused-function] drivers/usb/host/xhci-plat.c:211:12: warning: 'xhci_plat_resume' defined but not used [-Wunused-function] Cc: Olof Johansson o...@lixom.net Reported-by: Olof Johansson o...@lixom.net Signed-off-by: Fabio Estevam fabio.este...@freescale.com Acked-by: Olof Johansson o...@lixom.net -- 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] Phytec phyFLEX-i.MX6 : Added USB_HOST Support
This patch adds support for USB_HOST on Phytec phyFLEX-i.MX6 Quad module.
Signed-off-by: Ashutosh singh ashutos...@phytec.in
---
arch/arm/boot/dts/imx6q-phytec-pbab01.dts |4
arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi | 15 +++
2 files changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
index 87c3702..91aecba 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
+++ b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
@@ -25,6 +25,10 @@
status = okay;
};
+usbh1 {
+ status = okay;
+};
+
usbotg {
status = okay;
};
diff --git a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
index e682bf8..fb39dae 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
+++ b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
@@ -27,6 +27,15 @@
gpio = gpio4 15 0;
enable-active-low;
};
+
+ reg_usb_h1_vbus: regulator@1 {
+ compatible = regulator-fixed;
+ regulator-name = usb_h1_vbus;
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ gpio = gpio1 0 0;
+ enable-active-low;
+ };
};
ecspi3 {
@@ -144,6 +153,7 @@
MX6QDL_PAD_DISP0_DAT3__GPIO4_IO24 0x8000 /*
SPI NOR chipselect */
MX6QDL_PAD_DI0_PIN15__GPIO4_IO17 0x8000 /*
PMIC interrupt */
MX6QDL_PAD_KEY_ROW4__GPIO4_IO15 0x8000 /*
USB_OTG_PWR_EN */
+ MX6QDL_PAD_GPIO_0__USB_H1_PWR 0x8000 /*
USB_H1_PWR_EN */
;
};
};
@@ -172,6 +182,11 @@
status = disabled;
};
+usbh1 {
+ vbus-supply = reg_usb_h1_vbus;
+ status = disabled;
+};
+
usbotg {
vbus-supply = reg_usb_otg_vbus;
pinctrl-names = default;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] Phytec phyFLEX-i.MX6 : Added GPMI-NAND Support
This patch adds support for GPMI-NAND on Phytec phyFLEX-i.MX6 Quad module.
Signed-off-by: Ashutosh singh ashutos...@phytec.in
---
arch/arm/boot/dts/imx6q-phytec-pbab01.dts |4
arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi |7 +++
2 files changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
index 91aecba..21c8b37 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
+++ b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
@@ -21,6 +21,10 @@
status = okay;
};
+gpmi {
+ status = okay;
+};
+
uart4 {
status = okay;
};
diff --git a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
index fb39dae..8787101 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
+++ b/arch/arm/boot/dts/imx6q-phytec-pfla02.dtsi
@@ -176,6 +176,13 @@
status = disabled;
};
+gpmi {
+ pinctrl-names = default;
+ pinctrl-0 = pinctrl_gpmi_nand_1;
+ nand-on-flash-bbt;
+ status = disabled;
+};
+
uart4 {
pinctrl-names = default;
pinctrl-0 = pinctrl_uart4_1;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] Phytec phyFLEX-i.MX6 : Added SATA Support
This patch adds support for SATA on Phytec phyFLEX-i.MX6 Quad module.
Signed-off-by: Ashutosh singh ashutos...@phytec.in
---
arch/arm/boot/dts/imx6q-phytec-pbab01.dts |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
index 21c8b37..5607c33 100644
--- a/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
+++ b/arch/arm/boot/dts/imx6q-phytec-pbab01.dts
@@ -25,6 +25,10 @@
status = okay;
};
+sata {
+ status = okay;
+};
+
uart4 {
status = okay;
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: s3c-hsotg: use %pad for dma_addr_t
Use %pad for dma_addr_t to avoid the following build warnings in printks. drivers/usb/gadget/s3c-hsotg.c: In function 's3c_hsotg_start_req' drivers/usb/gadget/s3c-hsotg.c:722:3: warning: format '%x' expects argument of type 'unsigned int' but argument 6 has type 'dma_addr_t' [-Wformat] drivers/usb/gadget/s3c-hsotg.c:792:3: warning: format '%x' expects argument of type 'unsigned int' but argument 5 has type 'dma_addr_t' [-Wformat] Signed-off-by: Jingoo Han jg1@samsung.com --- Compile-tested only. drivers/usb/gadget/s3c-hsotg.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/gadget/s3c-hsotg.c index 1172eae..9ea7f1b 100644 --- a/drivers/usb/gadget/s3c-hsotg.c +++ b/drivers/usb/gadget/s3c-hsotg.c @@ -720,8 +720,8 @@ static void s3c_hsotg_start_req(struct s3c_hsotg *hsotg, ureq-length, ureq-actual); if (0) dev_dbg(hsotg-dev, - REQ buf %p len %d dma 0x%08x noi=%d zp=%d snok=%d\n, - ureq-buf, length, ureq-dma, + REQ buf %p len %d dma 0x%pad noi=%d zp=%d snok=%d\n, + ureq-buf, length, ureq-dma, ureq-no_interrupt, ureq-zero, ureq-short_not_ok); maxreq = get_ep_limit(hs_ep); @@ -789,8 +789,8 @@ static void s3c_hsotg_start_req(struct s3c_hsotg *hsotg, dma_reg = dir_in ? DIEPDMA(index) : DOEPDMA(index); writel(ureq-dma, hsotg-regs + dma_reg); - dev_dbg(hsotg-dev, %s: 0x%08x = 0x%08x\n, - __func__, ureq-dma, dma_reg); + dev_dbg(hsotg-dev, %s: 0x%pad = 0x%08x\n, + __func__, ureq-dma, dma_reg); } ctrl |= DxEPCTL_EPEna; /* ensure ep enabled */ -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: xhci and other woes
Bought a NEC/Renesas pD7020201 based pcie card today. Ok so now I have a really strange problem if I load the r8169 realtek ethernet module before xhci_hcd the Renesas controller gets a timeout on initialization error. If I load the xhci_hcd module before the r8169 module then my onboard ethernet doesn't work. wow. Must be some kind of problem using that pcie slot on this motherboard. Regards, Will Trives On Monday 03 February 2014 23:29:37 renev...@internode.on.net wrote: One last thing. With the VL800, the thing that crashed the system was traffic being transmitted to a client wirelessly over a VPN with an MTU of 1300 I'm not sure if it was ip fragments or something causing the issue or what but everything else was pretty much ok in the end except for this, I could easily crash the whole system within minutes doing this. Regards, Will Trives On Monday 03 February 2014 23:19:09 renev...@internode.on.net wrote: Hello guys, At this point it just looks like I have 2 problems: 1 The AX88179 won't initialize and operate properly when connected via the Asmedia 1042 (at least on my ASUS AMD 990FX based system) this appears to go back to at least kernel version 3.11.0 this issue. Perhaps this is BIOS version related. This is an obvious issue being experienced even by David and others who have reported it on the list. 2 The VIA VL800 is currently problematic under Linux with my system. It's not just an issue with the XHCI driver in Linux as VFIO also can't handle it and throws up a bunch of page faults just booting before the XHCI module is ever loaded, whereas the Asmedia 1042 can be passed through to guests without this issue. Sorry if I went off on the wrong tangents, I plan on grabbing a NEC based controller. Regards, Will Trives -- 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] tools: usb: aio example applications
On 01/30/2014 03:09 PM, Michal Nazarewicz wrote:
On Thu, Jan 30 2014, Robert Baldyga wrote:
diff --git a/tools/usb/aio_multibuff/device_app/aio_multibuff.c
b/tools/usb/aio_multibuff/device_app/aio_multibuff.c
+static void display_event(struct usb_functionfs_event *event)
+{
+static const char *const names[] = {
+[FUNCTIONFS_BIND] = BIND,
+[FUNCTIONFS_UNBIND] = UNBIND,
+[FUNCTIONFS_ENABLE] = ENABLE,
+[FUNCTIONFS_DISABLE] = DISABLE,
+[FUNCTIONFS_SETUP] = SETUP,
+[FUNCTIONFS_SUSPEND] = SUSPEND,
+[FUNCTIONFS_RESUME] = RESUME,
+};
+switch (event-type) {
+case FUNCTIONFS_BIND:
+case FUNCTIONFS_UNBIND:
+case FUNCTIONFS_ENABLE:
+case FUNCTIONFS_DISABLE:
+case FUNCTIONFS_SETUP:
+case FUNCTIONFS_SUSPEND:
+case FUNCTIONFS_RESUME:
+printf(Event %s\n, names[event-type]);
+default:
+break;
The default case serves no purpose here.
+}
+}
+struct io_buffer {
+struct iocb **iocb;
I'm wondering whether it would be easier to just declare it as:
+ struct iocb **iocb;
and then allocate the structures as a single flat array rather than
array of pointers to the structures. I can see why you might prefer not
to do that with “buf”, but struct iocb should not be that big, and
having one indirection less should simplify the code.
It looks like AIO API needs this. Last parameter of io_submit is struct
iocb **, and it expects it will be pointer to array of pointers to
struct iocb.
+unsigned char **buf;
+int cnt;
+int len;
Make those unsigned. Add:
+ unsigned requested;
+};
+
+void init_bufs(struct io_buffer *iobuf, int n, int len)
Make those unsigned.
+{
+int i;
unsigned
+iobuf-buf = malloc(n*sizeof(*iobuf-buf));
+iobuf-iocb = malloc(n*sizeof(*iobuf-iocb));
+iobuf-cnt = n;
+iobuf-len = len;
+for (i = 0; i n; ++i) {
+iobuf-buf[i] = malloc(len*sizeof(**iobuf-buf));
+iobuf-iocb[i] = malloc(sizeof(**iobuf-iocb));
+}
+ iobuf-requested = 0;
+}
+
+void delete_bufs(struct io_buffer *iobuf)
+{
+int i;
+for (i = 0; i iobuf-cnt; ++i) {
+free(iobuf-buf[i]);
+free(iobuf-iocb[i]);
+}
+free(iobuf-buf);
+free(iobuf-iocb);
+}
+
+#define BUF_LEN 8192
+#define BUFS_MAX128
+#define AIO_MAX (BUFS_MAX*2)
+
+int main(int argc, char *argv[])
+{
+int i, ret;
+char *ep_path;
+
+int ep0, ep1;
+
+io_context_t ctx;
+
+struct io_buffer iobuf1, iobuf2;
+ struct io_buffer iobuf[2];
But to be honest, why are there two of those anyway? Each have a bunch
of buffers so why multiply number of buffers even more?
It can be useful for multibuffering, when you need to use huge buffers
(for example when you want to send video data). Then you need to split
your buffer into many small buffers of size up to endpoint maxpacket
value (it does not apply to bulk transfers, but it's necessary when you
use isochronous mode). So this example shows how to do it.
+int requested1 = 0, requested2 = 0;
+int actual;
+bool ready;
+
+if (argc != 2) {
+printf(ffs directory not specified!\n);
+return 1;
+}
+
+ep_path = malloc(strlen(argv[1]) + 4 /* /ep# */ + 1 /* '\0' */);
+if (!ep_path) {
+perror(malloc);
+return 1;
+}
+
+/* open endpoint files */
+sprintf(ep_path, %s/ep0, argv[1]);
+ep0 = open(ep_path, O_RDWR);
+if (ep0 0) {
+perror(unable to open ep0);
+return 1;
+}
+if (write(ep0, descriptors, sizeof(descriptors)) 0) {
+perror(unable do write descriptors);
+return 1;
+}
+if (write(ep0, strings, sizeof(strings)) 0) {
+perror(unable to write strings);
+return 1;
+}
+sprintf(ep_path, %s/ep1, argv[1]);
+ep1 = open(ep_path, O_RDWR);
+if (ep1 0) {
+perror(unable to open ep1);
+return 1;
+}
+
+free(ep_path);
+
+memset(ctx, 0, sizeof(ctx));
+/* setup aio context to handle up to AIO_MAX requests */
+if (io_setup(AIO_MAX, ctx) 0) {
+perror(unable to setup aio);
+return 1;
+}
+
+init_bufs(iobuf1, BUFS_MAX, BUF_LEN);
+init_bufs(iobuf2, BUFS_MAX, BUF_LEN);
+ for (i = 0; i sizeof iobuf / sizeof *iobuf; ++i)
+ init_bufs(iobuf + i, BUFS_MAX, BUF_LEN);
+
+while (1) {
+handle_ep0(ep0, ready);
+/* we are waiting for function ENABLE */
+if (!ready)
+continue;
+/*
+ * when we're preparing new data to submit,
+ * second buffer being transmitted
+ */
+if (!requested1) { /* if
