Your email a.w.a.r.d in the Jargua sum of $800, 000.00 send your full name, address phone number
-- 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] r8152: remove limitation
From: Hayes Wang Date: Wed, 15 Jan 2014 10:42:13 +0800 > Remove the limitation between ecm mode and vendor mode. > > v2: replace the patch #3 with "ecm and vendor modes coexist". This looks better, series, applied, 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
[PATCH net-next v2 1/3] r8152: change the descriptor
The r8152 could support RTL8153. Update the relative descriptor. Signed-off-by: Hayes Wang --- drivers/net/usb/Kconfig | 5 +++-- drivers/net/usb/r8152.c | 2 +- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig index 47b0f73..6b638a0 100644 --- a/drivers/net/usb/Kconfig +++ b/drivers/net/usb/Kconfig @@ -92,11 +92,12 @@ config USB_RTL8150 module will be called rtl8150. config USB_RTL8152 - tristate "Realtek RTL8152 Based USB 2.0 Ethernet Adapters" + tristate "Realtek RTL8152/RTL8153 Based USB Ethernet Adapters" select MII help This option adds support for Realtek RTL8152 based USB 2.0 - 10/100 Ethernet adapters. + 10/100 Ethernet adapters and RTL8153 based USB 3.0 10/100/1000 + Ethernet adapters. To compile this driver as a module, choose M here: the module will be called r8152. diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index bf7d549..38f3c14 100644 --- a/drivers/net/usb/r8152.c +++ b/drivers/net/usb/r8152.c @@ -26,7 +26,7 @@ /* Version Information */ #define DRIVER_VERSION "v1.03.0 (2013/12/26)" #define DRIVER_AUTHOR "Realtek linux nic maintainers " -#define DRIVER_DESC "Realtek RTL8152 Based USB 2.0 Ethernet Adapters" +#define DRIVER_DESC "Realtek RTL8152/RTL8153 Based USB Ethernet Adapters" #define MODULENAME "r8152" #define R8152_PHY_ID 32 -- 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 0/3] r8152: remove limitation
Remove the limitation between ecm mode and vendor mode. v2: replace the patch #3 with "ecm and vendor modes coexist". Hayes Wang (3): r8152: change the descriptor r8152: fix the warnings and a error from checkpatch.pl r8152: ecm and vendor modes coexist drivers/net/usb/Kconfig | 5 ++-- drivers/net/usb/cdc_ether.c | 9 --- drivers/net/usb/r8152.c | 62 ++--- drivers/net/usb/r815x.c | 8 -- 4 files changed, 27 insertions(+), 57 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 2/3] r8152: fix the warnings and a error from checkpatch.pl
Fix the following warnings and error:
- WARNING: usb_free_urb(NULL) is safe this check is probably not required
- WARNING: kfree(NULL) is safe this check is probably not required
- ERROR: do not use C99 // comments
Signed-off-by: Hayes Wang
---
drivers/net/usb/r8152.c | 42 +++---
1 file changed, 15 insertions(+), 27 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 38f3c14..eab078b 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1100,40 +1100,28 @@ static void free_all_mem(struct r8152 *tp)
int i;
for (i = 0; i < RTL8152_MAX_RX; i++) {
- if (tp->rx_info[i].urb) {
- usb_free_urb(tp->rx_info[i].urb);
- tp->rx_info[i].urb = NULL;
- }
+ usb_free_urb(tp->rx_info[i].urb);
+ tp->rx_info[i].urb = NULL;
- if (tp->rx_info[i].buffer) {
- kfree(tp->rx_info[i].buffer);
- tp->rx_info[i].buffer = NULL;
- tp->rx_info[i].head = NULL;
- }
+ kfree(tp->rx_info[i].buffer);
+ tp->rx_info[i].buffer = NULL;
+ tp->rx_info[i].head = NULL;
}
for (i = 0; i < RTL8152_MAX_TX; i++) {
- if (tp->tx_info[i].urb) {
- usb_free_urb(tp->tx_info[i].urb);
- tp->tx_info[i].urb = NULL;
- }
+ usb_free_urb(tp->tx_info[i].urb);
+ tp->tx_info[i].urb = NULL;
- if (tp->tx_info[i].buffer) {
- kfree(tp->tx_info[i].buffer);
- tp->tx_info[i].buffer = NULL;
- tp->tx_info[i].head = NULL;
- }
+ kfree(tp->tx_info[i].buffer);
+ tp->tx_info[i].buffer = NULL;
+ tp->tx_info[i].head = NULL;
}
- if (tp->intr_urb) {
- usb_free_urb(tp->intr_urb);
- tp->intr_urb = NULL;
- }
+ usb_free_urb(tp->intr_urb);
+ tp->intr_urb = NULL;
- if (tp->intr_buff) {
- kfree(tp->intr_buff);
- tp->intr_buff = NULL;
- }
+ kfree(tp->intr_buff);
+ tp->intr_buff = NULL;
}
static int alloc_all_mem(struct r8152 *tp)
@@ -2048,7 +2036,7 @@ static void r8153_first_init(struct r8152 *tp)
/* TX share fifo free credit full threshold */
ocp_write_dword(tp, MCU_TYPE_PLA, PLA_TXFIFO_CTRL, TXFIFO_THR_NORMAL2);
- // rx aggregation
+ /* rx aggregation */
ocp_data = ocp_read_word(tp, MCU_TYPE_USB, USB_USB_CTRL);
ocp_data &= ~RX_AGG_DISABLE;
ocp_write_word(tp, MCU_TYPE_USB, USB_USB_CTRL, ocp_data);
--
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 3/3] r8152: ecm and vendor modes coexist
Remove the limitation that the ecm and r8152 drivers couldn't coexist.
- Remove the devices from the blacklist of relative drivers.
- Remove usb_driver_set_configuration() from r8152 driver.
- Modify the id_table of the r8152 driver for the vendor mode only.
Signed-off-by: Hayes Wang
---
drivers/net/usb/cdc_ether.c | 9 -
drivers/net/usb/r8152.c | 18 --
drivers/net/usb/r815x.c | 8
3 files changed, 8 insertions(+), 27 deletions(-)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 640406a..7d32be8 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -653,15 +653,6 @@ static const struct usb_device_id products[] = {
.driver_info = 0,
},
-#if defined(CONFIG_USB_RTL8152) || defined(CONFIG_USB_RTL8152_MODULE)
-/* Samsung USB Ethernet Adapters */
-{
- USB_DEVICE_AND_INTERFACE_INFO(SAMSUNG_VENDOR_ID, 0xa101, USB_CLASS_COMM,
- USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
- .driver_info = 0,
-},
-#endif
-
/* WHITELIST!!!
*
* CDC Ether uses two interfaces, not necessarily consecutive.
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index eab078b..31d13ca 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2013 Realtek Semiconductor Corp. All rights reserved.
+ * Copyright (c) 2014 Realtek Semiconductor Corp. All rights reserved.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -24,7 +24,7 @@
#include
/* Version Information */
-#define DRIVER_VERSION "v1.03.0 (2013/12/26)"
+#define DRIVER_VERSION "v1.04.0 (2014/01/15)"
#define DRIVER_AUTHOR "Realtek linux nic maintainers "
#define DRIVER_DESC "Realtek RTL8152/RTL8153 Based USB Ethernet Adapters"
#define MODULENAME "r8152"
@@ -450,6 +450,9 @@ enum rtl8152_flags {
#define MCU_TYPE_PLA 0x0100
#define MCU_TYPE_USB 0x
+#define REALTEK_USB_DEVICE(vend, prod) \
+ USB_DEVICE_INTERFACE_CLASS(vend, prod, USB_CLASS_VENDOR_SPEC)
+
struct rx_desc {
__le32 opts1;
#define RX_LEN_MASK0x7fff
@@ -2738,11 +2741,6 @@ static int rtl8152_probe(struct usb_interface *intf,
struct net_device *netdev;
int ret;
- if (udev->actconfig->desc.bConfigurationValue != 1) {
- usb_driver_set_configuration(udev, 1);
- return -ENODEV;
- }
-
netdev = alloc_etherdev(sizeof(struct r8152));
if (!netdev) {
dev_err(&intf->dev, "Out of memory\n");
@@ -2823,9 +2821,9 @@ static void rtl8152_disconnect(struct usb_interface *intf)
/* table of devices that work with this driver */
static struct usb_device_id rtl8152_table[] = {
- {USB_DEVICE(VENDOR_ID_REALTEK, PRODUCT_ID_RTL8152)},
- {USB_DEVICE(VENDOR_ID_REALTEK, PRODUCT_ID_RTL8153)},
- {USB_DEVICE(VENDOR_ID_SAMSUNG, PRODUCT_ID_SAMSUNG)},
+ {REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, PRODUCT_ID_RTL8152)},
+ {REALTEK_USB_DEVICE(VENDOR_ID_REALTEK, PRODUCT_ID_RTL8153)},
+ {REALTEK_USB_DEVICE(VENDOR_ID_SAMSUNG, PRODUCT_ID_SAMSUNG)},
{}
};
diff --git a/drivers/net/usb/r815x.c b/drivers/net/usb/r815x.c
index 5fd2ca6..f0a8791 100644
--- a/drivers/net/usb/r815x.c
+++ b/drivers/net/usb/r815x.c
@@ -216,21 +216,13 @@ static const struct usb_device_id products[] = {
{
USB_DEVICE_AND_INTERFACE_INFO(REALTEK_VENDOR_ID, 0x8152, USB_CLASS_COMM,
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
-#if defined(CONFIG_USB_RTL8152) || defined(CONFIG_USB_RTL8152_MODULE)
- .driver_info = 0,
-#else
.driver_info = (unsigned long) &r8152_info,
-#endif
},
{
USB_DEVICE_AND_INTERFACE_INFO(REALTEK_VENDOR_ID, 0x8153, USB_CLASS_COMM,
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
-#if defined(CONFIG_USB_RTL8152) || defined(CONFIG_USB_RTL8152_MODULE)
- .driver_info = 0,
-#else
.driver_info = (unsigned long) &r8153_info,
-#endif
},
{ },/* END */
--
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: chipidea: need to mask when writting endptflush and endptprime
On Tue, Jan 14, 2014 at 03:39:25PM +0100, Matthieu CASTET wrote:
> ENDPTFLUSH and ENDPTPRIME registers are set by software and
> clear by hardware.
> There is a bit for each endpoint.
> When we are setting a bit for an endpoint we should make sure we not touch
> other endpoint bit. There is a race condition if the hardware clear the
> bit between the read and the write in hw_write.
>
Hi Matthieu,
The patch is ok, would you mind format commit log a bit, keep the number
of character for each line are almost the same (within 2-3 words).
Peter
> Signed-off-by: Matthieu CASTET
> ---
> drivers/usb/chipidea/udc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index 69d20fb..9e2e39b 100644
> --- a/drivers/usb/chipidea/udc.c
> +++ b/drivers/usb/chipidea/udc.c
> @@ -105,7 +105,7 @@ static int hw_ep_flush(struct ci_hdrc *ci, int num, int
> dir)
>
> do {
> /* flush any pending transfer */
> - hw_write(ci, OP_ENDPTFLUSH, BIT(n), BIT(n));
> + hw_write(ci, OP_ENDPTFLUSH, ~0, BIT(n));
> while (hw_read(ci, OP_ENDPTFLUSH, BIT(n)))
> cpu_relax();
> } while (hw_read(ci, OP_ENDPTSTAT, BIT(n)));
> @@ -205,7 +205,7 @@ static int hw_ep_prime(struct ci_hdrc *ci, int num, int
> dir, int is_ctrl)
> if (is_ctrl && dir == RX && hw_read(ci, OP_ENDPTSETUPSTAT, BIT(num)))
> return -EAGAIN;
>
> - hw_write(ci, OP_ENDPTPRIME, BIT(n), BIT(n));
> + hw_write(ci, OP_ENDPTPRIME, ~0, BIT(n));
>
> while (hw_read(ci, OP_ENDPTPRIME, BIT(n)))
> cpu_relax();
> --
> 1.8.5.2
>
>
>
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 10/10] usb: documentation for usb port power off mechanisms
On Mon, Jan 13, 2014 at 1:48 PM, Sarah Sharp wrote: > A couple comments below. > > On Tue, Jan 07, 2014 at 12:30:21PM -0800, Dan Williams wrote: >> From: Lan Tianyu >> >> describe the mechanisms for controlling port power policy and >> discovering the port power state. >> >> Cc: Oliver Neukum >> Signed-off-by: Lan Tianyu >> Signed-off-by: Sarah Sharp > > I think this version of the patch was changed since the last time I > internally signed off on it. I'll have to be more careful about sending > draft patches out with my Signed-off-by line. In this case I left it in because you authored part of the patch, but yeah makes it awkward if you are going to also be in the submission chain... > >> Signed-off-by: Dan Williams >> --- >> Documentation/usb/power-management.txt | 210 >> >> 1 files changed, 210 insertions(+), 0 deletions(-) >> >> diff --git a/Documentation/usb/power-management.txt >> b/Documentation/usb/power-management.txt >> index 1392b61d6ebe..e5e77a67abb7 100644 >> --- a/Documentation/usb/power-management.txt >> +++ b/Documentation/usb/power-management.txt [..] >> +In addition to these files some ports may have a 'peer' link to a port on >> +another hub. The expectation is that all superspeed ports have a >> +hi-speed peer. >> + >> +/sys/bus/usb/devices/usb2/2-0:1.0/port1/peer -> ../../../usb3/3-0:1.0/port1 >> +/sys/bus/usb/devices/usb3/3-0:1.0/port1/peer -> ../../../usb2/2-0:1.0/port1 >> + >> +Physically, a superspeed port is ganged with a hi-speed port to form a >> +connector. Distinct from 'companion ports', peer ports share the same >> +ancestor XHCI device. Whereas, with a companion port, an EHCI or XHCI >> +device optionally drive the same pins. While a superspeed port is > > I think you mean "with a companion port, an EHCI or OHCI/UHCI device > optionally drive the same pins". Or are you talking about the Intel > EHCI to xHCI port switchover? We don't call those companion ports in > that case. My mistake, yes, ehci/xhci is another kind of relationship. I'll reduce that to: "Distinct from 'companion ports', or 'ehci/xhci switchover ports' peer ports are simply the hi-speed and superspeed interface pins that are combined into a single usb3 connector. Peer ports share the same ancestor XHCI device." I probably picked this up from usb_enable_intel_xhci_ports() which uses 'companion' to reference the ehci device. >> +powered off a device may downgrade its connection and attempt to connect >> +to the hi-speed pins. The implementation takes steps to prevent this >> +and sequences port power to guarantee that hi-speed ports are >> +powered-off before superspeed are allowed to suspend, and that >> +superspeed ports are recovered/repowered before hi-speed. >> + >> + power/pm_qos_no_power_off: >> + This writable flag controls the state of an idle port. >> + Once all children and descendants have suspended the >> + port may suspend/poweroff provided that >> + pm_qos_no_power_off is '0'. If pm_qos_no_power_off is >> + '1' the port will remain active/powered regardless of >> + the stats of descendants. > > You probably want to mention the default policy of '1' here. Ok, noted. [..] >> +A more aggressive userspace policy is to enable USB port power off >> +for all ports (set portX/power/pm_qos_no_power_off to '0' and set >> +portX/connect_type to 'hardwired') when some external factor indicates >> +the user has stopped interacting with the system. For example, a distro >> +may want to enable power off all USB ports when the screen blanks, and >> +re-power them when the screen becomes active. Smart phones and tablets >> +may want to power off USB ports when the user pushes the power button. > > This paragraph is out-of-date. You mention that connect_type is > read-only above, and this paragraph assumes it's read-write. > > It also assumes that the reason why userspace needs to write into > connect_type is because we won't power off a port unless it's set to > hardwired. I think that assumption is false with the current code base, > and we'll power off a port with any connect_type value, as long as > userspace says it's OK. Is that correct? Oops missed that one. Yes, ports will poweroff as soon as pm_qos_no_poweroff and pm_runtime_usage/autosuspend allows. -- 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] usb: chipidea: usbmisc: Add support for i.MX27/i.MX31 CPUs
On Tuesday, January 14, 2014 09:49 PM, Uwe Kleine-König wrote: Hello Chris, On Tue, Jan 14, 2014 at 11:53:47AM +0800, Chris Ruehl wrote: On Tuesday, January 14, 2014 11:30 AM, Alexander Shiyan wrote: Понедельник, 13 января 2014, 22:31 +01:00 от Uwe Kleine-König : On Sat, Jan 11, 2014 at 06:01:48PM +0400, Alexander Shiyan wrote: Суббота, 11 января 2014, 13:55 +01:00 от Uwe Kleine-König : On Mon, Nov 11, 2013 at 11:09:16AM +0400, Alexander Shiyan wrote: Hello. On Sunday, November 10, 2013 03:18 PM, Alexander Shiyan wrote: This adds i.MX27 and i.MX31 as the next user of the usbmisc driver. Signed-off-by: Alexander Shiyan --- drivers/usb/chipidea/usbmisc_imx.c | 42 ++ 1 file changed, 42 insertions(+) ... At this point might be good to patch the imx27.dtsi with the usb defines. ... I have a working configuration for i.MX27 USB, but I prefer to make a few more tests before the addition of definitions in DTS. This will be a next step. Thanks. Any news here? Not ready yet. Are you still working at it? Would you mind sharing more details, like your current tree/patch stack and what works/doesn't work for you? Now my work on this is suspended, but will continue later. I'll send you a personal letter with DT configuration. Ports (both Host & OTG) are detected by kernel, but works Host only. OTG not works nor as Host, nor as Device... --- hi, I'm still working on my patches for imx27 and ULPI integration. But have more urgent things in the queue. Starting from here I'm not sure I understand you. I have a running version but it cant make it in the kernel. Rework on platform device code needed. I have a customized board running OTG/host and USB2/host (USB1 not connected) Both ports are connected to a ISP1504 ULPI a) I need a rs-gpio to reset in addition to the cs-gpio the ISP1504 (done) b) Implement UPLI viewport (IORESOURCE_MEM) and logic to set the external power supply. The code (b) was rejected and needs rework. Just wait until the patches already accepted appears in the linux-next before commit new patches. That means: USB works for you? What does "it cant make it in the kernel" mean? Problems to upstream it? Do you wait or should I? I will fix the problem with (b) and resend my patches. Best regards Uwe -- GTSYS Limited RFID Technology A01 24/F Gold King Industrial Bld 35-41 Tai Lin Pai Road, Kwai Chung, Hong Kong Fax (852) 8167 4060 - Tel (852) 3598 9488 Disclaimer: http://www.gtsys.com.hk/email/classified.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 v3 00/10] Just the essential port power control fixes for 3.14
On Tue, Jan 14, 2014 at 5:27 PM, Dan Williams wrote: > On Tue, Jan 14, 2014 at 3:22 PM, Sarah Sharp > wrote: >> On Tue, Jan 07, 2014 at 12:29:28PM -0800, Dan Williams wrote: >>> Alan, Sarah, >>> >>> This revision boils down the port power control fixes to the >>> bare minimum to get the implementation functional and reliable. >>> Data structure changes are constrained to struct usb_port and >>> gone are the clumsier attempts at wider reworks from v1 [1] and >>> v2 [2]. No device model changes to consider or changes to the >>> meaning of 'runtime_status' for port devices. Three disconnect >>> bugs are fixed: >>> >>> 1/ Superspeed devices downgrade to their hi-speed connection: fix this by >>>preventing superspeed poweroff until the peer port is suspended. See >>>patch 5. >> >> I've been testing these a bit, and run into some unexpected behavior. >> >> First, just checking: what do you expect to happen if a USB 2.0 port has >> port power off enabled, but its peer USB 3.0 port has power off >> disabled? I had expected that the port would remained powered on, but >> this does not seem to be what the code actually does. > > The implementation never expects a USB2 port to remain powered once > poweroff is enabled. Only USB3 if it it's peer is powered. > >> >> Say I have one xHCI host that registers bus 1 (USB 2.0) and bus 2 (USB >> 3.0). Port 1 on both buses are peer ports, and both ports have power >> off disabled. Then I do the following: >> >> 1. Plug in a USB mouse into the USB 2.0 port. >> 2. Enable port power off for the USB 2.0 port. >> 4. Enable suspend for the mouse. Port should be prevented from being >>powered off, since usbhid enables remote wakeup for the device, and >>the port's runtime_status does reflect that it's active. >> 3. Unbind usbhid. >> 5. Check that the USB 2.0 port's runtime_status is 'suspended' while the >>USB 3.0 port's runtime_status is 'active'. (Note, at this point, >>according to my assumption, the port should still be powered, but >>it's not.) > > Once usbhid is unbound it clears intf->needs_remote_wakeup so the port > is allowed to go to sleep. > >> 6. Unplug the USB mouse. No disconnect event observed. > > Ok, so far so good... > >> 7. Disable port power off for the USB 2.0 port. Still no disconnect. > > hmm... > >> 8. Run `sudo lsusb` and note that the mouse is still listed in lsusb >>output. Further, the sysfs directories are still there. The device >>remains even after running `sudo lsusb -v` (which should trigger a >>get port status for the roothub, where the disconnect should be >>noticed. >> >> A command line history of that procedure is attached. >> >> It seems like there needs to be a way to detect whether a USB device is >> really disconnected after the port is powered back on. ISTR asking >> Tianyu to fix this, but I'm not sure if it ever did get fixed. > > I believe we're just missing a kick of khubd after recovery has > completed like we have in the hub_resume() case. I'll take a look at > why this did not trigger in my tests (presumably another hub event ran > to flag the disconnect). > Acutally no. The device/port should be force resumed via port_dev_wake_child() which should trigger a hub_port_logical_disconnect() and kick khubd. I'll reproduce to see where the "disconnect" is. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/10] Just the essential port power control fixes for 3.14
On Tue, Jan 14, 2014 at 3:22 PM, Sarah Sharp wrote: > On Tue, Jan 07, 2014 at 12:29:28PM -0800, Dan Williams wrote: >> Alan, Sarah, >> >> This revision boils down the port power control fixes to the >> bare minimum to get the implementation functional and reliable. >> Data structure changes are constrained to struct usb_port and >> gone are the clumsier attempts at wider reworks from v1 [1] and >> v2 [2]. No device model changes to consider or changes to the >> meaning of 'runtime_status' for port devices. Three disconnect >> bugs are fixed: >> >> 1/ Superspeed devices downgrade to their hi-speed connection: fix this by >>preventing superspeed poweroff until the peer port is suspended. See >>patch 5. > > I've been testing these a bit, and run into some unexpected behavior. > > First, just checking: what do you expect to happen if a USB 2.0 port has > port power off enabled, but its peer USB 3.0 port has power off > disabled? I had expected that the port would remained powered on, but > this does not seem to be what the code actually does. The implementation never expects a USB2 port to remain powered once poweroff is enabled. Only USB3 if it it's peer is powered. > > Say I have one xHCI host that registers bus 1 (USB 2.0) and bus 2 (USB > 3.0). Port 1 on both buses are peer ports, and both ports have power > off disabled. Then I do the following: > > 1. Plug in a USB mouse into the USB 2.0 port. > 2. Enable port power off for the USB 2.0 port. > 4. Enable suspend for the mouse. Port should be prevented from being >powered off, since usbhid enables remote wakeup for the device, and >the port's runtime_status does reflect that it's active. > 3. Unbind usbhid. > 5. Check that the USB 2.0 port's runtime_status is 'suspended' while the >USB 3.0 port's runtime_status is 'active'. (Note, at this point, >according to my assumption, the port should still be powered, but >it's not.) Once usbhid is unbound it clears intf->needs_remote_wakeup so the port is allowed to go to sleep. > 6. Unplug the USB mouse. No disconnect event observed. Ok, so far so good... > 7. Disable port power off for the USB 2.0 port. Still no disconnect. hmm... > 8. Run `sudo lsusb` and note that the mouse is still listed in lsusb >output. Further, the sysfs directories are still there. The device >remains even after running `sudo lsusb -v` (which should trigger a >get port status for the roothub, where the disconnect should be >noticed. > > A command line history of that procedure is attached. > > It seems like there needs to be a way to detect whether a USB device is > really disconnected after the port is powered back on. ISTR asking > Tianyu to fix this, but I'm not sure if it ever did get fixed. I believe we're just missing a kick of khubd after recovery has completed like we have in the hub_resume() case. I'll take a look at why this did not trigger in my tests (presumably another hub event ran to flag the disconnect). > Also, it seems that my self-powered USB 3.0 Pluggable UAS dock can > "overcome" the port power off mechanism. When USB 2.0 power off is > enabled, the USB 3.0 peer port power off is disabled, and I connect it, > the device appears for a very brief amount of time before disconnecting. It appears on the USB2 interface or USB3? I'd like to see a log if you can grab it. > A bus powered USB 3.0 flash drive never connects when the port is > powered. ...USB3 port "powered off" you mean? > > It's intermittent though, I can't reproduce it all the time, so it may > just be BIOS issues. Not sure how the BIOS trips us up here unless it asynchronously disables the port after the poweroff request completes? -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] usb: gadget: bcm63xx_udc: fix build failure on DMA channel code
Commit 3dc6475 ("bcm63xx_enet: add support Broadcom BCM6345 Ethernet")
changed the ENETDMA[CS] macros such that they are no longer macros, but
actual register offset definitions. The bcm63xx_udc driver was not
updated, and as a result, causes the following build error to pop up:
CC drivers/usb/gadget/u_ether.o
drivers/usb/gadget/bcm63xx_udc.c: In function 'iudma_write':
drivers/usb/gadget/bcm63xx_udc.c:642:24: error: called object '0' is not
a function
drivers/usb/gadget/bcm63xx_udc.c: In function 'iudma_reset_channel':
drivers/usb/gadget/bcm63xx_udc.c:698:46: error: called object '0' is not
a function
drivers/usb/gadget/bcm63xx_udc.c:700:49: error: called object '0' is not
a function
Fix this by updating usb_dmac_{read,write}l and usb_dmas_{read,write}l to
take an extra channel argument, and use the channel width
(ENETDMA_CHAN_WIDTH) to offset the register we want to access, hence
doing again what the macro implicitely did for us.
CC: Kevin Cernekee
CC: Jonas Gorski
CC: sta...@vger.kernel.org
Signed-off-by: Florian Fainelli
---
Felipe,
This is against your branch as balbi/usb.git, and this fix should be applied to
stable 3.11 onwards.
Thanks!
drivers/usb/gadget/bcm63xx_udc.c | 58 ++--
1 file changed, 32 insertions(+), 26 deletions(-)
diff --git a/drivers/usb/gadget/bcm63xx_udc.c b/drivers/usb/gadget/bcm63xx_udc.c
index 2ac7a8f..4c7b47f 100644
--- a/drivers/usb/gadget/bcm63xx_udc.c
+++ b/drivers/usb/gadget/bcm63xx_udc.c
@@ -361,24 +361,30 @@ static inline void usb_dma_writel(struct bcm63xx_udc
*udc, u32 val, u32 off)
bcm_writel(val, udc->iudma_regs + off);
}
-static inline u32 usb_dmac_readl(struct bcm63xx_udc *udc, u32 off)
+static inline u32 usb_dmac_readl(struct bcm63xx_udc *udc, u32 off, int chan)
{
- return bcm_readl(udc->iudma_regs + IUDMA_DMAC_OFFSET + off);
+ return bcm_readl(udc->iudma_regs + IUDMA_DMAC_OFFSET + off +
+ (ENETDMA_CHAN_WIDTH * chan));
}
-static inline void usb_dmac_writel(struct bcm63xx_udc *udc, u32 val, u32 off)
+static inline void usb_dmac_writel(struct bcm63xx_udc *udc, u32 val, u32 off,
+ int chan)
{
- bcm_writel(val, udc->iudma_regs + IUDMA_DMAC_OFFSET + off);
+ bcm_writel(val, udc->iudma_regs + IUDMA_DMAC_OFFSET + off +
+ (ENETDMA_CHAN_WIDTH * chan));
}
-static inline u32 usb_dmas_readl(struct bcm63xx_udc *udc, u32 off)
+static inline u32 usb_dmas_readl(struct bcm63xx_udc *udc, u32 off, int chan)
{
- return bcm_readl(udc->iudma_regs + IUDMA_DMAS_OFFSET + off);
+ return bcm_readl(udc->iudma_regs + IUDMA_DMAS_OFFSET + off +
+ (ENETDMA_CHAN_WIDTH * chan));
}
-static inline void usb_dmas_writel(struct bcm63xx_udc *udc, u32 val, u32 off)
+static inline void usb_dmas_writel(struct bcm63xx_udc *udc, u32 val, u32 off,
+ int chan)
{
- bcm_writel(val, udc->iudma_regs + IUDMA_DMAS_OFFSET + off);
+ bcm_writel(val, udc->iudma_regs + IUDMA_DMAS_OFFSET + off +
+ (ENETDMA_CHAN_WIDTH * chan));
}
static inline void set_clocks(struct bcm63xx_udc *udc, bool is_enabled)
@@ -639,7 +645,7 @@ static void iudma_write(struct bcm63xx_udc *udc, struct
iudma_ch *iudma,
} while (!last_bd);
usb_dmac_writel(udc, ENETDMAC_CHANCFG_EN_MASK,
- ENETDMAC_CHANCFG_REG(iudma->ch_idx));
+ ENETDMAC_CHANCFG_REG, iudma->ch_idx);
}
/**
@@ -695,9 +701,9 @@ static void iudma_reset_channel(struct bcm63xx_udc *udc,
struct iudma_ch *iudma)
bcm63xx_fifo_reset_ep(udc, max(0, iudma->ep_num));
/* stop DMA, then wait for the hardware to wrap up */
- usb_dmac_writel(udc, 0, ENETDMAC_CHANCFG_REG(ch_idx));
+ usb_dmac_writel(udc, 0, ENETDMAC_CHANCFG_REG, ch_idx);
- while (usb_dmac_readl(udc, ENETDMAC_CHANCFG_REG(ch_idx)) &
+ while (usb_dmac_readl(udc, ENETDMAC_CHANCFG_REG, ch_idx) &
ENETDMAC_CHANCFG_EN_MASK) {
udelay(1);
@@ -714,10 +720,10 @@ static void iudma_reset_channel(struct bcm63xx_udc *udc,
struct iudma_ch *iudma)
dev_warn(udc->dev, "forcibly halting IUDMA channel
%d\n",
ch_idx);
usb_dmac_writel(udc, ENETDMAC_CHANCFG_BUFHALT_MASK,
- ENETDMAC_CHANCFG_REG(ch_idx));
+ ENETDMAC_CHANCFG_REG, ch_idx);
}
}
- usb_dmac_writel(udc, ~0, ENETDMAC_IR_REG(ch_idx));
+ usb_dmac_writel(udc, ~0, ENETDMAC_IR_REG, ch_idx);
/* don't leave "live" HW-owned entries for the next guy to step on */
for (d = iudma->bd_ring; d <= iudma->end_bd; d++)
@@ -729,11 +735,11 @@ static void iudma_reset_channel(struct bcm63xx_udc *udc,
struct iudma_ch *iudma)
/* set up IRQs, UBUS burst
Re: [PATCH v3 00/10] Just the essential port power control fixes for 3.14
On Tue, Jan 07, 2014 at 12:29:28PM -0800, Dan Williams wrote: > Alan, Sarah, > > This revision boils down the port power control fixes to the > bare minimum to get the implementation functional and reliable. > Data structure changes are constrained to struct usb_port and > gone are the clumsier attempts at wider reworks from v1 [1] and > v2 [2]. No device model changes to consider or changes to the > meaning of 'runtime_status' for port devices. Three disconnect > bugs are fixed: > > 1/ Superspeed devices downgrade to their hi-speed connection: fix this by >preventing superspeed poweroff until the peer port is suspended. See >patch 5. I've been testing these a bit, and run into some unexpected behavior. First, just checking: what do you expect to happen if a USB 2.0 port has port power off enabled, but its peer USB 3.0 port has power off disabled? I had expected that the port would remained powered on, but this does not seem to be what the code actually does. Say I have one xHCI host that registers bus 1 (USB 2.0) and bus 2 (USB 3.0). Port 1 on both buses are peer ports, and both ports have power off disabled. Then I do the following: 1. Plug in a USB mouse into the USB 2.0 port. 2. Enable port power off for the USB 2.0 port. 4. Enable suspend for the mouse. Port should be prevented from being powered off, since usbhid enables remote wakeup for the device, and the port's runtime_status does reflect that it's active. 3. Unbind usbhid. 5. Check that the USB 2.0 port's runtime_status is 'suspended' while the USB 3.0 port's runtime_status is 'active'. (Note, at this point, according to my assumption, the port should still be powered, but it's not.) 6. Unplug the USB mouse. No disconnect event observed. 7. Disable port power off for the USB 2.0 port. Still no disconnect. 8. Run `sudo lsusb` and note that the mouse is still listed in lsusb output. Further, the sysfs directories are still there. The device remains even after running `sudo lsusb -v` (which should trigger a get port status for the roothub, where the disconnect should be noticed. A command line history of that procedure is attached. It seems like there needs to be a way to detect whether a USB device is really disconnected after the port is powered back on. ISTR asking Tianyu to fix this, but I'm not sure if it ever did get fixed. Also, it seems that my self-powered USB 3.0 Pluggable UAS dock can "overcome" the port power off mechanism. When USB 2.0 power off is enabled, the USB 3.0 peer port power off is disabled, and I connect it, the device appears for a very brief amount of time before disconnecting. A bus powered USB 3.0 flash drive never connects when the port is powered. It's intermittent though, I can't reproduce it all the time, so it may just be BIOS issues. Sarah Sharp root@maggie:/sys/bus/usb/devices# lsusb -t /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M |__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/8p, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/9p, 480M |__ Port 1: Dev 3, If 0, Class=HID, Driver=usbhid, 1.5M |__ Port 8: Dev 2, If 0, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M |__ Port 8: Dev 2, If 1, Class='bInterfaceClass 0xe0 not yet handled', Driver=btusb, 12M root@maggie:/sys/bus/usb/devices# echo 0 > usb1/1-0\:1.0/port1/power/pm_qos_no_power_off root@maggie:/sys/bus/usb/devices# cat usb1/1-0\:1.0/port1/power/runtime_status active root@maggie:/sys/bus/usb/devices# echo "1-1" > usb1/1-0\:1.0/port1/device/driver/unbind root@maggie:/sys/bus/usb/devices# cat usb1/1-0\:1.0/port1/power/runtime_status active root@maggie:/sys/bus/usb/devices# echo "auto" > usb1/1-0\:1.0/port1/device/power/control root@maggie:/sys/bus/usb/devices# cat usb1/1-0\:1.0/port1/power/runtime_status suspended root@maggie:/sys/bus/usb/devices# echo 1 > usb1/1-0\:1.0/port1/power/pm_qos_no_power_off root@maggie:/sys/bus/usb/devices# lsusb Bus 001 Device 003: ID 046d:c040 Logitech, Inc. Corded Tilt-Wheel Mouse Bus 001 Device 002: ID 8087:07dc Intel Corp. Bus 003 Device 002: ID 8087:8000 Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub root@maggie:/sys/bus/usb/devices# cat usb2/2-0\:1.0/port1/power/pm_qos_no_power_off 1 root@maggie:/sys/bus/usb/devices# cat usb2/2-0\:1.0/port1/power/runtime_status active root@maggie:/sys/bus/usb/devices# lsusb -v -d 046d:c040 Bus 001 Device 003: ID 046d:c040 Logitech, Inc. Corded Tilt-Wheel Mouse Couldn't open device, some information will be missing Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0
[PATCH] ARM: sunxi: Add driver for sunxi usb phy
The Allwinner A1x / A2x SoCs have 2 or 3 usb phys which are all accessed
through a single set of registers. Besides this there are also some other
phy related bits which need poking, which are per phy, but shared between the
ohci and ehci controllers, so these are also controlled from this new phy
driver.
Signed-off-by: Hans de Goede
---
.../devicetree/bindings/phy/sun4i-usb-phy.txt | 26 ++
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-sun4i-usb.c| 318 +
4 files changed, 356 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
create mode 100644 drivers/phy/phy-sun4i-usb.c
diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
new file mode 100644
index 000..6c54b3b
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -0,0 +1,26 @@
+Allwinner sun4i USB PHY
+---
+
+Required properties:
+- compatible : should be one of "allwinner,sun4i-a10-usb-phy",
+ "allwinner,sun5i-a13-usb-phy" or "allwinner,sun7i-a20-usb-phy"
+- reg : 2 or 3 register offset + length pairs, 1 phy base reg pair +
+ 1 pair for the pmu-irq register of each hcd
+- #phy-cells : from the generic phy bindings, must be 1
+
+Optional properties:
+- clocks : phandle + clock specifier for the phy clock
+- clock-names : "usb_phy"
+- resets : a list of phandle + reset specifier pairs
+- reset-names : "usb0_reset", "usb1_reset", and / or "usb2_reset"
+
+Example:
+ usbphy: phy@0x01c13400 {
+ #phy-cells = <1>;
+ compatible = "allwinner,sun4i-a10-usb-phy";
+ reg = <0x01c13400 0x10 0x01c14800 0x4 0x01c1c800 0x4>;
+ clocks = <&usb_clk 8>;
+ clock-names = "usb_phy";
+ resets = <&usb_clk 1>, <&usb_clk 2>;
+ reset-names = "usb1_reset", "usb2_reset";
+ };
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 330ef2d..dcce4cf 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -51,4 +51,15 @@ config PHY_EXYNOS_DP_VIDEO
help
Support for Display Port PHY found on Samsung EXYNOS SoCs.
+config PHY_SUN4I_USB
+ tristate "Allwinner sunxi SoC USB PHY driver"
+ depends on ARCH_SUNXI
+ select GENERIC_PHY
+ help
+ Enable this to support the transceiver that is part of Allwinner
+ sunxi SoCs.
+
+ This driver controls the entire USB PHY block, both the USB OTG
+ parts, as well as the 2 regular USB 2 host PHYs.
+
endmenu
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index d0caae9..e9e82f0 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_PHY_EXYNOS_DP_VIDEO) += phy-exynos-dp-video.o
obj-$(CONFIG_PHY_EXYNOS_MIPI_VIDEO)+= phy-exynos-mipi-video.o
obj-$(CONFIG_OMAP_USB2)+= phy-omap-usb2.o
obj-$(CONFIG_TWL4030_USB) += phy-twl4030-usb.o
+obj-$(CONFIG_PHY_SUN4I_USB)+= phy-sun4i-usb.o
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
new file mode 100644
index 000..a15ecc1
--- /dev/null
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -0,0 +1,318 @@
+/*
+ * Allwinner sun4i USB phy driver
+ *
+ * Copyright (C) 2014 Hans de Goede
+ *
+ * Based on code from
+ * Allwinner Technology Co., Ltd.
+ *
+ * Modelled after: Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY driver
+ * Copyright (C) 2013 Samsung Electronics Co., Ltd.
+ * Author: Sylwester Nawrocki
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define REG_ISCR 0x00
+#define REG_PHYCTL 0x04
+#define REG_PHYBIST0x08
+#define REG_PHYTUNE0x0c
+
+#define SUNXI_AHB_ICHR8_EN BIT(10)
+#define SUNXI_AHB_INCR4_BURST_EN BIT(9)
+#define SUNXI_AHB_INCRX_ALIGN_EN BIT(8)
+#define SUNXI_ULPI_BYPASS_EN BIT(0)
+
+#define MAX_PHYS 3
+
+struct sun4i_usb_phy_data {
+ struct clk *clk;
+ void __iomem *base;
+ struct mutex mutex;
+ int num_phys;
+ u32 disc_thresh;
+ struct sun4i_usb_phy {
+ struct phy *phy;
+ void __iomem *pmu_irq;
+
Re: [RFC/PATCH 1/3] pm: make PM macros more smart
On Fri, Dec 20, 2013 at 12:23:36PM -0800, David Cohen wrote:
> On Fri, Dec 20, 2013 at 08:55:27PM +0100, Pavel Machek wrote:
> > On Sun 2013-12-15 11:25:08, David Cohen wrote:
> > > On Sun, Dec 15, 2013 at 06:51:12PM +0100, Pavel Machek wrote:
> > > > On Thu 2013-12-12 21:18:23, David Cohen wrote:
> > > > > This patch makes SET_SYSTEM_SLEEP_PM_OPS() and SET_RUNTIME_PM_OPS()
> > > > > more
> > > > > smart.
> > > > >
> > > > > Despite those macros check for '#ifdef CONFIG_PM_SLEEP/RUNTIME' to
> > > > > avoid
> > > > > setting the callbacks when such #ifdef's aren't defined, they don't
> > > > > handle compiler to avoid messages like that:
> > > > >
> > > > > drivers/usb/host/xhci-plat.c:200:12: warning: ???xhci_plat_suspend???
> > > > > defined but not used [-Wunused-function]
> > > > > drivers/usb/host/xhci-plat.c:208:12: warning: ???xhci_plat_resume???
> > > > > defined but not used [-Wunused-function]
> > > > >
> > > > > As result, those macros get rid of #ifdef's when setting callbacks but
> > > > > not when implementing them.
> > > > >
> > > > > With this patch, drivers using SET_*_PM_OPS() macros don't need to
> > > > > #ifdef
> > > > > the callbacks implementation as well.
> > > >
> > > > Well... Interesting trickery, but it means that resulting kernel
> > > > will be bigge due to the dead functions no?
> > >
> > > Actually, it doesn't get bigger. Before sending the patch I did this
> > > dummy test app:
> > >
> > >
> > > #include
> > >
> > > #define USE_IT_OR_LOOSE_IT(fn) ((void *)((unsigned long)(fn) - (unsigned
> > > long)(fn)))
> > >
> > > #ifdef MAKE_ME_NULL
> > > static int func1(int a)
> > > {
> > > printf("Hey!!\n");
> > > return 0;
> > > }
> > > #endif
> >
> > I thought that point of this patch series was getting rid of the
> > #ifdefs around the function...? Now I'm confused.
>
> Maybe you're misinterpreting the test :)
>
> This #ifdef is used to make this same test code to replicate both
> scenarios according to -DMAKE_ME_NULL (just pay attention to actual
> resulting code after #ifdef's are tested. the #ifdef here is nor related
> to actual #ifdef on kernel). Here are both scenarios:
>
> (1) Not using my trickery (which needs the function to not be present).
> (2) Using my trickery (which needs to function to stay).
>
> With -DMAKE_ME_NULL we replicate (2), then the function *is* there but
> gcc gets rid of it on resulting binary without warnings if used with -O2.
>
> Without -DMAKE_ME_NULL we replicate (1). The #ifdef will fail and then
> remove the function which is an obvious scenario the function won't be
> part of resulting binary.
>
> If we use -S option to have human readable resulting assembly code
> (which is kind of 1:1 for resulting binary), we can compare the result
> of (1) and (2) and check they are pretty similar.
> This proves gcc behaves as expected with my patch: do not need #ifdef
> and do not generate dead codes to resulting binary.
>
> >
> > > struct global_data {
> > > int (*func)(int);
> > > };
> > >
> > > static struct global_data gd = {
> > > #ifdef MAKE_ME_NULL
> > > .func = USE_IT_OR_LOOSE_IT(func1),
> >
> > If you have ifdef around the function, why do you need magic here? Why
> > not
>
> This #ifdef is necessary to prevent the function to be used when it
> doesn't exist due to above #ifdef. But once again: don't misinterpret
> the #ifdefs in this test app with the ones in kernel. They are not
> related at all. If it's still confusing you just make 2 test apps
> without #ifdeds out of this one where one keeps the code inside #ifdefs
> and the other doesn't.
>
> >
> > .func = func1
> >
> > ?
> >
> > Basically the warning tells you that you want the ifdef around the
> > function, too... (Otherwise you waste space). That seems like good
> > warning.
>
> Just check my first explanation.
Ping :)
Comments here?
Br, David Cohen
--
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: [RFC PATCH 0/2] dwc2/s3c-hsotg: Initial steps to combine the 2 driver
> From: Dinh Nguyen [mailto:dingu...@altera.com] > Sent: Tuesday, January 14, 2014 1:30 PM > > On Tue, 2014-01-14 at 13:14 -0800, Greg KH wrote: > > On Tue, Jan 14, 2014 at 08:57:12PM +, Paul Zimmerman wrote: > > > > From: Dinh Nguyen [mailto:dingu...@altera.com] > > > > Sent: Tuesday, January 14, 2014 12:46 PM > > > > > > > > On Tue, 2014-01-14 at 06:21 -0800, Greg KH wrote: > > > > > On Tue, Jan 14, 2014 at 05:01:00AM -0600, dingu...@altera.com wrote: > > > > > > From: Dinh Nguyen > > > > > > > > > > > > Hi, > > > > > > > > > > > > I'm starting work downstream on combining the DWC2 host driver and > > > > > > the s3c-hsotg > > > > > > gadget driver into a dual-role OTG driver. Before I go further, I > > > > > > was hoping to > > > > > > solicit comments on whether or not my initial approach is correct? > > > > > > I know there > > > > > > are plans to combine the 2, so would like to solicit > > > > > > comments/suggestions so > > > > > > that I can also upstream it as well. > > > > > > > > > > > > These 2 patches: > > > > > > > > > > > > * Moves the DWC2 driver out of drivers/staging into > > > > > > drivers/usb/dwc2/ > > > > > > > > > > This already happened yesterday in my tree, so you should see this in > > > > > linux-next by now, no need to do it again :) > > > > > > > > > > > > > I see it now. Thanks for the pointer. > > > > > > > > > > * Moves the s3c-hsotg driver into drivers/usb/dwc2/ > > > > > > * Delete s3c-hsotg.h > > > > > > * Make the s3c-hsotg.c file use the defines in hw.h from the DWC2 > > > > > > driver. > > > > > > > > > > > > This initial patch has been tested on the SOCFPGA platform only in > > > > > > Host-only > > > > > > and Gadget-only mode. > > > > > > > > > > > > The next step would be to do the combining of the driver into a > > > > > > dual-role OTG > > > > > > driver. > > > > > > > > > > I was told that merging the two of these isn't going to work as the > > > > > silicon is just too different, which is why I allowed the code to move > > > > > out of staging. If you feel differently, and think you can combine > > > > > the > > > > > two drivers, that's wonderful, I'll gladly take patches to do so, but > > > > > be > > > > > sure to test on the proper platforms to make sure nothing breaks. > > > > > > > > > > > > > I wasn't aware of the silicon differences. I just took the s3c-hsotg > > > > driver as is and it worked fine on my version 2.93a of the USB IP. I'll > > > > search the ML for information, or perhaps Paul can comment? > > > > > > I think Greg is thinking of the octeon-usb driver in staging [1], not > > > the s3c-hsotg driver. The plan was always to eventually merge dwc2 with > > > s3c-hsotg. > > > > Yes, I'm totally confused, you are right. > > > > Nevermind then, Dinh, if you want to redo your patch after 3.14-rc1 is > > out, that would be great as merging the drivers together can be done > > easier after that development point. > > Unless, Paul has already started the work, I can take a crack at it. No, I have not started any work on that (too busy with other things these days), so please feel free to work on it. -- Paul
Re: [BUG] FL1009: xHCI host not responding to stop endpoint command.
Hi Sarah,
Sarah Sharp writes:
>> I can add the following:
>>
>> 2) I just tested the copy of the small files using the ICY DOCK
>> MB981U3S-1S connected to my ReadyNAS 102 *on a 3.11.7 kernel*
>> and it completed successfully.
>
> Please try a 3.13-rc7 kernel after running `git revert 35773dac5f86`.
I tried current 3.13.0-rc8 w/ 35773dac5f86 reverted and the result is
the same:
Powering the dock station:
[ 70.530128] usb 3-1: new SuperSpeed USB device number 2 using xhci_hcd
[ 70.550649] usb 3-1: New USB device found, idVendor=174c, idProduct=5106
[ 70.557368] usb 3-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 70.564529] usb 3-1: Product: AS2105
[ 70.568112] usb 3-1: Manufacturer: ASMedia
[ 70.57] usb 3-1: SerialNumber:
[ 70.579174] usb-storage 3-1:1.0: USB Mass Storage device detected
[ 70.586379] scsi4 : usb-storage 3-1:1.0
[ 71.590415] scsi 4:0:0:0: Direct-Access ASMT 2105 0
PQ: 0 ANSI: 6
[ 71.601630] sd 4:0:0:0: Attached scsi generic sg2 type 0
[ 76.968663] sd 4:0:0:0: [sdc] 488281250 512-byte logical blocks: (250 GB/232
GiB)
[ 76.976800] sd 4:0:0:0: [sdc] Write Protect is off
[ 76.982190] sd 4:0:0:0: [sdc] Write cache: enabled, read cache: enabled,
doesn't support DPO or FUA
[ 77.028598] sdc: sdc1 sdc2
[ 77.035729] sd 4:0:0:0: [sdc] Attached SCSI disk
Starting the copy after mounting the disk and creating test/:
# cp -r /bin/ /lib /sbin /opt /etc /usr test/
[ 398.130048] xhci_hcd :02:00.0: xHCI host not responding to stop endpoint
command.
[ 398.137905] xhci_hcd :02:00.0: Assuming host is dying, halting host.
[ 398.144650] xhci_hcd :02:00.0: HC died; cleaning up
[ 398.150337] usb 3-1: USB disconnect, device number 2
[ 398.155472] sd 4:0:0:0: Device offlined - not ready after error recovery
[ 398.170111] sd 4:0:0:0: [sdc] Unhandled error code
[ 398.174923] sd 4:0:0:0: [sdc]
[ 398.178076] sd 4:0:0:0: [sdc] CDB:
[ 398.181606] end_request: I/O error, dev sdc, sector 235538432
[ 398.187367] EXT4-fs warning (device sdc1): ext4_end_bio:317: I/O error
writing to inode 7347656 (offset 0 size 323584 starting block 29442334)
[ 398.200175] Buffer I/O error on device sdc1, logical block 29442048
[ 398.206457] Buffer I/O error on device sdc1, logical block 29442049
[ 398.212739] Buffer I/O error on device sdc1, logical block 29442050
[ 398.219016] Buffer I/O error on device sdc1, logical block 29442051
[ 398.225298] Buffer I/O error on device sdc1, logical block 29442052
[ 398.231579] Buffer I/O error on device sdc1, logical block 29442053
[ 398.237857] Buffer I/O error on device sdc1, logical block 29442054
[ 398.244137] Buffer I/O error on device sdc1, logical block 29442055
[ 398.250418] Buffer I/O error on device sdc1, logical block 29442056
[ 398.256696] Buffer I/O error on device sdc1, logical block 29442057
[ 398.264481] sd 4:0:0:0: [sdc] Unhandled error code
[ 398.269290] sd 4:0:0:0: [sdc]
[ 398.272466] sd 4:0:0:0: [sdc] CDB:
[ 398.275980] end_request: I/O error, dev sdc, sector 235538672
[ 398.281744] EXT4-fs warning (device sdc1): ext4_end_bio:317: I/O error
writing to inode 7347656 (offset 0 size 323584 starting block 29442364)
[ 398.294606] EXT4-fs warning (device sdc1): ext4_end_bio:317: I/O error
writing to inode 7347656 (offset 0 size 323584 starting block 29442383)
>> 2) on current 3.13.0-rc7 kernel (w/ Bjørn patch applied just in case), I
>
> Which patch are you referring to?
This one:
Commit 60e453a940ac ("USBNET: fix handling padding packet")
added an extra SG entry in case padding is necessary, but
failed to update the initialisation of the list. This can
cause list traversal to fall off the end of the list,
resulting in an oops.
Fixes: 60e453a940ac ("USBNET: fix handling padding packet")
Reported-by: Thomas Kear
Cc: Ming Lei
Signed-off-by: Bjørn Mork
>> just transferred 40GB through a Logitec LAN-GT JU3H3 (it is based on an
>> ASIX AX88179) connected to my ReadyNAS Duo v2 (NEC XHCI controller) at
>> an average rate of 82MB/s. Bottom line: no issue. When I try to do the
>> same on my ReadyNAS 102, I immediately get complaints:
>
> Was the ReadyNAS 102 with the Fresco Logic host running 3.13.0-rc7 as
> well?
Yes. Summary is:
- RN102 w/ 3.11.7: OK
- RN102 w/ 3.13-rc7: KO
- Duo v2 w/ 3.13.0-rc7: OK
>> [ 383.280429] xhci_hcd :02:00.0: ep 0x82 - asked for 20480 bytes, 20400
>> bytes untransferred
>> [ 383.280892] xhci_hcd :02:00.0: ep 0x82 - asked for 20480 bytes, 20400
>> bytes untransferred
>> [ 411.620073] xhci_hcd :02:00.0: ep 0x82 - asked for 20480 bytes, 20352
>> bytes untransferred
>> [ 411.620750] xhci_hcd :02:00.0: ep 0x82 - asked for 20480 bytes, 20400
>> bytes untransferred
>> [ 411.621727] xhci_hcd :02:00.0: ep 0x82 - asked for 20480 bytes, 20400
>> bytes untransferred
>> [ 412.066651] xhci_hcd :02:00.0: ep 0x82 - asked for 20480 bytes, 20352
>> bytes untransfer
Re: [PATCH v3 03/10] usb: find internal hub tier mismatch via acpi
On Tue, Jan 14, 2014 at 1:42 PM, Sarah Sharp wrote: > On Mon, Jan 13, 2014 at 08:57:38PM -0500, Alan Stern wrote: >> On Mon, 13 Jan 2014, Sarah Sharp wrote: >> >> > On Mon, Jan 13, 2014 at 02:56:57PM -0800, Sarah Sharp wrote: >> >> > > I haven't looked at this too closely, but what happens if: >> > > - the USB 2.0 roothub is registered >> > > - userspace immediately sets autosuspend_delay to zero and >> > >pm_qos_no_port_poweroff to zero >> > > - usb_acpi_find_device changes the connect_type to something other than >> > >unknown >> > > - before usb_acpi_check_port_peer() is called, the port is suspended >> > >> > Or that call finishes, but no peer port is set yet, because the USB 3.0 >> > roothub isn't registered yet. The USB 2.0 bus can be suspended before >> > the USB 3.0 bus has finished registering, as I've seen from this thread: >> > >> > http://marc.info/?l=linux-usb&m=138914518219334&w=2 >> >> It's always possible for xhci-hcd to prevent the USB-2 root hub from >> being suspended by calling pm_runtime_get_noresume. The corresponding >> _put can be done after the USB-3 root hub has been registered. > > Sure, it's on my todo list to fix that. I just wondered if there were > other race conditions present, given that I could find one off the top > of my head. At least as far as this patchset is concerned there is no race/requirement to hold off usb-2 root hub power management. The patchset expects usb2 ports to suspend independent of their peer usb3 port state, and forces usb3 ports to always resume before usb2 peers. > > What do you think about the rest of the patchset? > -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 03/10] usb: find internal hub tier mismatch via acpi
On Mon, Jan 13, 2014 at 08:57:38PM -0500, Alan Stern wrote: > On Mon, 13 Jan 2014, Sarah Sharp wrote: > > > On Mon, Jan 13, 2014 at 02:56:57PM -0800, Sarah Sharp wrote: > > > > I haven't looked at this too closely, but what happens if: > > > - the USB 2.0 roothub is registered > > > - userspace immediately sets autosuspend_delay to zero and > > >pm_qos_no_port_poweroff to zero > > > - usb_acpi_find_device changes the connect_type to something other than > > >unknown > > > - before usb_acpi_check_port_peer() is called, the port is suspended > > > > Or that call finishes, but no peer port is set yet, because the USB 3.0 > > roothub isn't registered yet. The USB 2.0 bus can be suspended before > > the USB 3.0 bus has finished registering, as I've seen from this thread: > > > > http://marc.info/?l=linux-usb&m=138914518219334&w=2 > > It's always possible for xhci-hcd to prevent the USB-2 root hub from > being suspended by calling pm_runtime_get_noresume. The corresponding > _put can be done after the USB-3 root hub has been registered. Sure, it's on my todo list to fix that. I just wondered if there were other race conditions present, given that I could find one off the top of my head. What do you think about the rest of the patchset? 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: [RFC PATCH 0/2] dwc2/s3c-hsotg: Initial steps to combine the 2 driver
On Tue, 2014-01-14 at 13:14 -0800, Greg KH wrote: > On Tue, Jan 14, 2014 at 08:57:12PM +, Paul Zimmerman wrote: > > > From: Dinh Nguyen [mailto:dingu...@altera.com] > > > Sent: Tuesday, January 14, 2014 12:46 PM > > > > > > On Tue, 2014-01-14 at 06:21 -0800, Greg KH wrote: > > > > On Tue, Jan 14, 2014 at 05:01:00AM -0600, dingu...@altera.com wrote: > > > > > From: Dinh Nguyen > > > > > > > > > > Hi, > > > > > > > > > > I'm starting work downstream on combining the DWC2 host driver and > > > > > the s3c-hsotg > > > > > gadget driver into a dual-role OTG driver. Before I go further, I was > > > > > hoping to > > > > > solicit comments on whether or not my initial approach is correct? I > > > > > know there > > > > > are plans to combine the 2, so would like to solicit > > > > > comments/suggestions so > > > > > that I can also upstream it as well. > > > > > > > > > > These 2 patches: > > > > > > > > > > * Moves the DWC2 driver out of drivers/staging into drivers/usb/dwc2/ > > > > > > > > This already happened yesterday in my tree, so you should see this in > > > > linux-next by now, no need to do it again :) > > > > > > > > > > I see it now. Thanks for the pointer. > > > > > > > > * Moves the s3c-hsotg driver into drivers/usb/dwc2/ > > > > > * Delete s3c-hsotg.h > > > > > * Make the s3c-hsotg.c file use the defines in hw.h from the DWC2 > > > > > driver. > > > > > > > > > > This initial patch has been tested on the SOCFPGA platform only in > > > > > Host-only > > > > > and Gadget-only mode. > > > > > > > > > > The next step would be to do the combining of the driver into a > > > > > dual-role OTG > > > > > driver. > > > > > > > > I was told that merging the two of these isn't going to work as the > > > > silicon is just too different, which is why I allowed the code to move > > > > out of staging. If you feel differently, and think you can combine the > > > > two drivers, that's wonderful, I'll gladly take patches to do so, but be > > > > sure to test on the proper platforms to make sure nothing breaks. > > > > > > > > > > I wasn't aware of the silicon differences. I just took the s3c-hsotg > > > driver as is and it worked fine on my version 2.93a of the USB IP. I'll > > > search the ML for information, or perhaps Paul can comment? > > > > I think Greg is thinking of the octeon-usb driver in staging [1], not > > the s3c-hsotg driver. The plan was always to eventually merge dwc2 with > > s3c-hsotg. > > Yes, I'm totally confused, you are right. > > Nevermind then, Dinh, if you want to redo your patch after 3.14-rc1 is > out, that would be great as merging the drivers together can be done > easier after that development point. > Unless, Paul has already started the work, I can take a crack at it. Dinh > 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 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst [NEW HARDWARE]
On 01/14/2014 09:20 AM, Sarah Sharp wrote: > On Mon, Jan 13, 2014 at 03:39:07PM -0800, walt wrote: >> Sarah, I just fixed my xhci bug for US$19.99 :) >> >> #lspci | tail -1 >> 04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller >> (rev 03) >> >> This new NEC usb3 controller does everything the ASMedia controller should >> have >> done from the start. > I just got a similar report from someone with a Fresco Logic host > controller, so I may need you to test a work-around patch for the > ASMedia host at some point. Oy, Sarah! ;) I put the ASMedia adapter in my older amd64 machine, and, well, the stupid thing Just Works(TM) with kernel 3.12.7! (Yes, with the same disk docking station, too.) I can't believe the adapter works perfectly in a different computer. Have you seen this kind of thing before? At the moment I have two machines using your xhci driver and both work perfectly, so I thank you again :) I'm not sure where to go with this next. I could put the adapter back in the other machine again if you have more patches to test. -- 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: [RFC PATCH 0/2] dwc2/s3c-hsotg: Initial steps to combine the 2 driver
On Tue, Jan 14, 2014 at 08:57:12PM +, Paul Zimmerman wrote: > > From: Dinh Nguyen [mailto:dingu...@altera.com] > > Sent: Tuesday, January 14, 2014 12:46 PM > > > > On Tue, 2014-01-14 at 06:21 -0800, Greg KH wrote: > > > On Tue, Jan 14, 2014 at 05:01:00AM -0600, dingu...@altera.com wrote: > > > > From: Dinh Nguyen > > > > > > > > Hi, > > > > > > > > I'm starting work downstream on combining the DWC2 host driver and the > > > > s3c-hsotg > > > > gadget driver into a dual-role OTG driver. Before I go further, I was > > > > hoping to > > > > solicit comments on whether or not my initial approach is correct? I > > > > know there > > > > are plans to combine the 2, so would like to solicit > > > > comments/suggestions so > > > > that I can also upstream it as well. > > > > > > > > These 2 patches: > > > > > > > > * Moves the DWC2 driver out of drivers/staging into drivers/usb/dwc2/ > > > > > > This already happened yesterday in my tree, so you should see this in > > > linux-next by now, no need to do it again :) > > > > > > > I see it now. Thanks for the pointer. > > > > > > * Moves the s3c-hsotg driver into drivers/usb/dwc2/ > > > > * Delete s3c-hsotg.h > > > > * Make the s3c-hsotg.c file use the defines in hw.h from the DWC2 > > > > driver. > > > > > > > > This initial patch has been tested on the SOCFPGA platform only in > > > > Host-only > > > > and Gadget-only mode. > > > > > > > > The next step would be to do the combining of the driver into a > > > > dual-role OTG > > > > driver. > > > > > > I was told that merging the two of these isn't going to work as the > > > silicon is just too different, which is why I allowed the code to move > > > out of staging. If you feel differently, and think you can combine the > > > two drivers, that's wonderful, I'll gladly take patches to do so, but be > > > sure to test on the proper platforms to make sure nothing breaks. > > > > > > > I wasn't aware of the silicon differences. I just took the s3c-hsotg > > driver as is and it worked fine on my version 2.93a of the USB IP. I'll > > search the ML for information, or perhaps Paul can comment? > > I think Greg is thinking of the octeon-usb driver in staging [1], not > the s3c-hsotg driver. The plan was always to eventually merge dwc2 with > s3c-hsotg. Yes, I'm totally confused, you are right. Nevermind then, Dinh, if you want to redo your patch after 3.14-rc1 is out, that would be great as merging the drivers together can be done easier after that development point. 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: [RFC PATCH 0/2] dwc2/s3c-hsotg: Initial steps to combine the 2 driver
> From: Dinh Nguyen [mailto:dingu...@altera.com]
> Sent: Tuesday, January 14, 2014 12:46 PM
>
> On Tue, 2014-01-14 at 06:21 -0800, Greg KH wrote:
> > On Tue, Jan 14, 2014 at 05:01:00AM -0600, dingu...@altera.com wrote:
> > > From: Dinh Nguyen
> > >
> > > Hi,
> > >
> > > I'm starting work downstream on combining the DWC2 host driver and the
> > > s3c-hsotg
> > > gadget driver into a dual-role OTG driver. Before I go further, I was
> > > hoping to
> > > solicit comments on whether or not my initial approach is correct? I know
> > > there
> > > are plans to combine the 2, so would like to solicit comments/suggestions
> > > so
> > > that I can also upstream it as well.
> > >
> > > These 2 patches:
> > >
> > > * Moves the DWC2 driver out of drivers/staging into drivers/usb/dwc2/
> >
> > This already happened yesterday in my tree, so you should see this in
> > linux-next by now, no need to do it again :)
> >
>
> I see it now. Thanks for the pointer.
>
> > > * Moves the s3c-hsotg driver into drivers/usb/dwc2/
> > > * Delete s3c-hsotg.h
> > > * Make the s3c-hsotg.c file use the defines in hw.h from the DWC2 driver.
> > >
> > > This initial patch has been tested on the SOCFPGA platform only in
> > > Host-only
> > > and Gadget-only mode.
> > >
> > > The next step would be to do the combining of the driver into a dual-role
> > > OTG
> > > driver.
> >
> > I was told that merging the two of these isn't going to work as the
> > silicon is just too different, which is why I allowed the code to move
> > out of staging. If you feel differently, and think you can combine the
> > two drivers, that's wonderful, I'll gladly take patches to do so, but be
> > sure to test on the proper platforms to make sure nothing breaks.
> >
>
> I wasn't aware of the silicon differences. I just took the s3c-hsotg
> driver as is and it worked fine on my version 2.93a of the USB IP. I'll
> search the ML for information, or perhaps Paul can comment?
I think Greg is thinking of the octeon-usb driver in staging [1], not
the s3c-hsotg driver. The plan was always to eventually merge dwc2 with
s3c-hsotg.
--
Paul
[1] http://marc.info/?l=linux-driver-devel&m=137665801904014
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h�&�� �G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�
Re: [RFC PATCH 0/2] dwc2/s3c-hsotg: Initial steps to combine the 2 driver
On Tue, 2014-01-14 at 06:21 -0800, Greg KH wrote: > On Tue, Jan 14, 2014 at 05:01:00AM -0600, dingu...@altera.com wrote: > > From: Dinh Nguyen > > > > Hi, > > > > I'm starting work downstream on combining the DWC2 host driver and the > > s3c-hsotg > > gadget driver into a dual-role OTG driver. Before I go further, I was > > hoping to > > solicit comments on whether or not my initial approach is correct? I know > > there > > are plans to combine the 2, so would like to solicit comments/suggestions so > > that I can also upstream it as well. > > > > These 2 patches: > > > > * Moves the DWC2 driver out of drivers/staging into drivers/usb/dwc2/ > > This already happened yesterday in my tree, so you should see this in > linux-next by now, no need to do it again :) > I see it now. Thanks for the pointer. > > * Moves the s3c-hsotg driver into drivers/usb/dwc2/ > > * Delete s3c-hsotg.h > > * Make the s3c-hsotg.c file use the defines in hw.h from the DWC2 driver. > > > > This initial patch has been tested on the SOCFPGA platform only in Host-only > > and Gadget-only mode. > > > > The next step would be to do the combining of the driver into a dual-role > > OTG > > driver. > > I was told that merging the two of these isn't going to work as the > silicon is just too different, which is why I allowed the code to move > out of staging. If you feel differently, and think you can combine the > two drivers, that's wonderful, I'll gladly take patches to do so, but be > sure to test on the proper platforms to make sure nothing breaks. > I wasn't aware of the silicon differences. I just took the s3c-hsotg driver as is and it worked fine on my version 2.93a of the USB IP. I'll search the ML for information, or perhaps Paul can comment? Thanks, Dinh > 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] usb: ftdi_sio: add Mindstorms EV3 console adapter
Greg Kroah-Hartman writes: > On Tue, Jan 14, 2014 at 06:56:54PM +0100, Bjørn Mork wrote: >> Cc: >> Signed-off-by: Bjørn Mork >> --- >> Hello Greg! >> >> I saw your post on Google+ :-) You'll probably want one of >> these nice adapters to go with that toy. It's simply not worth >> the job making the console cable yourself. > > Very true, any idea where I can get one of these at? I bought it here: http://www.mindsensors.com/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=189&MMN_position=39:39 Bjørn -- 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 68161] Unstable work of xhci with USB3.0 card reader and UDMA7 CompactFlash card.
Update on my current research status. 1. To get normal read/write speed over USB3 I have to set max_sector_kb to 64. Otherwise write is fine, but read is very slow (about 300kb/s). Maybe this is hardware issue of this reader/card. However over USB2 all works fine without any tweaks. All that said below is for case of max_sector_kb = 64. 2. Stall and reset of device while mounting CF card from Thunar or entering mount point with Midnight Commander was a consequence of syscall statfs (I've ptraced mc). Google said this is a well known issue of a vfat kernel module that was fixed some time ago, but a mount option to workaround it still present and called "usefree". When this option is supplied to mount command all works without any issues. 3. Also when I build kernel without CONFIG_PM option all works fine without mount option "usefree". Now I'm a bit confused by influence of CONFIG_PM and vfat mount option on USB3 cardreader. Especially when reading and writing the whole CF in reader using dd and corresponding /dev/sd? is done without any issues and doesn't demand any tweaks like changing default value of max_sector_kb. -- 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: usb3 hdd docking station doesn't work with recent kernels
On Tue, 14 Jan 2014, Sarah Sharp wrote:
> Alan, I believe your analysis of the code was incorrect when you asked
> Xenia to create commit 60e102ac73cd40069d077014c93c86dc7205cb68 in
> August:
>
> http://marc.info/?l=linux-usb&m=137780837109921&w=2
>
> You asked her to set lpm_capable because you thought it simply wasn't
> being set at all. You overlooked the xHCI driver setting lpm_capable in
> drivers/usb/host/xhci-pci.c.
So I did.
> The xHCI driver only sets lpm_capable for xHCI host controllers that it
> knows how to calculate the U1/U2 timeout values for. Since those
> timeout values are highly dependent on how the xHCI host hardware
> scheduling works, I've only enabled USB 3.0 Link PM for Intel hosts:
>
> static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
> {
> ...
> if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
> xhci->quirks |= XHCI_LPM_SUPPORT;
> xhci->quirks |= XHCI_INTEL_HOST;
> }
>
> static int xhci_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
> {
> ...
> /* We know the LPM timeout algorithms for this host, let the USB core
> * enable and disable LPM for devices under the USB 3.0 roothub.
> */
> if (xhci->quirks & XHCI_LPM_SUPPORT)
> hcd_to_bus(xhci->shared_hcd)->root_hub->lpm_capable = 1;
>
> lpm_capable shouldn't be set for hosts where we don't know how to
> calculate the U1/U2 timeout values, so commit
> 60e102ac73cd40069d077014c93c86dc7205cb68 should just be reverted.
Allow me to propose an alternative.
Let's do our best to treat root hubs the same as external hubs. This
means that udev->lpm_capable should be set the same way in
hub_port_init() and register_root_hub(): by calling
usb_device_supports_lpm(), which gets the information from the BOS
extended capabilities.
In particular, xhci-hcd shouldn't go messing around with the innards of
the root hub structure. Instead of setting lpm_capable when it knows
how to calculate the timeout values, it should pass the necessary
information through the ss_cap descriptor, just like an external hub
would. Either don't provide that descriptor at all if you don't know
the timeout values, or else set those fields in the descriptor to
something invalid (and make usb_device_supports_lpm() test for it).
And while we're at it, let's change the comment in
usb_device_supports_lpm() that says "All USB 3.0 must support LPM".
Not only is it ungrammatical, but as you point out, it is wrong for
some root hubs.
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 v5 2/2] ehci-platform: Add support for clks and phy passed through devicetree
On Mon, 13 Jan 2014, Hans de Goede wrote:
> Currently ehci-platform is only used in combination with devicetree when used
> with some Via socs. By extending it to (optionally) get clks and a phy from
> devicetree, and enabling / disabling those on power_on / off, it can be used
> more generically. Specifically after this commit it can be used for the
> ehci controller on Allwinner sunxi SoCs.
>
> Since ehci-platform is intended to handle any generic enough non pci ehci
> device, add a "usb-ehci" compatibility string.
>
> There already is a usb-ehci device-tree bindings document, update this
> with clks and phy bindings info.
>
> Although actually quite generic so far the via,vt8500 compatibilty string
> had its own bindings document. Somehow we even ended up with 2 of them. Since
> these provide no extra information over the generic usb-ehci documentation,
> this patch removes them.
>
> The ehci-ppc-of.c driver also claims the usb-ehci compatibility string,
> even though it mostly is ibm,usb-ehci-440epx specific. ehci-platform.c is
> not needed on ppc platforms, so add a !PPC_OF dependency to it to avoid
> 2 drivers claiming the same compatibility string getting build on ppc.
>
> Signed-off-by: Hans de Goede
Same comment as the ohci-platform patch.
Oh, and one other thing I almost missed. (This applies to both
patches.)
> +static int ehci_platform_power_on(struct platform_device *dev)
> +{
> + struct usb_hcd *hcd = platform_get_drvdata(dev);
> + struct ehci_platform_priv *priv = hcd_to_ehci_priv(hcd);
> + int clk, ret;
> +
> + for (clk = 0; priv->clks[clk] && clk < EHCI_MAX_CLKS; clk++) {
Here and in ehci_platform_remove, you need to check clk < EHCI_MAX_CLKS
_before_ dereferencing priv->clks[clk]. Yes, it probably won't make
any difference in real life, but it's still wrong in principle. In
fact, this is the sort of thing a static checker might find.
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 v5 1/2] ohci-platform: Add support for devicetree instantiation
On Mon, 13 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.
This is fine as far as I am concerned, except for one thing.
> @@ -60,17 +127,23 @@ static int ohci_platform_probe(struct platform_device
> *dev)
> struct usb_hcd *hcd;
> struct resource *res_mem;
> struct usb_ohci_pdata *pdata = dev_get_platdata(&dev->dev);
> - int irq;
> - int err = -ENOMEM;
> -
> - if (!pdata) {
> - WARN_ON(1);
> - return -ENODEV;
> - }
> + struct ohci_platform_priv *priv;
> + int clk, irq, err;
clk isn't initialized to anything...
> -err_put_hcd:
> - usb_put_hcd(hcd);
> err_power:
> if (pdata->power_off)
> pdata->power_off(dev);
> +err_put_clks:
> + while (--clk >= 0)
> + clk_put(priv->clks[clk]);
... but it gets used here. The compiler should have warned about this.
After fixing that, you can add
Acked-by: Alan Stern
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: usb3 hdd docking station doesn't work with recent kernels
On Tue, Jan 14, 2014 at 10:04:46AM -0500, Alan Stern wrote:
> On Tue, 14 Jan 2014, Sergey Galanov wrote:
>
> > Hi Oliver.
> > Yes, reverting that commit fixes the problem (I did it on top of 3.13rc8).
> >
> > On 13 January 2014 14:05, Oliver Neukum wrote:
> > > On Sun, 2014-01-12 at 14:12 +0400, Sergey Galanov wrote:
> > >> Hi.
> > >> My hdd docking station (AgeStar 3UBT with usb3 support) stopped
> > >> working after upgrade to linux 3.12.3. It worked fine in 3.12.0 and
> > >> before. I can't point to more specific version because it's hard to
> > >> find old packages for my distro (ArchLinux). I also tried 3.12.6,
> > >> 3.12.7 and 3.13rc7 and the problem persists.
> > >
> > > This is not good. My bet is on 60e102ac73cd40069d077014c93c86dc7205cb68
> > > Could you revert that? If that doesn't do the job, I think you'll need
> > > to bisect.
>
> Bear in mind that this doesn't mean there's anything wrong with the
> commit. In this case, it appears to be a bug in the hardware. The
> commit merely exposes the bug, by allowing the kernel to use a feature
> it wasn't using before.
Sergey, with that commit reverted, please send me the `lsusb -v` output
when the docking station is attached.
Also, please send the output of `sudo lspci -vvv -n`.
Alan, I believe your analysis of the code was incorrect when you asked
Xenia to create commit 60e102ac73cd40069d077014c93c86dc7205cb68 in
August:
http://marc.info/?l=linux-usb&m=137780837109921&w=2
You asked her to set lpm_capable because you thought it simply wasn't
being set at all. You overlooked the xHCI driver setting lpm_capable in
drivers/usb/host/xhci-pci.c.
The xHCI driver only sets lpm_capable for xHCI host controllers that it
knows how to calculate the U1/U2 timeout values for. Since those
timeout values are highly dependent on how the xHCI host hardware
scheduling works, I've only enabled USB 3.0 Link PM for Intel hosts:
static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
{
...
if (pdev->vendor == PCI_VENDOR_ID_INTEL) {
xhci->quirks |= XHCI_LPM_SUPPORT;
xhci->quirks |= XHCI_INTEL_HOST;
}
static int xhci_pci_probe(struct pci_dev *dev, const struct pci_device_id *id)
{
...
/* We know the LPM timeout algorithms for this host, let the USB core
* enable and disable LPM for devices under the USB 3.0 roothub.
*/
if (xhci->quirks & XHCI_LPM_SUPPORT)
hcd_to_bus(xhci->shared_hcd)->root_hub->lpm_capable = 1;
lpm_capable shouldn't be set for hosts where we don't know how to
calculate the U1/U2 timeout values, so commit
60e102ac73cd40069d077014c93c86dc7205cb68 should just be reverted.
It could also be that Sergey has an Intel host controller, and the
device simply barfs when USB 3.0 Link PM is enabled. In that case,
we'll have to figure out a work-around (perhaps by disabling lpm for the
device all together if it doesn't respond to the Set SEL control
transfer).
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: EHCI host broken -- interrupts disabled
On Tue, 14 Jan 2014, Sarah Sharp wrote: > Hi Alan, I'm not a good person to ask about this. Maybe Bjorn can help. > All this info is second- or third-hand, so please excuse the extremely > vague bug report. > > A new Intel Atom system (Baytrail) comes with both an xHCI host and an > EHCI host, but the BIOS has an "EHCI only" option that hides the xHCI > host PCI device from the operating system. It appears that when the > BIOS is in this mode, the EHCI PCI interrupt is disabled, and the host > simply doesn't work. > > Jamie and Gaggery have more details about the system and the exact > failure mode. They can provide dmesg as well as a PCI register space > dump, if necessary. (Jamie and Gaggery, please note, a publicly > archived mailing list is Cc'ed.) > > A customer reports that the following patch fixes the issue: > > diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c > index 3e86bf4371b3..e77566a021ec 100644 > --- a/drivers/usb/host/ehci-pci.c > +++ b/drivers/usb/host/ehci-pci.c > @@ -112,6 +112,9 @@ static int ehci_pci_setup(struct usb_hcd *hcd) > case PCI_VENDOR_ID_INTEL: > if (pdev->device == PCI_DEVICE_ID_INTEL_CE4100_USB) > hcd->has_tt = 1; > + /* Baytrail BIOS in EHCI only mode fails to enable interrupts */ > + if (pdev->device == 0x0f34) > + pci_intx(pdev, 1); > break; > case PCI_VENDOR_ID_TDI: > if (pdev->device == PCI_DEVICE_ID_TDI_EHCI) > > I looked through the USB PCI initialization code, and I can't find any > place where interrupts are enabled, so I assume the PCI core is supposed > to enable interrupts? Or is it assumed that the system boots with all > PCI device interrupts enabled? In that case, is it a BIOS issue? As I recall, the original PCI spec did not include any way to enable or disable interrupts -- a rather surprising omission. It was added later on. Anyhow, this is all handled in the PCI core. The device driver shouldn't need to do much more than pci_enable_device() (which handles power plus I/O and memory resources) and pci_set_master() (which handles DMA). Nothing about enabling interrupt generation. A quick search did not show any place where the PCI core explicitly enables interrupts on new devices, so maybe it does assume that the firmware always enables them. I don't know what guarantees (if any) a BIOS is supposed to fulfill. It seems like the best place to fix this is probably in the PCI core. 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: EHCI host broken -- interrupts disabled
On Tue, Jan 14, 2014 at 10:17:21AM -0800, Sarah Sharp wrote: > Hi Alan, > > All this info is second- or third-hand, so please excuse the extremely > vague bug report. > > A new Intel Atom system (Baytrail) comes with both an xHCI host and an > EHCI host, but the BIOS has an "EHCI only" option that hides the xHCI > host PCI device from the operating system. It appears that when the > BIOS is in this mode, the EHCI PCI interrupt is disabled, and the host > simply doesn't work. > > Jamie and Gaggery have more details about the system and the exact > failure mode. They can provide dmesg as well as a PCI register space > dump, if necessary. (Jamie and Gaggery, please note, a publicly > archived mailing list is Cc'ed.) Ah, I found the dmesg sent from Jamie: [ 10.800309] usb 1-1: khubd timed out on ep0in len=18/64 [ 15.920809] usb 1-1: khubd timed out on ep0out len=0/0 [ 21.130284] usb 1-1: khubd timed out on ep0out len=0/0 [ 21.339922] usb 1-1: device not accepting address 2, error -110 [ 21.469657] usb 1-1: new high-speed USB device number 3 using ehci_hcd [ 21.469657] usb 1-1: new high-speed USB device number 3 using ehci_hcd [ 26.470005] usb 1-1: khubd timed out on ep0in len=18/64 [ 31.599927] usb 1-1: khubd timed out on ep0out len=0/0 [ 36.809314] usb 1-1: khubd timed out on ep0out len=0/0 [ 37.018898] usb 1-1: device not accepting address 3, error -110 [ 37.148525] usb 1-1: new high-speed USB device number 4 using ehci_hcd [ 37.148525] usb 1-1: new high-speed USB device number 4 using ehci_hcd [ 42.149106] usb 1-1: khubd timed out on ep0out len=0/0 [ 47.369158] usb 1-1: khubd timed out on ep0out len=0/0 [ 47.578584] usb 1-1: device not accepting address 4, error -110 [ 47.708060] usb 1-1: new high-speed USB device number 5 using ehci_hcd [ 47.708060] usb 1-1: new high-speed USB device number 5 using ehci_hcd So it looks like the port reported the rate-matching hub connected, but control transfers to the device simply failed. > A customer reports that the following patch fixes the issue: > > diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c > index 3e86bf4371b3..e77566a021ec 100644 > --- a/drivers/usb/host/ehci-pci.c > +++ b/drivers/usb/host/ehci-pci.c > @@ -112,6 +112,9 @@ static int ehci_pci_setup(struct usb_hcd *hcd) > case PCI_VENDOR_ID_INTEL: > if (pdev->device == PCI_DEVICE_ID_INTEL_CE4100_USB) > hcd->has_tt = 1; > + /* Baytrail BIOS in EHCI only mode fails to enable interrupts */ > + if (pdev->device == 0x0f34) > + pci_intx(pdev, 1); > break; > case PCI_VENDOR_ID_TDI: > if (pdev->device == PCI_DEVICE_ID_TDI_EHCI) > > I looked through the USB PCI initialization code, and I can't find any > place where interrupts are enabled, so I assume the PCI core is supposed > to enable interrupts? Or is it assumed that the system boots with all > PCI device interrupts enabled? In that case, is it a BIOS issue? > > 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 -- 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: ftdi_sio: add Mindstorms EV3 console adapter
On Tue, Jan 14, 2014 at 06:56:54PM +0100, Bjørn Mork wrote: > Cc: > Signed-off-by: Bjørn Mork > --- > Hello Greg! > > I saw your post on Google+ :-) You'll probably want one of > these nice adapters to go with that toy. It's simply not worth > the job making the console cable yourself. Very true, any idea where I can get one of these at? 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
EHCI host broken -- interrupts disabled
Hi Alan, All this info is second- or third-hand, so please excuse the extremely vague bug report. A new Intel Atom system (Baytrail) comes with both an xHCI host and an EHCI host, but the BIOS has an "EHCI only" option that hides the xHCI host PCI device from the operating system. It appears that when the BIOS is in this mode, the EHCI PCI interrupt is disabled, and the host simply doesn't work. Jamie and Gaggery have more details about the system and the exact failure mode. They can provide dmesg as well as a PCI register space dump, if necessary. (Jamie and Gaggery, please note, a publicly archived mailing list is Cc'ed.) A customer reports that the following patch fixes the issue: diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c index 3e86bf4371b3..e77566a021ec 100644 --- a/drivers/usb/host/ehci-pci.c +++ b/drivers/usb/host/ehci-pci.c @@ -112,6 +112,9 @@ static int ehci_pci_setup(struct usb_hcd *hcd) case PCI_VENDOR_ID_INTEL: if (pdev->device == PCI_DEVICE_ID_INTEL_CE4100_USB) hcd->has_tt = 1; + /* Baytrail BIOS in EHCI only mode fails to enable interrupts */ + if (pdev->device == 0x0f34) + pci_intx(pdev, 1); break; case PCI_VENDOR_ID_TDI: if (pdev->device == PCI_DEVICE_ID_TDI_EHCI) I looked through the USB PCI initialization code, and I can't find any place where interrupts are enabled, so I assume the PCI core is supposed to enable interrupts? Or is it assumed that the system boots with all PCI device interrupts enabled? In that case, is it a BIOS issue? 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: [BUG] FL1009: xHCI host not responding to stop endpoint command.
Sarah Sharp writes: > On Sun, Jan 12, 2014 at 10:36:56PM +0100, Arnaud Ebalard wrote: > >> a...@natisbad.org (Arnaud Ebalard) writes: >> >> 2) on current 3.13.0-rc7 kernel (w/ Bjørn patch applied just in case), I > > Which patch are you referring to? I wondered about that too at first :-) But luckily I don't work that much, and the reference to the ASIX AX88179 made it clearer. I believe it must have been this patch: https://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=fdc3452cd2c7b2bfe0f378f92123f4f9a98fa2bd Bjørn -- 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: add Mindstorms EV3 console adapter
Cc:
Signed-off-by: Bjørn Mork
---
Hello Greg!
I saw your post on Google+ :-) You'll probably want one of
these nice adapters to go with that toy. It's simply not worth
the job making the console cable yourself.
Bjørn
drivers/usb/serial/ftdi_sio.c | 1 +
drivers/usb/serial/ftdi_sio_ids.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/usb/serial/ftdi_sio.c b/drivers/usb/serial/ftdi_sio.c
index ce0d7b0db012..0f3248a017b3 100644
--- a/drivers/usb/serial/ftdi_sio.c
+++ b/drivers/usb/serial/ftdi_sio.c
@@ -152,6 +152,7 @@ static const struct usb_device_id id_table_combined[] = {
{ USB_DEVICE(FTDI_VID, FTDI_CANUSB_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_CANDAPTER_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_NXTCAM_PID) },
+ { USB_DEVICE(FTDI_VID, FTDI_EV3CON_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_SCS_DEVICE_0_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_SCS_DEVICE_1_PID) },
{ USB_DEVICE(FTDI_VID, FTDI_SCS_DEVICE_2_PID) },
diff --git a/drivers/usb/serial/ftdi_sio_ids.h
b/drivers/usb/serial/ftdi_sio_ids.h
index a7019d1e3058..eb0302135348 100644
--- a/drivers/usb/serial/ftdi_sio_ids.h
+++ b/drivers/usb/serial/ftdi_sio_ids.h
@@ -50,6 +50,7 @@
#define TI_XDS100V2_PID0xa6d0
#define FTDI_NXTCAM_PID0xABB8 /* NXTCam for Mindstorms NXT */
+#define FTDI_EV3CON_PID0xABB9 /* Mindstorms EV3 Console
Adapter */
/* US Interface Navigator (http://www.usinterface.com/) */
#define FTDI_USINT_CAT_PID 0xb810 /* Navigator CAT and 2nd PTT lines */
--
1.8.5.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: EG20T USB Gadget Performance
On Tue, Jan 14, 2014 at 9:26 PM, Alan Ott wrote: > On 01/14/2014 09:13 AM, Felipe Balbi wrote: >> >> On Mon, Jan 13, 2014 at 11:25:16PM -0500, Alan Ott wrote: >>> >>> On 01/13/2014 09:01 PM, Alan Stern wrote: On Mon, 13 Jan 2014, Felipe Balbi wrote: > On Mon, Jan 13, 2014 at 03:20:31PM -0500, Alan Ott wrote: >> >> I have an EG20T-based board and have some issues with performance on >> the USB device interface. >> >> >> I'll shoot in the dark here and assume current pch_udc only starts >> request N after N-1 has been givenback, and that's probably what's >> causing the extra delay. > > > Yes, that's what it looks like from my analysis. The DMAs work on the > transfer level though (one DMA per USB transfer), so making larger transfers > increases the performance significantly. > > >> Just as a debugging effort, can you move the call to giveback to a >> workqueue or something like that just so it gets scheduled into the >> future ? This wouldn't be an acceptable patch, but just to see if my >> statement is valid. Generally this delay caused due to processing rather than the pdc driver. I blv in this case checking of data and memset could be the cause for delay. Had tried workqueue for a different PDC driver but didnt change things because mostly completion is necessary before taking the next action. > > > Do you mean move the starting of the next transfer (after a transfer > completes) to a workqueue to delay it further? (for testing of course). > > > Alan. > > -- > 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 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst [NEW HARDWARE]
On Mon, Jan 13, 2014 at 03:39:07PM -0800, walt wrote: > On 01/09/2014 03:50 PM, Sarah Sharp wrote: > > >>> On Tue, Jan 07, 2014 at 03:57:00PM -0800, walt wrote: > >> > >> I've wondered if my xhci problems might be caused by hardware quirks, and > >> wondering why I seem to be the only one who has this problem. > >> > >> Maybe I could "take one for the team" by buying new hardware toys that I > >> don't really need but I could use to test the xhci driver? (I do enjoy > >> buying new toys, necessary, or, um, maybe not :) > > > > It would be appreciated if you could see if your device causes other > > host controllers to fail. Who am I to keep a geek from new toys? ;) > > Sarah, I just fixed my xhci bug for US$19.99 :) > > #lspci | tail -1 > 04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller > (rev 03) > > This new NEC usb3 controller does everything the ASMedia controller should > have > done from the start. I can even power-up the outboard usb3 disk docking > station > after the computer is running and still everything Just Works :) > > I appreciate all the debugging work you've done to fix the ASMedia problem but > I think it's time to quit now. If hundreds of irate linux users complain > about > the same bug then I'll be happy to test more patches. I just got a similar report from someone with a Fresco Logic host controller, so I may need you to test a work-around patch for the ASMedia host at some point. I'm considering disabling the effect of David's patch for those two host controllers. That will mean USB storage works fine, but USB ethernet may fail. I had considered just disabling scatter-gather for the hosts, but we can still run into the ethernet issue if we need to break a TRB at a 64KB boundary. So disabling scatter-gather would make USB ethernet work _most of the time_, but fail intermittently, and USB storage performance would be impacted. Since USB ethernet will fail in either case, I would rather keep USB storage performance and sacrifice USB ethernet on those particular hosts. So please keep the ASMedia host around for testing, if possible. 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: [BUG] FL1009: xHCI host not responding to stop endpoint command.
On Sun, Jan 12, 2014 at 10:36:56PM +0100, Arnaud Ebalard wrote: > Hi, > > a...@natisbad.org (Arnaud Ebalard) writes: > > > Both with a LaCie 2.5" USB 3.0 Rugged Mini disk (powered by the port) > > and a 3.5" SATA disk connected via an ICY DOCK MB981U3S-1S dock station > > (external power), I can transfer huge files w/o issue but I get the > > following when transferring small files (e.g. copy of some debian > > directory to a folder on the disk): > > > > # cp -rf /lib/ /bin/ /sbin/ /opt /var/ /usr/ test/ > > [ 327.130045] xhci_hcd :02:00.0: xHCI host not responding to stop > > endpoint command. > > [ 327.137899] xhci_hcd :02:00.0: Assuming host is dying, halting host. > > [ 327.144644] xhci_hcd :02:00.0: HC died; cleaning up Hmm, you're the second person to report an issue with a host dying. > I can add the following: > > 2) I just tested the copy of the small files using the ICY DOCK > MB981U3S-1S connected to my ReadyNAS 102 *on a 3.11.7 kernel* > and it completed successfully. Please try a 3.13-rc7 kernel after running `git revert 35773dac5f86`. > 2) on current 3.13.0-rc7 kernel (w/ Bjørn patch applied just in case), I Which patch are you referring to? > just transferred 40GB through a Logitec LAN-GT JU3H3 (it is based on an > ASIX AX88179) connected to my ReadyNAS Duo v2 (NEC XHCI controller) at > an average rate of 82MB/s. Bottom line: no issue. When I try to do the > same on my ReadyNAS 102, I immediately get complaints: Was the ReadyNAS 102 with the Fresco Logic host running 3.13.0-rc7 as well? > [ 383.280429] xhci_hcd :02:00.0: ep 0x82 - asked for 20480 bytes, 20400 > bytes untransferred > [ 383.280892] xhci_hcd :02:00.0: ep 0x82 - asked for 20480 bytes, 20400 > bytes untransferred > [ 411.620073] xhci_hcd :02:00.0: ep 0x82 - asked for 20480 bytes, 20352 > bytes untransferred > [ 411.620750] xhci_hcd :02:00.0: ep 0x82 - asked for 20480 bytes, 20400 > bytes untransferred > [ 411.621727] xhci_hcd :02:00.0: ep 0x82 - asked for 20480 bytes, 20400 > bytes untransferred > [ 412.066651] xhci_hcd :02:00.0: ep 0x82 - asked for 20480 bytes, 20352 > bytes untransferred > [ 412.067233] xhci_hcd :02:00.0: ep 0x82 - asked for 20480 bytes, 20400 > bytes untransferred > [ 412.068196] xhci_hcd :02:00.0: ep 0x82 - asked for 20480 bytes, 20400 > bytes untransferred > [ 412.242708] xhci_hcd :02:00.0: ep 0x82 - asked for 20480 bytes, 20352 > bytes untransferred > [ 412.24] xhci_hcd :02:00.0: ep 0x82 - asked for 20480 bytes, 20400 > bytes untransferred > [ 412.244246] xhci_hcd :02:00.0: ep 0x82 - asked for 20480 bytes, 20400 > bytes untransferred > [ 412.417956] xhci_hcd :02:00.0: ep 0x82 - asked for 20480 bytes, 20352 > bytes untransferred > [ 412.418516] xhci_hcd :02:00.0: ep 0x82 - asked for 20480 bytes, 20400 > bytes untransferred > [ 412.419473] xhci_hcd :02:00.0: ep 0x82 - asked for 20480 bytes, 20400 > bytes untransferred > [ 412.545330] xhci_hcd :02:00.0: ep 0x82 - asked for 20480 bytes, 20352 > bytes untransferred Those messages are normal. It just means the device transferred less data than the host asked for, which is part of normal USB operation. Does the dock work despite the messages? Please send me the output of `sudo lspci -vvv -n` for the ReadyNAS 102 Fresco Logic host. 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: XHCI issues: WD MyBook 1230 - reset SuperSpeed USB device
On Tue, 14 Jan 2014, Peter Palúch wrote: > Dear friends, > > So far, there has been no response to this issue report. I understand > this is not a help desk with guaranteed replies but the fact that there > was no response whatsoever is surprising to me. This means that nobody who has looked at your information knows what the problem is. > I would like to at least kindly ask that someone looks at the traces and > tells me if this is a possible software issue, or a hardware quirk that > can hardly be worked around. A "no, we won't fix this" or even "this is > not the proper mailing list for this" type of answer would be welcome at > this point. It is kind of frustrating to report an USB-related issue to > linux-usb mailing list, keep it updated, and yet receive absolutely no > reaction in almost a month. If I knew how to fix this, I would - but I > am no expert in USB stuff myself, so I am turning to experts... Nothing stands out in the logs. It may be a power management issue. Have you tried using a kernel with CONFIG_PM not set? 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: EG20T USB Gadget Performance
On 01/14/2014 09:13 AM, Felipe Balbi wrote: On Mon, Jan 13, 2014 at 11:25:16PM -0500, Alan Ott wrote: On 01/13/2014 09:01 PM, Alan Stern wrote: On Mon, 13 Jan 2014, Felipe Balbi wrote: On Mon, Jan 13, 2014 at 03:20:31PM -0500, Alan Ott wrote: I have an EG20T-based board and have some issues with performance on the USB device interface. I'll shoot in the dark here and assume current pch_udc only starts request N after N-1 has been givenback, and that's probably what's causing the extra delay. Yes, that's what it looks like from my analysis. The DMAs work on the transfer level though (one DMA per USB transfer), so making larger transfers increases the performance significantly. Just as a debugging effort, can you move the call to giveback to a workqueue or something like that just so it gets scheduled into the future ? This wouldn't be an acceptable patch, but just to see if my statement is valid. Do you mean move the starting of the next transfer (after a transfer completes) to a workqueue to delay it further? (for testing of course). Alan. -- 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: fix resume issues on Renesas chips
On Mon, Jan 13, 2014 at 03:17:48PM -0800, Sarah Sharp wrote: > On Mon, Jan 13, 2014 at 10:49:49AM -0500, Don Zickus wrote: > > Some co-workers of mine bought Samsung laptops that had mostly usb3 ports. > > Those ports did not resume correctly (the driver would timeout communicating > > and fail). This led to frustration as suspend/resume is a common use for > > laptops. > > > > Poking around, I applied the reset on resume quirk to this chipset and the > > resume started working. Reloading the xhci_hcd module had been the > > temporary > > workaround. > > > > Not sure if I should restrict this further or not. Probably should be sent > > to stable too. > > Can you provide the `sudo lspci -vvv -n` for the xHCI host? I would > rather restrict this quirk further, since this is the first report I've > seen of an NEC host needing this quirk. I would rather limit it to a > Samsung subsystem vendor ID if that's available. I figured. I attached the output of one laptop here. The other laptop's owner is on vacation for two weeks. :-( Cheers, Don 00:00.0 0600: 8086:0154 (rev 09) Subsystem: 144d:c0d3 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 00:02.0 0300: 8086:0166 (rev 09) (prog-if 00 [VGA controller]) Subsystem: 144d:c0d3 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- [disabled] Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee0f00c Data: 41e1 Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [a4] PCI Advanced Features AFCap: TP+ FLR+ AFCtrl: FLR- AFStatus: TP- Kernel driver in use: i915 Kernel modules: i915 00:16.0 0780: 8086:1e3a (rev 04) Subsystem: 144d:c0d3 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend- LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <16us ClockPM- Surprise- LLActRep+ BwNot- LnkCtl: ASPM L1 Enabled; RCB 64 bytes Disabled- Retrain- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive+ BWMgmt+ ABWMgmt- SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug- Surprise- Slot #0, PowerLimit 10.000W; Interlock- NoCompl+ SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq- LinkChg- Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock- SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock- Changed: MRL- PresDet- LinkState+ RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible- RootCap: CRSVisible- RootSta: PME ReqID , PMEStatus- PMEPending- DevCap2: Completion Timeout: Range BC, TimeoutDis+, LTR-, OBFF Not Supported ARIFwd- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled ARIFwd- LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -3.5dB, EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit- Address: Data: Capabilities: [90] Subsystem: 144d:c0d3 Capabilities: [a0] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurr
Re: EG20T USB Gadget Performance
On 01/14/2014 02:08 AM, Pratyush Anand wrote:
On Tue, Jan 14, 2014 at 02:06:13PM +0800, Alan Ott wrote:
On 01/14/2014 12:08 AM, Rajaram R wrote:
I guess it is something to do with the buffer size of the gadget
driver. Could you please try change the buffer size to 16K and confirm
if the delay is shifting ? In this case your delay should be after 31
transfers...
===
66 static struct usb_zero_options gzero_options = {
67 .isoc_interval = 4,
68 .isoc_maxpacket = 1024,
69 .bulk_buflen = 4096, => change to 16K
70 .qlen = 32,
71 };
===
Hi Rajram,
Yes, this does as you suspected. I now get 222Mbit/sec of data transfer.
See here, some way to get higher speed with zero gadget.
http://www.spinics.net/lists/linux-usb/msg100588.html
Thanks Pratyush for the info.
--
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: EG20T USB Gadget Performance
On 01/14/2014 10:02 AM, Alan Stern wrote: On Mon, 13 Jan 2014, Alan Ott wrote: By the way, isn't it true that f_sourcesink uses only one request for each bulk endpoint? That would naturally lead to a delay each time the request completes and has to be resubmitted. That's what the comment at the top of the file says, but it doesn't appear to be true. See source_sink_start_ep(). It seems to start by queueing up 8 transactions. I've adjusted this number up with no effect (currently at 64). I don't follow your reasoning. The comment at the top of the file says: This just sinks bulk packets OUT to the peripheral... which is true, and also ... this doesn't queue more than one request at a time... which is also true for the bulk endpoints (although not for the isochronous endpoints). At high speed, one request = 8 transactions unless you specify a value for the buflen module parameter other than 4096. Yes, I mistyped. I meant transfer instead of transaction above. Maybe there's something else I'm missing. At the end of the loop in source_sink_start_ep(): if (!is_iso) break; You could try removing those two lines and see what happens. (I'm not sure why those lines are there to begin with...) You're right. I missed those two lines at the bottom. It looks like it goes back to b4036ccdd2ce5ec0c4f29b91312dd3cf19fc9152 when support for isochronous endpoints was added to f_sourcesink and gadget zero. Before that patch it was bulk only and only queued one transfer. That patch added iso and made it queue 8 transfers, but only for iso, I suppose in an attempt to not change the existing behavior. Is there any reason now to only queue one packet? I'll take those out and see what happens. Thanks Alan. Alan. -- 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: EG20T USB Gadget Performance
On Mon, 13 Jan 2014, Alan Ott wrote: > > By the way, isn't it true that f_sourcesink uses only one request for > > each bulk endpoint? That would naturally lead to a delay each time the > > request completes and has to be resubmitted. > > That's what the comment at the top of the file says, but it doesn't > appear to be true. See source_sink_start_ep(). It seems to start by > queueing up 8 transactions. I've adjusted this number up with no effect > (currently at 64). I don't follow your reasoning. The comment at the top of the file says: This just sinks bulk packets OUT to the peripheral... which is true, and also ... this doesn't queue more than one request at a time... which is also true for the bulk endpoints (although not for the isochronous endpoints). At high speed, one request = 8 transactions unless you specify a value for the buflen module parameter other than 4096. > Maybe there's something else I'm missing. At the end of the loop in source_sink_start_ep(): if (!is_iso) break; You could try removing those two lines and see what happens. (I'm not sure why those lines are there to begin with...) > > If the driver used two requests instead, the pipeline would be much > > less likely to empty out. > > Yes, I absolutely agree, the queue must be kept full, but in this case I > think it is. No, it isn't. 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: usb3 hdd docking station doesn't work with recent kernels
On Tue, 14 Jan 2014, Sergey Galanov wrote: > Hi Oliver. > Yes, reverting that commit fixes the problem (I did it on top of 3.13rc8). > > On 13 January 2014 14:05, Oliver Neukum wrote: > > On Sun, 2014-01-12 at 14:12 +0400, Sergey Galanov wrote: > >> Hi. > >> My hdd docking station (AgeStar 3UBT with usb3 support) stopped > >> working after upgrade to linux 3.12.3. It worked fine in 3.12.0 and > >> before. I can't point to more specific version because it's hard to > >> find old packages for my distro (ArchLinux). I also tried 3.12.6, > >> 3.12.7 and 3.13rc7 and the problem persists. > > > > This is not good. My bet is on 60e102ac73cd40069d077014c93c86dc7205cb68 > > Could you revert that? If that doesn't do the job, I think you'll need > > to bisect. Bear in mind that this doesn't mean there's anything wrong with the commit. In this case, it appears to be a bug in the hardware. The commit merely exposes the bug, by allowing the kernel to use a feature it wasn't using before. 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
[PATCH] usb: chipidea: need to mask when writting endptflush and endptprime
ENDPTFLUSH and ENDPTPRIME registers are set by software and
clear by hardware.
There is a bit for each endpoint.
When we are setting a bit for an endpoint we should make sure we not touch
other endpoint bit. There is a race condition if the hardware clear the
bit between the read and the write in hw_write.
Signed-off-by: Matthieu CASTET
---
drivers/usb/chipidea/udc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 69d20fb..9e2e39b 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -105,7 +105,7 @@ static int hw_ep_flush(struct ci_hdrc *ci, int num, int dir)
do {
/* flush any pending transfer */
- hw_write(ci, OP_ENDPTFLUSH, BIT(n), BIT(n));
+ hw_write(ci, OP_ENDPTFLUSH, ~0, BIT(n));
while (hw_read(ci, OP_ENDPTFLUSH, BIT(n)))
cpu_relax();
} while (hw_read(ci, OP_ENDPTSTAT, BIT(n)));
@@ -205,7 +205,7 @@ static int hw_ep_prime(struct ci_hdrc *ci, int num, int
dir, int is_ctrl)
if (is_ctrl && dir == RX && hw_read(ci, OP_ENDPTSETUPSTAT, BIT(num)))
return -EAGAIN;
- hw_write(ci, OP_ENDPTPRIME, BIT(n), BIT(n));
+ hw_write(ci, OP_ENDPTPRIME, ~0, BIT(n));
while (hw_read(ci, OP_ENDPTPRIME, BIT(n)))
cpu_relax();
--
1.8.5.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: [RFC PATCH 0/2] dwc2/s3c-hsotg: Initial steps to combine the 2 driver
On Tue, Jan 14, 2014 at 05:01:00AM -0600, dingu...@altera.com wrote: > From: Dinh Nguyen > > Hi, > > I'm starting work downstream on combining the DWC2 host driver and the > s3c-hsotg > gadget driver into a dual-role OTG driver. Before I go further, I was hoping > to > solicit comments on whether or not my initial approach is correct? I know > there > are plans to combine the 2, so would like to solicit comments/suggestions so > that I can also upstream it as well. > > These 2 patches: > > * Moves the DWC2 driver out of drivers/staging into drivers/usb/dwc2/ This already happened yesterday in my tree, so you should see this in linux-next by now, no need to do it again :) > * Moves the s3c-hsotg driver into drivers/usb/dwc2/ > * Delete s3c-hsotg.h > * Make the s3c-hsotg.c file use the defines in hw.h from the DWC2 driver. > > This initial patch has been tested on the SOCFPGA platform only in Host-only > and Gadget-only mode. > > The next step would be to do the combining of the driver into a dual-role OTG > driver. I was told that merging the two of these isn't going to work as the silicon is just too different, which is why I allowed the code to move out of staging. If you feel differently, and think you can combine the two drivers, that's wonderful, I'll gladly take patches to do so, but be sure to test on the proper platforms to make sure nothing breaks. 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 5/7] drivers/usb/dwc3: don't check resource with devm_ioremap_resource
On Tue, Jan 14, 2014 at 12:58:56PM +0100, Wolfram Sang wrote: > devm_ioremap_resource does sanity checks on the given resource. No need to > duplicate this in the driver. > > Signed-off-by: Wolfram Sang > --- > > Should go via subsystem tree too late for v3.14, I'll merge this for v3.15. -- balbi signature.asc Description: Digital signature
Re: EG20T USB Gadget Performance
On Mon, Jan 13, 2014 at 11:25:16PM -0500, Alan Ott wrote: > On 01/13/2014 09:01 PM, Alan Stern wrote: > >On Mon, 13 Jan 2014, Felipe Balbi wrote: > > > >>Hi, > >> > >>On Mon, Jan 13, 2014 at 03:20:31PM -0500, Alan Ott wrote: > >>>I have an EG20T-based board and have some issues with performance on > >>>the USB device interface. > >>I don't have that hardware but ... > >> > >>>I made a libusb test program (using the async interface)[0] to read > >>>data from the EG20T's USB device port which has the gadget zero > >>>source/sink function bound. In theory, one would hope this would give > >>>the fastest real-world results for the hardware connected. > >>> > >>>The test program submits 32 IN transfers and re-submits on transfer > >>>completion, counting received packets. > >>> > >>> From running my test program for a few minutes I get the following: > >>> elapsed: 548.468416 seconds > >>> packets: 21503334 > >>> packets/sec: 39206.148199 > >>> bytes/sec: 20073547.877732 > >>> MBit/sec: 160.588383 > >>> > >>>160MBit/sec isn't terrible, but I hoped for better. A USB analyzer > >>>shows 7 transactions happening quickly (with about 14us separating > >>>them), but every 8th transaction, the EG20T will NAK between 20-80 > >>>times[1], losing 50-100us[2]. > >>as Alan stated, this is a problem on the device side. The device is > >>replying with NAK because, I believe, it has ran out of free TDs. > >> > >>>This delay happens every 8th transaction without fail[3]. > >>> > >>>I've looked at the following: > >>>1. The f_sourcesink.c function it queues up 8 responses at the > >>>beginning. Changing this number up or down had no effect. > >>>2. Analysis of pch_udc.c doesn't show anything which would obviously > >>>cause a delay every 8th packet. > >>>3. f_eem seems to have roughly the same performance with ping -f -s > >>>64000 (160Mbit/sec). > >>> > >>>The CPU load of the gadget-side Atom PC sits very close to zero. > >>> > >>>System Details: > >>> Linux 3.13.0-rc7 (With a defconfig from Yocto for Intel Crownbay) > >>> Intel Atom E680 with EG20T > >>> > >>>I seem to have eliminated everything on the host side, since the host > >>>is asking for data, and the device is saying it doesn't have any for > >>>up to 100us at a time. > >>> > >>>What am I missing? > >>you should probably profile your pch_udc_pcd_queue() to figure out if > >>there's anything wasting a lot of time there. > >> > >>Unlike Alan, I would use trace_printk() rather than pr_debug() since > >>trace_printk() is of much lower overhead. Google around and you'll see > >>how to use trace_printk() and how to use the kernel function profiler. > >By the way, isn't it true that f_sourcesink uses only one request for > >each bulk endpoint? That would naturally lead to a delay each time the > >request completes and has to be resubmitted. > > That's what the comment at the top of the file says, but it doesn't > appear to be true. See source_sink_start_ep(). It seems to start by > queueing up 8 transactions. I've adjusted this number up with no > effect (currently at 64). right, the comment needs to be updated with what source_sink_start_ep() actually does. > >If the driver used two requests instead, the pipeline would be much > >less likely to empty out. > > Yes, I absolutely agree, the queue must be kept full, but in this > case I think it is. I'll shoot in the dark here and assume current pch_udc only starts request N after N-1 has been givenback, and that's probably what's causing the extra delay. Just as a debugging effort, can you move the call to giveback to a workqueue or something like that just so it gets scheduled into the future ? This wouldn't be an acceptable patch, but just to see if my statement is valid. cheers -- balbi signature.asc Description: Digital signature
Re: problem to retrieve usb_serial object from usb_serial_port object
On Tue, 2014-01-14 at 14:54 +0100, Silvio F. wrote:
> Hello,
>
> I try to communicate with a cp210x-device on my usb bus. I create a sysfs
> object with some simple lines of code like the next one ...
>
> static ssize_t cp210x_show_x(struct device *dev, struct device_attribute
> *attr, char *buf)
> {
> struct usb_serial_port *port = to_usb_serial_port(dev);
>
> if(!port) {
> printk("no port\n");
> goto exit;
> }
>
> if(!port->serial) {
> printk("no serial\n");
> goto exit;
> }
>
> struct cp210x_serial_private *spriv =
> usb_get_serial_data(port->serial);
> printk("%s:%s:%d num_ports:0x%08x\n", __FILE__, __func__, __LINE__,
> port->serial->num_ports);
>
> exit:
> return 0;
> }
> static DEVICE_ATTR(x, S_IRUGO, cp210x_show_x, NULL);
>
> static int create_sysfs_attrs(struct usb_serial *serial)
> {
> return device_create_file(&serial->dev->dev, &dev_attr_x);
> }
You are creating a sysfs entry for struct device associated with a
struct usb_serial. Yet you convert this to struct usb_serial_port.
struct usb_serial {
struct usb_device *dev;
struct usb_serial_driver*type;
struct usb_interface*interface;
unsigned char disconnected:1;
unsigned char suspending:1;
unsigned char attached:1;
unsigned char minors_reserved:1;
unsigned char num_ports;
unsigned char num_port_pointers;
charnum_interrupt_in;
charnum_interrupt_out;
charnum_bulk_in;
charnum_bulk_out;
struct usb_serial_port *port[MAX_NUM_PORTS];
struct kref kref;
struct mutexdisc_mutex;
void*private;
};
This structure points to multiple instances of struct usb_serial_port.
This cannot work.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] usb: gadget: f_fs: add aio support
This patch adds asynchronous I/O support for FunctionFS endpoint files.
It adds ffs_epfile_aio_write() and ffs_epfile_aio_read() functions responsible
for preparing AIO operations.
It also modifies ffs_epfile_io() function, adding aio handling code. Instead
of extending list of parameters of this function, there is new struct
ffs_io_data which contains all information needed to perform I/O operation.
Pointer to this struct replaces "buf" and "len" parameters of ffs_epfile_io()
function. Allocated buffer is freed immediately only after sync operation,
because in async IO it's freed in complete funcion. For each async operation
an USB request is allocated, because it allows to have more than one request
queued on single endpoint.
According to changes in ffs_epfile_io() function, functions ffs_epfile_write()
and ffs_epfile_read() are updated to use new API.
For asynchronous I/O operations there is new request complete function named
ffs_epfile_async_io_complete(), which completes AIO operation, and frees
used memory.
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/f_fs.c | 259 ++---
1 file changed, 223 insertions(+), 36 deletions(-)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index c820a47..f9b1de3 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -27,6 +27,8 @@
#include
#include
+#include
+#include
#include
#define FUNCTIONFS_MAGIC 0xa647361 /* Chosen by a honest dice roll ;) */
@@ -343,6 +345,25 @@ static char *ffs_prepare_buffer(const char __user *buf,
size_t len)
__attribute__((warn_unused_result, nonnull));
+/* ffs_io_data structure ***/
+
+struct ffs_io_data {
+ int aio:1;
+ int read:1;
+
+ struct kiocb *kiocb;
+ const struct iovec *iovec;
+ unsigned long nr_segs;
+ char __user *buf;
+ size_t len;
+
+ struct mm_struct *mm;
+ struct work_struct work;
+
+ struct usb_ep *ep;
+ struct usb_request *req;
+};
+
/* Control file aka ep0 */
static void ffs_ep0_complete(struct usb_ep *ep, struct usb_request *req)
@@ -788,8 +809,51 @@ static void ffs_epfile_io_complete(struct usb_ep *_ep,
struct usb_request *req)
}
}
-static ssize_t ffs_epfile_io(struct file *file,
-char __user *buf, size_t len, int read)
+static void ffs_user_copy_worker(struct work_struct *work)
+{
+ size_t len = 0;
+ int i = 0;
+ int ret;
+
+ struct ffs_io_data *io_data = container_of(work, struct ffs_io_data,
work);
+
+ use_mm(io_data->mm);
+ for (i=0; i < io_data->nr_segs; i++) {
+ ret = copy_to_user(io_data->iovec[i].iov_base,
+ &io_data->buf[len],
+ io_data->iovec[i].iov_len);
+ len += io_data->iovec[i].iov_len;
+ }
+ unuse_mm(io_data->mm);
+
+ aio_complete(io_data->kiocb, 0, 0);
+
+ kfree(io_data->iovec);
+ kfree(io_data->buf);
+ kfree(io_data);
+}
+
+static void ffs_epfile_async_io_complete(struct usb_ep *_ep,
+struct usb_request *req)
+{
+ struct ffs_io_data *io_data = req->context;
+ struct ffs_ep *ep = _ep->driver_data;
+ ep->status = req->status ? req->status : req->actual;
+
+ if (io_data->read) {
+ INIT_WORK(&io_data->work, ffs_user_copy_worker);
+ schedule_work(&io_data->work);
+ }
+ else {
+ aio_complete(io_data->kiocb, 0, 0);
+ kfree(io_data->buf);
+ kfree(io_data);
+ }
+
+ usb_ep_free_request(_ep, req);
+}
+
+static ssize_t ffs_epfile_io(struct file *file, struct ffs_io_data *io_data)
{
struct ffs_epfile *epfile = file->private_data;
struct ffs_ep *ep;
@@ -825,25 +889,12 @@ first_try:
}
/* Do we halt? */
- halt = !read == !epfile->in;
+ halt = !io_data->read == !epfile->in;
if (halt && epfile->isoc) {
ret = -EINVAL;
goto error;
}
- /* Allocate & copy */
- if (!halt && !data) {
- data = kzalloc(len, GFP_KERNEL);
- if (unlikely(!data))
- return -ENOMEM;
-
- if (!read &&
- unlikely(__copy_from_user(data, buf, len))) {
- ret = -EFAULT;
- goto error;
- }
- }
-
/* We will be using request */
ret = ffs_mutex_lock(&epfile->mutex,
file->f_flags & O_NONBLOCK);
@@ -869,33 +920,86 @@ first_try:
[PATCH 1/2] usb: gadget: f_fs: add poll for endpoint 0
This patch adds poll function for file representing ep0.
Ability of read from or write to ep0 file is related with actual state of ffs:
- When desctiptors or strings are not written yet, POLLOUT flag is set.
- If there is any event to read, POLLIN flag is set.
- If setup request was read, POLLIN and POLLOUT flag is set, to allow
send response (by performing I/O operation consistent with setup request
direction) or set stall (by performing I/O operation opposite setup
request direction).
Signed-off-by: Robert Baldyga
---
drivers/usb/gadget/f_fs.c | 43 +--
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/gadget/f_fs.c b/drivers/usb/gadget/f_fs.c
index 241fc87..c820a47 100644
--- a/drivers/usb/gadget/f_fs.c
+++ b/drivers/usb/gadget/f_fs.c
@@ -27,6 +27,7 @@
#include
#include
+#include
#define FUNCTIONFS_MAGIC 0xa647361 /* Chosen by a honest dice roll ;) */
@@ -107,8 +108,6 @@ enum ffs_setup_state {
FFS_SETUP_CANCELED
};
-
-
struct ffs_epfile;
struct ffs_function;
@@ -726,6 +725,45 @@ static long ffs_ep0_ioctl(struct file *file, unsigned
code, unsigned long value)
return ret;
}
+static unsigned int ffs_ep0_poll(struct file *file, poll_table *wait)
+{
+ struct ffs_data *ffs = file->private_data;
+ unsigned int mask = POLLWRNORM;
+ int ret;
+
+ ret = ffs_mutex_lock(&ffs->mutex, file->f_flags & O_NONBLOCK);
+ if (unlikely(ret < 0))
+ return mask;
+
+ switch (ffs->state) {
+ case FFS_READ_DESCRIPTORS:
+ case FFS_READ_STRINGS:
+ mask |= POLLOUT;
+ break;
+
+ case FFS_ACTIVE:
+ switch (FFS_SETUP_STATE(ffs)) {
+ case FFS_NO_SETUP:
+ if(ffs->ev.count)
+ mask |= POLLIN;
+ break;
+
+ case FFS_SETUP_PENDING:
+ mask |= (POLLIN | POLLOUT);
+ break;
+
+ default:
+ break;
+ }
+ default:
+ break;
+ }
+
+ mutex_unlock(&ffs->mutex);
+
+ return mask;
+}
+
static const struct file_operations ffs_ep0_operations = {
.llseek = no_llseek,
@@ -734,6 +772,7 @@ static const struct file_operations ffs_ep0_operations = {
.read = ffs_ep0_read,
.release = ffs_ep0_release,
.unlocked_ioctl = ffs_ep0_ioctl,
+ .poll = ffs_ep0_poll,
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] usb: gadget: f_fs: add asynchronous I/O support
Hello, This two patches contains improvements for FunctionFS which allows to use it with asynchronous I/O interface. It also adds poll function for ep0, to make it usable without creating additional thread, needed by blocking I/O. More details in commit messages. Best regards Robert Baldyga Samsung R&D Institute Poland Robert Baldyga (2): usb: gadget: f_fs: add poll for endpoint 0 usb: gadget: f_fs: add aio support drivers/usb/gadget/f_fs.c | 302 +++-- 1 file changed, 264 insertions(+), 38 deletions(-) -- 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 1/2] usb: chipidea: usbmisc: Add support for i.MX27/i.MX31 CPUs
Hello Alexander, On Tue, Jan 14, 2014 at 02:47:39PM +0100, Uwe Kleine-König wrote: > On Tue, Jan 14, 2014 at 07:30:46AM +0400, Alexander Shiyan wrote: > > I'll send you a personal letter with DT configuration. > That would be great. You didn't send it yet, did you? I take that back, just found it in my inbox. Don't know why I needed a reply on this mail to find it. Sorry. Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
problem to retrieve usb_serial object from usb_serial_port object
Hello,
I try to communicate with a cp210x-device on my usb bus. I create a sysfs
object with some simple lines of code like the next one ...
static ssize_t cp210x_show_x(struct device *dev, struct device_attribute
*attr, char *buf)
{
struct usb_serial_port *port = to_usb_serial_port(dev);
if(!port) {
printk("no port\n");
goto exit;
}
if(!port->serial) {
printk("no serial\n");
goto exit;
}
struct cp210x_serial_private *spriv = usb_get_serial_data(port->serial);
printk("%s:%s:%d num_ports:0x%08x\n", __FILE__, __func__, __LINE__,
port->serial->num_ports);
exit:
return 0;
}
static DEVICE_ATTR(x, S_IRUGO, cp210x_show_x, NULL);
static int create_sysfs_attrs(struct usb_serial *serial)
{
return device_create_file(&serial->dev->dev, &dev_attr_x);
}
I have the problem that port->serial is everytime NULL.
Some digging in usb-serial.c shows me that the port->serial is set on plugin of
my device through the usb_serial_probe-function.
Is this a bug or should I recive the usb_serial object with other mehods? What
methods should I use?
This Problem occurs on 3.9-rc7 and 3.13-rc3.
Thanks for some hints,
Silvio
--
-- S. Fricke sil...@port1024.net --
Diplom-Informatiker (FH)
Linux-Entwicklung JABBER: sil...@conversation.port1024.net
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: chipidea: usbmisc: Add support for i.MX27/i.MX31 CPUs
Hello Chris, On Tue, Jan 14, 2014 at 11:53:47AM +0800, Chris Ruehl wrote: > On Tuesday, January 14, 2014 11:30 AM, Alexander Shiyan wrote: > >Понедельник, 13 января 2014, 22:31 +01:00 от Uwe Kleine-König > >: > >>On Sat, Jan 11, 2014 at 06:01:48PM +0400, Alexander Shiyan wrote: > >>>Суббота, 11 января 2014, 13:55 +01:00 от Uwe Kleine-König > >>>: > On Mon, Nov 11, 2013 at 11:09:16AM +0400, Alexander Shiyan wrote: > >Hello. > > > >>On Sunday, November 10, 2013 03:18 PM, Alexander Shiyan wrote: > >>>This adds i.MX27 and i.MX31 as the next user of the usbmisc driver. > >>> > >>>Signed-off-by: Alexander Shiyan > >>>--- > >>> drivers/usb/chipidea/usbmisc_imx.c | 42 > >>> ++ > >>> 1 file changed, 42 insertions(+) > >... > >>At this point might be good to patch the imx27.dtsi with the usb > >>defines. > >... > > > >I have a working configuration for i.MX27 USB, but I prefer to make a > >few more > >tests before the addition of definitions in DTS. This will be a next > >step. > >Thanks. > Any news here? > >>>Not ready yet. > >>Are you still working at it? Would you mind sharing more details, like > >>your current tree/patch stack and what works/doesn't work for you? > > > >Now my work on this is suspended, but will continue later. > >I'll send you a personal letter with DT configuration. > >Ports (both Host & OTG) are detected by kernel, but works Host only. > >OTG not works nor as Host, nor as Device... > > > >--- > hi, > I'm still working on my patches for imx27 and ULPI integration. But > have more urgent things in the queue. Starting from here I'm not sure I understand you. > I have a running version but it cant make it in the kernel. Rework > on platform device code needed. > Just wait until the patches already accepted appears in the > linux-next before commit new patches. That means: USB works for you? What does "it cant make it in the kernel" mean? Problems to upstream it? Do you wait or should I? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] usb: chipidea: usbmisc: Add support for i.MX27/i.MX31 CPUs
Hello Alexander, On Tue, Jan 14, 2014 at 07:30:46AM +0400, Alexander Shiyan wrote: > I'll send you a personal letter with DT configuration. That would be great. You didn't send it yet, did you? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC 00/10] xhci: re-work command queue management
From: Mathias Nyman ... > > The fact that you are having to allocate memory ion an ISR ought also to be > > ringing alarm bells. > > It did. > Other options are as you said to use a 'software command ring'. Either > just pre-allocate a full command ring (64 trbs * sizeof(struct > xhci_command)), roughly 2300 bytes when driver loads, > or then a smaller pool of commands just used for ISR submitted commands. > (We then need to either either expand pool, or start allocating in isr > if pool is empty) If you pre-allocate mapping 1-1 with the command ring entries you don't need many of the fields of xhci_command at all. So the allocated size will be much smaller. Also not that all the rings have been increased to 256 entries, not that there is any requirement for them to match. > These solutions require some ring management and possibly expansion > code, and increases the complexity again. I selected this simpler > approach as I understood that the frequency of commands allocated in ISR > is quite low. The frequency isn't the problem - the fact that it is allowed is a problem. > This also feels like trying to optimize before we get the main > changes working. I would call it 'not realising the full scope of the problem' and thus leaving the 'difficult bits' for last. Sorting out how to solve the difficult bits up front can lead to a nicer solution. > > > > > Have you considered adding a 'software command ring' (indexed with the > > same value as the hardware one) and using it to hold additional parameters? > > > > It might even be worth only putting a single command into the hardware ring! > > That might simplify the timer code. > > This is something I haven't thought about. Could be one possibility, but > feels like artificially restricting something the HW is designed to care > of. It might resolve any issues about the fixed finite size of the hardware command ring. OTOH you probably don't need that many entries in the hardware command ring for 'normal' processing - provided you have a software ring/queue that can buffer all the requests. Looking at the number of fields in xci_command, why do you need the caller to pass a structure at all? Just make the fields parameters to the 'send a command' function along with a parameter that says whether it can sleep (in kmalloc() or if the ring is full depending on the implementation). ... > > This still has a fixed constraint on the number of queued commands, but > > I suspect that is bounded anyway (a few per device?). > > 64 commands fit on the command ring segment, I'm not aware of any > per-device limits? I was wondering about how many commands the software might try to queue, not the number that the hardware allowed to be queued. David -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/7] drivers/usb/dwc3: don't check resource with devm_ioremap_resource
devm_ioremap_resource does sanity checks on the given resource. No need to
duplicate this in the driver.
Signed-off-by: Wolfram Sang
---
Should go via subsystem tree
drivers/usb/dwc3/dwc3-omap.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 7f7ea62..cbcd972 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -432,11 +432,6 @@ static int dwc3_omap_probe(struct platform_device *pdev)
}
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(dev, "missing memory base resource\n");
- return -EINVAL;
- }
-
base = devm_ioremap_resource(dev, res);
if (IS_ERR(base))
return PTR_ERR(base);
--
1.8.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 00/10] xhci: re-work command queue management
IMHO the xhci driver is already far too complicated, and this probably just
makes
it even worse.
This is an attempt to make it cleaner and less complicated.
In the end this series removes far more more code than it adds:
5 files changed, 373 insertions(+), 530 deletions(-)
The timers are also simplified, so now we only have one timeout timer
instead of each command running its own timer.
The fact that you are having to allocate memory ion an ISR ought also to be
ringing alarm bells.
It did.
Other options are as you said to use a 'software command ring'. Either
just pre-allocate a full command ring (64 trbs * sizeof(struct
xhci_command)), roughly 2300 bytes when driver loads,
or then a smaller pool of commands just used for ISR submitted commands.
(We then need to either either expand pool, or start allocating in isr
if pool is empty)
These solutions require some ring management and possibly expansion
code, and increases the complexity again. I selected this simpler
approach as I understood that the frequency of commands allocated in ISR
is quite low.
This also feels like trying to optimize before we get the main
changes working.
Have you considered adding a 'software command ring' (indexed with the
same value as the hardware one) and using it to hold additional parameters?
It might even be worth only putting a single command into the hardware ring!
That might simplify the timer code.
This is something I haven't thought about. Could be one possibility, but
feels like artificially restricting something the HW is designed to care
of. The timer code isn't that complex anyway. In addition to init/exit
parts we basically got:
queue_command(...)
{
if (command list is empty)
/* start timer for new command added to empty list*/
mod_timer(cmd_timer, timeout);
}
handle_cmd_completion(...) /* in ISR */
{
/* A commandcompleted, remove timeout timer */
del_timer(cmd_timer)
do_other_stuff
if(more commands in list)
mod_timer(cmd_timer, timeout); /* start timer for next command */
}
This still has a fixed constraint on the number of queued commands, but
I suspect that is bounded anyway (a few per device?).
64 commands fit on the command ring segment, I'm not aware of any
per-device limits?
Thanks for the comments and ideas
-Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH 2/2] usb: gadget: s3c-hsotg: move s3c-hsotg driver into dwc2
From: Dinh Nguyen
In preparation for combining the dwc2 host driver and the s3c-hsotg
gadget driver into a dual-role USB driver, move the s3c-hsotg into
the same place with DWC2 host driver.
Signed-off-by: Dinh Nguyen
Cc: Paul Zimmerman
Cc: Rashika Kheria
Cc: Matthijs Kooijman
Cc: Luis Ortega Perez de Villar
Cc: Dom Cobley
Cc: Ben Dooks
Cc: Kukjin Kim
Cc: Robert Baldyga
Cc: Kyungmin Park
Cc: Jingoo Han
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
---
drivers/usb/dwc2/Makefile|2 +-
drivers/usb/{gadget => dwc2}/s3c-hsotg.c | 439 +++---
drivers/usb/gadget/Makefile |1 -
drivers/usb/gadget/s3c-hsotg.h | 378 -
4 files changed, 220 insertions(+), 600 deletions(-)
rename drivers/usb/{gadget => dwc2}/s3c-hsotg.c (90%)
delete mode 100644 drivers/usb/gadget/s3c-hsotg.h
diff --git a/drivers/usb/dwc2/Makefile b/drivers/usb/dwc2/Makefile
index 11529d3..265df03 100644
--- a/drivers/usb/dwc2/Makefile
+++ b/drivers/usb/dwc2/Makefile
@@ -2,9 +2,9 @@ ccflags-$(CONFIG_USB_DWC2_DEBUG)+= -DDEBUG
ccflags-$(CONFIG_USB_DWC2_VERBOSE) += -DVERBOSE_DEBUG
obj-$(CONFIG_USB_DWC2) += dwc2.o
+obj-$(CONFIG_USB_S3C_HSOTG)+= s3c-hsotg.o
dwc2-y += core.o core_intr.o
-
# NOTE: This driver at present only implements the Host mode
# of the controller. The existing s3c-hsotg driver supports
# Peripheral mode, but only for the Samsung S3C platforms.
diff --git a/drivers/usb/gadget/s3c-hsotg.c b/drivers/usb/dwc2/s3c-hsotg.c
similarity index 90%
rename from drivers/usb/gadget/s3c-hsotg.c
rename to drivers/usb/dwc2/s3c-hsotg.c
index c0ff1cb..c32b1c7 100644
--- a/drivers/usb/gadget/s3c-hsotg.c
+++ b/drivers/usb/dwc2/s3c-hsotg.c
@@ -38,7 +38,7 @@
#include
#include
-#include "s3c-hsotg.h"
+#include "hw.h"
static const char * const s3c_hsotg_supply_names[] = {
"vusb_d", /* digital USB supply, 1.2V */
@@ -94,7 +94,7 @@ struct s3c_hsotg_req;
* @fifo_size: The size of the FIFO (for periodic IN endpoints)
* @fifo_load: The amount of data loaded into the FIFO (periodic IN)
* @last_load: The offset of data for the last start of request.
- * @size_loaded: The last loaded size for DxEPTSIZE for periodic IN
+ * @size_loaded: The last loaded size for DXEPTSIZE for periodic IN
*
* This is the driver's state for each registered enpoint, allowing it
* to keep track of transactions that need doing. Each endpoint has a
@@ -341,8 +341,8 @@ static void s3c_hsotg_init_fifo(struct s3c_hsotg *hsotg)
/* set FIFO sizes to 2048/1024 */
writel(2048, hsotg->regs + GRXFSIZ);
- writel(GNPTXFSIZ_NPTxFStAddr(2048) |
- GNPTXFSIZ_NPTxFDep(1024),
+ writel(DPTXFSIZN_DPTXFADDR(2048) |
+ DPTXFSIZN_DPTXFSIZE(1024),
hsotg->regs + GNPTXFSIZ);
/*
@@ -363,10 +363,10 @@ static void s3c_hsotg_init_fifo(struct s3c_hsotg *hsotg)
for (ep = 1; ep <= 15; ep++) {
val = addr;
- val |= size << DPTXFSIZn_DPTxFSize_SHIFT;
+ val |= size << FIFOSIZE_DEPTH_SHIFT;
addr += size;
- writel(val, hsotg->regs + DPTXFSIZn(ep));
+ writel(val, hsotg->regs + DPTXFSIZN(ep));
}
/*
@@ -374,15 +374,15 @@ static void s3c_hsotg_init_fifo(struct s3c_hsotg *hsotg)
* all fifos are flushed before continuing
*/
- writel(GRSTCTL_TxFNum(0x10) | GRSTCTL_TxFFlsh |
- GRSTCTL_RxFFlsh, hsotg->regs + GRSTCTL);
+ writel(GRSTCTL_TXFNUM(0x10) | GRSTCTL_TXFFLSH |
+ GRSTCTL_RXFFLSH, hsotg->regs + GRSTCTL);
/* wait until the fifos are both flushed */
timeout = 100;
while (1) {
val = readl(hsotg->regs + GRSTCTL);
- if ((val & (GRSTCTL_TxFFlsh | GRSTCTL_RxFFlsh)) == 0)
+ if ((val & (GRSTCTL_TXFFLSH | GRSTCTL_RXFFLSH)) == 0)
break;
if (--timeout == 0) {
@@ -496,14 +496,14 @@ static int s3c_hsotg_write_fifo(struct s3c_hsotg *hsotg,
* how much data is left in the fifo.
*/
- size_left = DxEPTSIZ_XferSize_GET(epsize);
+ size_left = DXEPTSIZ_XFERSIZE_GET(epsize);
/*
* if shared fifo, we cannot write anything until the
* previous data has been completely sent.
*/
if (hs_ep->fifo_load != 0) {
- s3c_hsotg_en_gsint(hsotg, GINTSTS_PTxFEmp);
+ s3c_hsotg_en_gsint(hsotg, GINTSTS_PTXFEMP);
return -ENOSPC;
}
@@ -524,7 +524,7 @@ static int s3c_hsotg_write_fifo(struct s3c_hsotg *hsotg,
__func__, can_write);
if (can_write <=
[RFC PATCH 0/2] dwc2/s3c-hsotg: Initial steps to combine the 2 driver
From: Dinh Nguyen Hi, I'm starting work downstream on combining the DWC2 host driver and the s3c-hsotg gadget driver into a dual-role OTG driver. Before I go further, I was hoping to solicit comments on whether or not my initial approach is correct? I know there are plans to combine the 2, so would like to solicit comments/suggestions so that I can also upstream it as well. These 2 patches: * Moves the DWC2 driver out of drivers/staging into drivers/usb/dwc2/ * Moves the s3c-hsotg driver into drivers/usb/dwc2/ * Delete s3c-hsotg.h * Make the s3c-hsotg.c file use the defines in hw.h from the DWC2 driver. This initial patch has been tested on the SOCFPGA platform only in Host-only and Gadget-only mode. The next step would be to do the combining of the driver into a dual-role OTG driver. Patchset is base on Felipe Balbi's usb-next tree. Thanks, in advance for any comments and suggestions. Dinh Dinh Nguyen (2): staging: dwc2: Move DWC2 usb driver out of staging usb: gadget: s3c-hsotg: move s3c-hsotg driver into dwc2 drivers/staging/Kconfig |2 - drivers/staging/dwc2/Kconfig | 53 - drivers/staging/dwc2/Makefile| 25 - drivers/staging/dwc2/core.c | 2853 drivers/staging/dwc2/core.h | 768 drivers/staging/dwc2/core_intr.c | 498 - drivers/staging/dwc2/hcd.c | 2976 -- drivers/staging/dwc2/hcd.h | 769 drivers/staging/dwc2/hcd_ddma.c | 1210 drivers/staging/dwc2/hcd_intr.c | 2119 - drivers/staging/dwc2/hcd_queue.c | 862 - drivers/staging/dwc2/hw.h| 809 drivers/staging/dwc2/pci.c | 178 -- drivers/staging/dwc2/platform.c | 149 -- drivers/usb/Kconfig |2 + drivers/usb/Makefile |1 + drivers/usb/dwc2/Kconfig | 82 + drivers/usb/dwc2/Makefile| 25 + drivers/usb/dwc2/core.c | 2853 drivers/usb/dwc2/core.h | 768 drivers/usb/dwc2/core_intr.c | 498 + drivers/usb/dwc2/hcd.c | 2976 ++ drivers/usb/dwc2/hcd.h | 769 drivers/usb/dwc2/hcd_ddma.c | 1210 drivers/usb/dwc2/hcd_intr.c | 2119 + drivers/usb/dwc2/hcd_queue.c | 862 + drivers/usb/dwc2/hw.h| 814 drivers/usb/dwc2/pci.c | 178 ++ drivers/usb/dwc2/platform.c | 149 ++ drivers/usb/dwc2/s3c-hsotg.c | 3794 + drivers/usb/gadget/Makefile |1 - drivers/usb/gadget/s3c-hsotg.c | 3795 -- drivers/usb/gadget/s3c-hsotg.h | 378 33 files changed, 17100 insertions(+), 17445 deletions(-) delete mode 100644 drivers/staging/dwc2/Kconfig delete mode 100644 drivers/staging/dwc2/Makefile delete mode 100644 drivers/staging/dwc2/core.c delete mode 100644 drivers/staging/dwc2/core.h delete mode 100644 drivers/staging/dwc2/core_intr.c delete mode 100644 drivers/staging/dwc2/hcd.c delete mode 100644 drivers/staging/dwc2/hcd.h delete mode 100644 drivers/staging/dwc2/hcd_ddma.c delete mode 100644 drivers/staging/dwc2/hcd_intr.c delete mode 100644 drivers/staging/dwc2/hcd_queue.c delete mode 100644 drivers/staging/dwc2/hw.h delete mode 100644 drivers/staging/dwc2/pci.c delete mode 100644 drivers/staging/dwc2/platform.c create mode 100644 drivers/usb/dwc2/Kconfig create mode 100644 drivers/usb/dwc2/Makefile create mode 100644 drivers/usb/dwc2/core.c create mode 100644 drivers/usb/dwc2/core.h create mode 100644 drivers/usb/dwc2/core_intr.c create mode 100644 drivers/usb/dwc2/hcd.c create mode 100644 drivers/usb/dwc2/hcd.h create mode 100644 drivers/usb/dwc2/hcd_ddma.c create mode 100644 drivers/usb/dwc2/hcd_intr.c create mode 100644 drivers/usb/dwc2/hcd_queue.c create mode 100644 drivers/usb/dwc2/hw.h create mode 100644 drivers/usb/dwc2/pci.c create mode 100644 drivers/usb/dwc2/platform.c create mode 100644 drivers/usb/dwc2/s3c-hsotg.c delete mode 100644 drivers/usb/gadget/s3c-hsotg.c delete mode 100644 drivers/usb/gadget/s3c-hsotg.h --- Cc: Paul Zimmerman Cc: Rashika Kheria Cc: Matthijs Kooijman Cc: Luis Ortega Perez de Villar Cc: Dom Cobley Cc: Ben Dooks Cc: Kukjin Kim Cc: Robert Baldyga Cc: Kyungmin Park Cc: Jingoo Han Cc: Felipe Balbi Cc: Greg Kroah-Hartman Cc: linux-samsung-...@vger.kernel.org Cc: linux-usb@vger.kernel.org -- 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
[RFC PATCH 1/2] staging: dwc2: Move DWC2 usb driver out of staging
From: Dinh Nguyen
Signed-off-by: Dinh Nguyen
Cc: Paul Zimmerman
Cc: Rashika Kheria
Cc: Matthijs Kooijman
Cc: Luis Ortega Perez de Villar
Cc: Dom Cobley
Cc: Ben Dooks
Cc: Kukjin Kim
Cc: Robert Baldyga
Cc: Kyungmin Park
Cc: Jingoo Han
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-usb@vger.kernel.org
---
drivers/staging/Kconfig |2 --
drivers/usb/Kconfig |2 ++
drivers/usb/Makefile |1 +
drivers/{staging => usb}/dwc2/Kconfig | 29 +
drivers/{staging => usb}/dwc2/Makefile|0
drivers/{staging => usb}/dwc2/core.c |0
drivers/{staging => usb}/dwc2/core.h |0
drivers/{staging => usb}/dwc2/core_intr.c |0
drivers/{staging => usb}/dwc2/hcd.c |0
drivers/{staging => usb}/dwc2/hcd.h |0
drivers/{staging => usb}/dwc2/hcd_ddma.c |0
drivers/{staging => usb}/dwc2/hcd_intr.c |0
drivers/{staging => usb}/dwc2/hcd_queue.c |0
drivers/{staging => usb}/dwc2/hw.h| 25 +++--
drivers/{staging => usb}/dwc2/pci.c |0
drivers/{staging => usb}/dwc2/platform.c |0
16 files changed, 47 insertions(+), 12 deletions(-)
rename drivers/{staging => usb}/dwc2/Kconfig (69%)
rename drivers/{staging => usb}/dwc2/Makefile (100%)
rename drivers/{staging => usb}/dwc2/core.c (100%)
rename drivers/{staging => usb}/dwc2/core.h (100%)
rename drivers/{staging => usb}/dwc2/core_intr.c (100%)
rename drivers/{staging => usb}/dwc2/hcd.c (100%)
rename drivers/{staging => usb}/dwc2/hcd.h (100%)
rename drivers/{staging => usb}/dwc2/hcd_ddma.c (100%)
rename drivers/{staging => usb}/dwc2/hcd_intr.c (100%)
rename drivers/{staging => usb}/dwc2/hcd_queue.c (100%)
rename drivers/{staging => usb}/dwc2/hw.h (97%)
rename drivers/{staging => usb}/dwc2/pci.c (100%)
rename drivers/{staging => usb}/dwc2/platform.c (100%)
diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index 3bfdaa8..16b3a5c 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -138,8 +138,6 @@ source "drivers/staging/netlogic/Kconfig"
source "drivers/staging/mt29f_spinand/Kconfig"
-source "drivers/staging/dwc2/Kconfig"
-
source "drivers/staging/lustre/Kconfig"
source "drivers/staging/btmtk_usb/Kconfig"
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index a34fb98..3bbce71 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -106,6 +106,8 @@ endif
source "drivers/usb/musb/Kconfig"
+source "drivers/usb/dwc2/Kconfig"
+
source "drivers/usb/dwc3/Kconfig"
source "drivers/usb/chipidea/Kconfig"
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 70d7c5b..e4136d4 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -6,6 +6,7 @@
obj-$(CONFIG_USB) += core/
+obj-$(CONFIG_USB_DWC2) += dwc2/
obj-$(CONFIG_USB_DWC3) += dwc3/
obj-$(CONFIG_USB_MON) += mon/
diff --git a/drivers/staging/dwc2/Kconfig b/drivers/usb/dwc2/Kconfig
similarity index 69%
rename from drivers/staging/dwc2/Kconfig
rename to drivers/usb/dwc2/Kconfig
index be947d6..299227a 100644
--- a/drivers/staging/dwc2/Kconfig
+++ b/drivers/usb/dwc2/Kconfig
@@ -20,6 +20,35 @@ config USB_DWC2
if USB_DWC2
+choice
+ bool "DWC2 Mode Selection"
+ default USB_DWC2_DUAL_ROLE if (USB && USB_GADGET)
+ default USB_DWC2_HOST if (USB && !USB_GADGET)
+ default USB_DWC2_GADGET if (!USB && USB_GADGET)
+
+config USB_DWC2_HOST
+ bool "Host only mode"
+ depends on USB=y || USB=USB_DWC2
+ help
+ Select this when you want to use DWC2 in host mode only,
+ thereby the gadget feature will be regressed.
+
+config USB_DWC2_GADGET
+ bool "Gadget only mode"
+ depends on USB_GADGET=y || USB_GADGET=USB_DWC2
+ help
+ Select this when you want to use DWC2 in gadget mode only,
+ thereby the host feature will be regressed.
+
+config USB_DWC2_DUAL_ROLE
+ bool "Dual Role mode"
+ depends on ((USB=y || USB=USB_DWC2) && (USB_GADGET=y ||
USB_GADGET=USB_DWC2))
+ help
+ This is the default mode of working of DWC2 controller where
+ both host and gadget features are enabled.
+
+endchoice
+
config USB_DWC2_DEBUG
bool "Enable Debugging Messages"
help
diff --git a/drivers/staging/dwc2/Makefile b/drivers/usb/dwc2/Makefile
similarity index 100%
rename from drivers/staging/dwc2/Makefile
rename to drivers/usb/dwc2/Makefile
diff --git a/drivers/staging/dwc2/core.c b/drivers/usb/dwc2/core.c
similarity index 100%
rename from drivers/staging/dwc2/core.c
rename to drivers/usb/dwc2/core.c
diff --git a/drivers/staging/dwc2/core.h b/drivers/usb/dwc2/core.h
similarity index 100%
rename from drivers/staging/dwc2/core.h
rename to drivers/usb/dwc2/core.h
diff --git a/drivers/staging/dwc2/core_intr.c b/drivers/usb/dwc2/core_intr.c
similarity index 100%
rename from dri
RE: [PATCH 3.12 033/118] usb: xhci: Link TRB must not occur within a USB payload burst [NEW HARDWARE]
From: walt > On 01/09/2014 03:50 PM, Sarah Sharp wrote: > > >>> On Tue, Jan 07, 2014 at 03:57:00PM -0800, walt wrote: > >> > >> I've wondered if my xhci problems might be caused by hardware quirks, and > >> wondering why I seem to be the only one who has this problem. > >> > >> Maybe I could "take one for the team" by buying new hardware toys that I > >> don't really need but I could use to test the xhci driver? (I do enjoy > >> buying new toys, necessary, or, um, maybe not :) > > > > It would be appreciated if you could see if your device causes other > > host controllers to fail. Who am I to keep a geek from new toys? ;) > > Sarah, I just fixed my xhci bug for US$19.99 :) > > #lspci | tail -1 > 04:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller > (rev 03) Do you know which version of the xhci spec it conforms to? (Will probably be 0.96 or 1.00). Of course, ASMedia will probably change the silicon they are using without changing anything on the packaging. David
Re: [linux-sunxi] Re: [PATCH v5 2/2] ehci-platform: Add support for clks and phy passed through devicetree
Hi,
On 01/14/2014 05:12 AM, Tony Prisk wrote:
On 14/01/14 11:45, Hans de Goede wrote:
Currently ehci-platform is only used in combination with devicetree when used
with some Via socs. By extending it to (optionally) get clks and a phy from
devicetree, and enabling / disabling those on power_on / off, it can be used
more generically. Specifically after this commit it can be used for the
ehci controller on Allwinner sunxi SoCs.
Since ehci-platform is intended to handle any generic enough non pci ehci
device, add a "usb-ehci" compatibility string.
There already is a usb-ehci device-tree bindings document, update this
with clks and phy bindings info.
Although actually quite generic so far the via,vt8500 compatibilty string
had its own bindings document. Somehow we even ended up with 2 of them. Since
these provide no extra information over the generic usb-ehci documentation,
this patch removes them.
The ehci-ppc-of.c driver also claims the usb-ehci compatibility string,
even though it mostly is ibm,usb-ehci-440epx specific. ehci-platform.c is
not needed on ppc platforms, so add a !PPC_OF dependency to it to avoid
2 drivers claiming the same compatibility string getting build on ppc.
Signed-off-by: Hans de Goede
---
Documentation/devicetree/bindings/usb/usb-ehci.txt | 25 +++-
.../devicetree/bindings/usb/via,vt8500-ehci.txt| 15 ---
.../devicetree/bindings/usb/vt8500-ehci.txt| 12 --
drivers/usb/host/Kconfig | 1 +
drivers/usb/host/ehci-platform.c | 149 +
5 files changed, 142 insertions(+), 60 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt
delete mode 100644 Documentation/devicetree/bindings/usb/vt8500-ehci.txt
diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt
b/Documentation/devicetree/bindings/usb/usb-ehci.txt
index fa18612..fad10f3 100644
--- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
@@ -7,13 +7,14 @@ Required properties:
(debug-port or other) can be also specified here, but only after
definition of standard EHCI registers.
- interrupts : one EHCI interrupt should be described here.
-If device registers are implemented in big endian mode, the device
-node should have "big-endian-regs" property.
-If controller implementation operates with big endian descriptors,
-"big-endian-desc" property should be specified.
-If both big endian registers and descriptors are used by the controller
-implementation, "big-endian" property can be specified instead of having
-both "big-endian-regs" and "big-endian-desc".
+
+Optional properties:
+ - big-endian-regs : boolean, set this for hcds with big-endian registers
+ - big-endian-desc : boolean, set this for hcds with big-endian descriptors
+ - big-endian : boolean, for hcds with big-endian-regs + big-endian-desc
+ - clocks : a list of phandle + clock specifier pairs
+ - phys : phandle + phy specifier pair
+ - phy-names : "usb"
Example (Sequoia 440EPx):
ehci@e300 {
@@ -23,3 +24,13 @@ Example (Sequoia 440EPx):
reg = <0 e300 90 0 e390 70>;
big-endian;
};
+
+Example (Allwinner sun4i A10 SoC):
+ ehci0: ehci@0x01c14000 {
+ compatible = "allwinner,sun4i-a10-ehci", "usb-ehci";
+ reg = <0x01c14000 0x100>;
+ interrupts = <39>;
+ clocks = <&ahb_gates 1>;
+ phys = <&usbphy 1>;
+ phy-names = "usb";
+ };
You have removed the documentation for the via,vt8500-ehci and wm,prizm-ehci
bindings (which in itself isn't really an issue), and left them in the driver
(again, not an issue)
Correct.
- except now we have two bindings without any binding documentation?!?
My reasoning behind is that the driver is really a generic usb-ehci driver, and
the only reason
the 2 compatibility strings are left in there is for backwards compatibility. I
don't think
compatibility strings only kept in the driver for backwards compatibility
should be documented,
because documented suggests people can rely on them and then they may end up
getting used for new things.
I'm not sure where the 'wm,prizm-ehci' string came from (presumably me some
time ago), but it isn't used and could be dropped.
All WonderMedia SoCs use the 'via,vt8500-ehci' - Doing a quick grep of
arch/arm/boot/dts shows no usage of 'wm,prizm-ehci'.
Arguably, the dtsi files for the WonderMedia SoCs could be updated to include
'usb-ehci' as a second compatible string
Right, I think this would be a good thing to do regardless, also see all the
existing dts files for other
boards already doing this (which is why we ended up using usb-ehci in the first
place).
and the 'via,vt8500-ehci' could be dropped from the driver - but it does mean
that old dts files won't work with the current kernel (and I think that's a
no-no).
Right, which is exactly why I did not remove them from the driver. But since as
you i
Re: usb3 hdd docking station doesn't work with recent kernels
Hi Oliver. Yes, reverting that commit fixes the problem (I did it on top of 3.13rc8). On 13 January 2014 14:05, Oliver Neukum wrote: > On Sun, 2014-01-12 at 14:12 +0400, Sergey Galanov wrote: >> Hi. >> My hdd docking station (AgeStar 3UBT with usb3 support) stopped >> working after upgrade to linux 3.12.3. It worked fine in 3.12.0 and >> before. I can't point to more specific version because it's hard to >> find old packages for my distro (ArchLinux). I also tried 3.12.6, >> 3.12.7 and 3.13rc7 and the problem persists. > > This is not good. My bet is on 60e102ac73cd40069d077014c93c86dc7205cb68 > Could you revert that? If that doesn't do the job, I think you'll need > to bisect. > > Regards > Oliver > > -- 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
