[PATCH net] r8152: drop the tx packet with invalid length
Drop the tx packet which is more than the size of agg_buf_sz. When
creating a bridge with the device, we may get the tx packet with
TSO and the length is more than the gso_max_size which is set by
the driver through netif_set_gso_max_size(). Such packets couldn't
be transmitted and should be dropped directly.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index c6554c7..ebdaff7 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1897,6 +1897,15 @@ static netdev_tx_t rtl8152_start_xmit(struct sk_buff
*skb,
{
struct r8152 *tp = netdev_priv(netdev);
+ if ((skb-len + sizeof(struct tx_desc)) agg_buf_sz) {
+ struct net_device_stats *stats = netdev-stats;
+
+ dev_kfree_skb_any(skb);
+ stats-tx_dropped++;
+ WARN_ON_ONCE(1);
+ return NETDEV_TX_OK;
+ }
+
skb_tx_timestamp(skb);
skb_queue_tail(tp-tx_queue, skb);
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: zero: fix INT endpoint assignment
Dear Sebastian,
On 11/25/2014 10:52 PM, Sebastian Andrzej Siewior wrote:
The max packet size within the FS descriptor has to be highest possible
value and _not_ the one that is (or will be) used on FS.
The current code sets wMaxPacketSize of FS interrupt endpoint descriptor
as 64, which is in accordance with the usb 2.0 specification, section 5.7.3
The maximum allowable interrupt data payload size is 64 bytes
or less for full-speed. High-speed endpoints are allowed
maximum data payload sizes up to 1024 bytes.
The way the code works (since day 1) is that usb_ep_autoconfig() is
invoked _only_ on the FS endpoint and then the endpoint address is
copies over to HS/SS endpoints. If the any of the critical options are
different between FS and HS then we have to pass the HS value and
correct later.
What now happens is that we look for an INT-OUT endpoint of 64bytes. The
code will return an endpoint matching this category. Further the
sourcesink will take this endpoint and increase the MPS to 1024. On
This is valid only for HS and SS interrupt endpoints. Right?
net2280 for instance the code tries to be clever to return an endpoint
which can only do 64 MPS. The same happens on musb where we mostlike get
an endpoint which can only do 512. The result is then on the host side:
What is the speed at which your device is operating?
|~# testusb -a -t 9 -c 2
|unknown speed /dev/bus/usb/002/0450
|usbtest 2-1:3.0: TEST 9: ch9 (subset) control tests, 2 times
|usbtest 2-1:3.0: can't set_interface = 2, -32
|usbtest 2-1:3.0: ch9 subset failed, iterations left 1
|/dev/bus/usb/002/045 test 9 -- 32 (Broken pipe)
because the on the gadget side we can't enable the endpoint because
desc-size ep-max_size.
Fixes: ef11982dd7a6 (usb: gadget: zero: Add support for interrupt EP)
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/usb/gadget/function/f_sourcesink.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/gadget/function/f_sourcesink.c
b/drivers/usb/gadget/function/f_sourcesink.c
index 80be25b32cd7..7d8f0216e1a6 100644
--- a/drivers/usb/gadget/function/f_sourcesink.c
+++ b/drivers/usb/gadget/function/f_sourcesink.c
@@ -161,7 +161,7 @@ static struct usb_endpoint_descriptor fs_int_source_desc = {
.bEndpointAddress = USB_DIR_IN,
.bmAttributes = USB_ENDPOINT_XFER_INT,
- .wMaxPacketSize = cpu_to_le16(64),
+ .wMaxPacketSize = cpu_to_le16(1024),
.bInterval =GZERO_INT_INTERVAL,
};
@@ -171,7 +171,7 @@ static struct usb_endpoint_descriptor fs_int_sink_desc = {
.bEndpointAddress = USB_DIR_OUT,
.bmAttributes = USB_ENDPOINT_XFER_INT,
- .wMaxPacketSize = cpu_to_le16(64),
+ .wMaxPacketSize = cpu_to_le16(1024),
.bInterval =GZERO_INT_INTERVAL,
};
This change in wMAxPacketSize of FS interrupt descriptors is violation
of the specs.
@@ -556,16 +556,6 @@ sourcesink_bind(struct usb_configuration *c, struct
usb_function *f)
if (int_maxburst 15)
int_maxburst = 15;
- /* fill in the FS interrupt descriptors from the module parameters */
- fs_int_source_desc.wMaxPacketSize = int_maxpacket 64 ?
- 64 : int_maxpacket;
- fs_int_source_desc.bInterval = int_interval 255 ?
- 255 : int_interval;
- fs_int_sink_desc.wMaxPacketSize = int_maxpacket 64 ?
- 64 : int_maxpacket;
- fs_int_sink_desc.bInterval = int_interval 255 ?
- 255 : int_interval;
-
/* allocate int endpoints */
ss-int_in_ep = usb_ep_autoconfig(cdev-gadget, fs_int_source_desc);
if (!ss-int_in_ep)
@@ -587,6 +577,16 @@ sourcesink_bind(struct usb_configuration *c, struct
usb_function *f)
if (int_maxpacket 1024)
int_maxpacket = 1024;
+ /* fill in the FS interrupt descriptors from the module parameters */
+ fs_int_source_desc.wMaxPacketSize = int_maxpacket 64 ?
+ 64 : int_maxpacket;
+ fs_int_source_desc.bInterval = int_interval 255 ?
+ 255 : int_interval;
+ fs_int_sink_desc.wMaxPacketSize = int_maxpacket 64 ?
+ 64 : int_maxpacket;
+ fs_int_sink_desc.bInterval = int_interval 255 ?
+ 255 : int_interval;
+
/* support high speed hardware */
hs_source_desc.bEndpointAddress = fs_source_desc.bEndpointAddress;
hs_sink_desc.bEndpointAddress = fs_sink_desc.bEndpointAddress;
Things might be working for you but this is not the correct fix, IMO.
Looking into the patch I feel it shall introduce other
Re: [PATCH] usb: gadget: zero: fix INT endpoint assignment
Dear Sebastian, On 11/25/2014 10:56 PM, Sebastian Andrzej Siewior wrote: This fixes the test case mentioned for musb which is a regression. Other things that I noticed: - if ISOC is not available, we won't have INT as well. I didn't understand this. The original patch added a new alternate setting (2) that has two interrupt endpoints. ISOC EP is available through alternate setting 1. - wMaxPacketSize is supposed to be LE. The assignments within the code does not use cpu_to_le16(). Can you please point to the code where it should have been and is missing? - the module Parameter for INT says max packet size is 0…1023 for FS. Yes, I'll send a patch to rectify this. This is clearly a copy/paste bug. Amit could you please look at this and fix it? Sebastian Regards Amit Virdi -- 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] arm64: exynos: Add bus1 pinctrl node on exynos7
Hi Vivek,
On Mon, Nov 24, 2014 at 6:36 PM, Vivek Gautam gautam.vi...@samsung.com wrote:
BUS1 pinctrl provides gpios for usb and power regulator
available on exynos7-espresso board. So add relevant device
node for pinctrl-bus1.
Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
Looks good to me.
Reviewed-by: Alim Akhtar alim.akh...@samsung.com
This patch was part of series:
[PATCH 00/11] Exynos7: Adding USB 3.0 support
https://lkml.org/lkml/2014/11/21/247
Changes since V1:
- Added support for all pin banks which are part of BUS1 pin controller.
arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi | 82
+++
arch/arm64/boot/dts/exynos/exynos7.dtsi |7 ++
2 files changed, 89 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
index 2eef4a2..c367f0a 100644
--- a/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7-pinctrl.dtsi
@@ -335,6 +335,88 @@
};
};
+pinctrl_bus1 {
+ gpf0: gpf0 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpf1: gpf1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpf2: gpf2 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpf3: gpf3 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpf4: gpf4 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpf5: gpf5 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpg1: gpg1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpg2: gpg2 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gph1: gph1 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+
+ gpv6: gpv6 {
+ gpio-controller;
+ #gpio-cells = 2;
+
+ interrupt-controller;
+ #interrupt-cells = 2;
+ };
+};
+
pinctrl_nfc {
gpj0: gpj0 {
gpio-controller;
diff --git a/arch/arm64/boot/dts/exynos/exynos7.dtsi
b/arch/arm64/boot/dts/exynos/exynos7.dtsi
index 1d9e4c9..e633b02 100644
--- a/arch/arm64/boot/dts/exynos/exynos7.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos7.dtsi
@@ -26,6 +26,7 @@
pinctrl5 = pinctrl_ese;
pinctrl6 = pinctrl_fsys0;
pinctrl7 = pinctrl_fsys1;
+ pinctrl8 = pinctrl_bus1;
};
cpus {
@@ -242,6 +243,12 @@
interrupts = 0 383 0;
};
+ pinctrl_bus1: pinctrl@1487 {
+ compatible = samsung,exynos7-pinctrl;
+ reg = 0x1487 0x1000;
+ interrupts = 0 384 0;
+ };
+
pinctrl_nfc: pinctrl@14cd {
compatible = samsung,exynos7-pinctrl;
reg = 0x14cd 0x1000;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Regards,
Alim
--
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 1/2] pinctrl: exynos: Add BUS1 pin controller for exynos7
Hi Vivek,
On Mon, Nov 24, 2014 at 6:32 PM, Vivek Gautam gautam.vi...@samsung.com wrote:
USB and Power regulator on Exynos7 require gpios available
in BUS1 pin controller block.
So adding the BUS1 pinctrl support.
Signed-off-by: Naveen Krishna Ch naveenkrishna...@gmail.com
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
Cc: Linus Walleij linus.wall...@linaro.org
---
Looks good to me.
Thanks!
Reviewed-by: Alim Akhtar alim.akh...@samsung.com
This patch was part of series:
[PATCH 00/11] Exynos7: Adding USB 3.0 support
https://lkml.org/lkml/2014/11/21/247
Changes since V1:
- Added support for all pin banks which are part of BUS1 pin controller.
drivers/pinctrl/samsung/pinctrl-exynos.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index d5d4cfc..44e60dc 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -1300,6 +1300,20 @@ static const struct samsung_pin_bank_data
exynos7_pin_banks7[] __initconst = {
EXYNOS_PIN_BANK_EINTG(8, 0x060, gpr3, 0x0c),
};
+/* pin banks of exynos7 pin-controller - BUS1 */
+static const struct samsung_pin_bank_data exynos7_pin_banks8[] __initconst =
{
+ EXYNOS_PIN_BANK_EINTG(8, 0x020, gpf0, 0x00),
+ EXYNOS_PIN_BANK_EINTG(8, 0x040, gpf1, 0x04),
+ EXYNOS_PIN_BANK_EINTG(4, 0x060, gpf2, 0x08),
+ EXYNOS_PIN_BANK_EINTG(5, 0x080, gpf3, 0x0c),
+ EXYNOS_PIN_BANK_EINTG(8, 0x0a0, gpf4, 0x10),
+ EXYNOS_PIN_BANK_EINTG(8, 0x0c0, gpf5, 0x14),
+ EXYNOS_PIN_BANK_EINTG(5, 0x0e0, gpg1, 0x18),
+ EXYNOS_PIN_BANK_EINTG(5, 0x100, gpg2, 0x1c),
+ EXYNOS_PIN_BANK_EINTG(6, 0x120, gph1, 0x20),
+ EXYNOS_PIN_BANK_EINTG(3, 0x140, gpv6, 0x24),
+};
+
const struct samsung_pin_ctrl exynos7_pin_ctrl[] __initconst = {
{
/* pin-controller instance 0 Alive data */
@@ -1342,5 +1356,10 @@ const struct samsung_pin_ctrl exynos7_pin_ctrl[]
__initconst = {
.pin_banks = exynos7_pin_banks7,
.nr_banks = ARRAY_SIZE(exynos7_pin_banks7),
.eint_gpio_init = exynos_eint_gpio_init,
+ }, {
+ /* pin-controller instance 8 BUS1 data */
+ .pin_banks = exynos7_pin_banks8,
+ .nr_banks = ARRAY_SIZE(exynos7_pin_banks8),
+ .eint_gpio_init = exynos_eint_gpio_init,
},
};
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Regards,
Alim
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb: musb: blackfin: fix build break
commit cc92f681 (usb: musb: Populate new IO
functions for blackfin) added a typo which
prevented MUSB's blackfin glue layer from being
built. Due to lack of tests and compilers for
that architecture, the typo ended up being
merged and causing a build regression.
Fix that here
Cc: Tony Lindgren t...@atomide.com
Reported-by: Fengguang Wu fengguang...@intel.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/musb/blackfin.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index a441a2d..1782501 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -63,7 +63,7 @@ static void bfin_writew(void __iomem *addr, unsigned offset,
u16 data)
bfin_write16(addr + offset, data);
}
-static void binf_writel(void __iomem *addr, unsigned offset, u32 data)
+static void bfin_writel(void __iomem *addr, unsigned offset, u32 data)
{
bfin_write16(addr + offset, (u16)data);
}
--
2.1.0.GIT
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] usb: musb: build fixes
Hi, Here are two build fixes for recent breaks which can be triggered when building MUSB for Blackfin. I don't have any blackfin platform nor a cross compiler for that architecture, so these breaks were merged without me noticing. Greg, if you want to merge these two as patches, please go ahead. I can also create another pull request for you, whatever works. Steven, can you help build testing these ? Felipe Balbi (2): usb: musb: debugfs: cope with blackfin's oddities usb: musb: blackfin: fix build break drivers/usb/musb/blackfin.c | 2 +- drivers/usb/musb/musb_debugfs.c | 18 ++ 2 files changed, 11 insertions(+), 9 deletions(-) -- 2.1.0.GIT -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] usb: musb: debugfs: cope with blackfin's oddities
Blackfin's MUSB implementation lacks a bunch of
registers which they end up not defining a macro
for. In order to avoid build breaks, let's ifdef
out some of the registers from our regdump debugfs
utility so that we don't try to use those on
Blackfin builds.
Reported-by: Fengguang Wu fengguang...@intel.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/musb/musb_debugfs.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index ad3701a..54e8cde 100644
--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -59,20 +59,12 @@ static const struct musb_register_map musb_regmap[] = {
{ RxMaxPp,MUSB_RXMAXP,16 },
{ RxCSR, MUSB_RXCSR, 16 },
{ RxCount,MUSB_RXCOUNT, 16 },
- { ConfigData, MUSB_CONFIGDATA,8 },
{ IntrRxE,MUSB_INTRRXE, 16 },
{ IntrTxE,MUSB_INTRTXE, 16 },
{ IntrUsbE, MUSB_INTRUSBE, 8 },
{ DevCtl, MUSB_DEVCTL,8 },
- { BabbleCtl, MUSB_BABBLE_CTL,8 },
- { TxFIFOsz, MUSB_TXFIFOSZ, 8 },
- { RxFIFOsz, MUSB_RXFIFOSZ, 8 },
- { TxFIFOadd, MUSB_TXFIFOADD, 16 },
- { RxFIFOadd, MUSB_RXFIFOADD, 16 },
{ VControl, 0x68, 32 },
{ HWVers, 0x69, 16 },
- { EPInfo, MUSB_EPINFO,8 },
- { RAMInfo,MUSB_RAMINFO, 8 },
{ LinkInfo, MUSB_LINKINFO, 8 },
{ VPLen, MUSB_VPLEN, 8 },
{ HS_EOF1,MUSB_HS_EOF1, 8 },
@@ -103,6 +95,16 @@ static const struct musb_register_map musb_regmap[] = {
{ DMA_CNTLch7,0x274, 16 },
{ DMA_ADDRch7,0x278, 32 },
{ DMA_COUNTch7, 0x27C, 32 },
+#ifndef CONFIG_BLACKFIN
+ { ConfigData, MUSB_CONFIGDATA,8 },
+ { BabbleCtl, MUSB_BABBLE_CTL,8 },
+ { TxFIFOsz, MUSB_TXFIFOSZ, 8 },
+ { RxFIFOsz, MUSB_RXFIFOSZ, 8 },
+ { TxFIFOadd, MUSB_TXFIFOADD, 16 },
+ { RxFIFOadd, MUSB_RXFIFOADD, 16 },
+ { EPInfo, MUSB_EPINFO,8 },
+ { RAMInfo,MUSB_RAMINFO, 8 },
+#endif
{ }/* Terminating Entry */
};
--
2.1.0.GIT
--
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: adutux: NULL dereferences on disconnect
Both dev-udev and interface-dev are NULL. These printks are not
very interesting so I just deleted them.
Fixes: 03270634e242 ('USB: Add ADU support for Ontrak ADU devices')
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/usb/misc/adutux.c b/drivers/usb/misc/adutux.c
index 493c7f2..3071c0e 100644
--- a/drivers/usb/misc/adutux.c
+++ b/drivers/usb/misc/adutux.c
@@ -814,15 +814,10 @@ static void adu_disconnect(struct usb_interface
*interface)
usb_set_intfdata(interface, NULL);
/* if the device is not opened, then we clean up right now */
- dev_dbg(dev-udev-dev, %s : open count %d\n,
- __func__, dev-open_count);
if (!dev-open_count)
adu_delete(dev);
mutex_unlock(adutux_mutex);
-
- dev_info(interface-dev, ADU device adutux%d now disconnected\n,
-(minor - ADU_MINOR_BASE));
}
/* usb specific object needed to register this driver with the usb subsystem */
--
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 9/9] usb: {ohci,ehci}-platform: Use new OF big-endian helper function
On Tue, 25 Nov 2014, Kevin Cernekee wrote: This handles the existing big-endian case, and in addition, it also does the right thing when native-endian is specified. Signed-off-by: Kevin Cernekee cerne...@gmail.com --- Documentation/devicetree/bindings/usb/usb-ehci.txt | 2 ++ Documentation/devicetree/bindings/usb/usb-ohci.txt | 2 ++ drivers/usb/host/ehci-platform.c | 2 +- drivers/usb/host/ohci-platform.c | 2 +- 4 files changed, 6 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt b/Documentation/devicetree/bindings/usb/usb-ehci.txt index 43c1a4e..9505c31 100644 --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt @@ -12,6 +12,8 @@ Optional properties: - big-endian-regs : boolean, set this for hcds with big-endian registers - big-endian-desc : boolean, set this for hcds with big-endian descriptors - big-endian : boolean, for hcds with big-endian-regs + big-endian-desc + - native-endian : boolean, enables big-endian-regs + big-endian-desc + iff the kernel was compiled for big endian Is this really a property of the hardware? It appears to depend on the kernel configuration. As such, is it appropriate for DT? 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 storage device cause usb bus can't enter runtime suspend
On Wed, 26 Nov 2014, tianjulin wrote: Hi Stern, Many Thanks!!! You're welcome. I use command as follows,the usb bus can enter runtime suspend when I connect usb storage,and if have operate on usb storage,the usb bus can be resume,if have not any operate on usb storage,the usb bus can enter runtime suspend. echo auto /sys/bus/usb/devices/1-1/power/control auto echo auto /sys/bus/usb/devices/1-1:1.0/host0/target0:0:0/0:0:0:0/power/control auto echo 1000 /sys/bus/usb/devices/1-1:1.0/host0/target0:0:0/0:0:0:0/power/autosuspend_delay_ms 100 But how to modify source code to implement this feature?can you provide some help? If you want to enable runtime suspend automatically, you can write a udev script to do it (assuming your platform uses udev). 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: gadget: zero: fix INT endpoint assignment
On Wed, 26 Nov 2014, Amit Virdi wrote: Dear Sebastian, On 11/25/2014 10:52 PM, Sebastian Andrzej Siewior wrote: The max packet size within the FS descriptor has to be highest possible value and _not_ the one that is (or will be) used on FS. The current code sets wMaxPacketSize of FS interrupt endpoint descriptor as 64, which is in accordance with the usb 2.0 specification, section 5.7.3 The maximum allowable interrupt data payload size is 64 bytes or less for full-speed. High-speed endpoints are allowed maximum data payload sizes up to 1024 bytes. The real problem is that we are assuming endpoints can be allocated in a single way that will work correctly for all possible connection speeds. (I suspect it was done this way out of laziness and a desire to minimize the code size.) This assumption is obviously incorrect when the hardware has an interrupt endpoint that supports packet sizes of 64 but no larger. The right way to fix the problem is to avoid allocating endpoints until after the connection speed is known. Then we can call usb_ep_autoconfig() with the appropriate set of descriptors, and nothing will need to be fixed up. However, I don't know if this approach is compatible with the composite framework in its current form. 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 9/9] usb: {ohci,ehci}-platform: Use new OF big-endian helper function
On Wed, Nov 26, 2014 at 7:14 AM, Alan Stern st...@rowland.harvard.edu wrote: diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt b/Documentation/devicetree/bindings/usb/usb-ehci.txt index 43c1a4e..9505c31 100644 --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt @@ -12,6 +12,8 @@ Optional properties: - big-endian-regs : boolean, set this for hcds with big-endian registers - big-endian-desc : boolean, set this for hcds with big-endian descriptors - big-endian : boolean, for hcds with big-endian-regs + big-endian-desc + - native-endian : boolean, enables big-endian-regs + big-endian-desc + iff the kernel was compiled for big endian Is this really a property of the hardware? It appears to depend on the kernel configuration. As such, is it appropriate for DT? Yes, the peripheral registers automatically adjust their endianness to match the CPU. So if the CPU is running an LE kernel, the peripheral needs to be accessed in LE mode; if the CPU is running a BE kernel, the peripheral needs to be accessed in BE mode. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] usb: musb: blackfin: fix build break
* Felipe Balbi ba...@ti.com [141126 06:03]:
commit cc92f681 (usb: musb: Populate new IO
functions for blackfin) added a typo which
prevented MUSB's blackfin glue layer from being
built. Due to lack of tests and compilers for
that architecture, the typo ended up being
merged and causing a build regression.
Fix that here
Oops sorry about the typo. I did not have blackin compilers here
either.
Regards,
Tony
Cc: Tony Lindgren t...@atomide.com
Reported-by: Fengguang Wu fengguang...@intel.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/musb/blackfin.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/musb/blackfin.c b/drivers/usb/musb/blackfin.c
index a441a2d..1782501 100644
--- a/drivers/usb/musb/blackfin.c
+++ b/drivers/usb/musb/blackfin.c
@@ -63,7 +63,7 @@ static void bfin_writew(void __iomem *addr, unsigned
offset, u16 data)
bfin_write16(addr + offset, data);
}
-static void binf_writel(void __iomem *addr, unsigned offset, u32 data)
+static void bfin_writel(void __iomem *addr, unsigned offset, u32 data)
{
bfin_write16(addr + offset, (u16)data);
}
--
2.1.0.GIT
--
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 9/9] usb: {ohci,ehci}-platform: Use new OF big-endian helper function
On Wed, 26 Nov 2014, Kevin Cernekee wrote: On Wed, Nov 26, 2014 at 7:14 AM, Alan Stern st...@rowland.harvard.edu wrote: diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt b/Documentation/devicetree/bindings/usb/usb-ehci.txt index 43c1a4e..9505c31 100644 --- a/Documentation/devicetree/bindings/usb/usb-ehci.txt +++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt @@ -12,6 +12,8 @@ Optional properties: - big-endian-regs : boolean, set this for hcds with big-endian registers - big-endian-desc : boolean, set this for hcds with big-endian descriptors - big-endian : boolean, for hcds with big-endian-regs + big-endian-desc + - native-endian : boolean, enables big-endian-regs + big-endian-desc + iff the kernel was compiled for big endian Is this really a property of the hardware? It appears to depend on the kernel configuration. As such, is it appropriate for DT? Yes, the peripheral registers automatically adjust their endianness to match the CPU. So if the CPU is running an LE kernel, the peripheral needs to be accessed in LE mode; if the CPU is running a BE kernel, the peripheral needs to be accessed in BE mode. Okay, then: Acked-by: Alan Stern st...@rowland.harvard.edu But you might want to update the description slightly to say: - native-endian : boolean, enables big-endian-regs + big-endian-desc iff the CPU is running in big-endian mode It's a very minor distinction, since you can't run a kernel that was compiled for little endian if the CPU is running in big-endian mode, but this makes it clear that you're talking about the hardware rather than the software. 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 net] r8152: drop the tx packet with invalid length
On Wed, 2014-11-26 at 17:56 +0800, Hayes Wang wrote:
Drop the tx packet which is more than the size of agg_buf_sz. When
creating a bridge with the device, we may get the tx packet with
TSO and the length is more than the gso_max_size which is set by
the driver through netif_set_gso_max_size(). Such packets couldn't
be transmitted and should be dropped directly.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index c6554c7..ebdaff7 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1897,6 +1897,15 @@ static netdev_tx_t rtl8152_start_xmit(struct sk_buff
*skb,
{
struct r8152 *tp = netdev_priv(netdev);
+ if ((skb-len + sizeof(struct tx_desc)) agg_buf_sz) {
+ struct net_device_stats *stats = netdev-stats;
+
+ dev_kfree_skb_any(skb);
+ stats-tx_dropped++;
+ WARN_ON_ONCE(1);
+ return NETDEV_TX_OK;
+ }
+
skb_tx_timestamp(skb);
skb_queue_tail(tp-tx_queue, skb);
Looks like a candidate for ndo_gso_check(), so that we do not drop, but
instead segment from netif_needs_gso()/validate_xmit_skb()
--
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 net] r8152: drop the tx packet with invalid length
From: Eric Dumazet eric.duma...@gmail.com Date: Wed, 26 Nov 2014 08:52:28 -0800 On Wed, 2014-11-26 at 17:56 +0800, Hayes Wang wrote: Drop the tx packet which is more than the size of agg_buf_sz. When creating a bridge with the device, we may get the tx packet with TSO and the length is more than the gso_max_size which is set by the driver through netif_set_gso_max_size(). Such packets couldn't be transmitted and should be dropped directly. Signed-off-by: Hayes Wang hayesw...@realtek.com ... Looks like a candidate for ndo_gso_check(), so that we do not drop, but instead segment from netif_needs_gso()/validate_xmit_skb() You mean have the bridge implement the ndo_gso_check() method right? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] USB-serial updates for v3.19
Hi Greg, Here's my pull-request for v3.19-rc1. All have been in linux-next for a while. Thanks, Johan The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1: Linux 3.18-rc1 (2014-10-19 18:08:38 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git tags/usb-serial-3.19-rc1 for you to fetch changes up to e7181d005e84b15fe3121a8d22840adc3395d496: USB: qcserial: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem (2014-11-19 16:17:03 +0100) USB-serial updates for v3.19-rc1 These changes add a new simple driver for Google USB-serial devices and add support for Huawei Gobi modems to qcserial. Included are also some removals of unnecessary atomic allocations and a few spelling fixes. Signed-off-by: Johan Hovold jo...@kernel.org Anton Staaf (1): USB: serial: add Google simple serial SubClass support Johan Hovold (3): USB: kobil_sct: replace unnecessary atomic allocation USB: mos7720: replace unnecessary atomic allocations USB: mos7840: replace unnecessary atomic allocations Mark Knibbs (1): USB: serial: keyspan_pda: fix Entrega company name spelling Martin Hauke (1): USB: qcserial: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem Documentation/usb/usb-serial.txt | 2 +- drivers/usb/serial/Kconfig | 5 +++-- drivers/usb/serial/keyspan_pda.c | 16 drivers/usb/serial/kobil_sct.c | 2 +- drivers/usb/serial/mos7720.c | 4 ++-- drivers/usb/serial/mos7840.c | 4 ++-- drivers/usb/serial/qcserial.c | 33 + drivers/usb/serial/usb-serial-simple.c | 10 ++ 8 files changed, 60 insertions(+), 16 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: zero: fix INT endpoint assignment
On 11/26/2014 02:21 PM, Amit Virdi wrote:
- if ISOC is not available, we won't have INT as well.
I didn't understand this. The original patch added a new alternate
setting (2) that has two interrupt endpoints. ISOC EP is available
through alternate setting 1.
The ISOC code does this:
no_iso:
/*
* We still want to work even if the UDC doesn't have isoc
* endpoints, so null out the alt interface that contains
* them and continue.
*/
fs_source_sink_descs[FS_ALT_IFC_1_OFFSET] = NULL;
hs_source_sink_descs[HS_ALT_IFC_1_OFFSET] = NULL;
ss_source_sink_descs[SS_ALT_IFC_1_OFFSET] = NULL;
That means the descriptor is terminated early:
static struct usb_descriptor_header *fs_source_sink_descs[] = {
(struct usb_descriptor_header *) source_sink_intf_alt0,
(struct usb_descriptor_header *) fs_sink_desc,
(struct usb_descriptor_header *) fs_source_desc,
= (struct usb_descriptor_header *) source_sink_intf_alt1,
#define FS_ALT_IFC_1_OFFSET 3
That means no ISOC will NULL the fourth descriptor and there is no
alt1 including your alt2. Those descs won't be passed to the host. It
was okay while it was ISOC only but now disabling ISOC means no INT
either.
- wMaxPacketSize is supposed to be LE. The assignments within the code
does not use cpu_to_le16().
Can you please point to the code where it should have been and is missing?
You look for each assignment to wMaxPacketSize and you will notice that
the cpu_to_le16 isn't used:
/* fill in the FS isoc descriptors from the module parameters */
fs_iso_source_desc.wMaxPacketSize = isoc_maxpacket 1023 ?
1023 : isoc_maxpacket;
this one example, the very same is true for your copy/pasted INT
handling.
Regards
Amit Virdi
Sebastian
--
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: ath9k - bogus usb xfer on at91
Am 26.11.2014 um 01:28 schrieb David Lechner: On 7 July 2014 17:08, Oleksij Rempel linux@ wrote: / Am 07.07.2014 15:40, schrieb Anders Darander:/ / On 4 July 2014 18:54, Oleksij Rempel linux@ wrote:/ / Am 04.07.2014 18:30, schrieb Alan Stern:/ / On Fri, 4 Jul 2014, Anders Darander wrote:/ / ~# usb 1-1: new full-speed USB device number 3 using at91_ohci/ / usb 1-1: ath9k_htc: Firmware htc_9271.fw requested/ / usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272/ / ---[ cut here ]---/ / WARNING: CPU: 0 PID: 93 at/ / /mnt/cs-builds/anders/oe-build/build-ccu/tmp-eglibc/work/ccu-oe-linux-gnueabi/linux-yocto-ccu/3.14+gitAUTOINC+7b03bd3dfd-r0/linux/drivers/usb/core/urb.c:450/ / usb_submit_urb+0x2ac/0x460()/ / usb 1-1: BOGUS urb xfer, pipe 1 != type 3/ // // / I can't tell exactly where the fault is, but this message means that an/ / URB was submitted for a bulk endpoint with a pipe of type/ / PIPE_INTERRUPT./ // / Then kernel driver and firmware should be updated. There was some/ / Bulk/Interrupt issues which was fixed last year./ // / Any pointers to the bulk/interrupt issues? Was it a general issue, or/ / related either to/ / at91-ohci or ar9271?/ / It is primary ar9271 issue. The interrupt EP has different response time/ / on different host controllers. Initially as workaround ath9k was forcing/ / Bulk traffic on Interrupt EP. But this workaround is working with some/ / host controllers and completely fails on others. So i removed it. The/ / patches are included in master kernel branch and git firmware source./ Thanks for the comments! I'll take a look at it, though it might have to be scheduled after the upcoming vacations... I'll sure try to look into those workarounds (and your removal of those). I guess that it's the firmware in open-ath9-htc-firmware you're talking about. // / As far as I've been able to find out, I've got the latest firmware/ / (check again with linux-firmware)./ / I've also tried with the master from open-ath9k-htc-firmware./ // / I hope this HW will not be used as AP./ // / Is this based on the use of at91- SoC, or based on the ar9271?/ / ar9271 can work as AP with limit on 8 stations but according to user/ / reports it fails even with one station on at91/ / The primary use case is to run as a client, though there will likely/ / be some instances where it'll/ / function as a AP. (Though primarily for M2M communications), thus/ / pretty low traffic./ / For AP usually should be created monitor mode interface for receiving/ / and transmitting management frames. Depending on location and STAs or/ / APs working on same channel, you will get a lot of traffic on this usb/ / interface./ / Some users reported huge traffic drops on at91 based APs. Since i can't/ / debug it, i can't promise that it will be fixed any time soon./ Again, thanks for the information. I think I've got a much better understanding of the issues (both those that I've seen, and those that you have mentioned / explained). I'll see when/what I can look into this and what I can find out. Cheers, Anders Anders, did you ever have a chance to look at this? I am seeing this same warning that is filling up the kernel logs in v3.18-rc6. The device I am using is: |ID 0846:9030 NetGear, Inc. WNA1100 Wireless-N 150 [Atheros AR9271]|| I found that if I revert kernel commit 2b72111 that the warning stops, but the device does not work very well.||If you are interested to know more about the symptoms we are seeing, there is a bug report here: https://github.com/ev3dev/ev3dev/issues/152. But, I figured at least knowing the kernel commit that introduced the problem would be helpful.| i assume you mean this: commit 2b721118b7821107757eb1d37af4b60e877b27e7 Author: Oleksij Rempel li...@rempel-privat.de Date: Tue Aug 13 21:10:19 2013 +0200 ath9k_htc: do not use bulk on EP3 and EP4 If usb auto suspend is enabled or system run in to suspend/resume cycle, ath9k-htc adapter will stop to response. It is reproducible on xhci H Host part of problem: XHCI do timing calculation based on Transfer Type and bInterval, immediately after device was detected. Ath9k-htc try to overwrite this parameters on module probe and some changes in FW, since we do not initiate usb reset from the driver this changes are not took to account. So, before any kind of suspend or reset, host controller will operate with old parameters. Only after suspend/resume and if interface id stay unchanged, new parameters will be applied. Host will send bulk data with no intervals (?), which will cause overflow on FIFO of EP4. Firmware part of problem: By default, ath9k-htc adapters configured with EP3 and EP4 as interrupt endpoints. Current firmware will try to overwrite ConfigDescriptor to make EP3 and EP4 bulk. FIFO for this endpoints
Re: [PATCH] usb: gadget: zero: fix INT endpoint assignment
On 11/26/2014 04:24 PM, Alan Stern wrote: On 11/25/2014 10:52 PM, Sebastian Andrzej Siewior wrote: The max packet size within the FS descriptor has to be highest possible value and _not_ the one that is (or will be) used on FS. The current code sets wMaxPacketSize of FS interrupt endpoint descriptor as 64, which is in accordance with the usb 2.0 specification, section 5.7.3 The maximum allowable interrupt data payload size is 64 bytes or less for full-speed. High-speed endpoints are allowed maximum data payload sizes up to 1024 bytes. The real problem is that we are assuming endpoints can be allocated in a single way that will work correctly for all possible connection speeds. (I suspect it was done this way out of laziness and a desire to minimize the code size.) This assumption is obviously incorrect when the hardware has an interrupt endpoint that supports packet sizes of 64 but no larger. The code will check properly if you pass 1024 and check the size accordingly. You have to downsize your FS descriptor later. This function will only fail to do this if your gadget isn't dual speed. In that case it expects 64 as the upper limit for INT (if I recall correctly). But what you can't do (and this is done by ISOC and INT endpoint) is to upgrade your capabilities by increasing the max packet size after you received an endpoint. This works for ISOC because on FS you can use up to 1023 bytes and the matching FIFO has usually 1024 bytes and not 1023. It isn't correct but it works. This was done out of laziness and simplicity as far as I recall. Usually the only difference between FS and HS is 0 so the only thing you do is to update the bEndpointAddress member in HS/SS descriptors. Nothing more. Most INT don't care for 1024 transfer size or anything like that and the first gadgets in kernel were not ISOC and even these days their MPS is 200. So it was easy just to update the endpoint address for the HS descriptor, you used the same endpoint as for FS. Most in tree gadgets don't do more. The right way to fix the problem is to avoid allocating endpoints until after the connection speed is known. Then we can call usb_ep_autoconfig() with the appropriate set of descriptors, and nothing will need to be fixed up. However, I don't know if this approach is compatible with the composite framework in its current form. I've been looking at this mess by the time I started the configfs. I tried a few times and decided not now and there was no later. You need all descriptors prior you connect / at bind time. At this time you need also your endpoints allocated. A small change to this breaks things in multiple places therefore the created configfs gadget is bound once it is complete. I tried even to have one descriptor and let the code create HS/SS descriptors out of it (since in 99% they are the same) but a few gadgets did more and I dropped that idea again. So this is what is expected in most parts of the code as of now. Then you have USB_DT_OTHER_SPEED_CONFIG where you may ask for HS descriptors on a FS link. So you need those. All in all I tried to minimize the effects by leaving the descriptors untouched and creating a copy after bind. I didn't manage to redo the endpoint allocation. Part of the problem is that you have no clear cut currently between descriptor preparation and endpoint allocation. The endpoint allocator does not know about HS/FS/SS. It knows that there is an endpoint, it can do all speeds and has a special special upper limit (it may not be able to INT or BULK or ISOC so it considers that as well). Once it finds a match, it writes the endpoint address into the descriptor and returns the pointer to the endpoint. So technically you return two values here. The endpoint is considered taken once ep-private is set (so it is a little racy). Based on this you can't get the same endpoint on HS because it is gone. You could but then you get another one. it will work but is a waste of resources. Ah. And endpoints are never returned to the allocator. Some gadgets set -private to NULL, other just ignore it and let the core do it. So re-doing the endpoint allocator is probably the right thing to do. And then force every gadget to allocate an endpoint for FS/HS/SS and give it back _and_ please edit the copy of the descriptor and not the global original. But the work will not be done before we have the next release is out and as of now it breaks g_zero on musb, net2280 and maybe others. Alan Stern Sebastian -- 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 net] r8152: drop the tx packet with invalid length
On Wed, 2014-11-26 at 12:06 -0500, David Miller wrote: From: Eric Dumazet eric.duma...@gmail.com Date: Wed, 26 Nov 2014 08:52:28 -0800 On Wed, 2014-11-26 at 17:56 +0800, Hayes Wang wrote: Drop the tx packet which is more than the size of agg_buf_sz. When creating a bridge with the device, we may get the tx packet with TSO and the length is more than the gso_max_size which is set by the driver through netif_set_gso_max_size(). Such packets couldn't be transmitted and should be dropped directly. Signed-off-by: Hayes Wang hayesw...@realtek.com ... Looks like a candidate for ndo_gso_check(), so that we do not drop, but instead segment from netif_needs_gso()/validate_xmit_skb() You mean have the bridge implement the ndo_gso_check() method right? No, I meant this particular driver. Note that netif_skb_features() does only this check : if (gso_segs dev-gso_max_segs || gso_segs dev-gso_min_segs) features = ~NETIF_F_GSO_MASK; Ie not testing gso_max_size It looks like all these particular tests should be moved on ndo_gso_check(), to remove code from netif_skb_features() -- 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
Fix Penguin Penalty 17th October2014 ( mail-archive.com )
Dear Sir Did your website get hit by Google Penguin update on October 17th 2014? What basically is Google Penguin Update? It is actually a code name for Google algorithm which aims at decreasing your websites search engine rankings that violate Googles guidelines by using black hat SEO techniques to rank your webpage by giving number of spammy links to the page. We are one of those few SEO companies that can help you avoid penalties from Google Updates like Penguin and Panda. Our clients have survived all the previous and present updates with ease. They have never been hit because we use 100% white hat SEO techniques to rank Webpages. Simple thing that we do to keep websites away from any Penguin or Panda penalties is follow Google guidelines and we give Google users the best answers to their queries. If you are looking to increase the quality of your websites and to get more targeted traffic or save your websites from these Google penalties email us back with your interest. We will be glad to serve you and help you grow your business. Regards Roshni Patel SEO Manager ( TOB ) B7 Green Avenue, Amritsar 143001 Punjab NO CLICK in the subject to STOP EMAILS -- 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 storage device cause usb bus can't enter runtime suspend
On Wed, 26 Nov 2014, liu chunlin wrote: Hi Stern, My platform not use udev,do you have good idea to modify usb driver to enable usb storage runtime suspend? It is not possible to do what you want by modifying the USB driver. What does your platform use instead of udev? 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: ath9k - bogus usb xfer on at91
On 11/26/14 12:29 PM, Oleksij Rempel wrote: Am 26.11.2014 um 01:28 schrieb David Lechner: On 7 July 2014 17:08, Oleksij Rempel linux@ wrote: / Am 07.07.2014 15:40, schrieb Anders Darander:/ / On 4 July 2014 18:54, Oleksij Rempel linux@ wrote:/ / Am 04.07.2014 18:30, schrieb Alan Stern:/ / On Fri, 4 Jul 2014, Anders Darander wrote:/ / ~# usb 1-1: new full-speed USB device number 3 using at91_ohci/ / usb 1-1: ath9k_htc: Firmware htc_9271.fw requested/ / usb 1-1: ath9k_htc: Transferred FW: htc_9271.fw, size: 51272/ / ---[ cut here ]---/ / WARNING: CPU: 0 PID: 93 at/ / /mnt/cs-builds/anders/oe-build/build-ccu/tmp-eglibc/work/ccu-oe-linux-gnueabi/linux-yocto-ccu/3.14+gitAUTOINC+7b03bd3dfd-r0/linux/drivers/usb/core/urb.c:450/ / usb_submit_urb+0x2ac/0x460()/ / usb 1-1: BOGUS urb xfer, pipe 1 != type 3/ // // / I can't tell exactly where the fault is, but this message means that an/ / URB was submitted for a bulk endpoint with a pipe of type/ / PIPE_INTERRUPT./ // / Then kernel driver and firmware should be updated. There was some/ / Bulk/Interrupt issues which was fixed last year./ // / Any pointers to the bulk/interrupt issues? Was it a general issue, or/ / related either to/ / at91-ohci or ar9271?/ / It is primary ar9271 issue. The interrupt EP has different response time/ / on different host controllers. Initially as workaround ath9k was forcing/ / Bulk traffic on Interrupt EP. But this workaround is working with some/ / host controllers and completely fails on others. So i removed it. The/ / patches are included in master kernel branch and git firmware source./ Thanks for the comments! I'll take a look at it, though it might have to be scheduled after the upcoming vacations... I'll sure try to look into those workarounds (and your removal of those). I guess that it's the firmware in open-ath9-htc-firmware you're talking about. // / As far as I've been able to find out, I've got the latest firmware/ / (check again with linux-firmware)./ / I've also tried with the master from open-ath9k-htc-firmware./ // / I hope this HW will not be used as AP./ // / Is this based on the use of at91- SoC, or based on the ar9271?/ / ar9271 can work as AP with limit on 8 stations but according to user/ / reports it fails even with one station on at91/ / The primary use case is to run as a client, though there will likely/ / be some instances where it'll/ / function as a AP. (Though primarily for M2M communications), thus/ / pretty low traffic./ / For AP usually should be created monitor mode interface for receiving/ / and transmitting management frames. Depending on location and STAs or/ / APs working on same channel, you will get a lot of traffic on this usb/ / interface./ / Some users reported huge traffic drops on at91 based APs. Since i can't/ / debug it, i can't promise that it will be fixed any time soon./ Again, thanks for the information. I think I've got a much better understanding of the issues (both those that I've seen, and those that you have mentioned / explained). I'll see when/what I can look into this and what I can find out. Cheers, Anders Anders, did you ever have a chance to look at this? I am seeing this same warning that is filling up the kernel logs in v3.18-rc6. The device I am using is: |ID 0846:9030 NetGear, Inc. WNA1100 Wireless-N 150 [Atheros AR9271]|| I found that if I revert kernel commit 2b72111 that the warning stops, but the device does not work very well.||If you are interested to know more about the symptoms we are seeing, there is a bug report here: https://github.com/ev3dev/ev3dev/issues/152. But, I figured at least knowing the kernel commit that introduced the problem would be helpful.| i assume you mean this: commit 2b721118b7821107757eb1d37af4b60e877b27e7 Author: Oleksij Rempel li...@rempel-privat.de Date: Tue Aug 13 21:10:19 2013 +0200 ath9k_htc: do not use bulk on EP3 and EP4 If usb auto suspend is enabled or system run in to suspend/resume cycle, ath9k-htc adapter will stop to response. It is reproducible on xhci H Host part of problem: XHCI do timing calculation based on Transfer Type and bInterval, immediately after device was detected. Ath9k-htc try to overwrite this parameters on module probe and some changes in FW, since we do not initiate usb reset from the driver this changes are not took to account. So, before any kind of suspend or reset, host controller will operate with old parameters. Only after suspend/resume and if interface id stay unchanged, new parameters will be applied. Host will send bulk data with no intervals (?), which will cause overflow on FIFO of EP4. Firmware part of problem: By default, ath9k-htc adapters configured with EP3 and EP4 as interrupt endpoints. Current firmware will try to overwrite ConfigDescriptor to make EP3 and EP4 bulk. FIFO for this endpoints
Re: [GIT PULL] USB-serial updates for v3.19
On Wed, Nov 26, 2014 at 06:25:07PM +0100, Johan Hovold wrote: Hi Greg, Here's my pull-request for v3.19-rc1. All have been in linux-next for a while. Thanks, Johan The following changes since commit f114040e3ea6e07372334ade75d1ee0775c355e1: Linux 3.18-rc1 (2014-10-19 18:08:38 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial.git tags/usb-serial-3.19-rc1 Pulled and pushed out, thanks. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V6 00/12] Tegra xHCI support
On Tue, Nov 25, 2014 at 5:32 AM, Jassi Brar jaswinder.si...@linaro.org wrote: On 25 November 2014 at 05:47, Andrew Bresticker abres...@chromium.org wrote: This series adds support for xHCI on NVIDIA Tegra SoCs. This includes: - patches 1, 2, and 3: minor cleanups for mailbox framework and xHCI, - patches 4 and 5: adding a driver for the mailbox used to communicate with the xHCI controller's firmware, - patches 6 and 7: extending the XUSB pad controller driver to support the USB PHY types (UTMI, HSIC, and USB3), - patches 8 and 9: adding a xHCI host-controller driver, and - patches 10, 11, and 12: updating the relevant DT files. The mailbox driver (patch 5) has a compile-time dependency on patch 2 and a run-time dependency on patch 3. Both the PHY (patch 7) and host (patch 9) drivers have compile-time dependencies on the mailbox driver. The host driver also has a run-time dependency on patch 1. Because of this, this entire series should probably go through the Tegra tree. Why shouldn't I pick 2 3 at least? I don't see why not. Because of the PHY API change I'm going to have to re-spin the series and at this point 3.19 is looking pretty unlikely. Maybe we could get a Tegra maintainer's ACK for patches 4 and 5 so that you could take them through your tree as well for 3.19? (Stephen, Thierry, Alex?) -- 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 V6 07/12] pinctrl: tegra-xusb: Add USB PHY support
On Tue, Nov 25, 2014 at 5:49 AM, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, On Tuesday 25 November 2014 05:47 AM, Andrew Bresticker wrote: In addition to the PCIe and SATA PHYs, the XUSB pad controller also supports 3 UTMI, 2 HSIC, and 2 USB3 PHYs. Each USB3 PHY uses a single PCIe or SATA lane and is mapped to one of the three UTMI ports. The xHCI controller will also send messages intended for the PHY driver, so request and listen for messages on the mailbox's PHY channel. Signed-off-by: Andrew Bresticker abres...@chromium.org Acked-by: Linus Walleij linus.wall...@linaro.org Reviewed-by: Stephen Warren swar...@nvidia.com --- No changes from v5. Changes from v4: - Disabled USB support on missing mailbox channel instead of failing to probe. - Made usb3-port a pinconfig property. - Addressed review comments from Thierry. No changes from v3. Changes from v2: - Added support for nvidia,otg-hs-curr-level-offset property. - Moved mailbox request handling to workqueue. - Added filtering out of non-PHY mailbox messages. - Dropped -otg from VBUS supplies. Changes from v1: - Updated to use common mailbox API. - Added SATA PHY enable sequence for USB3 ports using the SATA lane. - Made USB3 port-to-lane mappins a top-level binding rather than a pinconfig binding. --- drivers/pinctrl/Kconfig |1 + drivers/pinctrl/pinctrl-tegra-xusb.c | 1262 +- include/soc/tegra/xusb.h |7 + 3 files changed, 1254 insertions(+), 16 deletions(-) The devm_phy_create() API has changed (see linux-phy next) and the patch that modified the existing devm_phy_create() in pinctrl-tegra-xusb.c has also been merged in linux-phy tree. Ok, I'll rebase on top of that. -- 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
Suspected (out of tree) HCI issue
Hi.
(please keep me cc'ed in replies, I'm not subscribed)
I'm trying OpenWRT on a DSL modem[1] which has an out-of-tree HCI
driver. I'm getting one particular process to hang in D 100% of time
when talking to a 3G USB modem. I'm on current default OpenWRT kernel,
3.14.18 .
Here is the hung process:
root@OpenWrt:/# echo w /proc/sysrq-trigger
[ 98.16] SysRq : Show Blocked State
[ 98.16] taskPC stack pid father
[ 98.16] gcomD 8030861c 0 2228 2188 0x08100020
[ 98.16] Stack : 81bde880 0001 80307b18 81bde880 80435698
81bde88c 80414c60
81d213c0 0001 8041 81bb7180 0001 8030861c 81bcd480
81452e00
81452e00 803a 814bf070 8007fc04 80435698 80435698
81452e00
803a 0004 81d21380 0010 81be2800 81828900
81d08c28
81be2804 81be2884 81452e00 803a
81d08c28
...
[ 98.16] Call Trace:
[ 98.16] [8000d954] __schedule+0x4cc/0x578
[ 98.16] [8030861c] usb_kill_urb+0xe0/0x164
[ 98.16] [81828900] usb_wwan_close+0x100/0x2e4 [usb_wwan]
[ 98.16] [802b6e8c] tty_port_shutdown+0xc0/0xdc
[ 98.16] [802b64ac] tty_port_close+0x30/0xa4
[ 98.16] [802b7918] tty_release+0x168/0x524
[ 98.16] [80041038] __fput+0xf8/0x274
[ 98.16] [80289560] task_work_run+0xf0/0x128
[ 98.16] [800ef3d0] do_exit+0x3fc/0x858
[ 98.16] [800f154c] do_group_exit+0x78/0xb4
[ 98.16] [800198a8] SyS_faccessat+0x0/0x250
As can be seen, it is while cleaning up process resources on exit (at
kernel level) that the hang happens. If I unplug the modem, process
exits and I get the following output:
[ 2862.228000] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb
failed. (-19)
[ 2862.236000] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb
failed. (-19)
[ 2862.244000] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb
failed. (-19)
[ 2862.252000] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb
failed. (-19)
[ 2862.26] option1 ttyUSB0: option_instat_callback: error -150
Here is the HCD driver source code:
http://git.openwrt.org/?p=openwrt.git;a=tree;f=package/kernel/lantiq/ltq-hcd/src;h=926980738d4eb39d78fdf116fe4f2f787040fa1d;hb=fee2d7ec702586850e0eafbd82f43c851d1c45b3
(to the revision I'm at locally, which is 2 days old as I'm writing
this, and no change since touch this path)
Poking around with printk debugging (*cough*), I found that the URB
__schedule is waiting upon has a use_count of 1. Adding printks after
the 2 atomic_dec and the only atomic_inc on it, I see this URB's history
as:
[ 99.284000] 81ae2900-use_count 1 drivers/usb/core/hcd.c:1553
[ 99.916000] 81ae2900-use_count 2 drivers/usb/core/hcd.c:1553
[ 99.916000] 81ae2900-use_count 1 drivers/usb/core/hcd.c:1691
[ 100.332000] 81ae2900-use_count 2 drivers/usb/core/hcd.c:1553
[ 100.332000] 81ae2900-use_count 1 drivers/usb/core/hcd.c:1691
[ 101.436000] IFXUSB: 81ae2900 urbd-phase 0
[ 101.44] 81ae2900-use_count 2 drivers/usb/core/hcd.c:1553
[ 101.44] 81ae2900-use_count 1 drivers/usb/core/hcd.c:1691
[ 101.512000] wait_event 81ae2900
1553 is right after usb_hcd_submit_urb's atomic_inc
1691 is right after __usb_hcd_giveback_urb's atomic_dec
usb_hcd_submit_urb's atomic_dec is not hit.
The IFXUSB line is the HCD driver's ifxhcd_urb_dequeue telling it is
dequeueing the URB, currently in given phase (here 0, so URBD_IDLE).
wait_event line is usb_kill_urb calling wait_event or given URB.
This URB does not appear at any time before 99.284, when I started gcom.
Is it legal for use_count to exceed 1 ?
What would it mean ?
Eyeballing usb_wwan I could not see any obvious issue. I saw a large
patch set for this driver since 3.14.18 and copied it over (as of
linux-stable b0a9aa6da8088b722326a858ab572a13b5b6f9cb), with the only
visible improvement of not getting errors when unplugging the modem on
stuck process.
Is my debugging approach even reliable ? I'm reading use_count right
after an atomic_inc, which looks like a bad idea...
Any idea on what I should search for/look at next ?
I tried calling dump_stack after 1553, but kernel fails booting (maybe
URBs timing out just because of printks going through 115200 bauds
serial link ?). After ~260 seconds the router reboots (no error
message, maybe out of memory because of message buffer growing faster
than serial empties it ?).
If I only call it when count reaches 2, kernel boots and gives
stack traces I do not understand, such as (extracted from above run):
[ 99.916000] CPU: 0 PID: 1413 Comm: logd Not tainted 3.14.18 #38
[ 99.916000] Stack : 8095cdbe 0033
838bd7e8 803f
803c1644 8042136f 0585 80953b00 838bd7e8 803f 81d395a8
0020
000a 802f9998 80211878 803c49a4
838b5ccc
Re: [PATCH net] r8152: drop the tx packet with invalid length
From: Eric Dumazet eric.duma...@gmail.com Date: Wed, 26 Nov 2014 10:44:19 -0800 On Wed, 2014-11-26 at 12:06 -0500, David Miller wrote: From: Eric Dumazet eric.duma...@gmail.com Date: Wed, 26 Nov 2014 08:52:28 -0800 On Wed, 2014-11-26 at 17:56 +0800, Hayes Wang wrote: Drop the tx packet which is more than the size of agg_buf_sz. When creating a bridge with the device, we may get the tx packet with TSO and the length is more than the gso_max_size which is set by the driver through netif_set_gso_max_size(). Such packets couldn't be transmitted and should be dropped directly. Signed-off-by: Hayes Wang hayesw...@realtek.com ... Looks like a candidate for ndo_gso_check(), so that we do not drop, but instead segment from netif_needs_gso()/validate_xmit_skb() You mean have the bridge implement the ndo_gso_check() method right? No, I meant this particular driver. Note that netif_skb_features() does only this check : if (gso_segs dev-gso_max_segs || gso_segs dev-gso_min_segs) features = ~NETIF_F_GSO_MASK; Ie not testing gso_max_size It looks like all these particular tests should be moved on ndo_gso_check(), to remove code from netif_skb_features() A check against gso_max_size is generic enough that it ought to be put right into netif_needs_gso() rather then duplicating it into every driver's ndo_gso_check() method don't you think? -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] usb: core: buffer: smallest buffer should start at ARCH_DMA_MINALIGN
the following error pops up during testusb -a -t 10
| musb-hdrc musb-hdrc.1.auto: dma_pool_free buffer-128, f134e000/be842000 (bad
dma)
hcd_buffer_create() creates a few buffers, the smallest has 32 bytes of
size. ARCH_KMALLOC_MINALIGN is set to 64 bytes. This combo results in
hcd_buffer_alloc() returning memory which is 32bytes aligned and it
might by identified by buffer_offset() as another buffer. This means the
buffer which is on a 32byte boundary will not get freed, instead it
tries to free another buffer with the error message.
This patch fixes the issue by creating the smallest DMA buffer with the
size of ARCH_DMA_MINALIGN. This will be either 32 or 64 bytes. If the
ARCH_DMA_MINALIGN is 128 (currently powerpc64, mips ip32, x86 pentium 4) then
it will create the first buffer with 128 bytes and will have only 3
buffers. There is a BUILD_BUG_ON() now in case someone has a minalign of
128 bytes or more.
Cc: sta...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
v1…v2: rewrite pool_max so it is less confusing.
drivers/usb/core/buffer.c | 12
include/linux/usb/hcd.h | 8 ++--
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
index 684ef70dc09d..5ad5f71d6358 100644
--- a/drivers/usb/core/buffer.c
+++ b/drivers/usb/core/buffer.c
@@ -26,10 +26,13 @@ static const size_t pool_max[HCD_BUFFER_POOLS] = {
/* platforms without dma-friendly caches might need to
* prevent cacheline sharing...
*/
- 32,
- 128,
- 512,
- PAGE_SIZE / 2
+#if ARCH_KMALLOC_MINALIGN = 32
+ 32, 128, 512, PAGE_SIZE / 2,
+#elif ARCH_KMALLOC_MINALIGN = 64
+ 64, 128, 512, PAGE_SIZE / 2,
+#else
+ 128, 512, PAGE_SIZE / 2
+#endif
/* bigger -- allocate pages */
};
@@ -58,6 +61,7 @@ int hcd_buffer_create(struct usb_hcd *hcd)
!(hcd-driver-flags HCD_LOCAL_MEM))
return 0;
+ BUILD_BUG_ON(ARCH_KMALLOC_MINALIGN 128);
for (i = 0; i HCD_BUFFER_POOLS; i++) {
size = pool_max[i];
if (!size)
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index cd96a2bc3388..1e2234ca448d 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -23,6 +23,7 @@
#include linux/rwsem.h
#include linux/interrupt.h
+#include linux/slab.h
#define MAX_TOPO_LEVEL 6
@@ -171,8 +172,11 @@ struct usb_hcd {
struct usb_hcd *shared_hcd;
struct usb_hcd *primary_hcd;
-
-#define HCD_BUFFER_POOLS 4
+#if ARCH_KMALLOC_MINALIGN = 64
+ #define HCD_BUFFER_POOLS4
+#else
+ #define HCD_BUFFER_POOLS3
+#endif
struct dma_pool *pool[HCD_BUFFER_POOLS];
int state;
--
2.1.3
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Suspected (out of tree) HCI issue
On Wed, 26 Nov 2014, Vincent Pelletier wrote: Hi. (please keep me cc'ed in replies, I'm not subscribed) I'm trying OpenWRT on a DSL modem[1] which has an out-of-tree HCI driver. I'm getting one particular process to hang in D 100% of time when talking to a 3G USB modem. I'm on current default OpenWRT kernel, 3.14.18 . Here is the hung process: root@OpenWrt:/# echo w /proc/sysrq-trigger [ 98.16] SysRq : Show Blocked State [ 98.16] taskPC stack pid father [ 98.16] gcomD 8030861c 0 2228 2188 0x08100020 [ 98.16] Stack : 81bde880 0001 80307b18 81bde880 80435698 81bde88c 80414c60 81d213c0 0001 8041 81bb7180 0001 8030861c 81bcd480 81452e00 81452e00 803a 814bf070 8007fc04 80435698 80435698 81452e00 803a 0004 81d21380 0010 81be2800 81828900 81d08c28 81be2804 81be2884 81452e00 803a 81d08c28 ... [ 98.16] Call Trace: [ 98.16] [8000d954] __schedule+0x4cc/0x578 [ 98.16] [8030861c] usb_kill_urb+0xe0/0x164 [ 98.16] [81828900] usb_wwan_close+0x100/0x2e4 [usb_wwan] [ 98.16] [802b6e8c] tty_port_shutdown+0xc0/0xdc [ 98.16] [802b64ac] tty_port_close+0x30/0xa4 [ 98.16] [802b7918] tty_release+0x168/0x524 [ 98.16] [80041038] __fput+0xf8/0x274 [ 98.16] [80289560] task_work_run+0xf0/0x128 [ 98.16] [800ef3d0] do_exit+0x3fc/0x858 [ 98.16] [800f154c] do_group_exit+0x78/0xb4 [ 98.16] [800198a8] SyS_faccessat+0x0/0x250 Broadly speaking, this means the kernel is waiting for a completion interrupt which never arrives. The interrupt would indicate that the controller hardware has finished accessing the data structures belonging to the URB being killed. As can be seen, it is while cleaning up process resources on exit (at kernel level) that the hang happens. If I unplug the modem, process exits and I get the following output: [ 2862.228000] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb failed. (-19) [ 2862.236000] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb failed. (-19) [ 2862.244000] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb failed. (-19) [ 2862.252000] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb failed. (-19) [ 2862.26] option1 ttyUSB0: option_instat_callback: error -150 Here is the HCD driver source code: http://git.openwrt.org/?p=openwrt.git;a=tree;f=package/kernel/lantiq/ltq-hcd/src;h=926980738d4eb39d78fdf116fe4f2f787040fa1d;hb=fee2d7ec702586850e0eafbd82f43c851d1c45b3 (to the revision I'm at locally, which is 2 days old as I'm writing this, and no change since touch this path) Since this driver seems to be based on work by Synopsys, maybe someone from that company can help. (By the way, the license information in the ifxhcd.h header file doesn't say anything about the GPL. That doesn't seem kosher.) Poking around with printk debugging (*cough*), I found that the URB __schedule is waiting upon has a use_count of 1. Adding printks after the 2 atomic_dec and the only atomic_inc on it, I see this URB's history as: [ 99.284000] 81ae2900-use_count 1 drivers/usb/core/hcd.c:1553 [ 99.916000] 81ae2900-use_count 2 drivers/usb/core/hcd.c:1553 [ 99.916000] 81ae2900-use_count 1 drivers/usb/core/hcd.c:1691 [ 100.332000] 81ae2900-use_count 2 drivers/usb/core/hcd.c:1553 [ 100.332000] 81ae2900-use_count 1 drivers/usb/core/hcd.c:1691 [ 101.436000] IFXUSB: 81ae2900 urbd-phase 0 [ 101.44] 81ae2900-use_count 2 drivers/usb/core/hcd.c:1553 [ 101.44] 81ae2900-use_count 1 drivers/usb/core/hcd.c:1691 [ 101.512000] wait_event 81ae2900 1553 is right after usb_hcd_submit_urb's atomic_inc 1691 is right after __usb_hcd_giveback_urb's atomic_dec usb_hcd_submit_urb's atomic_dec is not hit. The IFXUSB line is the HCD driver's ifxhcd_urb_dequeue telling it is dequeueing the URB, currently in given phase (here 0, so URBD_IDLE). wait_event line is usb_kill_urb calling wait_event or given URB. This URB does not appear at any time before 99.284, when I started gcom. So at time 100.332 the URB completes and the completion routine resubmits it. At time 101.436 the driver tries to kill the URB. At 101.440 the URB completes (presumably with a status code indicating that it was killed) and the completion routine resubmits it. Evidently the resubmission succeeds, because usb_hcd_submit_urb's atomic_dec is not hit. Resubmission of a killed URB is not supposed to succeed. If it does, it means there's a bug in the HCD: It isn't calling usb_hcd_link_urb_to_ep() properly. That's the problem with using out-of-tree drivers -- they don't track changes to the rest of the kernel. :-( Is it legal for use_count to exceed 1 ? Yes. What would it mean ? It would mean that the completion routine has resubmitted the URB.
Re: Suspected (out of tree) HCI issue
On Wed, 26 Nov 2014 21:18:55 +0100, Vincent Pelletier plr.vinc...@gmail.com wrote: with the only visible improvement of not getting errors when unplugging the modem on stuck process. ...actually, not even, I was expecting errors on the wrong terminal: they are still present. Just for the record, here is an entire gcom run output with my printks (one line offset from removing show_stack call). Lock at 68.744 and unplug at 79.920 . [ 66.956000] 81bd0380-use_count 1 drivers/usb/core/hcd.c:1553 [ 66.964000] 83accd80-use_count 1 drivers/usb/core/hcd.c:1553 [ 66.968000] 83accd00-use_count 1 drivers/usb/core/hcd.c:1553 [ 66.972000] 81bd0380-use_count 2 drivers/usb/core/hcd.c:1553 [ 66.972000] 81bd0380-use_count 1 drivers/usb/core/hcd.c:1690 [ 66.984000] 83accc80-use_count 1 drivers/usb/core/hcd.c:1553 [ 66.992000] 83accc00-use_count 1 drivers/usb/core/hcd.c:1553 [ 66.996000] 814c5480-use_count 1 drivers/usb/core/hcd.c:1553 [ 67.004000] 814c5480-use_count 0 drivers/usb/core/hcd.c:1690 [ 67.528000] 83accb80-use_count 1 drivers/usb/core/hcd.c:1553 [ 67.532000] 83accb80-use_count 0 drivers/usb/core/hcd.c:1690 [ 67.54] 83accd80-use_count 2 drivers/usb/core/hcd.c:1553 [ 67.54] 83accd80-use_count 1 drivers/usb/core/hcd.c:1690 [ 67.572000] 83accb80-use_count 1 drivers/usb/core/hcd.c:1553 [ 67.576000] 83accb80-use_count 0 drivers/usb/core/hcd.c:1690 [ 67.58] 83accd00-use_count 2 drivers/usb/core/hcd.c:1553 [ 67.58] 83accd00-use_count 1 drivers/usb/core/hcd.c:1690 [ 67.616000] 83accb80-use_count 1 drivers/usb/core/hcd.c:1553 [ 67.62] 83accb80-use_count 0 drivers/usb/core/hcd.c:1690 [ 67.624000] 83accc80-use_count 2 drivers/usb/core/hcd.c:1553 [ 67.624000] 83accc80-use_count 1 drivers/usb/core/hcd.c:1690 [ 67.66] 83accb80-use_count 1 drivers/usb/core/hcd.c:1553 [ 67.664000] 83accb80-use_count 0 drivers/usb/core/hcd.c:1690 [ 67.668000] 83accc00-use_count 2 drivers/usb/core/hcd.c:1553 [ 67.668000] 83accc00-use_count 1 drivers/usb/core/hcd.c:1690 [ 67.68] 83accd80-use_count 2 drivers/usb/core/hcd.c:1553 [ 67.68] 83accd80-use_count 1 drivers/usb/core/hcd.c:1690 [ 68.72] 814e6700-use_count 1 drivers/usb/core/hcd.c:1553 [ 68.724000] 814e6700-use_count 0 drivers/usb/core/hcd.c:1690 [ 68.732000] IFXUSB: 83accd80 urbd-phase 0 [ 68.732000] 83accd80-use_count 2 drivers/usb/core/hcd.c:1553 [ 68.732000] 83accd80-use_count 1 drivers/usb/core/hcd.c:1690 [ 68.744000] wait_event 83accd80 [ 79.92] 83accd00-use_count 2 drivers/usb/core/hcd.c:1553 [ 79.92] 83accd00-use_count 1 drivers/usb/core/hcd.c:1582 [ 79.92] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb failed. (-19) [ 79.936000] 83accd00-use_count 0 drivers/usb/core/hcd.c:1690 [ 79.94] 83accc80-use_count 2 drivers/usb/core/hcd.c:1553 [ 79.94] 83accc80-use_count 1 drivers/usb/core/hcd.c:1582 [ 79.94] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb failed. (-19) [ 79.96] 83accc80-use_count 0 drivers/usb/core/hcd.c:1690 [ 79.968000] 83accc00-use_count 2 drivers/usb/core/hcd.c:1553 [ 79.968000] 83accc00-use_count 1 drivers/usb/core/hcd.c:1582 [ 79.968000] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb failed. (-19) [ 79.988000] 83accc00-use_count 0 drivers/usb/core/hcd.c:1690 [ 79.992000] 83accd80-use_count 2 drivers/usb/core/hcd.c:1553 [ 79.992000] 83accd80-use_count 1 drivers/usb/core/hcd.c:1582 [ 79.992000] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb failed. (-19) [ 80.012000] 83accd80-use_count 0 drivers/usb/core/hcd.c:1690 [ 80.016000] option1 ttyUSB0: option_instat_callback: error -150 [ 80.016000] 81bd0380-use_count 2 drivers/usb/core/hcd.c:1553 [ 80.016000] 81bd0380-use_count 1 drivers/usb/core/hcd.c:1582 [ 80.036000] 81bd0380-use_count 0 drivers/usb/core/hcd.c:1690 [ 80.04] 81d25a80-use_count 2 drivers/usb/core/hcd.c:1553 [ 80.044000] 81d25a80-use_count 1 drivers/usb/core/hcd.c:1690 [ 80.052000] 814c5680-use_count 1 drivers/usb/core/hcd.c:1553 [ 80.056000] 814c5680-use_count 0 drivers/usb/core/hcd.c:1690 [ 80.068000] 814c5680-use_count 1 drivers/usb/core/hcd.c:1553 [ 80.072000] 814c5680-use_count 0 drivers/usb/core/hcd.c:1690 [ 80.084000] 814c5680-use_count 1 drivers/usb/core/hcd.c:1553 [ 80.088000] 814c5680-use_count 0 drivers/usb/core/hcd.c:1690 [ 80.104000] wait_event 83accd00 [ 80.104000] wait_event 83accc80 [ 80.108000] wait_event 83accc00 [ 80.112000] wait_event 83accb80 [ 80.112000] wait_event 81bd0380 [ 80.116000] usb 1-1: USB disconnect, device number 3 [ 80.14] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0 [ 80.164000] option 1-1:1.0: device disconnected [ 80.168000] option1 ttyUSB1: GSM modem (1-port) converter now disconnected from ttyUSB1 [ 80.196000] option 1-1:1.1: device disconnected (please keep me cc'ed in replies) -- Vincent Pelletier -- To unsubscribe from
Re: [PATCH v2] usb: core: buffer: smallest buffer should start at ARCH_DMA_MINALIGN
On Wed, 26 Nov 2014, Sebastian Andrzej Siewior wrote: the following error pops up during testusb -a -t 10 | musb-hdrc musb-hdrc.1.auto: dma_pool_free buffer-128, f134e000/be842000 (bad dma) hcd_buffer_create() creates a few buffers, the smallest has 32 bytes of size. ARCH_KMALLOC_MINALIGN is set to 64 bytes. This combo results in hcd_buffer_alloc() returning memory which is 32bytes aligned and it might by identified by buffer_offset() as another buffer. This means the buffer which is on a 32byte boundary will not get freed, instead it tries to free another buffer with the error message. This patch fixes the issue by creating the smallest DMA buffer with the size of ARCH_DMA_MINALIGN. This will be either 32 or 64 bytes. If the ARCH_DMA_MINALIGN is 128 (currently powerpc64, mips ip32, x86 pentium 4) then it will create the first buffer with 128 bytes and will have only 3 buffers. There is a BUILD_BUG_ON() now in case someone has a minalign of 128 bytes or more. More than 128 bytes. Not 128 bytes or more. Cc: sta...@vger.kernel.org Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- v1…v2: rewrite pool_max so it is less confusing. Acked-by: Alan Stern st...@rowland.harvard.edu -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: zero: fix INT endpoint assignment
On Wed, 26 Nov 2014, Sebastian Andrzej Siewior wrote: On 11/26/2014 04:24 PM, Alan Stern wrote: On 11/25/2014 10:52 PM, Sebastian Andrzej Siewior wrote: The max packet size within the FS descriptor has to be highest possible value and _not_ the one that is (or will be) used on FS. The current code sets wMaxPacketSize of FS interrupt endpoint descriptor as 64, which is in accordance with the usb 2.0 specification, section 5.7.3 The maximum allowable interrupt data payload size is 64 bytes or less for full-speed. High-speed endpoints are allowed maximum data payload sizes up to 1024 bytes. The real problem is that we are assuming endpoints can be allocated in a single way that will work correctly for all possible connection speeds. (I suspect it was done this way out of laziness and a desire to minimize the code size.) This assumption is obviously incorrect when the hardware has an interrupt endpoint that supports packet sizes of 64 but no larger. The code will check properly if you pass 1024 and check the size accordingly. You have to downsize your FS descriptor later. This function will only fail to do this if your gadget isn't dual speed. In that case it expects 64 as the upper limit for INT (if I recall correctly). It will also fail in situations where you use up a lot of endpoints. For example, let's say the UDC only supports 4 endpoints, one of which must have a maxpacket value = 64. If you want to have four interrupt endpoints, you can't run at high speed -- but you can run at full speed. However, the approach you outlined above won't allow it. But what you can't do (and this is done by ISOC and INT endpoint) is to upgrade your capabilities by increasing the max packet size after you received an endpoint. This works for ISOC because on FS you can use up to 1023 bytes and the matching FIFO has usually 1024 bytes and not 1023. It isn't correct but it works. This was done out of laziness and simplicity as far as I recall. Usually the only difference between FS and HS is 0 so the only thing you do is to update the bEndpointAddress member in HS/SS descriptors. Nothing more. Most INT don't care for 1024 transfer size or anything like that and the first gadgets in kernel were not ISOC and even these days their MPS is 200. So it was easy just to update the endpoint address for the HS descriptor, you used the same endpoint as for FS. Most in tree gadgets don't do more. The right way to fix the problem is to avoid allocating endpoints until after the connection speed is known. Then we can call usb_ep_autoconfig() with the appropriate set of descriptors, and nothing will need to be fixed up. However, I don't know if this approach is compatible with the composite framework in its current form. I've been looking at this mess by the time I started the configfs. I tried a few times and decided not now and there was no later. You need all descriptors prior you connect / at bind time. At this time you need also your endpoints allocated. A small change to this breaks things in multiple places therefore the created configfs gadget is bound once it is complete. I tried even to have one descriptor and let the code create HS/SS descriptors out of it (since in 99% they are the same) but a few gadgets did more and I dropped that idea again. So this is what is expected in most parts of the code as of now. Then you have USB_DT_OTHER_SPEED_CONFIG where you may ask for HS descriptors on a FS link. So you need those. You're right. It looks like we need to set up separate allocations of endpoints for all possible connection speeds, during initialization. If one of the allocations fails then the gadget must not be allowed to connect at that speed. (Unfortunately the gadget framework doesn't include any method for telling the hardware not to connect at a certain speed...) All in all I tried to minimize the effects by leaving the descriptors untouched and creating a copy after bind. I didn't manage to redo the endpoint allocation. Part of the problem is that you have no clear cut currently between descriptor preparation and endpoint allocation. The endpoint allocator does not know about HS/FS/SS. It knows that there is an endpoint, it can do all speeds and has a special special upper limit (it may not be able to INT or BULK or ISOC so it considers that as well). Once it finds a match, it writes the endpoint address into the descriptor and returns the pointer to the endpoint. So technically you return two values here. The endpoint is considered taken once ep-private is set (so it is a little racy). Based on this you can't get the same endpoint on HS because it is gone. You could but then you get another one. it will work but is a waste of resources. Ah. And endpoints are never returned to the allocator. Some gadgets set -private to NULL, other just ignore it and let the core do it. So
Re: [PATCH V2 3/5] usb: gadget: pxa25x_udc: prepare/unprepare clocks in pxa-ssp
OK Dmitry, I pulled through, the interrupts are working back. Actually one of the blockers I have is in pxa25x_udc, and it is also in your phy-lubbock.c. The bottom of the error is that disable_irq() is called from within a irq handler, and it deadlocks. A disable_irq_nosync() should be used ... ... but a better approach would be to use a threaded irq for vbus handling. I think that way disable_irq() can be used, no workqueue is needed anymore in phy-lubbock. Would you make that change, I'll test it and review it. Cheers. -- Robert -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 3/5] usb: gadget: pxa25x_udc: prepare/unprepare clocks in pxa-ssp
2014-11-27 1:12 GMT+03:00 Robert Jarzmik robert.jarz...@free.fr: OK Dmitry, I pulled through, the interrupts are working back. What was the problem? Hardware issues? Firmware in CPLD being of old revision? Actually one of the blockers I have is in pxa25x_udc, and it is also in your phy-lubbock.c. The bottom of the error is that disable_irq() is called from within a irq handler, and it deadlocks. A disable_irq_nosync() should be used ... ... but a better approach would be to use a threaded irq for vbus handling. I think that way disable_irq() can be used, no workqueue is needed anymore in phy-lubbock. Would you make that change, I'll test it and review it. OK, I will take a look in a next few days. BTW: I have also received a pxa270 board (Sophia Sandgate II, the one without the additional graphics accelerator), so after spending some efforts on bringup bsp, I should be able to also test pxa270 code. -- With best wishes Dmitry -- 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
Lubbock interrupts fix (was lubbock udc phy)
Dmitry Eremin-Solenikov dbarysh...@gmail.com writes: 2014-11-27 1:12 GMT+03:00 Robert Jarzmik robert.jarz...@free.fr: OK Dmitry, I pulled through, the interrupts are working back. What was the problem? Hardware issues? Firmware in CPLD being of old revision? There were basically 2 problems : - hardware: switch S13 was in a position that disabled interrupts all the time One other problem which fooled me was the incorrect gate schematics I had, and which make my understanding of linear function foo such as GPIO0 = foo(LUB_IRQ_EN, LUB_SET_CLR) false. - software: lubbock.c error Since gpio-pxa was ported to device/gpio, it is probed *after* lubbock_init_irq() is called. As lubbock_init_irq() installs lubbock_irq_handler() and sets the irq to falling edge detect before gpio-pxa is probed, gpio-pxa probe overwrites this by : - clearing any edge detection (probe state reset) - installing generic handle_edge_irq() instead of the lubbock irq handler So the conclusion is that I have to rework lubbock_init_irq(), remove from it the PXA_GPIO_TO_IRQ(0) stuff, and move it to a code in lubbock.c which will provide the guarantee of being executed _after_ gpio-pxa is probed. When I'm happy with my patch I'll submit it. Cheers. -- Robert -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Lubbock interrupts fix (was lubbock udc phy)
2014-11-27 1:38 GMT+03:00 Robert Jarzmik robert.jarz...@free.fr: Dmitry Eremin-Solenikov dbarysh...@gmail.com writes: 2014-11-27 1:12 GMT+03:00 Robert Jarzmik robert.jarz...@free.fr: OK Dmitry, I pulled through, the interrupts are working back. What was the problem? Hardware issues? Firmware in CPLD being of old revision? There were basically 2 problems : - hardware: switch S13 was in a position that disabled interrupts all the time One other problem which fooled me was the incorrect gate schematics I had, and which make my understanding of linear function foo such as GPIO0 = foo(LUB_IRQ_EN, LUB_SET_CLR) false. - software: lubbock.c error Since gpio-pxa was ported to device/gpio, it is probed *after* lubbock_init_irq() is called. As lubbock_init_irq() installs lubbock_irq_handler() and sets the irq to falling edge detect before gpio-pxa is probed, gpio-pxa probe overwrites this by : - clearing any edge detection (probe state reset) - installing generic handle_edge_irq() instead of the lubbock irq handler So the conclusion is that I have to rework lubbock_init_irq(), remove from it the PXA_GPIO_TO_IRQ(0) stuff, and move it to a code in lubbock.c which will provide the guarantee of being executed _after_ gpio-pxa is probed. When I'm happy with my patch I'll submit it. Thank you for your explanation. -- With best wishes Dmitry -- 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 06/19] usb: dwc3: host: Pass the XHCI_DRD_SUPPORT and XHCI_NEEDS_LHC_RESET quirk
On 2014年11月25日 21:11, George Cherian wrote:
Pass the quir flag XHCI_DRD_SUPPORT from DWC3 host to xhci platform driver.
quir to quirk
Regards,
Baolu
This enables xhci driver to handle deallocation's differently while in DRD mode.
Pass the quirk flag XHCI_NEEDS_LHC_RESET from DWC3 host to xhci platform
driver. This enables to do LHRESET during xhci_reset().
Signed-off-by: George Cherian george.cher...@ti.com
---
drivers/usb/dwc3/host.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index dcb8ca0..257b5b5 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -53,6 +53,8 @@ int dwc3_host_init(struct dwc3 *dwc)
#ifdef CONFIG_DWC3_HOST_USB3_LPM_ENABLE
pdata.usb3_lpm_capable = 1;
#endif
+ pdata.usb_drd_support = 1;
+ pdata.usb_needs_lhc_reset = 1;
ret = platform_device_add_data(xhci, pdata, sizeof(pdata));
if (ret) {
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: core: buffer: smallest buffer should start at ARCH_DMA_MINALIGN
On Wed, Nov 26, 2014 at 04:27:27PM -0500, Alan Stern wrote: On Wed, 26 Nov 2014, Sebastian Andrzej Siewior wrote: the following error pops up during testusb -a -t 10 | musb-hdrc musb-hdrc.1.auto: dma_pool_free buffer-128, f134e000/be842000 (bad dma) hcd_buffer_create() creates a few buffers, the smallest has 32 bytes of size. ARCH_KMALLOC_MINALIGN is set to 64 bytes. This combo results in hcd_buffer_alloc() returning memory which is 32bytes aligned and it might by identified by buffer_offset() as another buffer. This means the buffer which is on a 32byte boundary will not get freed, instead it tries to free another buffer with the error message. This patch fixes the issue by creating the smallest DMA buffer with the size of ARCH_DMA_MINALIGN. This will be either 32 or 64 bytes. If the ARCH_DMA_MINALIGN is 128 (currently powerpc64, mips ip32, x86 pentium 4) then it will create the first buffer with 128 bytes and will have only 3 buffers. There is a BUILD_BUG_ON() now in case someone has a minalign of 128 bytes or more. More than 128 bytes. Not 128 bytes or more. edited by hand, thanks. greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] usb: core: buffer: smallest buffer should start at ARCH_DMA_MINALIGN
On Wed, Nov 26, 2014 at 09:39:36PM +0100, Sebastian Andrzej Siewior wrote:
the following error pops up during testusb -a -t 10
| musb-hdrc musb-hdrc.1.auto: dma_pool_free buffer-128,
f134e000/be842000 (bad dma)
hcd_buffer_create() creates a few buffers, the smallest has 32 bytes of
size. ARCH_KMALLOC_MINALIGN is set to 64 bytes. This combo results in
hcd_buffer_alloc() returning memory which is 32bytes aligned and it
might by identified by buffer_offset() as another buffer. This means the
buffer which is on a 32byte boundary will not get freed, instead it
tries to free another buffer with the error message.
This patch fixes the issue by creating the smallest DMA buffer with the
size of ARCH_DMA_MINALIGN. This will be either 32 or 64 bytes. If the
ARCH_DMA_MINALIGN is 128 (currently powerpc64, mips ip32, x86 pentium 4) then
it will create the first buffer with 128 bytes and will have only 3
buffers. There is a BUILD_BUG_ON() now in case someone has a minalign of
more than 128 bytes.
Cc: sta...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
Acked-by: Alan Stern st...@rowland.harvard.edu
---
v1…v2: rewrite pool_max so it is less confusing.
drivers/usb/core/buffer.c | 12
include/linux/usb/hcd.h | 8 ++--
2 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/core/buffer.c b/drivers/usb/core/buffer.c
index 684ef70dc09d..5ad5f71d6358 100644
--- a/drivers/usb/core/buffer.c
+++ b/drivers/usb/core/buffer.c
@@ -26,10 +26,13 @@ static const size_t pool_max[HCD_BUFFER_POOLS] = {
/* platforms without dma-friendly caches might need to
* prevent cacheline sharing...
*/
- 32,
- 128,
- 512,
- PAGE_SIZE / 2
+#if ARCH_KMALLOC_MINALIGN = 32
+ 32, 128, 512, PAGE_SIZE / 2,
+#elif ARCH_KMALLOC_MINALIGN = 64
+ 64, 128, 512, PAGE_SIZE / 2,
+#else
+ 128, 512, PAGE_SIZE / 2
+#endif
G /* bigger -- allocate pages */
};
@@ -58,6 +61,7 @@ int hcd_buffer_create(struct usb_hcd *hcd)
!(hcd-driver-flags HCD_LOCAL_MEM))
return 0;
+ BUILD_BUG_ON(ARCH_KMALLOC_MINALIGN 128);
for (i = 0; i HCD_BUFFER_POOLS; i++) {
size = pool_max[i];
if (!size)
diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
index cd96a2bc3388..1e2234ca448d 100644
--- a/include/linux/usb/hcd.h
+++ b/include/linux/usb/hcd.h
@@ -23,6 +23,7 @@
#include linux/rwsem.h
#include linux/interrupt.h
+#include linux/slab.h
#define MAX_TOPO_LEVEL 6
@@ -171,8 +172,11 @@ struct usb_hcd {
struct usb_hcd *shared_hcd;
struct usb_hcd *primary_hcd;
-
-#define HCD_BUFFER_POOLS 4
+#if ARCH_KMALLOC_MINALIGN = 64
+ #define HCD_BUFFER_POOLS4
+#else
+ #define HCD_BUFFER_POOLS3
+#endif
struct dma_pool *pool[HCD_BUFFER_POOLS];
int state;
This breaks the build so badly, it's obvious you never tested it out.
never do that again.
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: Suspected (out of tree) HCI issue
On Wed, 26 Nov 2014 16:25:08 -0500 (EST), Alan Stern st...@rowland.harvard.edu wrote: Since this driver seems to be based on work by Synopsys, maybe someone from that company can help. (By the way, the license information in the ifxhcd.h header file doesn't say anything about the GPL. That doesn't seem kosher.) Actually the topmost chunk, mentioning Lantiq copyright, does. But it also says parts (which ?) are copyright Synopsys with a redistribute but keep this notice licence. So at time 100.332 the URB completes and the completion routine resubmits it. At time 101.436 the driver tries to kill the URB. At 101.440 the URB completes (presumably with a status code indicating that it was killed) and the completion routine resubmits it. Evidently the resubmission succeeds, because usb_hcd_submit_urb's atomic_dec is not hit. Resubmission of a killed URB is not supposed to succeed. Aha, this may just be what I was missing. I was aiming at getting use_count down by finding some missing completion call, rather than questioning that last submission's success. If it does, it means there's a bug in the HCD: It isn't calling usb_hcd_link_urb_to_ep() properly. Indeed, no trace of this function being called. Maybe you can adapt an in-tree HCD to work with your host controller hardware. The ifxhcd driver doesn't look so hot, at first glance. Maybe it can be fixed up... Looking at drivers/usb/host I see quite short files which I understand as hardware-specific (ex: 551 lines for ehci-terga.c). Such length should be in my reach, but the 6k lines of some non-[eo]hci are very likely not. I'll try to understand how this controller would fit in. Thanks a lot for your answers, -- Vincent Pelletier -- 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
