Re: [PATCH 4/8] usb: ehci: add freescale imx28 special write register method
Hello Peter and Greg, On 01/06/2014 03:10 AM, Peter Chen wrote: According to Freescale imx28 Errata, ENGR119653 USB: ARM to USB register error issue, All USB register write operations must use the ARM SWP instruction. So, we implement a special ehci_write for imx28. Discussion for it at below: http://marc.info/?l=linux-usbm=137996395529294w=2 Signed-off-by: Peter Chen peter.c...@freescale.com Acked-by: Alan Stern st...@rowland.harvard.edu Signed-off-by: Marc Kleine-Budde m...@pengutronix.de Tested-by: Marc Kleine-Budde m...@pengutronix.de please add stable on Cc for this and the next two patches: [PATCH 4/8] usb: ehci: add freescale imx28 special write register method [PATCH 5/8] usb: chipidea: add freescale imx28 special write register method [PATCH 6/8] usb: chipidea: imx: set CI_HDRC_IMX28_WRITE_FIX for imx28 Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de | signature.asc Description: OpenPGP digital signature
[PATCH net-next v2 0/3] adjust the code of r8152
Replace some tabs and modify the return value of rtl_ops_init(). v2: add the terminating newline for the message of patch #3. Hayes Wang (3): r8152: replace some tabs with spaces r8152: move the actions of saving the information of the device r8152: replace the return value of rtl_ops_init drivers/net/usb/r8152.c | 43 +++ 1 file changed, 23 insertions(+), 20 deletions(-) -- 1.8.4.2 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next v2 1/3] r8152: replace some tabs with spaces
Replace the tabs of the variables declaration with the spaces.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 13fabbb..095f15b 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -584,8 +584,8 @@ int set_registers(struct r8152 *tp, u16 value, u16 index,
u16 size, void *data)
static int generic_ocp_read(struct r8152 *tp, u16 index, u16 size,
void *data, u16 type)
{
- u16 limit = 64;
- int ret = 0;
+ u16 limit = 64;
+ int ret = 0;
if (test_bit(RTL8152_UNPLUG, tp-flags))
return -ENODEV;
@@ -624,9 +624,9 @@ static int generic_ocp_read(struct r8152 *tp, u16 index,
u16 size,
static int generic_ocp_write(struct r8152 *tp, u16 index, u16 byteen,
u16 size, void *data, u16 type)
{
- int ret;
- u16 byteen_start, byteen_end, byen;
- u16 limit = 512;
+ int ret;
+ u16 byteen_start, byteen_end, byen;
+ u16 limit = 512;
if (test_bit(RTL8152_UNPLUG, tp-flags))
return -ENODEV;
@@ -1812,8 +1812,8 @@ static void r8152b_exit_oob(struct r8152 *tp)
static void r8152b_enter_oob(struct r8152 *tp)
{
- u32 ocp_data;
- int i;
+ u32 ocp_data;
+ int i;
ocp_data = ocp_read_byte(tp, MCU_TYPE_PLA, PLA_OOB_CTRL);
ocp_data = ~NOW_IS_OOB;
@@ -2340,7 +2340,7 @@ static void r8153_clear_bp(struct r8152 *tp)
static void r8152b_enable_eee(struct r8152 *tp)
{
- u32 ocp_data;
+ u32 ocp_data;
ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEE_CR);
ocp_data |= EEE_RX_EN | EEE_TX_EN;
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next v2 2/3] r8152: move the actions of saving the information of the device
Some information of the device may be used in other functions. Move
the relative code to make sure it would be initialzed correctly
before using it.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 095f15b..8615681 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2759,6 +2759,10 @@ static int rtl8152_probe(struct usb_interface *intf,
tp = netdev_priv(netdev);
tp-msg_enable = 0x7FFF;
+ tp-udev = udev;
+ tp-netdev = netdev;
+ tp-intf = intf;
+
if (!rtl_ops_init(tp, id)) {
netif_err(tp, probe, netdev, Unknown Device);
return -ENODEV;
@@ -2767,9 +2771,6 @@ static int rtl8152_probe(struct usb_interface *intf,
tasklet_init(tp-tl, bottom_half, (unsigned long)tp);
INIT_DELAYED_WORK(tp-schedule, rtl_work_func_t);
- tp-udev = udev;
- tp-netdev = netdev;
- tp-intf = intf;
netdev-netdev_ops = rtl8152_netdev_ops;
netdev-watchdog_timeo = RTL8152_TX_TIMEOUT;
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net] r8152: add terminating newline
The netif_err() and netif_info() should have the terminating newline
at the end of the message.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 5107372..3d8a565 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -2135,11 +2135,11 @@ static int rtl8152_probe(struct usb_interface *intf,
ret = register_netdev(netdev);
if (ret != 0) {
- netif_err(tp, probe, netdev, couldn't register the device);
+ netif_err(tp, probe, netdev, couldn't register the device\n);
goto out1;
}
- netif_info(tp, probe, netdev, %s, DRIVER_VERSION);
+ netif_info(tp, probe, netdev, %s\n, DRIVER_VERSION);
return 0;
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
advertencia.
Usted necesita para proteger la seguridad de su cuenta de correo electrónico, con el fin de evitar la interrupción de sus servicios. Haga clic en siguiente enlace para activar. http://utru.st/32 -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 3/9] phy: Add new Exynos USB 2.0 PHY driver
Hi,
On Friday 20 December 2013 06:54 PM, Kamil Debski wrote:
Add a new driver for the Exynos USB 2.0 PHY. The new driver uses the generic
PHY framework. The driver includes support for the Exynos 4x10 and 4x12
SoC families.
Signed-off-by: Kamil Debski k.deb...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
.../devicetree/bindings/phy/samsung-phy.txt| 55
drivers/phy/Kconfig| 29 ++
drivers/phy/Makefile |3 +
drivers/phy/phy-exynos4210-usb2.c | 257
drivers/phy/phy-exynos4212-usb2.c | 306
drivers/phy/phy-samsung-usb2.c | 226 +++
drivers/phy/phy-samsung-usb2.h | 67 +
7 files changed, 943 insertions(+)
create mode 100644 drivers/phy/phy-exynos4210-usb2.c
create mode 100644 drivers/phy/phy-exynos4212-usb2.c
create mode 100644 drivers/phy/phy-samsung-usb2.c
create mode 100644 drivers/phy/phy-samsung-usb2.h
.
.
snip
.
.
diff --git a/drivers/phy/phy-samsung-usb2.h b/drivers/phy/phy-samsung-usb2.h
new file mode 100644
index 000..ab89f91
--- /dev/null
+++ b/drivers/phy/phy-samsung-usb2.h
@@ -0,0 +1,67 @@
+/*
+ * Samsung SoC USB 1.1/2.0 PHY driver
+ *
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Kamil Debski k.deb...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _PHY_EXYNOS_USB2_H
+#define _PHY_EXYNOS_USB2_H
+
+#include linux/clk.h
+#include linux/phy/phy.h
+#include linux/device.h
+#include linux/regmap.h
+#include linux/spinlock.h
+
+#define KHZ 1000
+#define MHZ (KHZ * KHZ)
+
+struct samsung_usb2_phy_driver;
+struct samsung_usb2_phy_instance;
+struct samsung_usb2_phy_config;
+
+struct samsung_usb2_phy_instance {
+ const struct samsung_usb2_common_phy *cfg;
+ struct clk *clk;
+ struct phy *phy;
+ struct samsung_usb2_phy_driver *drv;
+ unsigned long rate;
+ u32 clk_reg_val;
+ bool enabled;
+};
+
+struct samsung_usb2_phy_driver {
+ const struct samsung_usb2_phy_config *cfg;
+ struct clk *clk;
+ struct device *dev;
+ void __iomem *reg_phy;
+ struct regmap *reg_pmu;
+ struct regmap *reg_sys;
+ spinlock_t lock;
+ struct samsung_usb2_phy_instance instances[0];
I think having instances as array here would allocate more space while
allocating 'samsung_usb2_phy_driver' in 'samsung_usb2_phy_probe'.
Thanks
Kishon
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
From: walt ... /* Accept arbitrarily long scatter-gather lists */ - hcd-self.sg_tablesize = ~0; + hcd-self.sg_tablesize = 31; Even if that reduces the number of fragments passed to the xhci driver it may not be enough to limit the actual number of fragments that need to be placed in the ring itself. The xhci driver has to split every fragment on any 64k address boundary. One possibility is to scan long SG lists to see it they are actually problematic. If all the fragments are suitably aligned let them through (without any nops). My gut feeling is that problems only arise when the ring end isn't at a 1k boundary in the data. So provided all the fragments are multiples of 1k (after splitting on 64k boundaries) the transfer will be processed correctly. Alternatively, if the fragments are all longer than 1k (after the 64k split), the one that crosses the ring end can be split in two. A quick 'fix' would be to assume that anything with too many fragments is probably ok - maybe check the first fragment is suitably aligned. That would recover the old behaviour for usb disk transfers with a lot of fragments - yes it is a hack... David
Re: [PATCH v1] xhci: Switch Intel Lynx Point ports to EHCI on shutdown
Hi Sarah, On 01/03/2014 02:03 AM, Sarah Sharp wrote: Denis, do all of Compulab's Haswell systems reboot on shutdown? Are they all running a Phoenix BIOS? Can you send me the output of `sudo lspci -vvv -s` for the xHCI host? oem@oem-Intense-PC2 ~ $ sudo lspci -vvv -s 00:14.0 00:14.0 USB controller: Intel Corporation Lynx Point-LP USB xHCI HC (rev 04) (prog-if 30 [XHCI]) Subsystem: Intel Corporation Device 7270 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Interrupt: pin A routed to IRQ 59 Region 0: Memory at f062 (64-bit, non-prefetchable) [size=64K] Capabilities: [70] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot+,D3cold+) Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+ Address: fee0200c Data: 41b1 Kernel driver in use: xhci_hcd Basically, I'm trying to find a common variable to key off. I suspect BIOS vendor is probably the right thing, instead of system vendor. By the way the quirk introduced by commit e95829f474f0db3a4d940cae1423783edd966027 xhci: Switch PPT ports to EHCI on shutdown. works for Lynx Point as well at least on Intense-PC2. I mean we can add XHCI_SPURIOUS_REBOOT flag that invokes usb_disable_xhci_ports(). May be this solution works for HP and other systems without side effects? Denis -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ohci-platform: Add support for devicetree instantiation
On Sun, Jan 05, 2014 at 11:04:39PM +, Hans de Goede wrote: Add support for ohci-platform instantiation from devicetree, including optionally getting clks and a phy from devicetree, and enabling / disabling those on power_on / off. This should allow using ohci-platform from devicetree in various cases. Specifically after this commit it can be used for the ohci controller found on Allwinner sunxi SoCs. Signed-off-by: Hans de Goede hdego...@redhat.com --- .../devicetree/bindings/usb/platform-ohci.txt | 25 drivers/usb/host/ohci-platform.c | 146 ++--- 2 files changed, 151 insertions(+), 20 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/platform-ohci.txt diff --git a/Documentation/devicetree/bindings/usb/platform-ohci.txt b/Documentation/devicetree/bindings/usb/platform-ohci.txt new file mode 100644 index 000..6846f1c --- /dev/null +++ b/Documentation/devicetree/bindings/usb/platform-ohci.txt @@ -0,0 +1,25 @@ +Generic Platform OHCI controller + +Required properties: + - compatible: Should be platform-ohci To me, platform-ohci seems rather Linux-specific. Platform devices are a Linux abstraction that don't correspond to any particular bus type in reality. We have some *-generic bindings. A name of that form might be more appropriate. Or we could choose an arbitrary OHCI implementation's vendor,ochi string and everything else can declare compatibility with that. + - reg: Address range of the ohci registers. + - interrupts: Should contain the ohci interrupt. + +Optional properties: + - clocks: array of clocks + - clock-names: clock names ahb and/or ohci A description of what the clocks are might be helpful. How about something like: - clocks: a list of phandle + clock specifier pairs, one for each entry in clock-names. - clock-names: Should contain: * ahb - some description here. * ohci - some description here. Thanks, Mark. -- 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: Bug#733826: crazy loop xhci_hcd Too many fragments
From: Alan Stern Subject: Re: Bug#733826: crazy loop xhci_hcd Too many fragments On Mon, 6 Jan 2014, Ben Hutchings wrote: On Sat, 2014-01-04 at 05:44 +0800, jida...@jidanni.org wrote: ... # cat /var/log/syslog Jan 1 06:57:38 jidanni5 ntpd[2822]: Listen normally on 5 lo ::1 UDP 123 Jan 1 06:57:38 jidanni5 ntpd[2822]: Listen normally on 6 eth0 fe80::2289:84ff:fe28:ad9 UDP 123 Jan 1 06:57:38 jidanni5 ntpd[2822]: peers refreshed Jan 1 06:57:38 jidanni5 ntpd[2822]: Listening on routing socket on fd #23 for interface updates Jan 1 07:04:49 jidanni5 kernel: [ 559.624680] xhci_hcd :00:14.0: Too many fragments 79, max 63 Jan 1 07:04:49 jidanni5 kernel: [ 559.624695] xhci_hcd :00:14.0: Too many fragments 79, max 63 Jan 1 07:04:49 jidanni5 kernel: [ 559.624704] xhci_hcd :00:14.0: Too many fragments 79, max 63 10 lines later... oops I mean an actual MILLION lines later Assuming my fix for the repetition is correct, the remaining problem is why usb-storage is generating such large/fragmented urbs. usb-storage doesn't generate large or fragmented anything. It merely passes on the scatter-gather information it gets from the block layer. Although not a real fix to the underlying problem, it seems that the default ring size is far too small. Any amount of network traffic also activates the ring expansion code. IIRC each ring entry is 16 bytes, so increasing the ring size to 256 still keeps the rings to a single 4k page. Whether anything regularly exceeds 255 fragments is a another matter. 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: [PATCH 1/2] ohci-platform: Add support for devicetree instantiation
On Mon, 6 Jan 2014, Hans de Goede wrote: Add support for ohci-platform instantiation from devicetree, including optionally getting clks and a phy from devicetree, and enabling / disabling those on power_on / off. This should allow using ohci-platform from devicetree in various cases. Specifically after this commit it can be used for the ohci controller found on Allwinner sunxi SoCs. Signed-off-by: Hans de Goede hdego...@redhat.com --- .../devicetree/bindings/usb/platform-ohci.txt | 25 drivers/usb/host/ohci-platform.c | 146 ++--- 2 files changed, 151 insertions(+), 20 deletions(-) create mode 100644 Documentation/devicetree/bindings/usb/platform-ohci.txt diff --git a/Documentation/devicetree/bindings/usb/platform-ohci.txt b/Documentation/devicetree/bindings/usb/platform-ohci.txt new file mode 100644 index 000..6846f1c --- /dev/null +++ b/Documentation/devicetree/bindings/usb/platform-ohci.txt @@ -0,0 +1,25 @@ +Generic Platform OHCI controller + +Required properties: + - compatible: Should be platform-ohci + - reg: Address range of the ohci registers. + - interrupts: Should contain the ohci interrupt. + +Optional properties: + - clocks: array of clocks + - clock-names: clock names ahb and/or ohci Where does ahb come from, what does it mean, and how is it relevant to generic platforms? What about platforms that use 3 clocks? 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 1/2] ohci-platform: Add support for devicetree instantiation
On Monday 06 January 2014, Hans de Goede wrote:
On 01/06/2014 08:16 AM, Arnd Bergmann wrote:
On Monday 06 January 2014, Hans de Goede wrote:
+Required properties:
+ - compatible: Should be platform-ohci
+ - reg: Address range of the ohci registers.
+ - interrupts: Should contain the ohci interrupt.
+
+Optional properties:
+ - clocks: array of clocks
+ - clock-names: clock names ahb and/or ohci
+ - phys: phy
+ - phy-names: usb_phy
Maybe just usb? It obviously is a phy, so that part of the name
is a bit redundant. Actually, the usb part of the name also seems
redundant. Is it possible to make it an anonymous phy reference
without a phy-names property as we often do for clocks?
I'm not a big fan of anonymous references, IE currently the ahci-platform
driver is using an anonymous clk reference, but for sunxi (and ie imx too)
it needs to be extended to 2 clks, which means using names, while
keeping compatibility with the older anonymous using dts (and board)
files.
So I can agree to dropping the _phy, but I would like to keep the usb
name I realize the chances are slim of ever needing 2 phys but never
say never ...
Ok, fair enough.
Style-wise, I think I'd prefer not storing error values in the
ohci_platform_priv struct, but rather using NULL pointers for
when the clocks or phy references are unused.
This is a style I picked up from the mmc code, ie do a grep for
!IS_ERR in drivers/mmc/host/*.c, but I agree it is not the prettiest,
and on looking in other subsystems it is not common, so I'll convert
this to storing NULL on error to get the phy or clk.
Ok, thanks.
@@ -83,17 +171,30 @@ static int ohci_platform_probe(struct platform_device
*dev)
return -ENXIO;
}
+ hcd = usb_create_hcd(ohci_platform_hc_driver, dev-dev,
+ dev_name(dev-dev));
+ if (!hcd)
+ return -ENOMEM;
+
+ if (pdata == ohci_platform_defaults) {
+ struct ohci_platform_priv *priv = (struct ohci_platform_priv *)
+hcd_to_ohci(hcd)-priv;
+
+ priv-phy = devm_phy_get(dev-dev, usb_phy);
+ if (IS_ERR(priv-phy) PTR_ERR(priv-phy) == -EPROBE_DEFER) {
+ err = -EPROBE_DEFER;
+ goto err_put_hcd;
+ }
+
+ priv-ohci_clk = devm_clk_get(dev-dev, ohci);
+ priv-ahb_clk = devm_clk_get(dev-dev, ahb);
+ }
I think you have to check the clocks for -EPROBE_DEFER as well here, not
just the PHY.
So far I've never seen clk_get return -EPROBE_DEFER, but I guess on some
platforms it can.
Right. Most clock controllers tend to be initialized at early boot
time, but some of them are on external PMICs that are only probed after
i2c or some other subsystem is up.
Otherwise you don't know the difference between no clock
provided, error getting the clock reference and clock controller not
initialized yet, try again.
I guess of these 3 we really only want to continue on no clock provided,
so I think something like this (for both clks and the phy) would be best:
priv-ahb_clk = devm_clk_get(dev-dev, ahb);
if (IS_ERR(priv-ahb_clk)) {
err = PTR_ERR(priv-ahb_clk);
if (err != -EINVAL err != -ENODATA)
goto err_put_hcd;
priv-ahb_clk = NULL; /* No clock provided */
}
To clarify -EINVAL will be returned when there is no clock-names, and
-ENODATA when the specified name is not found in clock-names.
Ok, looks good.
@@ -178,6 +277,12 @@ static int ohci_platform_resume(struct device *dev)
#define ohci_platform_resume NULL
#endif /* CONFIG_PM */
+static const struct of_device_id ohci_platform_ids[] = {
+ { .compatible = platform-ohci, },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ohci_platform_ids);
I never liked the platform-* naming for compatible properties, the
name of the driver is just based on a linux implementation detail
(the platform bus), which could change. How about just calling the
generic one ohci or usb-ohci?
usb-ohci seems free but usb-ehci are already taken by
drivers/usb/host/ehci-ppc-of.c which is as the name implies pretty ppc
specific. And since ehci-platform.c can be build on ppc too, we could
end up with 2 drivers claiming the same compatibility string on ppc.
Also uhci-platform.c is already using platform-uhci, so using
ohci-platform and ehci-platform seems consistent and avoids the
conflict with drivers/usb/host/ehci-ppc-of.c
Hmm, that file seems to do two things that ehci-platform doesn't:
It handles big-endian controllers and it has special initialization
for compatible=ibm,usb-ehci-440epx. It also uses a different way
to get to the resources because the driver dates back to before the
unification of platform_bus and of_platform_bus, but that can be
trivially changed.
I would hope
[PATCH] hso: fix handling of modem port SERIAL_STATE notifications
The existing serial state notification handling expected older Option
devices, having a hardcoded assumption that the Modem port was always
USB interface #2. That isn't true for devices from the past few years.
hso_serial_state_notification is a local cache of a USB Communications
Interface Class SERIAL_STATE notification from the device, and the
USB CDC specification (section 6.3, table 67 Class-Specific Notifications)
defines wIndex as the USB interface the event applies to. For hso
devices this will always be the Modem port, as the Modem port is the
only port which is set up to receive them by the driver.
So instead of always expecting USB interface #2, instead validate the
notification with the actual USB interface number of the Modem port.
Signed-off-by: Dan Williams d...@redhat.com
Tested-by: H. Nikolaus Schaller h...@goldelico.com
---
drivers/net/usb/hso.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 86292e6..1a48234 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -181,15 +181,14 @@ enum rx_ctrl_state{
RX_SENT,
RX_PENDING
};
#define BM_REQUEST_TYPE (0xa1)
#define B_NOTIFICATION (0x20)
#define W_VALUE (0x0)
-#define W_INDEX (0x2)
#define W_LENGTH(0x2)
#define B_OVERRUN (0x16)
#define B_PARITY(0x15)
#define B_FRAMING (0x14)
#define B_RING_SIGNAL (0x13)
#define B_BREAK (0x12)
@@ -1483,31 +1482,41 @@ static void tiocmget_intr_callback(struct urb *urb)
struct hso_serial *serial = urb-context;
struct hso_tiocmget *tiocmget;
int status = urb-status;
u16 UART_state_bitmap, prev_UART_state_bitmap;
struct uart_icount *icount;
struct hso_serial_state_notification *serial_state_notification;
struct usb_device *usb;
+ int if_num;
/* Sanity checks */
if (!serial)
return;
if (status) {
handle_usb_error(status, __func__, serial-parent);
return;
}
+
+ /* tiocmget is only supported on HSO_PORT_MODEM */
tiocmget = serial-tiocmget;
if (!tiocmget)
return;
+ BUG_ON((serial-parent-port_spec HSO_PORT_MASK) != HSO_PORT_MODEM);
+
usb = serial-parent-usb;
+ if_num = serial-parent-interface-altsetting-desc.bInterfaceNumber;
+
+ /* wIndex should be the USB interface number of the port to which the
+* notification applies, which should always be the Modem port.
+*/
serial_state_notification = tiocmget-serial_state_notification;
if (serial_state_notification-bmRequestType != BM_REQUEST_TYPE ||
serial_state_notification-bNotification != B_NOTIFICATION ||
le16_to_cpu(serial_state_notification-wValue) != W_VALUE ||
- le16_to_cpu(serial_state_notification-wIndex) != W_INDEX ||
+ le16_to_cpu(serial_state_notification-wIndex) != if_num ||
le16_to_cpu(serial_state_notification-wLength) != W_LENGTH) {
dev_warn(usb-dev,
hso received invalid serial state notification\n);
DUMP(serial_state_notification,
sizeof(struct hso_serial_state_notification));
} else {
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: ftdi_sio: added CS5 quirk for broken smartcard readers
Genuine FTDI chips support only CS7/8. A previous fix enforced this
limitation and reported it back to userspace.
However, certain types of smartcard readers depend on specific
driver behaviour that requests 0 data bits (not 5) to change into a
different operating mode if CS5 has been set.
This patch reenables this behaviour for all FTDI devices.
Tagged to be added to stable, because it affects a lot of users of
embedded systems which rely on these readers to work properly.
Cc: sta...@vger.kernel.org
Tested-by: Heinrich Siebmanns h.siebma...@t-online.de
Signed-off-by: Colin Leitner colin.leit...@gmail.com
---
drivers/usb/serial/ftdi_sio.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index fb0d537..f3def6bb 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -2125,9 +2125,20 @@ static void ftdi_set_termios(struct tty_struct *tty,
/*
* All FTDI UART chips are limited to CS7/8. We won't pretend to
-* support CS5/6 and revert the CSIZE setting instead.
+* support CS6 and revert the CSIZE setting instead.
+*
+* Some smartcard readers abuse this limitation to switch modes.
+* Original FTDI chips fall back to eight data bits.
+*
+* TODO: Implement a quirk to only allow this with mentioned
+* readers. One I know of (Argolis Smartreader V1)
+* returns USB smartcard server as iInterface string.
+* The vendor didn't bother with a custom VID/PID of
+* course.
*/
- if ((C_CSIZE(tty) != CS8) (C_CSIZE(tty) != CS7)) {
+ if ((C_CSIZE(tty) != CS5)
+(C_CSIZE(tty) != CS8)
+(C_CSIZE(tty) != CS7)) {
dev_warn(ddev, requested CSIZE setting not supported\n);
termios-c_cflag = ~CSIZE;
@@ -2174,6 +2185,9 @@ no_skip:
urb_value |= FTDI_SIO_SET_DATA_PARITY_NONE;
}
switch (cflag CSIZE) {
+ case CS5:
+ dev_dbg(ddev, Setting CS5 quirk\n);
+ break;
case CS7:
urb_value |= 7;
dev_dbg(ddev, Setting CS7\n);
--
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: [PATCH v6] usb: gadget: Add UDC driver for Aeroflex Gaisler GRUSBDC
Hi,
Apologies for the late reply, I wasn't able to access my mail much over
the Christmas break.
On Mon, Dec 23, 2013 at 08:25:49PM +, Andreas Larsson wrote:
This adds an UDC driver for GRUSBDC USB Device Controller cores available in
the
GRLIB VHDL IP core library. The driver only supports DMA mode.
Signed-off-by: Andreas Larsson andr...@gaisler.com
---
Differences since v1:
- Use hexprint for debug printoutes instead of homemade equivalent
- Use the dev_* printk variants over the board
- Get rid of unnecessary casts and includes
- Use USB_STATE_NOTATTACHED instead of USB_STATE_ATTACHED for clarity
- Get rid of commented out VERBOSE_DEBUG definition
- Do not devm-allocate any requests
- Get rid of unnecessary resqueduling of the workqueue handler
- Make sure that gadget setup function is called with interrupts disabled
Differences since v2:
- Fixed an error printout
- Got rid of the work queue in favor of threaded interrupts
Differences since v3:
- Disable interrupts when locking spinlocks instead of using
local_irq_save deeper within critical section
Differences since v4:
- Set quirk_ep_out_aligned_size
- Use usb_ep_set_maxpacket_limit
- Add devicetree documentation
Differences since v5:
- Declare unexpected spin_unlock and spin_lock for sparse
- Fix a bad comment
- Use ACCESS_ONCE instead of gr_read32 when checking for update of dma
descriptor
Documentation/devicetree/bindings/usb/gr-udc.txt | 28 +
drivers/usb/gadget/Kconfig |7 +
drivers/usb/gadget/Makefile |1 +
drivers/usb/gadget/gr_udc.c | 2242
++
drivers/usb/gadget/gr_udc.h | 220 +++
5 files changed, 2498 insertions(+)
create mode 100644 Documentation/devicetree/bindings/usb/gr-udc.txt
create mode 100644 drivers/usb/gadget/gr_udc.c
create mode 100644 drivers/usb/gadget/gr_udc.h
diff --git a/Documentation/devicetree/bindings/usb/gr-udc.txt
b/Documentation/devicetree/bindings/usb/gr-udc.txt
new file mode 100644
index 000..0c5118f
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/gr-udc.txt
@@ -0,0 +1,28 @@
+USB Peripheral Controller driver for Aeroflex Gaisler GRUSBDC.
+
+The GRUSBDC USB Device Controller core is available in the GRLIB VHDL
+IP core library.
+
+Note: In the ordinary environment for the core, a Leon SPARC system,
+these properties are built from information in the AMBA plugplay.
+
+Required properties:
+
+- name : Should be GAISLER_USBDC or 01_021
What's this for?
Why is this not matched using a compatible string?
What does 01_021 mean?
+
+- reg : Address and length of the register set for the device
+
+- interrupts : Interrupt numbers for this device
How many, and what do they correspond to?
+
+Optional properties:
+
+- epobufsizes : An array of buffer sizes for OUT endpoints. If the property
is
+ not present, or for endpoints outside of the array, 1024 is assumed by
+ the driver.
+
+- epibufsizes : An array of buffer sizes for IN endpoints. If the property is
+ not present, or for endpoints outside of the array, 1024 is assumed by
+ the driver.
These names are rather opaque. Something like {input,output}-buf-lens
would be far clearer.
How many entries are expected?
A specific driver should have no relevance to the binding. Just say if
not 1024.
[...]
+/* Must be called with dev-lock held */
+static int gr_udc_init(struct gr_udc *dev)
+{
+ struct device_node *np = dev-dev-of_node;
+ u32 epctrl_val;
+ u32 dmactrl_val;
+ int i;
+ int ret = 0;
+ u32 *bufsizes;
+ u32 bufsize;
+ int len;
+
+ gr_set_address(dev, 0);
+
+ INIT_LIST_HEAD(dev-gadget.ep_list);
+ dev-gadget.speed = USB_SPEED_UNKNOWN;
+ dev-gadget.ep0 = dev-epi[0].ep;
+
+ INIT_LIST_HEAD(dev-ep_list);
+ gr_set_ep0state(dev, GR_EP0_DISCONNECT);
+
+ bufsizes = (u32 *)of_get_property(np, epobufsizes, len);
of_get_property gives you the raw property value bye string, which is
_not_ a u32 pointer -- it's not necessarily the same endianness as the
kernel. Please use an appropriate accessor.
+ len /= sizeof(u32);
+ for (i = 0; i dev-nepo; i++) {
+ bufsize = (bufsizes i len) ? bufsizes[i] : 1024;
You can use of_property_read_u32_index within the loop for this:
if (of_property_read_u32_index(np, epobufsizes, bufsize)
bufsize = 1024;
+ ret = gr_ep_init(dev, i, 0, bufsize);
+ if (ret)
+ return ret;
+ }
+
+ bufsizes = (u32 *)of_get_property(np, epibufsizes, len);
+ len /= sizeof(u32);
+ for (i = 0; i dev-nepi; i++) {
+ bufsize = (bufsizes i len) ? bufsizes[i] : 1024;
Likewise here.
[...]
+static int gr_probe(struct platform_device *ofdev)
+{
+
Re: Bug#733826: crazy loop xhci_hcd Too many fragments
On Mon, Jan 06, 2014 at 03:52:24PM +, David Laight wrote: From: Alan Stern Subject: Re: Bug#733826: crazy loop xhci_hcd Too many fragments On Mon, 6 Jan 2014, Ben Hutchings wrote: On Sat, 2014-01-04 at 05:44 +0800, jida...@jidanni.org wrote: ... # cat /var/log/syslog Jan 1 06:57:38 jidanni5 ntpd[2822]: Listen normally on 5 lo ::1 UDP 123 Jan 1 06:57:38 jidanni5 ntpd[2822]: Listen normally on 6 eth0 fe80::2289:84ff:fe28:ad9 UDP 123 Jan 1 06:57:38 jidanni5 ntpd[2822]: peers refreshed Jan 1 06:57:38 jidanni5 ntpd[2822]: Listening on routing socket on fd #23 for interface updates Jan 1 07:04:49 jidanni5 kernel: [ 559.624680] xhci_hcd :00:14.0: Too many fragments 79, max 63 Jan 1 07:04:49 jidanni5 kernel: [ 559.624695] xhci_hcd :00:14.0: Too many fragments 79, max 63 Jan 1 07:04:49 jidanni5 kernel: [ 559.624704] xhci_hcd :00:14.0: Too many fragments 79, max 63 10 lines later... oops I mean an actual MILLION lines later Assuming my fix for the repetition is correct, the remaining problem is why usb-storage is generating such large/fragmented urbs. usb-storage doesn't generate large or fragmented anything. It merely passes on the scatter-gather information it gets from the block layer. Although not a real fix to the underlying problem, it seems that the default ring size is far too small. Did you mean ring segment size? Any amount of network traffic also activates the ring expansion code. IIRC each ring entry is 16 bytes, so increasing the ring size to 256 still keeps the rings to a single 4k page. Whether anything regularly exceeds 255 fragments is a another matter. If so, yes, changing the segment size makes sense. TRBS_PER_SEGMENT could be increased to 256. I'm not sure if we should switch to using dma_alloc_coherent instead of a DMA pool. Some systems could be using bigger than 4K pages, so we should probably still stick with DMA pools. Ben, can you change your patch to increase TRBS_PER_SEGMENT to 256? 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] usb: Skip U1/U2 LPM disable if device is disconnected.
On Fri, Jan 03, 2014 at 04:49:16PM -0800, Greg KH wrote: On Fri, Jan 03, 2014 at 04:22:45PM -0800, Sarah Sharp wrote: Occasionally when a USB 3.0 device is disconnected, the roothub port goes into the SS.Inactive state, rather than reporting a disconnect. Is that a hardware bug? Or just something inherent in how the spec says things can work? Inherent in how the spec works. If link training with the device fails in a specific way, USB 3.0 hubs and host ports will go into this state. The xHCI roothub port state machines show it's valid for the host to transition into SS.Inactive from any state (except powered off or disabled). 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 v5 1/3] usb: ohci-at91: replace request_mem_region + ioremap by devm_ioremap_resource
Boris,
On Mon, Dec 9, 2013 at 12:51 AM, Boris BREZILLON
b.brezil...@overkiz.com wrote:
Replace the request_mem_region + ioremap calls by the
devm_ioremap_resource call which does the same things but with device
managed resources.
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
Signed-off-by: Alan Stern st...@rowland.harvard.edu
Did you build these patches? There's several breakages due to them in
last night's next. I'm a little puzzled how they passed testing before
you submitted?
This one fails with:
drivers/usb/host/ohci-at91.c: In function 'usb_hcd_at91_probe':
drivers/usb/host/ohci-at91.c:157:36: error: 'dev' undeclared (first
use in this function)
hcd-regs = devm_ioremap_resource(dev, res);
^
drivers/usb/host/ohci-at91.c:157:36: note: each undeclared identifier
is reported only once for each function it appears in
drivers/usb/host/ohci-at91.c:157:41: error: 'res' undeclared (first
use in this function)
hcd-regs = devm_ioremap_resource(dev, res);
There are more too, the original one I was bisecting for was the below
one, but the above hit first:
drivers/usb/host/ohci-at91.c: In function 'usb_hcd_at91_probe':
drivers/usb/host/ohci-at91.c:190:4: error: label 'err' used but not defined
drivers/usb/host/ohci-at91.c: At top level:
drivers/usb/host/ohci-at91.c:206:2: warning: data definition has no
type or storage class [enabled by default]
drivers/usb/host/ohci-at91.c:206:2: error: type defaults to 'int' in
declaration of 'at91_stop_hc' [-Werror=implicit-int]
drivers/usb/host/ohci-at91.c:206:2: warning: parameter names (without
types) in function declaration [enabled by default]
drivers/usb/host/ohci-at91.c:206:2: error: conflicting types for 'at91_stop_hc'
drivers/usb/host/ohci-at91.c:97:13: note: previous definition of
'at91_stop_hc' was here
drivers/usb/host/ohci-at91.c:208:5: error: expected '=', ',', ';',
'asm' or '__attribute__' before ':' token
drivers/usb/host/ohci-at91.c:210:2: error: expected identifier or '('
before 'return'
drivers/usb/host/ohci-at91.c:211:1: error: expected identifier or '('
before '}' token
drivers/usb/host/ohci-at91.c:97:13: warning: 'at91_stop_hc' defined
but not used [-Wunused-function]
static void at91_stop_hc(struct platform_device *pdev)
Somewhat spectacular. Greg, can you please drop these until he's
sorted out his submission? :(
-Olof
--
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: add terminating newline
On Mon, 2014-01-06 at 17:19 +0800, Hayes Wang wrote:
The netif_err() and netif_info() should have the terminating newline
at the end of the message.
dev_level uses also need terminating newlines.
Perhaps it's a bit more comprehensive to convert the
pr_level_ratelimited uses to use net_ratelimit and
netdev_level.
---
drivers/net/usb/r8152.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 13fabbb..8ae97a5 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -966,10 +966,12 @@ static void read_bulk_callback(struct urb *urb)
case -ENOENT:
return; /* the urb is in unlink state */
case -ETIME:
- pr_warn_ratelimited(may be reset is needed?..\n);
+ if (net_ratelimit())
+ netdev_warn(netdev, maybe reset is needed?\n);
break;
default:
- pr_warn_ratelimited(Rx status %d\n, status);
+ if (net_ratelimit())
+ netdev_warn(netdev, Rx status %d\n, status);
break;
}
@@ -1002,7 +1004,8 @@ static void write_bulk_callback(struct urb *urb)
stats = rtl8152_get_stats(tp-netdev);
if (status) {
- pr_warn_ratelimited(Tx status %d\n, status);
+ if (net_ratelimit())
+ netdev_warn(tp-netdev, Tx status %d\n, status);
stats-tx_errors += agg-skb_num;
} else {
stats-tx_packets += agg-skb_num;
@@ -1079,7 +1082,7 @@ resubmit:
netif_device_detach(tp-netdev);
else if (res)
netif_err(tp, intr, tp-netdev,
- can't resubmit intr, status %d\n, res);
+ can't resubmit intr, status %d\n, res);
}
static inline void *rx_agg_align(void *data)
@@ -1490,7 +1493,7 @@ static void rtl8152_tx_timeout(struct net_device *netdev)
struct r8152 *tp = netdev_priv(netdev);
int i;
- netif_warn(tp, tx_err, netdev, Tx timeout.\n);
+ netif_warn(tp, tx_err, netdev, Tx timeout\n);
for (i = 0; i RTL8152_MAX_TX; i++)
usb_unlink_urb(tp-tx_info[i].urb);
}
@@ -2284,8 +2287,8 @@ static int rtl8152_open(struct net_device *netdev)
if (res) {
if (res == -ENODEV)
netif_device_detach(tp-netdev);
- netif_warn(tp, ifup, netdev,
- intr_urb submit failed: %d\n, res);
+ netif_warn(tp, ifup, netdev, intr_urb submit failed: %d\n,
+ res);
return res;
}
@@ -2751,7 +2754,7 @@ static int rtl8152_probe(struct usb_interface *intf,
netdev = alloc_etherdev(sizeof(struct r8152));
if (!netdev) {
- dev_err(intf-dev, Out of memory);
+ dev_err(intf-dev, Out of memory\n);
return -ENOMEM;
}
@@ -2760,7 +2763,7 @@ static int rtl8152_probe(struct usb_interface *intf,
tp-msg_enable = 0x7FFF;
if (!rtl_ops_init(tp, id)) {
- netif_err(tp, probe, netdev, Unknown Device);
+ netif_err(tp, probe, netdev, Unknown Device\n);
return -ENODEV;
}
@@ -2797,11 +2800,11 @@ static int rtl8152_probe(struct usb_interface *intf,
ret = register_netdev(netdev);
if (ret != 0) {
- netif_err(tp, probe, netdev, couldn't register the device);
+ netif_err(tp, probe, netdev, couldn't register the device\n);
goto out1;
}
- netif_info(tp, probe, netdev, %s, DRIVER_VERSION);
+ netif_info(tp, probe, netdev, %s\n, DRIVER_VERSION);
return 0;
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: Skip U1/U2 LPM disable if device is disconnected.
On Sat, Jan 04, 2014 at 12:09:27PM -0500, Alan Stern wrote:
On Fri, 3 Jan 2014, Sarah Sharp wrote:
Occasionally when a USB 3.0 device is disconnected, the roothub port
goes into the SS.Inactive state, rather than reporting a disconnect. A
warm reset is the only way to get out of this state. khubd notices the
link state in hub_port_events(),
Do you mean hub_events()? There is no hub_port_events() routine.
Yes.
LPM is disabled before the port is reset. At that time, the port is
still in the SS.Inactive state, and the port-connect bit is the same as
it was when hub_events() first read the port status. So how will your
new hub_is_device_disconnected() routine be able to do any better than
the existing code already does?
It sounds like what you really want to do is balance the LPM count but
skip sending the actual request if the port is in the SS.Inactive
state.
Yes, that's what this patch is trying to do. It skips sending the
U1/U2 disable request if the device is disconnected. The connect status
bit is always set to disconnected if the port is in SS.Inactive.
Hmm, and now I see why you're confused. The current code in
hub_events() skips usb_reset_device() if the connect status is
disconnected:
if (hub_port_warm_reset_required(hub, portstatus)) {
int status;
struct usb_device *udev =
hub-ports[i - 1]-child;
dev_dbg(hub_dev, warm reset port %d\n, i);
if (!udev ||
!(portstatus USB_PORT_STAT_CONNECTION) ||
udev-state == USB_STATE_NOTATTACHED) {
status = hub_port_reset(hub, i,
NULL, HUB_BH_RESET_TIME,
true);
if (status 0)
hub_port_disable(hub, i, 1);
} else {
usb_lock_device(udev);
status = usb_reset_device(udev);
usb_unlock_device(udev);
connect_change = 0;
}
I missed that when preparing the patch. I now suspect that the only
reason Girish and Hemanth ran into the U1/U2 timeout issue is because
they're working on an older kernel that doesn't have commit
f3e94aa15dc3d9155f8fc4a3295866d7a207b4e5 usb: core: don't try to
reset_device() a port that got just disconnected (added in 3.12).
I'm extremely sorry for the noise, please ignore this patch.
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: Allow to blacklist xhci_hcd module and use ports with EHCI
Holger Hans Peter Freyther holger@... writes: Happy New Year, xhci_hcd does not work with the Canon Lide scanners and has issues with the suspend/resume handling. My Acer Aspire S5 notebook only exposes USB3.0 ports and the distribution kernels generally have xhci_hcd enabled and I don't have any USB3.0 hardware either. I am using the laptop with the ports routed to the EHCI and I didn't have any suspend/resume issues and I could even do the book keeping of sysmocom on my laptop now. Could we please get to a situation were users that only have USB3.0 ports can either drop to EHCI mode by unloading the xhci_hcd module or preferable be able to blacklist the xhci_hcd so I could even use the stock Debian kernel? thanks holger -- 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: Allow to blacklist xhci_hcd module and use ports with EHCI
On Mon, Jan 06, 2014 at 06:58:01PM +, Holger Freyther wrote: Holger Hans Peter Freyther holger@... writes: Happy New Year, xhci_hcd does not work with the Canon Lide scanners and has issues with the suspend/resume handling. My Acer Aspire S5 notebook only exposes USB3.0 ports and the distribution kernels generally have xhci_hcd enabled and I don't have any USB3.0 hardware either. I am using the laptop with the ports routed to the EHCI and I didn't have any suspend/resume issues and I could even do the book keeping of sysmocom on my laptop now. Could we please get to a situation were users that only have USB3.0 ports can either drop to EHCI mode by unloading the xhci_hcd module or preferable be able to blacklist the xhci_hcd so I could even use the stock Debian kernel? you can blacklist any module you want on /etc/modprobe.d/ on most distros (debian included). -- balbi signature.asc Description: Digital signature
Re: [PATCH] USB: ftdi_sio: added CS5 quirk for broken smartcard readers
On Mon, Jan 06, 2014 at 05:35:57PM +0100, Colin Leitner wrote:
Genuine FTDI chips support only CS7/8. A previous fix enforced this
limitation and reported it back to userspace.
Please include the commit id of the offending commit when fixing
regressions. In this case, you'd refer to commit 8704211f65a2 (USB:
ftdi_sio: fixed handling of unsupported CSIZE setting).
However, certain types of smartcard readers depend on specific
driver behaviour that requests 0 data bits (not 5) to change into a
different operating mode if CS5 has been set.
This patch reenables this behaviour for all FTDI devices.
Makes sense.
Tagged to be added to stable, because it affects a lot of users of
embedded systems which rely on these readers to work properly.
Cc: sta...@vger.kernel.org
Tested-by: Heinrich Siebmanns h.siebma...@t-online.de
You should add a Reported-by tag as well.
Signed-off-by: Colin Leitner colin.leit...@gmail.com
---
drivers/usb/serial/ftdi_sio.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index fb0d537..f3def6bb 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -2125,9 +2125,20 @@ static void ftdi_set_termios(struct tty_struct *tty,
/*
* All FTDI UART chips are limited to CS7/8. We won't pretend to
- * support CS5/6 and revert the CSIZE setting instead.
+ * support CS6 and revert the CSIZE setting instead.
+ *
+ * Some smartcard readers abuse this limitation to switch modes.
+ * Original FTDI chips fall back to eight data bits.
Could you mention CS5 here? Are you sure we shouldn't just restore the
behaviour for CS6 as well?
+ *
+ * TODO: Implement a quirk to only allow this with mentioned
+ * readers. One I know of (Argolis Smartreader V1)
+ * returns USB smartcard server as iInterface string.
+ * The vendor didn't bother with a custom VID/PID of
+ * course.
*/
- if ((C_CSIZE(tty) != CS8) (C_CSIZE(tty) != CS7)) {
+ if ((C_CSIZE(tty) != CS5)
+ (C_CSIZE(tty) != CS8)
+ (C_CSIZE(tty) != CS7)) {
Just do:
if (C_CSIZE(tty) == CS6)
as CSIZE is two bits wide.
dev_warn(ddev, requested CSIZE setting not supported\n);
termios-c_cflag = ~CSIZE;
@@ -2174,6 +2185,9 @@ no_skip:
urb_value |= FTDI_SIO_SET_DATA_PARITY_NONE;
}
switch (cflag CSIZE) {
+ case CS5:
+ dev_dbg(ddev, Setting CS5 quirk\n);
+ break;
case CS7:
urb_value |= 7;
dev_dbg(ddev, Setting CS7\n);
Thanks,
Johan
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-v2] USB: ftdi_sio: added CS5 quirk for broken smartcard readers
Genuine FTDI chips support only CS7/8. A previous fix in commit 8704211f65a2
enforced this limitation and reported it back to userspace.
However, certain types of smartcard readers depend on specific
driver behaviour that requests 0 data bits (not 5) to change into a
different operating mode if CS5 has been set.
This patch reenables this behaviour for all FTDI devices.
Tagged to be added to stable, because it affects a lot of users of
embedded systems which rely on these readers to work properly.
Cc: sta...@vger.kernel.org
Reported-by: Heinrich Siebmanns h.siebma...@t-online.de
Tested-by: Heinrich Siebmanns h.siebma...@t-online.de
Signed-off-by: Colin Leitner colin.leit...@gmail.com
--
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index fb0d537..8c204a5 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -2124,10 +2124,20 @@ static void ftdi_set_termios(struct tty_struct *tty,
}
/*
-* All FTDI UART chips are limited to CS7/8. We won't pretend to
+* All FTDI UART chips are limited to CS7/8. We shouldn't pretend to
* support CS5/6 and revert the CSIZE setting instead.
+*
+* CS5 however is used to control some smartcard readers which abuse
+* this limitation to switch modes. Original FTDI chips fall back to
+* eight data bits.
+*
+* TODO: Implement a quirk to only allow this with mentioned
+* readers. One I know of (Argolis Smartreader V1)
+* returns USB smartcard server as iInterface string.
+* The vendor didn't bother with a custom VID/PID of
+* course.
*/
- if ((C_CSIZE(tty) != CS8) (C_CSIZE(tty) != CS7)) {
+ if (C_CSIZE(tty) == CS6) {
dev_warn(ddev, requested CSIZE setting not supported\n);
termios-c_cflag = ~CSIZE;
@@ -2174,6 +2184,9 @@ no_skip:
urb_value |= FTDI_SIO_SET_DATA_PARITY_NONE;
}
switch (cflag CSIZE) {
+ case CS5:
+ dev_dbg(ddev, Setting CS5 quirk\n);
+ break;
case CS7:
urb_value |= 7;
dev_dbg(ddev, Setting CS7\n);
--
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: Bug#733826: crazy loop xhci_hcd Too many fragments
On Mon, Jan 06, 2014 at 10:06:33AM -0500, Alan Stern wrote:
On Mon, 6 Jan 2014, Ben Hutchings wrote:
On Sat, 2014-01-04 at 05:44 +0800, jida...@jidanni.org wrote:
BH == Ben Hutchings b...@decadent.org.uk writes:
BH And what were those error messages?
BH Which USB devices are you using (this is probably disk or network
BH related)?
I had done an aptitude update on writing onto
# fdisk -l
Disk /dev/sdg: 3867 MB, 3867148288 bytes
OK, the important thing is it's usb-storage.
181 heads, 32 sectors/track, 1304 cylinders, total 7553024 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xc3072e18
# mount
Device Boot Start End Blocks Id System
/dev/sdg1 32 868799 434384 83 Linux
/dev/sdg2 868800 7553023 3342112 83 Linux
/dev/sdg2 on /var/cache/apt/archives type ext3
(rw,noatime,errors=remount-ro,data=ordered)
/dev/sdg1 on /var/lib/apt/lists type ext3
(rw,noatime,errors=remount-ro,data=ordered)
# cat /var/log/syslog
Jan 1 06:57:38 jidanni5 ntpd[2822]: Listen normally on 5 lo ::1 UDP 123
Jan 1 06:57:38 jidanni5 ntpd[2822]: Listen normally on 6 eth0
fe80::2289:84ff:fe28:ad9 UDP 123
Jan 1 06:57:38 jidanni5 ntpd[2822]: peers refreshed
Jan 1 06:57:38 jidanni5 ntpd[2822]: Listening on routing socket on fd
#23 for interface updates
Jan 1 07:04:49 jidanni5 kernel: [ 559.624680] xhci_hcd :00:14.0:
Too many fragments 79, max 63
Jan 1 07:04:49 jidanni5 kernel: [ 559.624695] xhci_hcd :00:14.0:
Too many fragments 79, max 63
Jan 1 07:04:49 jidanni5 kernel: [ 559.624704] xhci_hcd :00:14.0:
Too many fragments 79, max 63
10 lines later... oops I mean an actual MILLION lines later
Assuming my fix for the repetition is correct, the remaining problem is
why usb-storage is generating such large/fragmented urbs.
usb-storage doesn't generate large or fragmented anything. It merely
passes on the scatter-gather information it gets from the block layer.
And the block layer depends on drivers to tell it what their
scatter-gather capabilities are.
The answer appears to be that xhci is lying:
int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t get_quirks)
{
[...]
/* Accept arbitrarily long scatter-gather lists */
hcd-self.sg_tablesize = ~0;
and this value gets copied up the stack to the block layer.
Ben.
--
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 1/3] usb: ohci-at91: replace request_mem_region + ioremap by devm_ioremap_resource
Hello Olof,
On 06/01/2014 19:08, Olof Johansson wrote:
Boris,
On Mon, Dec 9, 2013 at 12:51 AM, Boris BREZILLON
b.brezil...@overkiz.com wrote:
Replace the request_mem_region + ioremap calls by the
devm_ioremap_resource call which does the same things but with device
managed resources.
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
Signed-off-by: Alan Stern st...@rowland.harvard.edu
Did you build these patches?
Yes, I did.
There's several breakages due to them in
last night's next. I'm a little puzzled how they passed testing before
you submitted?
This one fails with:
drivers/usb/host/ohci-at91.c: In function 'usb_hcd_at91_probe':
drivers/usb/host/ohci-at91.c:157:36: error: 'dev' undeclared (first
use in this function)
hcd-regs = devm_ioremap_resource(dev, res);
^
drivers/usb/host/ohci-at91.c:157:36: note: each undeclared identifier
is reported only once for each function it appears in
drivers/usb/host/ohci-at91.c:157:41: error: 'res' undeclared (first
use in this function)
hcd-regs = devm_ioremap_resource(dev, res);
Actually this patch series depends on another patch :
usb: ohci-at91: fix irq and iomem resource retrieval
commit fb5f1834c3221e459324c6885eaad75429f722a5.
This patch was taken out to ease integration in 3.13-rc5.
Sorry, I should have stated it in my cover letter.
Which next are you using ?
I took a look at linux-next and the dev variable is declared.
There are more too, the original one I was bisecting for was the below
one, but the above hit first:
drivers/usb/host/ohci-at91.c: In function 'usb_hcd_at91_probe':
drivers/usb/host/ohci-at91.c:190:4: error: label 'err' used but not defined
drivers/usb/host/ohci-at91.c: At top level:
drivers/usb/host/ohci-at91.c:206:2: warning: data definition has no
type or storage class [enabled by default]
drivers/usb/host/ohci-at91.c:206:2: error: type defaults to 'int' in
declaration of 'at91_stop_hc' [-Werror=implicit-int]
drivers/usb/host/ohci-at91.c:206:2: warning: parameter names (without
types) in function declaration [enabled by default]
drivers/usb/host/ohci-at91.c:206:2: error: conflicting types for 'at91_stop_hc'
drivers/usb/host/ohci-at91.c:97:13: note: previous definition of
'at91_stop_hc' was here
drivers/usb/host/ohci-at91.c:208:5: error: expected '=', ',', ';',
'asm' or '__attribute__' before ':' token
drivers/usb/host/ohci-at91.c:210:2: error: expected identifier or '('
before 'return'
drivers/usb/host/ohci-at91.c:211:1: error: expected identifier or '('
before '}' token
drivers/usb/host/ohci-at91.c:97:13: warning: 'at91_stop_hc' defined
but not used [-Wunused-function]
static void at91_stop_hc(struct platform_device *pdev)
These errors come from merge commit
99f14bd4d1b2a1b1b6cd508e08efdbc5e3919198.
There is a missing brace on the last retval test.
Best Regards,
Boris
Somewhat spectacular. Greg, can you please drop these until he's
sorted out his submission? :(
-Olof
--
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: ftdi_sio: added CS5 quirk for broken smartcard readers
On Mon, Jan 06, 2014 at 08:35:08PM +0100, Colin Leitner wrote: Genuine FTDI chips support only CS7/8. A previous fix in commit 8704211f65a2 enforced this limitation and reported it back to userspace. You should keep the one-line description in parentheses after the sha-id as in my example. The patch delimiter was also missing (-- instead if ---). I'll just fix this up this time and submit it to Greg. Thanks, Johan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH-v2] USB: ftdi_sio: added CS5 quirk for broken smartcard readers
On Mon, Jan 06, 2014 at 09:29:57PM +0100, Colin Leitner wrote: Hi Johan I'll just fix this up this time and submit it to Greg. thanks! I promise to up my game in git usage for the next patch ;). Sounds good. :) Thanks for fixing this. Johan -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] USB: ftdi_sio: added CS5 quirk for broken smartcard readers
From: Colin Leitner colin.leit...@googlemail.com
Genuine FTDI chips support only CS7/8. A previous fix in commit
8704211f65a2 (USB: ftdi_sio: fixed handling of unsupported CSIZE
setting) enforced this limitation and reported it back to userspace.
However, certain types of smartcard readers depend on specific
driver behaviour that requests 0 data bits (not 5) to change into a
different operating mode if CS5 has been set.
This patch reenables this behaviour for all FTDI devices.
Tagged to be added to stable, because it affects a lot of users of
embedded systems which rely on these readers to work properly.
Cc: sta...@vger.kernel.org
Reported-by: Heinrich Siebmanns h.siebma...@t-online.de
Tested-by: Heinrich Siebmanns h.siebma...@t-online.de
Signed-off-by: Colin Leitner colin.leit...@gmail.com
Signed-off-by: Johan Hovold jhov...@gmail.com
---
Greg,
This patch fixes a reported regression in v3.13-rc which was
unfortunately also backported to stable.
Johan
drivers/usb/serial/ftdi_sio.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index a4bebacc5cae..5057201bbba8 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -2121,10 +2121,20 @@ static void ftdi_set_termios(struct tty_struct *tty,
}
/*
-* All FTDI UART chips are limited to CS7/8. We won't pretend to
+* All FTDI UART chips are limited to CS7/8. We shouldn't pretend to
* support CS5/6 and revert the CSIZE setting instead.
+*
+* CS5 however is used to control some smartcard readers which abuse
+* this limitation to switch modes. Original FTDI chips fall back to
+* eight data bits.
+*
+* TODO: Implement a quirk to only allow this with mentioned
+* readers. One I know of (Argolis Smartreader V1)
+* returns USB smartcard server as iInterface string.
+* The vendor didn't bother with a custom VID/PID of
+* course.
*/
- if ((C_CSIZE(tty) != CS8) (C_CSIZE(tty) != CS7)) {
+ if (C_CSIZE(tty) == CS6) {
dev_warn(ddev, requested CSIZE setting not supported\n);
termios-c_cflag = ~CSIZE;
@@ -2171,6 +2181,9 @@ no_skip:
urb_value |= FTDI_SIO_SET_DATA_PARITY_NONE;
}
switch (cflag CSIZE) {
+ case CS5:
+ dev_dbg(ddev, Setting CS5 quirk\n);
+ break;
case CS7:
urb_value |= 7;
dev_dbg(ddev, Setting CS7\n);
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next v2 0/3] adjust the code of r8152
From: Hayes Wang hayesw...@realtek.com Date: Mon, 6 Jan 2014 17:08:40 +0800 Replace some tabs and modify the return value of rtl_ops_init(). v2: add the terminating newline for the message of patch #3. Series applied. -- 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] hso: fix handling of modem port SERIAL_STATE notifications
From: Dan Williams d...@redhat.com Date: Mon, 06 Jan 2014 10:07:29 -0600 The existing serial state notification handling expected older Option devices, having a hardcoded assumption that the Modem port was always USB interface #2. That isn't true for devices from the past few years. hso_serial_state_notification is a local cache of a USB Communications Interface Class SERIAL_STATE notification from the device, and the USB CDC specification (section 6.3, table 67 Class-Specific Notifications) defines wIndex as the USB interface the event applies to. For hso devices this will always be the Modem port, as the Modem port is the only port which is set up to receive them by the driver. So instead of always expecting USB interface #2, instead validate the notification with the actual USB interface number of the Modem port. Signed-off-by: Dan Williams d...@redhat.com Tested-by: H. Nikolaus Schaller h...@goldelico.com Applied, although that BUG_ON() is a bit harsh. It might have been cleaner to just dev_warn() ratelimited or similar and return. -- 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] hso: fix handling of modem port SERIAL_STATE notifications
On Mon, 2014-01-06 at 16:30 -0500, David Miller wrote: From: Dan Williams d...@redhat.com Date: Mon, 06 Jan 2014 10:07:29 -0600 The existing serial state notification handling expected older Option devices, having a hardcoded assumption that the Modem port was always USB interface #2. That isn't true for devices from the past few years. hso_serial_state_notification is a local cache of a USB Communications Interface Class SERIAL_STATE notification from the device, and the USB CDC specification (section 6.3, table 67 Class-Specific Notifications) defines wIndex as the USB interface the event applies to. For hso devices this will always be the Modem port, as the Modem port is the only port which is set up to receive them by the driver. So instead of always expecting USB interface #2, instead validate the notification with the actual USB interface number of the Modem port. Signed-off-by: Dan Williams d...@redhat.com Tested-by: H. Nikolaus Schaller h...@goldelico.com Applied, although that BUG_ON() is a bit harsh. It might have been cleaner to just dev_warn() ratelimited or similar and return. If the driver ever gets to that callback for any !Modem port, something is horribly wrong, which the BUG_ON() was attempting to make explicit. The driver only enables that callback for the Modem port, so yeah, it's somewhat defensive. I'm happy to send a fixup if you like? 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: [PATCH] hso: fix handling of modem port SERIAL_STATE notifications
From: Dan Williams d...@redhat.com Date: Mon, 06 Jan 2014 15:39:40 -0600 If the driver ever gets to that callback for any !Modem port, something is horribly wrong, which the BUG_ON() was attempting to make explicit. The driver only enables that callback for the Modem port, so yeah, it's somewhat defensive. I'm happy to send a fixup if you like? You don't have to if you think the BUG_ON() is warranted. -- 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] xhci: Set scatter-gather limit to avoid failed block writes.
Dan, can you test this patch, on top of the other patch that Ben sent?
There's directions for building a custom kernel here, if you need it:
http://kernelnewbies.org/KernelBuild
I suggest either getting the Debian kernel source and patching that, or
patching 3.12.6 or later.
Sarah Sharp
8--8
Commit 35773dac5f862cb1c82ea151eba3e2f6de51ec3e usb: xhci: Link TRB
must not occur within a USB payload burst attempted to fix an issue
found with USB ethernet adapters, and inadvertently broke USB storage
devices. The patch attempts to ensure that transfers never span a
segment, and rejects transfers that have more than 63 entries (or
possibly less, if some entries cross 64KB boundaries).
usb-storage limits the maximum transfer size to 120K, and we had assumed
the block layer would pass a scatter-gather list of 4K entries,
resulting in no more than 31 sglist entries:
http://marc.info/?l=linux-usbm=138498190419312w=2
That assumption was wrong, since we've seen the driver reject a write
that was 218 sectors long (of probably 512 bytes each):
Jan 1 07:04:49 jidanni5 kernel: [ 559.624704] xhci_hcd :00:14.0: Too many
fragments 79, max 63
...
Jan 1 07:04:58 jidanni5 kernel: [ 568.622583] Write(10): 2a 00 00 06 85 0e 00
00 da 00
Limit the number of scatter-gather entries to half a ring segment. That
should be margin enough in case some entries cross 64KB boundaries.
Increase the number of TRBs per segment from 64 to 256, which should
result in ring segments fitting on a 4K page.
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
drivers/usb/host/xhci.c | 4 ++--
drivers/usb/host/xhci.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 4265b48856f6..d45a0d584daf 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4713,8 +4713,8 @@ int xhci_gen_setup(struct usb_hcd *hcd, xhci_get_quirks_t
get_quirks)
struct device *dev = hcd-self.controller;
int retval;
- /* Accept arbitrarily long scatter-gather lists */
- hcd-self.sg_tablesize = ~0;
+ /* Limit the block layer scatter-gather lists to half a segment. */
+ hcd-self.sg_tablesize = TRBS_PER_SEGMENT / 2;
/* support to build packet from discontinuous buffers */
hcd-self.no_sg_constraint = 1;
diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 03c74b7965f8..c283cf183c48 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1260,7 +1260,7 @@ union xhci_trb {
* since the command ring is 64-byte aligned.
* It must also be greater than 16.
*/
-#define TRBS_PER_SEGMENT 64
+#define TRBS_PER_SEGMENT 256
/* Allow two commands + a link TRB, along with any reserved command TRBs */
#define MAX_RSVD_CMD_TRBS (TRBS_PER_SEGMENT - 3)
#define TRB_SEGMENT_SIZE (TRBS_PER_SEGMENT*16)
--
1.8.3.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] RFC: Allow to blacklist xhci_hcd module and use ports with EHCI
On Mon, 6 Jan 2014, Felipe Balbi wrote: On Mon, Jan 06, 2014 at 06:58:01PM +, Holger Freyther wrote: Holger Hans Peter Freyther holger@... writes: Happy New Year, xhci_hcd does not work with the Canon Lide scanners and has issues with the suspend/resume handling. My Acer Aspire S5 notebook only exposes USB3.0 ports and the distribution kernels generally have xhci_hcd enabled and I don't have any USB3.0 hardware either. I am using the laptop with the ports routed to the EHCI and I didn't have any suspend/resume issues and I could even do the book keeping of sysmocom on my laptop now. Could we please get to a situation were users that only have USB3.0 ports can either drop to EHCI mode by unloading the xhci_hcd module or preferable be able to blacklist the xhci_hcd so I could even use the stock Debian kernel? you can blacklist any module you want on /etc/modprobe.d/ on most distros (debian included). Blacklisting that way doesn't work if the module is built-in. It also may not work if the module is loaded by an initramfs. Finally, blacklisting xhci-hcd won't solve the problem at hand, because the ports get switched from EHCI to xHCI during early PCI processing, before xhci-hcd is loaded. The only check is for whether CONFIG_USB_XHCI_HCD is enabled, which isn't affected by blacklisting. As far as I can see, the code that switches the ports back to EHCI gets run only when the computer is turned off (and then only for some types of machines). The best way to solve this problem would be a boot command-line option. 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] xhci: Set scatter-gather limit to avoid failed block writes.
Don't worry, I'll trust you! Plus I'm 53. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst
On Fri, Jan 03, 2014 at 03:29:29PM -0800, Sarah Sharp wrote:
On Fri, Jan 03, 2014 at 01:21:18PM -0800, walt wrote:
I'm so sorry Sarah, that was another mistake. The mistake is so stupid I'm
not
going to publish it here :(
Once I finally ran the kernel with debugging actually compiled in, dmesg
contains
xhci debugging messages. Wow :)
It's a big file so I zipped and attached it, which I hope is acceptable in
lkml.
Yep, that's fine. Sticking it in pastebin (or up on your server) is
also fine, if it gets really big.
BTW, this dmesg is from a kernel with sg_tablesize = 31, which as I said
before
doesn't fix the problem. The cp stopped around 7GB just as before.
Sorry for the noise...
No worries! :) With the dmesg, I can finally see what happened:
[ 188.703059] xhci_hcd :03:00.0: Cancel URB 8800b7d2e0c0, dev 1, ep
0x2, starting at offset 0xbb7b9000
[ 188.703072] xhci_hcd :03:00.0: // Ding dong!
[ 193.711022] xhci_hcd :03:00.0: xHCI host not responding to stop
endpoint command.
[ 193.711029] xhci_hcd :03:00.0: Assuming host is dying, halting host.
[ 193.711046] xhci_hcd :03:00.0: // Halt the HC
[ 193.711060] xhci_hcd :03:00.0: Killing URBs for slot ID 1, ep index 0
[ 193.711066] xhci_hcd :03:00.0: Killing URBs for slot ID 1, ep index 2
[ 193.711078] xhci_hcd :03:00.0: Killing URBs for slot ID 1, ep index 3
[ 193.711096] xhci_hcd :03:00.0: Calling usb_hc_died()
[ 193.711103] xhci_hcd :03:00.0: HC died; cleaning up
[ 193.76] xhci_hcd :03:00.0: xHCI host controller is dead.
It seems that the xHCI driver tried to stop the endpoint ring in order
to cancel a SCSI transfer, and the driver never got a response for that.
The offset is rather suspicious (0xbb7b9000), and it probably means the
driver attempted to cancel a transfer that had been moved to the
beginning of the ring segment, with no-op TRBs before the link TRB.
I suspect David's patch triggers a bug in the command cancellation code.
There's also the unlikely possibility that the no-op TRBs did indeed
cause the host to hang. Either way, I'll have to look into it.
I'll let you know when I have some diagnostic patches ready.
Hi Walt,
I have a couple of patches for you to test. You can either apply the
attached three patches, or you can pull down a kernel with:
git clone git://git.kernel.org/pub/scm/linux/kernel/git/sarah/xhci.git -b
3.12-td-fragment-failure
Please only apply the first patch (which is diagnostic only), trigger
your issue, and send me the resulting dmesg. Then try applying the
other two patches, and see if the issue goes away. (I suspect it won't
but I can't be sure.)
Sarah Sharp
From 0261dcd2711c010d786dcd940803a44e1bc19512 Mon Sep 17 00:00:00 2001
From: Sarah Sharp sarah.a.sh...@linux.intel.com
Date: Mon, 6 Jan 2014 16:06:27 -0800
Subject: [PATCH 1/3] TD fragment debugging
Signed-off-by: Sarah Sharp sarah.a.sh...@linux.intel.com
---
drivers/usb/host/xhci-ring.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index 55fc0c39b7e1..d05f61dc8359 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -982,6 +982,14 @@ void xhci_stop_endpoint_command_watchdog(unsigned long arg)
* doesn't touch the memory.
*/
}
+
+ xhci_dbg(xhci, Command ring:\n);
+ xhci_debug_ring(xhci, xhci-cmd_ring);
+ xhci_dbg_ring_ptrs(xhci, xhci-cmd_ring);
+ xhci_dbg(xhci, Event ring:\n);
+ xhci_debug_ring(xhci, xhci-event_ring);
+ xhci_dbg_ring_ptrs(xhci, xhci-event_ring);
+
for (i = 0; i MAX_HC_SLOTS; i++) {
if (!xhci-devs[i])
continue;
@@ -1003,6 +1011,12 @@ void xhci_stop_endpoint_command_watchdog(unsigned long arg)
xhci_giveback_urb_in_irq(xhci, cur_td,
-ESHUTDOWN, killed);
}
+ if (!list_empty(temp_ep-cancelled_td_list)) {
+xhci_dbg(xhci, Dev %i Ep 0x%x:\n, i,
+ xhci_get_endpoint_address(j));
+xhci_debug_ring(xhci, ring);
+xhci_dbg_ring_ptrs(xhci, ring);
+ }
while (!list_empty(temp_ep-cancelled_td_list)) {
cur_td = list_first_entry(
temp_ep-cancelled_td_list,
@@ -2966,6 +2980,10 @@ static int prepare_ring(struct xhci_hcd *xhci, struct xhci_ring *ep_ring,
num_trbs, TRBS_PER_SEGMENT - 1);
return -ENOMEM;
}
+ xhci_dbg(xhci, Insert no-op TRBs at 0x%llx\n,
+ (unsigned long long)
+ xhci_trb_virt_to_dma(ep_ring-enq_seg,
+ ep_ring-enqueue));
nop_cmd = cpu_to_le32(TRB_TYPE(TRB_TR_NOOP) |
ep_ring-cycle_state);
--
1.8.3.3
From 380071d6fa2430c7141faefc8acfc0909c75a0ed Mon Sep 17 00:00:00 2001
From: Ben Hutchings b...@decadent.org.uk
Date: Mon, 6 Jan 2014 03:16:32 +
Subject: [PATCH 2/3] xhci: Avoid infinite loop when sg urb requires too many
trbs
Currently prepare_ring() returns -ENOMEM if the urb won't fit into a
single ring segment. usb_sg_wait() treats this error as a temporary
condition and will
[PATCH 1/1] usb: chipidea: udc: using MultO at TD as real mult value for ISO-TX
We have met a bug that the high bandwidth ISO-TX transfer has failed
at the last packet if it is less than 1024, the TD status shows it
is Transaction Error.
The root cause of this problem is: the mult value at qh is not correct
for current TD's transfer length. We use TD list to queue un-transfer
TDs, and change mult for new adding TDs. If new adding TDs transfer length
less than 1024, but the queued un-transfer TDs transfer length is larger
than 1024, the transfer error will occur, and vice versa.
Usually, this problem occurs at the last packet, and the first packet for
new frame.
We fixed this problem by setting Mult at QH as the largest value (3), and
set MultO (Multiplier Override) at TD according to every transfer length.
It can cover both hardware version less than 2.3 (the real mult is MultO
if it is not 0) and 2.3+ (the real mult is min(qh.mult, td.multo)).
Since the MultO bits are only existed at TX TD, we keep the ISO-RX behavior
unchanged.
Cc: Michael Grzeschik m.grzesc...@pengutronix.de
Reported-by: Matthieu Vanin b47...@freescale.com
Tested-by: Matthieu Vanin b47...@freescale.com
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/udc.c | 19 +--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 69d20fb..ec27172 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -393,6 +393,14 @@ static int add_td_to_list(struct ci_hw_ep *hwep, struct
ci_hw_req *hwreq,
node-ptr-token = cpu_to_le32(length __ffs(TD_TOTAL_BYTES));
node-ptr-token = cpu_to_le32(TD_TOTAL_BYTES);
node-ptr-token |= cpu_to_le32(TD_STATUS_ACTIVE);
+ if (hwep-type == USB_ENDPOINT_XFER_ISOC hwep-dir == TX) {
+ u32 mul = hwreq-req.length / hwep-ep.maxpacket;
+
+ if (hwreq-req.length == 0
+ || hwreq-req.length % hwep-ep.maxpacket)
+ mul++;
+ node-ptr-token |= mul __ffs(TD_MULTO);
+ }
temp = (u32) (hwreq-req.dma + hwreq-req.actual);
if (length) {
@@ -515,10 +523,11 @@ static int _hardware_enqueue(struct ci_hw_ep *hwep,
struct ci_hw_req *hwreq)
hwep-qh.ptr-td.token =
cpu_to_le32(~(TD_STATUS_HALTED|TD_STATUS_ACTIVE));
- if (hwep-type == USB_ENDPOINT_XFER_ISOC) {
+ if (hwep-type == USB_ENDPOINT_XFER_ISOC hwep-dir == RX) {
u32 mul = hwreq-req.length / hwep-ep.maxpacket;
- if (hwreq-req.length % hwep-ep.maxpacket)
+ if (hwreq-req.length == 0
+ || hwreq-req.length % hwep-ep.maxpacket)
mul++;
hwep-qh.ptr-cap |= mul __ffs(QH_MULT);
}
@@ -1173,6 +1182,12 @@ static int ep_enable(struct usb_ep *ep,
if (hwep-num)
cap |= QH_ZLT;
cap |= (hwep-ep.maxpacket __ffs(QH_MAX_PKT)) QH_MAX_PKT;
+ /*
+* For ISO-TX, we set mult at QH as the largest value, and use
+* MultO at TD as real mult value.
+*/
+ if (hwep-type == USB_ENDPOINT_XFER_ISOC hwep-dir == TX)
+ cap |= 3 __ffs(QH_MULT);
hwep-qh.ptr-cap = cpu_to_le32(cap);
--
1.7.8
--
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/1] usb: chipidea: udc: using MultO at TD as real mult value for ISO-TX
We have met a bug that the high bandwidth ISO-TX transfer has failed
at the last packet if it is less than 1024, the TD status shows it
is Transaction Error.
The root cause of this problem is: the mult value at qh is not correct
for current TD's transfer length. We use TD list to queue un-transfer
TDs, and change mult for new adding TDs. If new adding TDs transfer length
less than 1024, but the queued un-transfer TDs transfer length is larger
than 1024, the transfer error will occur, and vice versa.
Usually, this problem occurs at the last packet, and the first packet for
new frame.
We fixed this problem by setting Mult at QH as the largest value (3), and
set MultO (Multiplier Override) at TD according to every transfer length.
It can cover both hardware version less than 2.3 (the real mult is MultO
if it is not 0) and 2.3+ (the real mult is min(qh.mult, td.multo)).
Since the MultO bits are only existed at TX TD, we keep the ISO-RX behavior
unchanged.
Cc: Michael Grzeschik m.grzesc...@pengutronix.de
Reported-by: Matthieu Vanin b47...@freescale.com
Tested-by: Matthieu Vanin b47...@freescale.com
Signed-off-by: Peter Chen peter.c...@freescale.com
---
drivers/usb/chipidea/udc.c | 19 +--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 69d20fb..ec27172 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -393,6 +393,14 @@ static int add_td_to_list(struct ci_hw_ep *hwep, struct
ci_hw_req *hwreq,
node-ptr-token = cpu_to_le32(length __ffs(TD_TOTAL_BYTES));
node-ptr-token = cpu_to_le32(TD_TOTAL_BYTES);
node-ptr-token |= cpu_to_le32(TD_STATUS_ACTIVE);
+ if (hwep-type == USB_ENDPOINT_XFER_ISOC hwep-dir == TX) {
+ u32 mul = hwreq-req.length / hwep-ep.maxpacket;
+
+ if (hwreq-req.length == 0
+ || hwreq-req.length % hwep-ep.maxpacket)
+ mul++;
+ node-ptr-token |= mul __ffs(TD_MULTO);
+ }
temp = (u32) (hwreq-req.dma + hwreq-req.actual);
if (length) {
@@ -515,10 +523,11 @@ static int _hardware_enqueue(struct ci_hw_ep *hwep,
struct ci_hw_req *hwreq)
hwep-qh.ptr-td.token =
cpu_to_le32(~(TD_STATUS_HALTED|TD_STATUS_ACTIVE));
- if (hwep-type == USB_ENDPOINT_XFER_ISOC) {
+ if (hwep-type == USB_ENDPOINT_XFER_ISOC hwep-dir == RX) {
u32 mul = hwreq-req.length / hwep-ep.maxpacket;
- if (hwreq-req.length % hwep-ep.maxpacket)
+ if (hwreq-req.length == 0
+ || hwreq-req.length % hwep-ep.maxpacket)
mul++;
hwep-qh.ptr-cap |= mul __ffs(QH_MULT);
}
@@ -1173,6 +1182,12 @@ static int ep_enable(struct usb_ep *ep,
if (hwep-num)
cap |= QH_ZLT;
cap |= (hwep-ep.maxpacket __ffs(QH_MAX_PKT)) QH_MAX_PKT;
+ /*
+* For ISO-TX, we set mult at QH as the largest value, and use
+* MultO at TD as real mult value.
+*/
+ if (hwep-type == USB_ENDPOINT_XFER_ISOC hwep-dir == TX)
+ cap |= 3 __ffs(QH_MULT);
hwep-qh.ptr-cap = cpu_to_le32(cap);
--
1.7.8
--
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/xhci: fix compilation warning when !CONFIG_PCI !CONFIG_PM
When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this
warning:
drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined
but not used [-Wunused-function]
Instead of creating nested #ifdefs, this patch fixes it by defining the
xHCI PCI stubs as inline.
Signed-off-by: David Cohen david.a.co...@linux.intel.com
---
drivers/usb/host/xhci.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 4265b48856f6..672df9840014 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -397,16 +397,16 @@ static int xhci_try_enable_msi(struct usb_hcd *hcd)
#else
-static int xhci_try_enable_msi(struct usb_hcd *hcd)
+static inline int xhci_try_enable_msi(struct usb_hcd *hcd)
{
return 0;
}
-static void xhci_cleanup_msix(struct xhci_hcd *xhci)
+static inline void xhci_cleanup_msix(struct xhci_hcd *xhci)
{
}
-static void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
+static inline void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
{
}
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/8] usb: ehci: add freescale imx28 special write register method
Hello Peter and Greg, On 01/06/2014 03:10 AM, Peter Chen wrote: According to Freescale imx28 Errata, ENGR119653 USB: ARM to USB register error issue, All USB register write operations must use the ARM SWP instruction. So, we implement a special ehci_write for imx28. Discussion for it at below: http://marc.info/?l=linux-usbm=137996395529294w=2 Signed-off-by: Peter Chen peter.c...@freescale.com Acked-by: Alan Stern st...@rowland.harvard.edu Signed-off-by: Marc Kleine-Budde m...@pengutronix.de Tested-by: Marc Kleine-Budde m...@pengutronix.de please add stable on Cc for this and the next two patches: Hi Greg, do you need me to send again by adding Cc: sta...@vger.kernel.org? This patches are needed for stable tree from 3.11. Peter [PATCH 4/8] usb: ehci: add freescale imx28 special write register method [PATCH 5/8] usb: chipidea: add freescale imx28 special write register method [PATCH 6/8] usb: chipidea: imx: set CI_HDRC_IMX28_WRITE_FIX for imx28 Marc -- Pengutronix e.K. | Marc Kleine-Budde | Industrial Linux Solutions| Phone: +49-231-2826-924 | Vertretung West/Dortmund | Fax: +49-5121-206917- | Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[PATCH] usb:hub set hub-change_bits when over-current happens
set hub-change_bits when we plug in a device which causes
over-current condition, so that hub_events() will check it.
Signed-off-by: Shen Guang shenguan...@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 bd9dc35..98b5679 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1154,7 +1154,8 @@ static void hub_activate(struct usb_hub *hub,
enum hub_activation_type type)
/* Tell khubd to disconnect the device or
* check for a new connection
*/
- if (udev || (portstatus USB_PORT_STAT_CONNECTION))
+ if (udev || (portstatus USB_PORT_STAT_CONNECTION) ||
+ (portstatus USB_PORT_STAT_OVERCURRENT))
set_bit(port1, hub-change_bits);
} else if (portstatus USB_PORT_STAT_ENABLE) {
--
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] usb:hub set hub-change_bits when over-current happens
On Tue, Jan 07, 2014 at 10:33:14AM +0800, 沈光 wrote: set hub-change_bits when we plug in a device which causes over-current condition, so that hub_events() will check it. Why? What does this solve? Is this a bug with existing devices that needs to be backported to older kernels? 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: Bug#733826: [PATCH] xhci: Set scatter-gather limit to avoid failed block writes.
On Tue, 2014-01-07 at 07:01 +0800, jida...@jidanni.org wrote: Don't worry, I'll trust you! Plus I'm 53. I don't think anyone else has reproduced this problem, so you are the person in the best place to check that these changes really fix it. You can test patches against the Debian kernel package by following the instructions here: http://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official Ben. -- Ben Hutchings Any smoothly functioning technology is indistinguishable from a rigged demo. signature.asc Description: This is a digitally signed message part
[PATCH v2] usb/xhci: fix compilation warning when !CONFIG_PCI !CONFIG_PM
When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this
warning:
drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined
but not used [-Wunused-function]
It happens due to lack of __maybe_unused flag on xhci_msix_sync_irqs()
function in case of !CONFIG_PCI.
Signed-off-by: David Cohen david.a.co...@linux.intel.com
---
Change v1 - v2:
- xhci_msix_sync_irqs() already uses __maybe_unused flag when CONFIG_PCI is
set. Proper solution is to add same flag when !CONFIG_PCI instead of define
function as inline.
drivers/usb/host/xhci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 4265b48856f6..ed6b717b8ee1 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -406,7 +406,7 @@ static void xhci_cleanup_msix(struct xhci_hcd *xhci)
{
}
-static void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
+static void __maybe_unused xhci_msix_sync_irqs(struct xhci_hcd *xhci)
{
}
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net] r8152: correct some messages
- Replace pr_warn_ratelimited() with net_ratelimit() and netdev_warn().
- Adjust the algnment of some messages.
- Remove the peroid.
- Fix some messages don't have terminating newline.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 5107372..49632ff 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -814,10 +814,12 @@ static void read_bulk_callback(struct urb *urb)
case -ENOENT:
return; /* the urb is in unlink state */
case -ETIME:
- pr_warn_ratelimited(may be reset is needed?..\n);
+ if (net_ratelimit())
+ netdev_warn(netdev, maybe reset is needed?\n);
break;
default:
- pr_warn_ratelimited(Rx status %d\n, status);
+ if (net_ratelimit())
+ netdev_warn(netdev, Rx status %d\n, status);
break;
}
@@ -850,7 +852,8 @@ static void write_bulk_callback(struct urb *urb)
stats = rtl8152_get_stats(tp-netdev);
if (status) {
- pr_warn_ratelimited(Tx status %d\n, status);
+ if (net_ratelimit())
+ netdev_warn(tp-netdev, Tx status %d\n, status);
stats-tx_errors += agg-skb_num;
} else {
stats-tx_packets += agg-skb_num;
@@ -927,7 +930,7 @@ resubmit:
netif_device_detach(tp-netdev);
else if (res)
netif_err(tp, intr, tp-netdev,
- can't resubmit intr, status %d\n, res);
+ can't resubmit intr, status %d\n, res);
}
static inline void *rx_agg_align(void *data)
@@ -1336,7 +1339,7 @@ static void rtl8152_tx_timeout(struct net_device *netdev)
struct r8152 *tp = netdev_priv(netdev);
int i;
- netif_warn(tp, tx_err, netdev, Tx timeout.\n);
+ netif_warn(tp, tx_err, netdev, Tx timeout\n);
for (i = 0; i RTL8152_MAX_TX; i++)
usb_unlink_urb(tp-tx_info[i].urb);
}
@@ -1806,8 +1809,8 @@ static int rtl8152_open(struct net_device *netdev)
if (res) {
if (res == -ENODEV)
netif_device_detach(tp-netdev);
- netif_warn(tp, ifup, netdev,
- intr_urb submit failed: %d\n, res);
+ netif_warn(tp, ifup, netdev, intr_urb submit failed: %d\n,
+ res);
return res;
}
@@ -2094,7 +2097,7 @@ static int rtl8152_probe(struct usb_interface *intf,
netdev = alloc_etherdev(sizeof(struct r8152));
if (!netdev) {
- dev_err(intf-dev, Out of memory);
+ dev_err(intf-dev, Out of memory\n);
return -ENOMEM;
}
@@ -2135,11 +2138,11 @@ static int rtl8152_probe(struct usb_interface *intf,
ret = register_netdev(netdev);
if (ret != 0) {
- netif_err(tp, probe, netdev, couldn't register the device);
+ netif_err(tp, probe, netdev, couldn't register the device\n);
goto out1;
}
- netif_info(tp, probe, netdev, %s, DRIVER_VERSION);
+ netif_info(tp, probe, netdev, %s\n, DRIVER_VERSION);
return 0;
--
1.8.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb:hub set hub-change_bits when over-current happens
On Tue, Jan 7, 2014 at 10:40 AM, Greg KH gre...@linuxfoundation.org wrote:
On Tue, Jan 07, 2014 at 10:33:14AM +0800, 沈光 wrote:
set hub-change_bits when we plug in a device which causes
over-current condition, so that hub_events() will check it.
Why?
What does this solve? Is this a bug with existing devices that needs to
be backported to older kernels?
thanks,
greg k-h
This is something that we found when we are doing compliance test with xHCI.
If we enable CONFIG_USB_SUSPEND, and plug in a bad device which causes
over-current condition to the root port, the hub-change_bits will not
be set in current code in the function of hub_activate.
Then hub_events() will ignore this change, below is a code fragment of
hub_events()
/* deal with port status changes */
for (i = 1; i = hub-descriptor-bNbrPorts; i++) {
if (test_bit(i, hub-busy_bits))
continue;
connect_change = test_bit(i, hub-change_bits);
wakeup_change = test_and_clear_bit(i, hub-wakeup_bits);
if (!test_and_clear_bit(i, hub-event_bits)
!connect_change !wakeup_change)
continue;
According to spec, software need to disable the port if there is an
over-current condition, while current code will not, since it will not
detect such condition.
but if we disable CONFIG_USB_SUSPEND, software can detect the
over-current condition. I am still checking the code to get the
reason.
--
Shen Guang
--
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:hub set hub-change_bits when over-current happens
On Tue, Jan 07, 2014 at 11:35:50AM +0800, 沈光 wrote: On Tue, Jan 7, 2014 at 10:40 AM, Greg KH gre...@linuxfoundation.org wrote: On Tue, Jan 07, 2014 at 10:33:14AM +0800, 沈光 wrote: set hub-change_bits when we plug in a device which causes over-current condition, so that hub_events() will check it. Why? What does this solve? Is this a bug with existing devices that needs to be backported to older kernels? thanks, greg k-h This is something that we found when we are doing compliance test with xHCI. If we enable CONFIG_USB_SUSPEND, and plug in a bad device which causes over-current condition to the root port, the hub-change_bits will not be set in current code in the function of hub_activate. Now that's something that should go in the changelog, don't you think? 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] xhci: Allocate the td array and urb_priv together.
On Mon, Jan 06, 2014 at 09:26:20AM +, David Laight wrote: From: David Cohen On Fri, Dec 20, 2013 at 09:26:35AM -, David Laight wrote: From: David Cohen The effect of this change is really to remove the first allocation and add 8 bytes (or maybe a pointer) to the start of the second one. So it is extremely unlikely to fail when the old code would work. Currently struct urb_priv has a dynamic array of pointers to struct xhci_td. You're replacing the pointer by structs itself. Now, instead of 2 kmallocs() (1 for urb_priv and another for size * xhci_td) we've 1 kmalloc() with urb_priv + size * xhci_td. You misread the old code. The first malloc was for the header and 'n' pointers. The second malloc was for 'n' copies of the structure. That's exactly what I described but in a more complicated way :) The new kmalloc is going to be n * sizeof(struct) - n * sizeof(pointer) bigger. I don't know what is the usual range of values for n, but my experience with android devices with non-abundant memory size is that they are sensible to kmalloc PAGE_SIZE. Back to your patch description, you mention new kmalloc size may be PAGE_SIZE + 8 bytes, which means kmalloc may have to find 2 consecutive free pages. Of course it is not a big issue, but I don't see a reason to unnecessarily change 2 kmalloc PAGE_SIZE by one possibly PAGE_SIZE. Br, David Cohen 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 -- 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: correct some messages
From: Hayes Wang hayesw...@realtek.com Date: Tue, 7 Jan 2014 11:18:22 +0800 - Replace pr_warn_ratelimited() with net_ratelimit() and netdev_warn(). - Adjust the algnment of some messages. - Remove the peroid. - Fix some messages don't have terminating newline. Signed-off-by: Hayes Wang hayesw...@realtek.com I only want major bug fixes in 'net' at this time so I've applied this to 'net-next'. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-usb in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb:hub set hub-change_bits when over-current happens
On Tue, Jan 7, 2014 at 11:53 AM, Greg KH gre...@linuxfoundation.org wrote: On Tue, Jan 07, 2014 at 11:35:50AM +0800, 沈光 wrote: On Tue, Jan 7, 2014 at 10:40 AM, Greg KH gre...@linuxfoundation.org wrote: On Tue, Jan 07, 2014 at 10:33:14AM +0800, 沈光 wrote: set hub-change_bits when we plug in a device which causes over-current condition, so that hub_events() will check it. Why? What does this solve? Is this a bug with existing devices that needs to be backported to older kernels? thanks, greg k-h This is something that we found when we are doing compliance test with xHCI. If we enable CONFIG_USB_SUSPEND, and plug in a bad device which causes over-current condition to the root port, the hub-change_bits will not be set in current code in the function of hub_activate. Now that's something that should go in the changelog, don't you think? thanks, greg k-h Sure, I agree. I am sorry I didn't make it clear enough. And the reason why over-current can be detected if CONFIG_USB_SUSPEND is disabled, is that the interrupt pipe of the hub will report the change and set hub-event_bits, and then hub_events() will check what events happened. Thanks, Shen Guang -- 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: Allow to blacklist xhci_hcd module and use ports with EHCI
On Mon, Jan 06, 2014 at 04:44:51PM -0500, Alan Stern wrote: Finally, blacklisting xhci-hcd won't solve the problem at hand, because the ports get switched from EHCI to xHCI during early PCI processing, before xhci-hcd is loaded. The only check is for whether CONFIG_USB_XHCI_HCD is enabled, which isn't affected by blacklisting. As far as I can see, the code that switches the ports back to EHCI gets run only when the computer is turned off (and then only for some types of machines). I think in my case quirk_usb_handoff_xhci is called during boot that will switch the ports to the XHCI. The question is about defaults. My RFC patch proposed to route the ports to the EHCI until the XHCI module is loaded. I had modified a comment to highlight a potential issue with this approach. The comment mentioned that the code tries to avoid taking away an already enumerated device (e.g. usb storage already mounted) from the EHCI. In my case this did not happen. ehci-hcd starts after xhci-hcd but this might be sheer luck. The question is if this can be made deterministic or not. The best way to solve this problem would be a boot command-line option. Do you have a proposal for a name? -- 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
