Re: [PATCH v2 9/9] tty/serial: atmel: Prevent a warning on suspend
On 15/09/2017 16:04, Romain Izard wrote:
> The atmel serial port driver reported the following warning on suspend:
> atmel_usart f802.serial: ttyS1: Unable to drain transmitter
>
> As the ATMEL_US_TXEMPTY status bit in ATMEL_US_CSR is always cleared
> when the transmitter is disabled, we need to know the transmitter's
> state to return the real fifo state. And as ATMEL_US_CR is write-only,
> it is necessary to save the state of the transmitter in a local
> variable, and update the variable when TXEN and TXDIS is written in
> ATMEL_US_CR.
>
> After those changes, atmel_tx_empty can return "empty" on suspend, the
> warning in uart_suspend_port disappears, and suspending is 20ms shorter
> for each enabled Atmel serial port.
>
> Signed-off-by: Romain Izard
> ---
> drivers/tty/serial/atmel_serial.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/tty/serial/atmel_serial.c
> b/drivers/tty/serial/atmel_serial.c
> index 7551cab438ff..783af6648be0 100644
> --- a/drivers/tty/serial/atmel_serial.c
> +++ b/drivers/tty/serial/atmel_serial.c
> @@ -171,6 +171,7 @@ struct atmel_uart_port {
> boolhas_hw_timer;
> struct timer_list uart_timer;
>
> + booltx_stopped;
> boolsuspended;
> unsigned intpending;
> unsigned intpending_status;
> @@ -380,6 +381,10 @@ static int atmel_config_rs485(struct uart_port *port,
> */
> static u_int atmel_tx_empty(struct uart_port *port)
> {
> + struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> +
> + if (atmel_port->tx_stopped)
> + return TIOCSER_TEMT;
> return (atmel_uart_readl(port, ATMEL_US_CSR) & ATMEL_US_TXEMPTY) ?
> TIOCSER_TEMT :
> 0;
> @@ -485,6 +490,7 @@ static void atmel_stop_tx(struct uart_port *port)
>* is fully transmitted.
>*/
> atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_TXDIS);
> + atmel_port->tx_stopped = true;
>
> /* Disable interrupts */
> atmel_uart_writel(port, ATMEL_US_IDR, atmel_port->tx_done_mask);
> @@ -492,6 +498,7 @@ static void atmel_stop_tx(struct uart_port *port)
> if ((port->rs485.flags & SER_RS485_ENABLED) &&
> !(port->rs485.flags & SER_RS485_RX_DURING_TX))
> atmel_start_rx(port);
> +
> }
This line feed is not needed.
Otherwise,
Acked-by: Richard Genoud
>
> /*
> @@ -521,6 +528,7 @@ static void atmel_start_tx(struct uart_port *port)
>
> /* re-enable the transmitter */
> atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_TXEN);
> + atmel_port->tx_stopped = false;
> }
>
> /*
> @@ -1866,6 +1874,7 @@ static int atmel_startup(struct uart_port *port)
> atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_RSTSTA | ATMEL_US_RSTRX);
> /* enable xmit & rcvr */
> atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_TXEN | ATMEL_US_RXEN);
> + atmel_port->tx_stopped = false;
>
> setup_timer(&atmel_port->uart_timer,
> atmel_uart_timer_callback,
> @@ -2122,6 +2131,7 @@ static void atmel_set_termios(struct uart_port *port,
> struct ktermios *termios,
>
> /* disable receiver and transmitter */
> atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_TXDIS | ATMEL_US_RXDIS);
> + atmel_port->tx_stopped = true;
>
> /* mode */
> if (port->rs485.flags & SER_RS485_ENABLED) {
> @@ -2207,6 +2217,7 @@ static void atmel_set_termios(struct uart_port *port,
> struct ktermios *termios,
> atmel_uart_writel(port, ATMEL_US_BRGR, quot);
> atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_RSTSTA | ATMEL_US_RSTRX);
> atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_TXEN | ATMEL_US_RXEN);
> + atmel_port->tx_stopped = false;
>
> /* restore interrupts */
> atmel_uart_writel(port, ATMEL_US_IER, imr);
> @@ -2450,6 +2461,7 @@ static void atmel_console_write(struct console *co,
> const char *s, u_int count)
>
> /* Make sure that tx path is actually able to send characters */
> atmel_uart_writel(port, ATMEL_US_CR, ATMEL_US_TXEN);
> + atmel_port->tx_stopped = false;
>
> uart_console_write(port, s, count, atmel_console_putchar);
>
> @@ -2511,6 +2523,7 @@ static int __init atmel_console_setup(struct console
> *co, char *options)
> {
> int ret;
> struct uart_port *port = &atmel_ports[co->index].uart;
> + struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
> int baud = 115200;
> int bits = 8;
> in
Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports
2017-02-10 14:34 GMT+01:00 Krzysztof Kozlowski :
> On Thu, Feb 09, 2017 at 11:26:48AM +0100, Richard Genoud wrote:
>> I did some tests with XU3 and XU4, playing with USB2 and USB3 quirks
>> (snps,dis_u{2,3}_susphy_quirk)
>>
>> kernel for the tests: next-20170206
>> DTBs: exynos5422-odroidxu3-lite.dtb exynos5422-odroidxu4.dtb
>>
>> USB devices used for the tests: kingston USB3 key, Akasa sata/USB3
>> +SSD standard USB2 key
>> once recognized, a dd if=/dev/sda bs=1M count=100 of=/dev/null is done.
>>
>>
>> The results are:
>> - On XU4:
>> - adding snps,dis_u2_susphy_quirk doesn't change anything:
>> inserting an USB2 or USB3 device gives the error message:
>> xhci-hcd xhci-hcd.2.auto: Port resume took longer than 2 msec,
>> port status = 0xc400fe3
>> - with snps,dis_u3_susphy_quirk, USB2 and USB3 devices are recognized
>>
>> - On XU3:
>> - Without changing XU3 dts, USB2 devices are recognized.
>> - With or without the snps,dis_u3_susphy_quirk, USB3 devices are not
>> recognized/not working properly
>> (never seen or disconnected, unable to enumerate, etc.)
>> However, adding an external powered USB3 hub in between works. (with
>> or without the snps,dis_u3_susphy_quirk)
>> Anyway, this problem doesn't seems to be related to the other since
>> addind the quirks doesn't change anything.
>
> From this description I am missing where are you inserting the USB
> devices.
>
> Both boards have totally different USB port configuration. On XU3 the
> hub is on USB 2.0 port. On XU4 the opposite - the hub is on USB 3.0
> port.
Yes, sorry.
All the tests I did were on USB3.0 ports.
So, for the XU4, it was the double USB3.0 connector.
For the XU3, it was the single USB3.0 host port.
(and the XU3 USB3.0 device port for the test bellow)
I didn't do any test on the USB2 ports.
>
> Best regards,
> Krzysztof
>
>> - On XU3 USB3 device port (dr_mode = "peripheral"):
>> - acting as an ethernet gadget only works with the
>> snps,dis_u3_susphy_quirk.
>> It works well as USB2 or USB3 (tested with ethernet gadget+iperf)
>>
>> So, at the end, it does seem usefull to add the
>> snps,dis_u3_susphy_quirk at the exynos5420.dtsi level.
>> Adding the snps,dis_u2_susphy_quirk doesn't seems to change anything
>> for XU3/XU4 board,
>> so I don't know if it is necessary or not.
--
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] ARM: dts: Odroid XU4: fix USB3.0 ports
2017-01-27 8:29 GMT+01:00 Richard Genoud :
> On 25/01/2017 15:17, Krzysztof Kozlowski wrote:
>> On Wed, Jan 25, 2017 at 3:48 PM, Marek Szyprowski
>> wrote:
>>> Hi Krzysztof,
>>>
>>> On 2017-01-25 08:55, Krzysztof Kozlowski wrote:
>>>>
>>>> On Wed, Jan 25, 2017 at 7:51 AM, Anand Moon wrote:
>>>>>
>>>>> On 24 January 2017 at 19:18, Richard Genoud
>>>>> wrote:
>>>>>>
>>>>>> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
>>>>>> the USB ports on odroid-XU4 don't work anymore.
>>>>>>
>>>>>> Inserting an usb key (USB2.0) on the USB3.0 port result in:
>>>>>> [ 64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than
>>>>>> 2 msec, port status = 0xc400fe3
>>>>>> [ 74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to
>>>>>> stop endpoint command.
>>>>>> [ 74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting
>>>>>> host.
>>>>>> [ 74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
>>>>>> [ 74.606276] usb 3-1: USB disconnect, device number 2
>>>>>> [ 74.613565] usb 4-1: USB disconnect, device number 2
>>>>>> [ 74.621208] usb usb3-port1: couldn't allocate usb_device
>>>>>> NB: it's not related to USB2.0 devices, I get the same result with an
>>>>>> USB3.0 device (SATA to USB3 for instance).
>>>>>> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the
>>>>>> realtek RTL8153 chip.
>>>>>>
>>>>>> If the lines:
>>>>>> if (dwc->revision > DWC3_REVISION_194A)
>>>>>> reg |= DWC3_GUSB3PIPECTL_SUSPHY;
>>>>>> are commented out, the USB3.0 start working.
>>>>>>
>>>>>> For a full analyse: https://lkml.org/lkml/2017/1/18/678
>>>>>>
>>>>>> Felipe suggested that suspend should be disabled temporarily while
>>>>>> what's wrong with DCW3 is figured out.
>>>>>>
>>>>>> Tested on Odroid XU4
>>>>>>
>>>>>> Suggested-by: Felipe Balbi
>>>>>> Tested-by: Richard Genoud
>>>>>> Signed-off-by: Richard Genoud
>>>>>> Cc: sta...@vger.kernel.org # 4.4+
>>>>>> Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
>>>>>> ---
>>>>>> arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +
>>>>>> 1 file changed, 9 insertions(+)
>>>>>>
>>>>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>>>> b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>>>> index 2faf88627a48..f62dbd9b5ad3 100644
>>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>>>> @@ -43,6 +43,15 @@
>>>>>> status = "okay";
>>>>>> };
>>>>>>
>>>>>> +&usbdrd_dwc3_0 {
>>>>>> + /*
>>>>>> +* without that, usb devices are not recognized when
>>>>>> +* they are plugged.
>>>>>> +* cf: https://lkml.org/lkml/2017/1/18/678
>>>>>> +*/
>>>>>> + snps,dis_u3_susphy_quirk;
>>>>>> +};
>>>>>> +
>>>>>> &usbdrd_dwc3_1 {
>>>>>> dr_mode = "host";
>>>>>> };
>>>>>> --
>>>>>
>>>>> Thanks for this patch.
>>>>> But could you consider moving this changes as below.
>>>>>
>>>>> https://lkml.org/lkml/2015/3/18/400
>>>>
>>>> The patch above (and other DTS patches from the set) was not even sent
>>>> to linux-samsung-soc nor to me... It is sad how easily one's work can
>>>> disappear. Also, it is really worthless to solve the same problem
>>>> twice.
>>>
>>>
>>> Well, they were sent about 2 years ago... and you were also working on this
>>> topic. ;)
>>
>> Nope, I have never worked on this. That time I was in Korea so my
>> tasks were completely di
Re: [PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports
On 25/01/2017 15:17, Krzysztof Kozlowski wrote:
> On Wed, Jan 25, 2017 at 3:48 PM, Marek Szyprowski
> wrote:
>> Hi Krzysztof,
>>
>> On 2017-01-25 08:55, Krzysztof Kozlowski wrote:
>>>
>>> On Wed, Jan 25, 2017 at 7:51 AM, Anand Moon wrote:
>>>>
>>>> On 24 January 2017 at 19:18, Richard Genoud
>>>> wrote:
>>>>>
>>>>> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
>>>>> the USB ports on odroid-XU4 don't work anymore.
>>>>>
>>>>> Inserting an usb key (USB2.0) on the USB3.0 port result in:
>>>>> [ 64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than
>>>>> 2 msec, port status = 0xc400fe3
>>>>> [ 74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to
>>>>> stop endpoint command.
>>>>> [ 74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting
>>>>> host.
>>>>> [ 74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
>>>>> [ 74.606276] usb 3-1: USB disconnect, device number 2
>>>>> [ 74.613565] usb 4-1: USB disconnect, device number 2
>>>>> [ 74.621208] usb usb3-port1: couldn't allocate usb_device
>>>>> NB: it's not related to USB2.0 devices, I get the same result with an
>>>>> USB3.0 device (SATA to USB3 for instance).
>>>>> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the
>>>>> realtek RTL8153 chip.
>>>>>
>>>>> If the lines:
>>>>> if (dwc->revision > DWC3_REVISION_194A)
>>>>> reg |= DWC3_GUSB3PIPECTL_SUSPHY;
>>>>> are commented out, the USB3.0 start working.
>>>>>
>>>>> For a full analyse: https://lkml.org/lkml/2017/1/18/678
>>>>>
>>>>> Felipe suggested that suspend should be disabled temporarily while
>>>>> what's wrong with DCW3 is figured out.
>>>>>
>>>>> Tested on Odroid XU4
>>>>>
>>>>> Suggested-by: Felipe Balbi
>>>>> Tested-by: Richard Genoud
>>>>> Signed-off-by: Richard Genoud
>>>>> Cc: sta...@vger.kernel.org # 4.4+
>>>>> Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
>>>>> ---
>>>>> arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +
>>>>> 1 file changed, 9 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>>> b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>>> index 2faf88627a48..f62dbd9b5ad3 100644
>>>>> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>>>>> @@ -43,6 +43,15 @@
>>>>> status = "okay";
>>>>> };
>>>>>
>>>>> +&usbdrd_dwc3_0 {
>>>>> + /*
>>>>> +* without that, usb devices are not recognized when
>>>>> +* they are plugged.
>>>>> +* cf: https://lkml.org/lkml/2017/1/18/678
>>>>> +*/
>>>>> + snps,dis_u3_susphy_quirk;
>>>>> +};
>>>>> +
>>>>> &usbdrd_dwc3_1 {
>>>>> dr_mode = "host";
>>>>> };
>>>>> --
>>>>
>>>> Thanks for this patch.
>>>> But could you consider moving this changes as below.
>>>>
>>>> https://lkml.org/lkml/2015/3/18/400
>>>
>>> The patch above (and other DTS patches from the set) was not even sent
>>> to linux-samsung-soc nor to me... It is sad how easily one's work can
>>> disappear. Also, it is really worthless to solve the same problem
>>> twice.
>>
>>
>> Well, they were sent about 2 years ago... and you were also working on this
>> topic. ;)
>
> Nope, I have never worked on this. That time I was in Korea so my
> tasks were completely different. Later when I got back, I took for a
> second U3 OTG which was not involving this thing.
>
>>> Cc Marek and Bartlomiej,
>>> Guys, do you want to continue with Robert's patch (linked above by
>>> Anand)? If yes, please take the ownership (Robert's address is not
>>> valid anymore). If not, I will take Richard's patch after
>>> resubmission.
>>
>>
>> Take Richard's patch because it has a bit more details describing why such
>> quirk
>> is needed.
>>
>> Richard: in Roberts patch there is also a quirk for USB 2.0 mode
>> (snps,dis_u2_susphy_quirk). Could you check if it really needed?
>>
>> Maybe it would make sense to set those quirks for both DWC3 controllers, as
>> this
>> issue with PHY suspend seems to be a Exynos specific thing.
>
> Okay,
> Richard, please continue with your patch.
Ok, I'll grab a XU3 & XU4 and do some more tests.
But I didn't recall having problems with the XU3 board. I'll try to add
a hub or something.
--
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] ARM: dts: Odroid XU4: fix USB3.0 ports
On 24/01/2017 19:22, Krzysztof Kozlowski wrote:
> On Tue, Jan 24, 2017 at 02:48:09PM +0100, Richard Genoud wrote:
>> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
>> the USB ports on odroid-XU4 don't work anymore.
>
> Hi,
>
> Thanks for the patch. Please:
> 1. Use recent kernel to test it, which could be one of: mainline
>(Linus'), recent linux-next or my for-next branch. Why am I thinking
>that you did not test it on thse? Because you sent the patch to
>k.kozlow...@samsung.com. The guy disappeared four months ago and
>recent kernel has all addresses updated (including mailmap).
My bad, I took the email from the commit 6658356014cb ("ARM: dts: Add
support Odroid XU4 board for exynos5422-odroidxu4") instead of taking it
from get_maintainer (That was clearly a bad idea).
I actually ran my tests on 4.4.44 / 4.8.5 / 4.9.5 4.10-rc4
I'll also run them on -next
> 2. Fix the title to match subsystem (git log --oneline
> arch/arm/boot/dts/exynos*).
Ok
>
>>
>> Inserting an usb key (USB2.0) on the USB3.0 port result in:
>> [ 64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than 2
>> msec, port status = 0xc400fe3
>> [ 74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to stop
>> endpoint command.
>> [ 74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting
>> host.
>> [ 74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
>> [ 74.606276] usb 3-1: USB disconnect, device number 2
>> [ 74.613565] usb 4-1: USB disconnect, device number 2
>> [ 74.621208] usb usb3-port1: couldn't allocate usb_device
>> NB: it's not related to USB2.0 devices, I get the same result with an USB3.0
>> device (SATA to USB3 for instance).
>> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the realtek
>> RTL8153 chip.
>
> Odroid-XU3
> s/realtek/Realtek/
> However I do not think that Realtek matters here. The USB3 ports are
> directly accessible on XU3. On XU4 on the other hand, the port USB3-0 is
> connected to USB hub. I think the sentence about Realtek is then
> misleading, so just mention the XU3.
Ok
>
>>
>> If the lines:
>> if (dwc->revision > DWC3_REVISION_194A)
>> reg |= DWC3_GUSB3PIPECTL_SUSPHY;
>> are commented out, the USB3.0 start working.
>
> s/start/starts/
Ok
>>
>> For a full analyse: https://lkml.org/lkml/2017/1/18/678
>
> Documentation/process/submitting-patches.rst
> Instead of this above (lkml.org is highly discouraged) use proper
> https://lkml.kernel.org/ in "Link:" put next to other tags (look at
> recent commits), however I do not find this link as necessary. Just
> describe here what is wrong and how you are going to fix it.
Ok
>>
>> Felipe suggested that suspend should be disabled temporarily while
>> what's wrong with DCW3 is figured out.
>>
>> Tested on Odroid XU4
>>
>> Suggested-by: Felipe Balbi
>> Tested-by: Richard Genoud
>
> Being an author implies testing. Please remove the tag.
Ok
>> Signed-off-by: Richard Genoud
>> Cc: sta...@vger.kernel.org # 4.4+
>
> Malformed tag - missing <>.
Ok
>> Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
>
> No need for such long hash (2164a405762c).
>
> I wonder about pointing the commit which introduced the issue. Usually
> the fixes directly indicates how far we want the patch to be backported.
> In this case this should be backported to kernel bringing XU4 DTS. The
> commit which was not valid, was the commit adding DTS without this
> property. 2164a476205c was innocent for XU4 because XU4 did not exist
> that time.
>
> Definitely something is wrong if Fixes tag does not match indicated
> backport version.
Yes, I see what you mean. We can't say that 2164a476205ccc ("usb: dwc3:
set SUSPHY bit for all cores") broke XU4 because it predates it !
I'll simply remove that.
>> ---
>> arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> index 2faf88627a48..f62dbd9b5ad3 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> @@ -43,6 +43,15 @@
>> status = "okay";
>> };
>>
>> +&usbdrd_dwc3_0 {
>> +/*
>> + * without that, usb devices are not recognized when
>> + * they are plugged.
>
> s/without/Wit
[PATCH] ARM: dts: Odroid XU4: fix USB3.0 ports
Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
the USB ports on odroid-XU4 don't work anymore.
Inserting an usb key (USB2.0) on the USB3.0 port result in:
[ 64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than 2
msec, port status = 0xc400fe3
[ 74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to stop
endpoint command.
[ 74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting host.
[ 74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
[ 74.606276] usb 3-1: USB disconnect, device number 2
[ 74.613565] usb 4-1: USB disconnect, device number 2
[ 74.621208] usb usb3-port1: couldn't allocate usb_device
NB: it's not related to USB2.0 devices, I get the same result with an USB3.0
device (SATA to USB3 for instance).
NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the realtek
RTL8153 chip.
If the lines:
if (dwc->revision > DWC3_REVISION_194A)
reg |= DWC3_GUSB3PIPECTL_SUSPHY;
are commented out, the USB3.0 start working.
For a full analyse: https://lkml.org/lkml/2017/1/18/678
Felipe suggested that suspend should be disabled temporarily while
what's wrong with DCW3 is figured out.
Tested on Odroid XU4
Suggested-by: Felipe Balbi
Tested-by: Richard Genoud
Signed-off-by: Richard Genoud
Cc: sta...@vger.kernel.org # 4.4+
Fixes: 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores")
---
arch/arm/boot/dts/exynos5422-odroidxu4.dts | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
index 2faf88627a48..f62dbd9b5ad3 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
@@ -43,6 +43,15 @@
status = "okay";
};
+&usbdrd_dwc3_0 {
+ /*
+* without that, usb devices are not recognized when
+* they are plugged.
+* cf: https://lkml.org/lkml/2017/1/18/678
+*/
+ snps,dis_u3_susphy_quirk;
+};
+
&usbdrd_dwc3_1 {
dr_mode = "host";
};
--
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: [BISSECTED]: BUG: usb: dwc3: usb ports not working anymore on odroid-XU4
2017-01-23 12:45 GMT+01:00 Felipe Balbi :
>
> Hi,
>
> Richard Genoud writes:
>> On 19/01/2017 09:03, Felipe Balbi wrote:
>>>
>>> Hi,
>>>
>>> Richard Genoud writes:
>>>> Hi,
>>>> Since commit c499ff71ff2a2 ("usb: dwc3: core: re-factor init and exit
>>>> paths")
>>>> (merged in 4.8), the usb ports on odroid-XU4 don't work anymore.
>>>>
>>>> [ Actually, it's commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all
>>>> cores"), cf below ]
>>>>
>>>> Inserting an usb key (USB2.0) on the USB3.0 port result in:
>>>> [ 64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than
>>>> 2 msec, port status = 0xc400fe3
>>>> [ 74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to stop
>>>> endpoint command.
>>>> [ 74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting
>>>> host.
>>>> [ 74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
>>>> [ 74.606276] usb 3-1: USB disconnect, device number 2
>>>> [ 74.613565] usb 4-1: USB disconnect, device number 2
>>>> [ 74.621208] usb usb3-port1: couldn't allocate usb_device
>>>> NB: it's not related to USB2.0 devices, I get the same result with an
>>>> USB3.0 device (SATA to USB3 for instance).
>>>> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the
>>>> realtek RTL8153 chip.
>>>>
>>>> I instrumented what was read/written in the registers before and after
>>>> this patch, and I found that the culprit is:
>>>> if (dwc->revision > DWC3_REVISION_194A)
>>>> reg |= DWC3_GUSB3PIPECTL_SUSPHY;
>>>> Before commit c499ff71ff2a2 ("usb: dwc3: core: re-factor init and exit
>>>> paths"), dwc3_phy_setup() was
>>>> done early in dwc3_probe() and thus, dwc->revision wasn't set yet (==0)
>>>> After this commit, dwc3_phy_setup() is done in dwc3_core_init(), after
>>>> setting dwc->revision (it's done in dwc3_core_is_valid()).
>>>>
>>>> (The dwc3->revision on odroid-XU4 is 5533200a.)
>>>>
>>>> If I comment out the 2 lines:
>>>> if (dwc->revision > DWC3_REVISION_194A)
>>>> reg |= DWC3_GUSB3PIPECTL_SUSPHY;
>>>> The usb key is recognized right away:
>>>> [ 38.008158] usb 3-1.2: new high-speed USB device number 3 using xhci-hcd
>>>> [ 38.138924] usb 3-1.2: New USB device found, idVendor=abcd,
>>>> idProduct=1234
>>>> [ 38.144399] usb 3-1.2: New USB device strings: Mfr=1, Product=2,
>>>> SerialNumber=3
>>>>
>>>> I took a look at the history behind those 2 lines, and they've been
>>>> introduced by:
>>>> commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores") in 3.19.
>>>> In 3.19, the dwc->revision dwc3_phy_setup() was set in dwc3_core_init().
>>>> And, booting a 3.19 kernel on XU4 gives the same error (whereas booting a
>>>> 3.18 kernel is ok)
>>>>
>>>> [ So, I should have started this email with:
>>>> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
>>>> the usb ports on odroid-XU4 don't work anymore. ]
>>>>
>>>> The funny thing is that commit 45bb7de213d8("usb: dwc3: setup phys
>>>> earlier") (merged in 4.2)
>>>> moved dwc3_phy_setup() in dwc3_probe(), way before dwc->revision was set,
>>>> acting like a revert
>>>> on commit 2164a476205c("usb: dwc3: set SUSPHY bit for all cores")
>>>> That's why on 4.2, inserting an USB key on odroid-XU4 worked again,
>>>>
>>>> So, to make a resume:
>>>> xxx-> 3.18: usb ok
>>>> 3.19->4.1: usb error (due to commit 2164a476205ccc ("usb: dwc3: set SUSPHY
>>>> bit for all cores"))
>>>> 4.2->4.7: usb ok (due to commit 45bb7de213d8("usb: dwc3: setup phys
>>>> earlier"))
>>>> 4.8->now: usb error (due to commit c499ff71ff2a2 ("usb: dwc3: core:
>>>> re-factor init and exit paths"))
>>>>
>>>>
>>>> any idea on this ?
>>>
>>> Thanks for bisecting. This could be caused by a similar case as
>>> described at [1]. Can you check if adding quirk
>>> "snps,dis_u3_susphy_quirk" helps ?
>>>
>>> [1]
>>> https://marc.info/?i=2b3535c5ece8b5419e3ecbe300772909021b3fd...@us01wembx2.internal.synopsys.com
>>>
>> Thanks for your quick answer !
>>
>> yes, adding this patch:
>>
>> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> index 2faf88627a48..c76e76bc9ade 100644
>> --- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> +++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
>> @@ -43,6 +43,9 @@
>> status = "okay";
>> };
>>
>> +&usbdrd_dwc3_0 {
>> + snps,dis_u3_susphy_quirk;
>> +};
>> &usbdrd_dwc3_1 {
>> dr_mode = "host";
>> };
>>
>> removes the error "Port resume took longer than 2 msec, port
>> status = 0xc400fe3" and the USB devices are detected.
>
> okay great. Temporarily, you can probably push a patch doing that to
> your DTS. At least you're gonna have things working until we understand
> what's going on with DWC3.
Ok.
Thanks !
Richard.
--
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: [BISSECTED]: BUG: usb: dwc3: usb ports not working anymore on odroid-XU4
On 19/01/2017 09:03, Felipe Balbi wrote:
>
> Hi,
>
> Richard Genoud writes:
>> Hi,
>> Since commit c499ff71ff2a2 ("usb: dwc3: core: re-factor init and exit paths")
>> (merged in 4.8), the usb ports on odroid-XU4 don't work anymore.
>>
>> [ Actually, it's commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all
>> cores"), cf below ]
>>
>> Inserting an usb key (USB2.0) on the USB3.0 port result in:
>> [ 64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than 2
>> msec, port status = 0xc400fe3
>> [ 74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to stop
>> endpoint command.
>> [ 74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting
>> host.
>> [ 74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
>> [ 74.606276] usb 3-1: USB disconnect, device number 2
>> [ 74.613565] usb 4-1: USB disconnect, device number 2
>> [ 74.621208] usb usb3-port1: couldn't allocate usb_device
>> NB: it's not related to USB2.0 devices, I get the same result with an USB3.0
>> device (SATA to USB3 for instance).
>> NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the realtek
>> RTL8153 chip.
>>
>> I instrumented what was read/written in the registers before and after this
>> patch, and I found that the culprit is:
>> if (dwc->revision > DWC3_REVISION_194A)
>> reg |= DWC3_GUSB3PIPECTL_SUSPHY;
>> Before commit c499ff71ff2a2 ("usb: dwc3: core: re-factor init and exit
>> paths"), dwc3_phy_setup() was
>> done early in dwc3_probe() and thus, dwc->revision wasn't set yet (==0)
>> After this commit, dwc3_phy_setup() is done in dwc3_core_init(), after
>> setting dwc->revision (it's done in dwc3_core_is_valid()).
>>
>> (The dwc3->revision on odroid-XU4 is 5533200a.)
>>
>> If I comment out the 2 lines:
>> if (dwc->revision > DWC3_REVISION_194A)
>> reg |= DWC3_GUSB3PIPECTL_SUSPHY;
>> The usb key is recognized right away:
>> [ 38.008158] usb 3-1.2: new high-speed USB device number 3 using xhci-hcd
>> [ 38.138924] usb 3-1.2: New USB device found, idVendor=abcd, idProduct=1234
>> [ 38.144399] usb 3-1.2: New USB device strings: Mfr=1, Product=2,
>> SerialNumber=3
>>
>> I took a look at the history behind those 2 lines, and they've been
>> introduced by:
>> commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores") in 3.19.
>> In 3.19, the dwc->revision dwc3_phy_setup() was set in dwc3_core_init().
>> And, booting a 3.19 kernel on XU4 gives the same error (whereas booting a
>> 3.18 kernel is ok)
>>
>> [ So, I should have started this email with:
>> Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
>> the usb ports on odroid-XU4 don't work anymore. ]
>>
>> The funny thing is that commit 45bb7de213d8("usb: dwc3: setup phys earlier")
>> (merged in 4.2)
>> moved dwc3_phy_setup() in dwc3_probe(), way before dwc->revision was set,
>> acting like a revert
>> on commit 2164a476205c("usb: dwc3: set SUSPHY bit for all cores")
>> That's why on 4.2, inserting an USB key on odroid-XU4 worked again,
>>
>> So, to make a resume:
>> xxx-> 3.18: usb ok
>> 3.19->4.1: usb error (due to commit 2164a476205ccc ("usb: dwc3: set SUSPHY
>> bit for all cores"))
>> 4.2->4.7: usb ok (due to commit 45bb7de213d8("usb: dwc3: setup phys
>> earlier"))
>> 4.8->now: usb error (due to commit c499ff71ff2a2 ("usb: dwc3: core:
>> re-factor init and exit paths"))
>>
>>
>> any idea on this ?
>
> Thanks for bisecting. This could be caused by a similar case as
> described at [1]. Can you check if adding quirk
> "snps,dis_u3_susphy_quirk" helps ?
>
> [1]
> https://marc.info/?i=2b3535c5ece8b5419e3ecbe300772909021b3fd...@us01wembx2.internal.synopsys.com
>
Thanks for your quick answer !
yes, adding this patch:
diff --git a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
index 2faf88627a48..c76e76bc9ade 100644
--- a/arch/arm/boot/dts/exynos5422-odroidxu4.dts
+++ b/arch/arm/boot/dts/exynos5422-odroidxu4.dts
@@ -43,6 +43,9 @@
status = "okay";
};
+&usbdrd_dwc3_0 {
+ snps,dis_u3_susphy_quirk;
+};
&usbdrd_dwc3_1 {
dr_mode = "host";
};
removes the error "Port resume took longer than 2 msec, port status =
0xc400fe3"
and the USB devices are detected.
Richard.
--
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
[BISSECTED]: BUG: usb: dwc3: usb ports not working anymore on odroid-XU4
Hi,
Since commit c499ff71ff2a2 ("usb: dwc3: core: re-factor init and exit paths")
(merged in 4.8), the usb ports on odroid-XU4 don't work anymore.
[ Actually, it's commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all
cores"), cf below ]
Inserting an usb key (USB2.0) on the USB3.0 port result in:
[ 64.488264] xhci-hcd xhci-hcd.2.auto: Port resume took longer than 2
msec, port status = 0xc400fe3
[ 74.568156] xhci-hcd xhci-hcd.2.auto: xHCI host not responding to stop
endpoint command.
[ 74.574806] xhci-hcd xhci-hcd.2.auto: Assuming host is dying, halting host.
[ 74.601970] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up
[ 74.606276] usb 3-1: USB disconnect, device number 2
[ 74.613565] usb 4-1: USB disconnect, device number 2
[ 74.621208] usb usb3-port1: couldn't allocate usb_device
NB: it's not related to USB2.0 devices, I get the same result with an USB3.0
device (SATA to USB3 for instance).
NB2: it doesn't happen on an odriod-XU3 board, that doesn't have the realtek
RTL8153 chip.
I instrumented what was read/written in the registers before and after this
patch, and I found that the culprit is:
if (dwc->revision > DWC3_REVISION_194A)
reg |= DWC3_GUSB3PIPECTL_SUSPHY;
Before commit c499ff71ff2a2 ("usb: dwc3: core: re-factor init and exit paths"),
dwc3_phy_setup() was
done early in dwc3_probe() and thus, dwc->revision wasn't set yet (==0)
After this commit, dwc3_phy_setup() is done in dwc3_core_init(), after setting
dwc->revision (it's done in dwc3_core_is_valid()).
(The dwc3->revision on odroid-XU4 is 5533200a.)
If I comment out the 2 lines:
if (dwc->revision > DWC3_REVISION_194A)
reg |= DWC3_GUSB3PIPECTL_SUSPHY;
The usb key is recognized right away:
[ 38.008158] usb 3-1.2: new high-speed USB device number 3 using xhci-hcd
[ 38.138924] usb 3-1.2: New USB device found, idVendor=abcd, idProduct=1234
[ 38.144399] usb 3-1.2: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
I took a look at the history behind those 2 lines, and they've been introduced
by:
commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores") in 3.19.
In 3.19, the dwc->revision dwc3_phy_setup() was set in dwc3_core_init().
And, booting a 3.19 kernel on XU4 gives the same error (whereas booting a 3.18
kernel is ok)
[ So, I should have started this email with:
Since commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit for all cores"),
the usb ports on odroid-XU4 don't work anymore. ]
The funny thing is that commit 45bb7de213d8("usb: dwc3: setup phys earlier")
(merged in 4.2)
moved dwc3_phy_setup() in dwc3_probe(), way before dwc->revision was set,
acting like a revert
on commit 2164a476205c("usb: dwc3: set SUSPHY bit for all cores")
That's why on 4.2, inserting an USB key on odroid-XU4 worked again,
So, to make a resume:
xxx-> 3.18: usb ok
3.19->4.1: usb error (due to commit 2164a476205ccc ("usb: dwc3: set SUSPHY bit
for all cores"))
4.2->4.7: usb ok (due to commit 45bb7de213d8("usb: dwc3: setup phys earlier"))
4.8->now: usb error (due to commit c499ff71ff2a2 ("usb: dwc3: core: re-factor
init and exit paths"))
any idea on this ?
regards,
Richard
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: gadget: udc: atmel: fix endpoint name
2016-09-26 9:18 GMT+02:00 Felipe Balbi :
>
> Hi,
>
> Greg Kroah-Hartman writes:
>> On Fri, Sep 23, 2016 at 04:20:45PM +0200, Nicolas Ferre wrote:
>>> Le 16/09/2016 à 10:36, Nicolas Ferre a écrit :
>>> > Le 15/09/2016 à 17:07, Alexandre Belloni a écrit :
>>> >> Since commit c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes"),
>>> >> atmel_usba_udc fails with:
>>> >>
>>> >> [ cut here ]
>>> >> WARNING: CPU: 0 PID: 0 at include/linux/usb/gadget.h:405
>>> >> ecm_do_notify+0x188/0x1a0
>>> >> Modules linked in:
>>> >> CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0+ #15
>>> >> Hardware name: Atmel SAMA5
>>> >> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
>>> >> [] (show_stack) from [] (__warn+0xe4/0xfc)
>>> >> [] (__warn) from [] (warn_slowpath_null+0x20/0x28)
>>> >> [] (warn_slowpath_null) from []
>>> >> (ecm_do_notify+0x188/0x1a0)
>>> >> [] (ecm_do_notify) from [] (ecm_set_alt+0x74/0x1ac)
>>> >> [] (ecm_set_alt) from []
>>> >> (composite_setup+0xfc0/0x19f8)
>>> >> [] (composite_setup) from []
>>> >> (usba_udc_irq+0x8f4/0xd9c)
>>> >> [] (usba_udc_irq) from []
>>> >> (handle_irq_event_percpu+0x9c/0x158)
>>> >> [] (handle_irq_event_percpu) from []
>>> >> (handle_irq_event+0x28/0x3c)
>>> >> [] (handle_irq_event) from []
>>> >> (handle_fasteoi_irq+0xa0/0x168)
>>> >> [] (handle_fasteoi_irq) from []
>>> >> (generic_handle_irq+0x24/0x34)
>>> >> [] (generic_handle_irq) from []
>>> >> (__handle_domain_irq+0x54/0xa8)
>>> >> [] (__handle_domain_irq) from []
>>> >> (__irq_svc+0x54/0x70)
>>> >> [] (__irq_svc) from [] (arch_cpu_idle+0x38/0x3c)
>>> >> [] (arch_cpu_idle) from []
>>> >> (cpu_startup_entry+0x9c/0xdc)
>>> >> [] (cpu_startup_entry) from []
>>> >> (start_kernel+0x354/0x360)
>>> >> [] (start_kernel) from [<20008078>] (0x20008078)
>>> >> ---[ end trace e7cf9dcebf4815a6 ]---
>>> >>
>>> >> Fixes: c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes")
>>> >> Reported-by: Richard Genoud
>>> >> Signed-off-by: Alexandre Belloni
>>> >
>>> > Acked-by: Nicolas Ferre
>>> >
>>> > Felipe, Greg,
>>> > It is clearly a regression and material for 4.8-fixes. But I do know
>>> > that we are very late in the process :-(
>>> > Please do what you can to make it progress before 4.8-final but I'm
>>> > truly aware of the challenge.
>>>
>>> Any chance that we can have it (aka ping)?
>>
>> It's Felipe's area, not mine :)
>
> Sorry, I had missed this one. Greg, seems like this would be the only
> pending fix. Do you want it in a pull request or would you prefer to
> just pick it up as a patch? Works either way for me. In case you decide
> to pick it up as a patch:
>
> Acked-by: Felipe Balbi
>
> If you prefer to pick it up as a pull request, I already have the patch
> in my 'fixes' branch, just need to tag it and send it to you.
>
> --
> balbi
All seems ok, thanks Alexandre.
Tested-by: Richard Genoud
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 5/5] usb-phy: samsung-usb3: Remove older phy-samsung-usb3 driver
Hi Vivek, 2014-04-09 13:34 GMT+02:00 Vivek Gautam : > Hi Tomasz, > ' > > On Wed, Apr 9, 2014 at 4:43 PM, Tomasz Figa wrote: >> Hi Vivek, >> > Thanks for reviewing the patch series. > >> >> On 08.04.2014 16:36, Vivek Gautam wrote: >>> >>> Removing this older USB 3.0 DRD controller PHY driver, since >>> a new driver based on generic phy framework is now available. >>> >>> Also removing the dt node for older driver from Exynos5250 >>> device tree and updating the dt node for DWC3 controller. >>> >>> Signed-off-by: Vivek Gautam >>> --- >>> >>> NOTE: This patch should be merged only when the new USB 3.0 >>> DRD phy controller driver is available in the tree from the >>> patches: >>> phy: Add new Exynos5 USB 3.0 PHY driver; and >>> dt: exynos5250: Enable support for generic USB DRD phy >>> >>> arch/arm/boot/dts/exynos5250.dtsi | 17 +- >>> drivers/usb/phy/phy-samsung-usb.h | 83 - >>> drivers/usb/phy/phy-samsung-usb3.c | 350 >>> >>> 3 files changed, 2 insertions(+), 448 deletions(-) >>> delete mode 100644 drivers/usb/phy/phy-samsung-usb3.c >>> >>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi >>> b/arch/arm/boot/dts/exynos5250.dtsi >>> index 92c6fcd..1cb1e91 100644 >>> --- a/arch/arm/boot/dts/exynos5250.dtsi >>> +++ b/arch/arm/boot/dts/exynos5250.dtsi >> >> >> IMHO driver and dts changes should be separated into two patches, first >> updating device tree to use the new driver and second removing the driver. > > Sure will separate the patch into driver and dts change. > >> >> After fixing this issue, >> >> Reviewed-by: Tomasz Figa >> I guess you should also remove phy-samsung-usb3.c references in the Makefile, Kconfig and exynos_defconfig Richard. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [usb-storage] Re: usb3.0 device recognized as usb2.1
2013/2/14 Richard Genoud : > 2013/2/12 Sarah Sharp : >> On Sun, Feb 03, 2013 at 09:52:42PM -0500, Alan Stern wrote: >>> On Sun, 3 Feb 2013, Richard Genoud wrote: >>> >>> > [previously] >>> > I tried to use this device : usb3.0 HDD dock ( >>> > http://www.icydock.com/goods.php?id=130 ) based on JMicron JMS539 >>> > chipset. >>> > It's always recognized as an usb2.1 device instead of USB3. >>> > My USB3 controller is based on VIA VL800 B3. >>> > Same controller and same device on windows7 is also recognized as USB2.1. >>> > [/previously] epilogue for this story: An hardware reviewer kindly tried his usb dock with a HDD instead of a SSD. (on windows) It was also recognized as an USB2. http://www.zeden.net/actu/19403-test-Icy-Dock-EZ-DOCK-MB881U3-1SA#comment_36566 (french inside !) So, it seems to be a hard conception problem. => I bought another sata/USB3 device (with no HUB, no IDE) and it's working perfectly. Thanks for the support. Best regards, Richard. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [usb-storage] Re: usb3.0 device recognized as usb2.1
2013/2/12 Sarah Sharp : > On Sun, Feb 03, 2013 at 09:52:42PM -0500, Alan Stern wrote: >> On Sun, 3 Feb 2013, Richard Genoud wrote: >> >> > [previously] >> > I tried to use this device : usb3.0 HDD dock ( >> > http://www.icydock.com/goods.php?id=130 ) based on JMicron JMS539 >> > chipset. >> > It's always recognized as an usb2.1 device instead of USB3. >> > My USB3 controller is based on VIA VL800 B3. >> > Same controller and same device on windows7 is also recognized as USB2.1. >> > [/previously] >> > >> > I did some tests with other controllers (NEC uPD720200 and Fresco Logic >> > FL1009) >> >> > Long story short, the icy dock device is still recognized as USB2.1 >> > with those controllers. >> > (The kern.log with usb debug is attached). >> > >> > I'm not sure that there's anything else to do... it seems that the icy >> > dock only works in USB3 when it's benchmarked on websites, with SSD >> > drives :( >> > cf http://www.thinkcomputers.org/icy-dock-mb881u3-1sa-ez-dock-review/3/ >> >> Maybe you could return it or exchange. Clearly it is not working >> properly. Not even under Windows, which is usually all that vendors >> care about. > > Or try buying a new USB 3.0 cable? > > Sarah Sharp Tried it with several different cables. No success. -- for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ? -- 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.0 device recognized as usb2.1
2013/1/18 Oliver Neukum : > The question is, what goes wrong, if indeed the device is SS. > > In this particular case a usbmon trace is likely not as useful as usually. > Could you compile a kernel with DEBUG for USB and XHCI enabled? no problem, I'll do that tomorrow (not at home until then). 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
