Re: [Bug 197863] Thinkpad X240 resume dramatically slower on kernels 4.13+

[Oliver Neukum]

Am Montag, den 29.01.2018, 19:21 +0100 schrieb Markus Demleitner:
> 
> Any guess what might be behind this?
> 

Hi,

have you checked the persist attribute between the versions working
well and working badly?

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

Re: [Bug 197863] Thinkpad X240 resume dramatically slower on kernels 4.13+

[Greg KH]

On Mon, Jan 29, 2018 at 07:21:09PM +0100, Markus Demleitner wrote:
> Hi,
> 
> A while ago I opened bug #197863 in the kernel bugzilla:
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=197863
> 
> Essentially, xhci_hcd on a resume from RAM takes several seconds on a
> Thinkpad X240 that is equipped with a Sierra LTE modem after an
> upgrade to 4.13:
> 
> On Mon, Nov 20, 2017 at 11:24:09AM +, bugzilla-dae...@bugzilla.kernel.org 
> wrote:
> > https://bugzilla.kernel.org/show_bug.cgi?id=197863
> > 
> > --- Comment #2 from Greg Kroah-Hartman (g...@kroah.com) ---
> > On Mon, Nov 20, 2017 at 09:02:46AM +, 
> > bugzilla-dae...@bugzilla.kernel.org
> > wrote:
> > > I think your speculation is right, the xhci has taken too much time for a
> > > reset:
> > > [   39.292052] usb 1-4: reset high-speed USB device number 2 using 
> > > xhci_hcd
> > > [   45.812046] usb 1-4: device descriptor read/64, error -110
> > > [   46.262082] usb 1-7: reset full-speed USB device number 3 using 
> > > xhci_hcd
> > > I don't know if it should be reset in this case, let me switch to usb
> > > component for suggestion.
> > 
> > All USB bugs should be sent to the linux-usb@vger.kernel.org mailing
> > list, and not entered into bugzilla.  Please bring this issue up there,
> > if it is still a problem in the latest kernel release.
> 
> The trouble persists in 4.15.0, and wakeup keeps being fast in 4.12.X.
> 
> I have just looked at things a bit more closely, and it would seem
> the changes are due to the USB subsystem blocking until the (slow)
> LTE modem sends an all clear.
> 
> Here's a dmesg excerpt from 4.15.0 slow resume:
> 
> 
> [  417.234716] ACPI: Low-level resume complete
> ...about 30 lines of non-USB jabber elided here...
> [  419.184328] usb usb1: root hub lost power or was reset
> [  419.184332] usb usb2: root hub lost power or was reset
> [  419.463469] usb 3-1: reset high-speed USB device number 2 using ehci-pci
> [  419.583449] usb 1-8: reset high-speed USB device number 4 using xhci_hcd
> [  419.588769] psmouse serio1: synaptics: queried min coordinates: x 
> [1232..], y [1216..]
> [  419.821258] restoring control ----0101/0/2
> [  419.913513] usb 1-4: reset high-speed USB device number 9 using xhci_hcd
> ...this is when the system hangs; the screen is on, but now wakeup
> actions are executed until...
> [  427.343486] usb 1-4: device descriptor read/64, error -110
> [  427.662438] OOM killer enabled.
> [  427.662440] Restarting tasks ... done.
> [  427.683062] PM: suspend exit
> 
> If you look at the corresponding sequence in 4.12.2:
> 
> [   31.678001] usb 1-4: reset high-speed USB device number 2 using xhci_hcd
> [   31.848202] usb 1-4: device firmware changed
> [   31.988048] usb 1-7: reset full-speed USB device number 3 using xhci_hcd
> [   32.159069] PM: resume of devices complete after 1170.527 msecs
> [   32.159546] OOM killer enabled.
> [   32.159548] Restarting tasks ... 
> [   32.159650] usb 1-4: USB disconnect, device number 2
> [   32.162274] done.
> [   32.297920] usb 1-4: new high-speed USB device number 5 using xhci_hcd
> [   32.469119] usb 1-4: New USB device found, idVendor=8087, idProduct=0716
> [   32.469124] usb 1-4: New USB device strings: Mfr=0, Product=0, 
> SerialNumber=0
> [   35.639922] usb 1-4: USB disconnect, device number 5
> [   38.438173] usb 1-4: new high-speed USB device number 6 using xhci_hcd
> [   38.616527] usb 1-4: New USB device found, idVendor=1199, idProduct=a001
> [   38.616535] usb 1-4: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=3
> [   38.616539] usb 1-4: Product: Sierra Wireless EM7345 4G LTE
> [   38.616543] usb 1-4: Manufacturer: Sierra Wireless Inc.
> [   38.616545] usb 1-4: SerialNumber: 013937002544516
> 
> ...it seems that the resume of the Sierra card happens
> "aynchronously", if you will.  In the "slow" cases, I just notice, no
> messages about the Sierra Wireless card appear in dmesg, but the
> modem still works.
> 
> Now, interestingly, there are quick resumes in 4.15.0, too, now and
> then.  In that case, things look pretty much like on 4.12.2.  Here's
> a 4.15.0 fast resume example:
> 
> [  873.127570] usb 1-4: device firmware changed
> [  873.277351] usb 1-8: reset high-speed USB device number 4 using xhci_hcd
> [  873.515141] restoring control ----0101/0/2
> [  873.583238] OOM killer enabled.
> [  873.583240] Restarting tasks ... 
> [  873.583339] usb 1-4: USB disconnect, device number 10
> [  873.586356] done.
> [  873.604420] PM: suspend exit
> [  873.737283] usb 1-4: new high-speed USB device number 11 using xhci_hcd
> [  880.867398] usb 1-4: device descriptor read/64, error -110
> [  881.175558] usb 1-4: New USB device found, idVendor=1199, idProduct=a001
> [  881.175563] usb 1-4: New USB device strings: Mfr=1, Product=2, 
> SerialNumber=3
> [  881.175566] usb 1-4: Product: Sierra Wireless EM7345 4G LTE
> [  881.175568] usb 1-4: Manufacturer: Sierra Wireless Inc.
> [  881.175570] 

Re: how to disable a xhci logical port?

[Chunfeng Yun]

Hi Bin,

On Mon, 2018-01-29 at 08:32 -0600, Bin Liu wrote:
> On Sat, Jan 27, 2018 at 09:20:56AM +0100, Greg KH wrote:
> > On Fri, Jan 26, 2018 at 12:56:26PM -0600, Bin Liu wrote:
> > > Hi,
> > > 
> > > A xHCI controller has two logical ports, hs and ss port. Is it
> > > possible to disable one port, for example the ss port? If so, how?
> > 
> > Why would you want to do that?
> 
> On the device I have (TI AM57x), PCIe and USB share the ss PHY. Now I am
> trying to figure out how to let PCIe use the ss PHY and disable it in
> USB.
> 
> Simply removing the ss PHY nodes from USB in devicetree causes kernel
> crashes at boot (but the crash log doesn't directly link to USB
> subsystem), so I wanted to ask how to disable the xhci ss roothub before
> I dig into the crash.
Maybe it's helpful to disable u3port with shared PHY but not SS roothub.

> 
> > 
> > > By disable, I meant the xHCI driver doesn't see the port when the xHCI
> > > driver is loaded and doesn't create that usb bus.
> > 
> > That goes against the spec for the hardware from what I can tell.
> 
> Okay, I will look into it from a different direction - focus on the
> crash log.
> 
> Thanks,
> -Bin.
> --
> 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: Problem with xhci_hcd on Gigabyte Z170X Gaming 7-EK

[Herbert Poetzl]

On Mon, Jan 29, 2018 at 02:26:52PM +0200, Mathias Nyman wrote:
> On 20.01.2018 06:20, Herbert Poetzl wrote:

>> I've recently acquired a Gigabyte Z170X Gaming 7-EK motherboard
>> with the Intel Z170 chipset and Sunrise Point-H USB 3.0 xHCI
>> Controller for running Linux.

>> Now most things seem to work fine (some problems with UEFI but
>> that was kind of expected), but the xhci_hcd module is filling
>> up my log files with a repeated message (ever 4 seconds):

>>   [ 2137.036187] usb usb2-port1: Cannot enable. Maybe the USB cable is 
>>   bad?
>>   [ 2137.036981] xhci_hcd :00:14.0: Cannot set link state.
>>   [ 2137.037767] usb usb2-port1: cannot disable (err = -32)

>> Now I have no idea where usb2-port1 is or why it should have a
>> bad cable, the only USB devices I know of are the USB drive
>> I've booted the system from and the wireless keyboard/mouse
>> combo I'm using.

>> Both seem to work just fine and plugging those into different
>> USB ports doesn't change the message.

>>   Bus 002 Device 002: ID 1b1c:1a00 Corsair
>>   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
>>   Bus 001 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver
>>   Bus 001 Device 002: ID 045b:0209 Hitachi, Ltd
>>   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

>> Note: I have no idea what the Hitachi device is.

>> The current kernel is 4.14.13 (from Mageia 6).

>> Any idea what the problem here is and how I can fix or work
>> around it?

>> Please let me know if you need any additional information on
>> the system or environment.

> lsusb -v could show more details about the misbehaving device.

> Output of dmesg could tell something as well

During testing I found out that there is a correlation between
the BIOS and the observed error. 

When I unplug the power supply for a few seconds, the problem
will completely disappear until the next time I enter the BIOS
and change something there (doesn't matter what and doesn't
affect the result).

It also seems to be related to the 'mystical' Hitachi device
I couldn't figure out what it is for or why it sits on each
USB bus.

You can find all the suggested output here ...

http://vserver.13thfloor.at/Stuff/XHCI_HCD/

where 'failing' means that the problem is present and 'working'
means that everything seems fine.

Many thanks in advance,
Herbert

> -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

Re: [PATCH 5/5] USB: serial: f81232: fix bulk_in/out size

[Johan Hovold]

On Mon, Jan 22, 2018 at 03:58:47PM +0800, Ji-Ze Hong (Peter Hong) wrote:
> Fix Fintek F81232 bulk_in/out size to 64/16 according to the spec.
> http://html.alldatasheet.com/html-pdf/406315/FINTEK/F81232/1762/8/F81232.html
> 
> Signed-off-by: Ji-Ze Hong (Peter Hong) 
> ---
>  drivers/usb/serial/f81232.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
> index a054f69446fd..f3ee537d643c 100644
> --- a/drivers/usb/serial/f81232.c
> +++ b/drivers/usb/serial/f81232.c
> @@ -769,8 +769,7 @@ static struct usb_serial_driver f81232_device = {
>   },
>   .id_table = id_table,
>   .num_ports =1,
> - .bulk_in_size = 256,
> - .bulk_out_size =256,
> + .bulk_out_size =16,

These fields control the URB buffer sizes and defaults to the corresponding
endpoint max-packet size, which would be 16 for all endpoints according
to the datasheet above.

So it seems you should really be setting bulk_in_size to 64 here (and
possibly leave bulk_out_size unset) as that would appear to match your
device buffer sizes.

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/5] USB: serial: f81232: enable remote wakeup via RX/RI pin

[Johan Hovold]

On Mon, Jan 22, 2018 at 03:58:45PM +0800, Ji-Ze Hong (Peter Hong) wrote:
> The F81232 can do remote wakeup via RX/RI pin with pulse.
> This patch will use device_set_wakeup_enable to enable this
> feature.

This is a policy decision that should be made by user space by setting
the power/wakeup attribute, and not something that something that
drivers should enable directly themselves.

Perhaps you really wanted to use device_set_wakeup_capable()? But then
you also need to honour the current setting in suspend() as well.

How have you tested this feature?

Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/5] USB: serial: f81232: add high baud rate support

[Johan Hovold]

On Tue, Jan 23, 2018 at 10:08:24AM +0800, Ji-Ze Hong (Peter Hong) wrote:
> Hi Andy,
> 
> Andy Shevchenko 於 2018/1/22 下午 10:55 寫道:
> > On Mon, Jan 22, 2018 at 9:58 AM, Ji-Ze Hong (Peter Hong)
> >  wrote:
> >> The F81232 had 4 clocksource 1.846/18.46/14.77/24MHz and baud rates
> >> can be up to 1.5Mbits with 24MHz.
> >>
> >> F81232 Clock registers (106h)
> >>
> >> Bit1-0: Clock source selector
> >>  00: 1.846MHz.
> >>  01: 18.46MHz.
> >>  10: 24MHz.
> >>  11: 14.77MHz.
> > 
> > Hmm... Why not to provide a proper clk driver (based on table variant
> > of clk-divider) and use it here?
> 
> It seems too complex to use clock framework in this driver.
> What do you think about this, Johan ?

Yeah, you don't need to implement a clk driver for this. If anyone
thinks that would simplify things, I'd be happy to consider it as a
follow-on patch.

Thanks,
Johan
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] dt-bindings: dwc3: add binding documentation for UniPhier dwc3 glue driver

[Rob Herring]

On Tue, Jan 23, 2018 at 10:00:51PM +0900, Kunihiko Hayashi wrote:
> Add devicetree binding documentation for dwc3 glue driver implemented
> on Socionext UniPhier SoCs.
> 
> Signed-off-by: Kunihiko Hayashi 
> ---
>  .../devicetree/bindings/usb/dwc3-uniphier.txt  | 58 
> ++
>  1 file changed, 58 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/usb/dwc3-uniphier.txt
> 
> diff --git a/Documentation/devicetree/bindings/usb/dwc3-uniphier.txt 
> b/Documentation/devicetree/bindings/usb/dwc3-uniphier.txt
> new file mode 100644
> index 000..677e072
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/dwc3-uniphier.txt
> @@ -0,0 +1,58 @@
> +UniPhier DWC3 glue layer
> +
> +This describes the devicetree bindings for dwc3-uniphier driver implemented 
> on
> +Socionext UniPhier SoCs.
> +
> +Required properties:
> +- compatible:
> +  - "socionext,uniphier-pxs2-dwc3" : For UniPhier PXs2 SoC
> +  - "socionext,uniphier-ld20-dwc3" : For UniPhier LD20 SoC
> +- reg: Address and range of the glue logic
> +- clocks: List of phandles for the clocks, and the number of phandles depends
> +   on SoC platform.

Number of clocks needs to be specific. It should be fixed per 
compatible.

> +
> +Optional properties:
> +- resets: List of phandles for the resets, and the number of phandles depends
> + on SoC platform.

Same here.

> +- nvmem-cells: Phandles to nvmem cell that contains the trimming data.
> + Available only for LD20, and if unspecified, default value is used.
> +- nvmem-cell-names: Should be the following names, which correspond to each
> + nvmem-cells. N is the number indicating a port of phy.
> + All of the 3 parameters associated with the following names are
> + required for each port, if any one is omitted, the trimming data
> + of the port will not be set at all.
> + - "rtermN", "sel_tN", "hs_iN" : Each cell name for phy parameters
> +
> +Required child node:
> +A child node must exist to represent the core DWC3 IP block. The name of
> +the node is not important. The content of the node is defined in dwc3.txt.
> +
> +Example:
> +
> + usb: usb@65b0 {
> + compatible = "socionext,uniphier-ld20-dwc3";
> + reg = <0x65b0 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + clocks = <_clk 14>, <_clk 16>, <_clk 17>;
> + resets = <_rst 12>, <_rst 16>, <_rst 17>,
> +  <_rst 18>, <_rst 19>;
> + nvmem-cells = <_rterm0>, <_rterm1>,
> +   <_rterm2>, <_rterm3>,
> +   <_sel_t0>, <_sel_t1>,
> +   <_sel_t2>, <_sel_t3>,
> +   <_hs_i0>,  <_hs_i0>,
> +   <_hs_i2>,  <_hs_i2>;
> + nvmem-cell-names = "rterm0", "rterm1", "rterm2", "rterm3",
> +"sel_t0", "sel_t1", "sel_t2", "sel_t3",
> +"hs_i0",  "hs_i1",  "hs_i2",  "hs_i3";
> + ranges;
> +
> + dwc3@65a0 {
> + compatible = "snps,dwc3";
> + reg = <0x65a0 0xcd00>;
> + interrupt-names = "host";
> + interrupts = <0 134 4>;
> + dr_mode = "host";
> + };
> + };
> -- 
> 2.7.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 08/15] usb: dwc3: Make TX/RX threshold configurable

[Thinh Nguyen]

Hi,

On 1/29/2018 10:46 AM, Rob Herring wrote:
> On Wed, Jan 17, 2018 at 05:57:15PM -0800, Thinh Nguyen wrote:
>> DWC_usb31 periodic transfer at 48K+ bytes per interval may need
>> modification to the TX/RX packet threshold to achieve optimal result.
>> Add properties to make it configurable.
>>
>> Cc: John Youn 
>> Signed-off-by: Thinh Nguyen 
>> ---
>>   Documentation/devicetree/bindings/usb/dwc3.txt | 4 
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
>> b/Documentation/devicetree/bindings/usb/dwc3.txt
>> index 52fb41046b34..a532fa6bf884 100644
>> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
>> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
>> @@ -55,6 +55,10 @@ Optional properties:
>>- snps,quirk-frame-length-adjustment: Value for GFLADJ_30MHZ field of 
>> GFLADJ
>>  register for post-silicon frame length adjustment when the
>>  fladj_30mhz_sdbnd signal is invalid or incorrect.
>> + - snps,rx-thr-num-pkt-prd: periodic ESS RX packet threshold count.
>> + - snps,rx-max-burst-prd: Max periodic ESS RX burst size.
>> + - snps,tx-thr-num-pkt-prd: periodic ESS TX packet threshold count.
>> + - snps,tx-max-burst-prd: Max periodic ESS TX burst size.
> 
> What are the defaults if not set?
> 

By default, periodic ESS TX and RX threshold are not enabled. To enable 
TX or RX threshold, both packet threshold count and max burst size must 
be set to a non-zero value.

Unfortunately, I did not document it in this file after I made a change 
to remove the enabling of TX/RX threshold property. I can update this 
patch series with this information. Thanks.

BR,
Thinh
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4.9] usbip: vhci_hcd: clear just the USB_PORT_STAT_POWER bit

[Shuah Khan]

On 01/28/2018 05:14 AM, Greg KH wrote:
> On Fri, Jan 26, 2018 at 11:54:35AM -0700, Shuah Khan wrote:
>> Upstream commit 1c9de5bf4286 ("usbip: vhci-hcd: Add USB3 SuperSpeed
>> support")
> 
> Hm, I think you have the wrong commit id here.
> 
> I don't see any commit upstream with the Subject you have here, what are
> you referring to?
> 
> thanks,
> 
> greg k-h
> 

That is odd. Th commit went in a while back. Here are the details:

This is the commit from upstream:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/usbip/vhci_hcd.c?id=1c9de5bf428612458427943b724bea51abde520a

commit 1c9de5bf428612458427943b724bea51abde520a
Author: Yuyang Du 
Date:   Thu Jun 8 13:04:10 2017 +0800

usbip: vhci-hcd: Add USB3 SuperSpeed support

This patch adds a USB3 HCD to an existing USB2 HCD and provides
the support of SuperSpeed, in case the device can only be enumerated
with SuperSpeed.

The bulk of the added code in usb3_bos_desc and hub_control to support
SuperSpeed is borrowed from the commit 1cd8fd2887e162ad ("usb: gadget:
dummy_hcd: add SuperSpeed support").

With this patch, each vhci will have VHCI_HC_PORTS HighSpeed ports
and VHCI_HC_PORTS SuperSpeed ports.

Suggested-by: Krzysztof Opasiak 
Signed-off-by: Yuyang Du 
Acked-by: Shuah Khan 
Signed-off-by: Greg Kroah-Hartman 


I isolated and backported a one line fix to the problem I saw in 4.9
and 4.4 stables.

thanks,
-- Shuah
--
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 TYPEC: RT1711H Type-C Chip Driver

[Guenter Roeck]

On Mon, Jan 29, 2018 at 07:19:06AM +, shufan_lee(李書帆) wrote:
> Hi Guenter,
> 
>   We try to use the TCPCI driver on RT1711H and here are some questions.
> 
>   Q1. Is current TCPCI driver written according to TypeC Port Controller 
> Interface Specification Revision 1.0 & Version 1.2?

Revision 1.0. Note that I did not find revision 1.2, only
Revision 1.0 and Revision 2.0 version 1.0.

>   Q2. Because 0x80~0xFF are vendor defined registers. Some of them are needed 
> to be initialized in tcpci_init for RT1711H (or other chips also).
> In the future TCPCI driver, will an initial interface that is called in 
> tcpci_init be released for different vendors to implement.

My suggestion would be to provide an API for vendor specific code.

> Or, we should directly copy tcpci.c to tcpci_rt1711h.c and add the different 
> parts?

That would defeat the purpose. It would be better to implement vendor
specific code in tcpci_rt1711h.c and call it from tcpci.c

Possible example:

struct tcpci_vendor_data {
int (*init)(...);
int (*irq_handler)(...);
...
}

static irqreturn_t tcpci_irq(...)
{
struct tcpci *tcpci = dev_id;

...
if (tcpci->vendor_data->irq_handler) {
ret = (*tcpci->vendor_data->irq_handler)(...);
...
}
...
}

tcpci_init()
{
struct tcpci_vendor_data *vendor_data = _rt1711h_data;
// eg from devicetree compatible property

...
if (vendor_data->init) {
ret = (*vendor_data->init)(...);
if (ret)
return ret;
}
...
}

>   Q3. If there are IRQs defined in vendor defined registers, will an 
> interface that is called in tcpci_irq be released for different vendors to 
> implement.
> So that they can handle their own IRQs first?

If there are vendor specific interrupts, I would assume that vendor specific
code will have to be called. Either the generic interrupt handler can call
vendor specific code, or the vendor specific code handles the interrupt and
calls the generic handler. I don't know at this point which one is better.

> If the suggestion of Q2 is to copy tcpci.c to tcpci_rt1711h.c, then Q3 will 
> not be a problem.
>   Q4. According to TCPCI Specification Revision 1.0, we should set DRP = 1 
> and role to Rp/Rp or Rd/Rd and set LOOK4CONNECTION command to start toggle.
> So we modify the tcpci_start_drp_toggling in TCPCI driver as following. Here 
> we write Rd/Rd and DRP = 0 simultaneously so that Rd/Rd takes effect.
> Then we write DRP = 1 and set LOOK4CONNECTION command to start toggling.
> 
SGTM.

> static int tcpci_start_drp_toggling(struct tcpc_dev *tcpc,
>  enum typec_cc_status cc)
>  {
> +int ret = 0;
>  struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
> -unsigned int reg = TCPC_ROLE_CTRL_DRP;
> +u32 reg = (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC1_SHIFT) |
> +(TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC2_SHIFT);
> 
>  switch (cc) {
>  default:
> @@ -125,8 +672,19 @@ static int tcpci_start_drp_toggling(stru
>  TCPC_ROLE_CTRL_RP_VAL_SHIFT);
>  break;
>  }
> -
> -return regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
> +ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
> +if (ret < 0)
> +return ret;
> +mdelay(1);

That is bad; you don't want to hold up teh system for that much.
Try to use usleep_range().

> +reg |= TCPC_ROLE_CTRL_DRP;
> +ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
> +if (ret < 0)
> +return ret;
> +ret = regmap_write(tcpci->regmap, TCPC_COMMAND,
> +TCPC_CMD_LOOK4CONNECTION);
> +if (ret < 0)
> +return ret;
> +return 0;
>  }
> 
>   Q5. The tcpci_set_vbus in TCPCI driver uses command to control Sink/Source 
> VBUS.
> If our chip does not support power path, i.e. Sink & Source are controlled by 
> other charger IC. Our chip will do nothing while setting these commands.
> In the future TCPCI driver, will a framework be applied to notify these 
> events. i.g. power_supply or notifier.
> 
I would think so.

Note that the driver is, at this point, fair game to change to
make it work with your chip. The only condition is that a standard
chip should still work, ie you should not make any changes which
would cause the driver to _only_ work with your chip. Everything else
is fair game.

Thanks,
Guenter
--
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 08/15] usb: dwc3: Make TX/RX threshold configurable

[Rob Herring]

On Wed, Jan 17, 2018 at 05:57:15PM -0800, Thinh Nguyen wrote:
> DWC_usb31 periodic transfer at 48K+ bytes per interval may need
> modification to the TX/RX packet threshold to achieve optimal result.
> Add properties to make it configurable.
> 
> Cc: John Youn 
> Signed-off-by: Thinh Nguyen 
> ---
>  Documentation/devicetree/bindings/usb/dwc3.txt | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
> b/Documentation/devicetree/bindings/usb/dwc3.txt
> index 52fb41046b34..a532fa6bf884 100644
> --- a/Documentation/devicetree/bindings/usb/dwc3.txt
> +++ b/Documentation/devicetree/bindings/usb/dwc3.txt
> @@ -55,6 +55,10 @@ Optional properties:
>   - snps,quirk-frame-length-adjustment: Value for GFLADJ_30MHZ field of GFLADJ
>   register for post-silicon frame length adjustment when the
>   fladj_30mhz_sdbnd signal is invalid or incorrect.
> + - snps,rx-thr-num-pkt-prd: periodic ESS RX packet threshold count.
> + - snps,rx-max-burst-prd: Max periodic ESS RX burst size.
> + - snps,tx-thr-num-pkt-prd: periodic ESS TX packet threshold count.
> + - snps,tx-max-burst-prd: Max periodic ESS TX burst size.

What are the defaults if not set?
--
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 197863] Thinkpad X240 resume dramatically slower on kernels 4.13+

[Markus Demleitner]

Hi,

A while ago I opened bug #197863 in the kernel bugzilla:

https://bugzilla.kernel.org/show_bug.cgi?id=197863

Essentially, xhci_hcd on a resume from RAM takes several seconds on a
Thinkpad X240 that is equipped with a Sierra LTE modem after an
upgrade to 4.13:

On Mon, Nov 20, 2017 at 11:24:09AM +, bugzilla-dae...@bugzilla.kernel.org 
wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=197863
> 
> --- Comment #2 from Greg Kroah-Hartman (g...@kroah.com) ---
> On Mon, Nov 20, 2017 at 09:02:46AM +, bugzilla-dae...@bugzilla.kernel.org
> wrote:
> > I think your speculation is right, the xhci has taken too much time for a
> > reset:
> > [   39.292052] usb 1-4: reset high-speed USB device number 2 using xhci_hcd
> > [   45.812046] usb 1-4: device descriptor read/64, error -110
> > [   46.262082] usb 1-7: reset full-speed USB device number 3 using xhci_hcd
> > I don't know if it should be reset in this case, let me switch to usb
> > component for suggestion.
> 
> All USB bugs should be sent to the linux-usb@vger.kernel.org mailing
> list, and not entered into bugzilla.  Please bring this issue up there,
> if it is still a problem in the latest kernel release.

The trouble persists in 4.15.0, and wakeup keeps being fast in 4.12.X.

I have just looked at things a bit more closely, and it would seem
the changes are due to the USB subsystem blocking until the (slow)
LTE modem sends an all clear.

Here's a dmesg excerpt from 4.15.0 slow resume:


[  417.234716] ACPI: Low-level resume complete
...about 30 lines of non-USB jabber elided here...
[  419.184328] usb usb1: root hub lost power or was reset
[  419.184332] usb usb2: root hub lost power or was reset
[  419.463469] usb 3-1: reset high-speed USB device number 2 using ehci-pci
[  419.583449] usb 1-8: reset high-speed USB device number 4 using xhci_hcd
[  419.588769] psmouse serio1: synaptics: queried min coordinates: x [1232..], 
y [1216..]
[  419.821258] restoring control ----0101/0/2
[  419.913513] usb 1-4: reset high-speed USB device number 9 using xhci_hcd
...this is when the system hangs; the screen is on, but now wakeup
actions are executed until...
[  427.343486] usb 1-4: device descriptor read/64, error -110
[  427.662438] OOM killer enabled.
[  427.662440] Restarting tasks ... done.
[  427.683062] PM: suspend exit

If you look at the corresponding sequence in 4.12.2:

[   31.678001] usb 1-4: reset high-speed USB device number 2 using xhci_hcd
[   31.848202] usb 1-4: device firmware changed
[   31.988048] usb 1-7: reset full-speed USB device number 3 using xhci_hcd
[   32.159069] PM: resume of devices complete after 1170.527 msecs
[   32.159546] OOM killer enabled.
[   32.159548] Restarting tasks ... 
[   32.159650] usb 1-4: USB disconnect, device number 2
[   32.162274] done.
[   32.297920] usb 1-4: new high-speed USB device number 5 using xhci_hcd
[   32.469119] usb 1-4: New USB device found, idVendor=8087, idProduct=0716
[   32.469124] usb 1-4: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[   35.639922] usb 1-4: USB disconnect, device number 5
[   38.438173] usb 1-4: new high-speed USB device number 6 using xhci_hcd
[   38.616527] usb 1-4: New USB device found, idVendor=1199, idProduct=a001
[   38.616535] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   38.616539] usb 1-4: Product: Sierra Wireless EM7345 4G LTE
[   38.616543] usb 1-4: Manufacturer: Sierra Wireless Inc.
[   38.616545] usb 1-4: SerialNumber: 013937002544516

...it seems that the resume of the Sierra card happens
"aynchronously", if you will.  In the "slow" cases, I just notice, no
messages about the Sierra Wireless card appear in dmesg, but the
modem still works.

Now, interestingly, there are quick resumes in 4.15.0, too, now and
then.  In that case, things look pretty much like on 4.12.2.  Here's
a 4.15.0 fast resume example:

[  873.127570] usb 1-4: device firmware changed
[  873.277351] usb 1-8: reset high-speed USB device number 4 using xhci_hcd
[  873.515141] restoring control ----0101/0/2
[  873.583238] OOM killer enabled.
[  873.583240] Restarting tasks ... 
[  873.583339] usb 1-4: USB disconnect, device number 10
[  873.586356] done.
[  873.604420] PM: suspend exit
[  873.737283] usb 1-4: new high-speed USB device number 11 using xhci_hcd
[  880.867398] usb 1-4: device descriptor read/64, error -110
[  881.175558] usb 1-4: New USB device found, idVendor=1199, idProduct=a001
[  881.175563] usb 1-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  881.175566] usb 1-4: Product: Sierra Wireless EM7345 4G LTE
[  881.175568] usb 1-4: Manufacturer: Sierra Wireless Inc.
[  881.175570] usb 1-4: SerialNumber: 013937002544516

Any guess what might be behind this?

Thanks,

  Markus

--
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  

[PATCH] Add delay-init quirk for Corsair K70 RGB keyboards

[JackStocker]

From: Jack Stocker 

Following on from this patch: https://lkml.org/lkml/2017/11/3/516,
Corsair K70 RGB keyboards also require the DELAY_INIT quirk to
start correctly at boot.

Device ids found here:
usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13
usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-3: Product: Corsair K70 RGB Gaming Keyboard 

Signed-off-by: Jack Stocker 
---
 drivers/usb/core/quirks.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/usb/core/quirks.c b/drivers/usb/core/quirks.c
index a6aaf2f..9eb92dc 100644
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -221,6 +221,9 @@ static const struct usb_device_id usb_quirk_list[] = {
/* Corsair Strafe RGB */
{ USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
 
+   /* Corsair K70 RGB */
+   { USB_DEVICE(0x1b1c, 0x1b13), .driver_info = USB_QUIRK_DELAY_INIT },
+
/* MIDI keyboard WORLDE MINI */
{ USB_DEVICE(0x1c75, 0x0204), .driver_info =
USB_QUIRK_CONFIG_INTF_STRINGS },
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: how to disable a xhci logical port?

[Bin Liu]

On Sat, Jan 27, 2018 at 09:20:56AM +0100, Greg KH wrote:
> On Fri, Jan 26, 2018 at 12:56:26PM -0600, Bin Liu wrote:
> > Hi,
> > 
> > A xHCI controller has two logical ports, hs and ss port. Is it
> > possible to disable one port, for example the ss port? If so, how?
> 
> Why would you want to do that?

On the device I have (TI AM57x), PCIe and USB share the ss PHY. Now I am
trying to figure out how to let PCIe use the ss PHY and disable it in
USB.

Simply removing the ss PHY nodes from USB in devicetree causes kernel
crashes at boot (but the crash log doesn't directly link to USB
subsystem), so I wanted to ask how to disable the xhci ss roothub before
I dig into the crash.

> 
> > By disable, I meant the xHCI driver doesn't see the port when the xHCI
> > driver is loaded and doesn't create that usb bus.
> 
> That goes against the spec for the hardware from what I can tell.

Okay, I will look into it from a different direction - focus on the
crash log.

Thanks,
-Bin.
--
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] SD card reader disappears after suspend

[Mathias Nyman]

On 25.01.2018 17:51, Alan Stern wrote:

On Thu, 25 Jan 2018, Samuel Sadok wrote:


2018-01-23 17:31 GMT+01:00 Alan Stern :

On Tue, 23 Jan 2018, Samuel Sadok wrote:


Thanks Alan,

While I was at it I also enabled debug logs for xhci_hcd and xhci_pci.

$ echo module usbcore =p > /sys/kernel/debug/dynamic_debug/control
$ echo module xhci_hcd =p > /sys/kernel/debug/dynamic_debug/control
$ echo module xhci_pci =p > /sys/kernel/debug/dynamic_debug/control
$ modprobe usbmon
$ cat /sys/kernel/debug/usb/usbmon/0u > /tmp/usbmon.log
$ # press power button

dmesg: https://gist.github.com/anonymous/29b81574abf40605f999cfeefe98e341
usbmon: https://gist.github.com/anonymous/55b6d9bbf8b8c8627230b10d2b09dcb6

Both logs were collected at the same time so the timestamps should match.


In fact they do, quite closely.  But there is a noticeable gap in the
usbmon trace, between lines 197 and 198 (the timestamp jumps from
35923531 to 38925126) and there obviously was a lot of activity on bus
1 in between.


Yes you're right, that's inconvenient because the "failed to disable
LTM" message occurs exactly in this gap. Are gaps like this expected /
known? Any ideas on how to mitigate them? (I kinda want to avoid
soldering an external bus monitor to the mainboard :) )


The text interface to usbmon uses a fixed-size buffer, and the size is
a little on the low side if you're dealing with large latencies (which
of course are unavoidable during a suspend/resume scenario).  The size
is determined by EVENT_MAX, defined around line 40 in
drivers/usb/mon/mon_text.c:

#define EVENT_MAX  (4*PAGE_SIZE / sizeof(struct mon_event_text))

Just change the 4 to something considerably larger and you should be in
good shape.


Resume starts at dmesg line 1255.
As far as I can judge, the earliest indication of something going
wrong is line 1514:
[ 36.087176] xhci_hcd :00:14.0: xHCI xhci_urb_enqueue called with
unaddressed device
[ 36.087180] usb 2-4: Disable of device-initiated U1 failed.
[ 36.087212] xhci_hcd :00:14.0: xHCI xhci_urb_enqueue called with
unaddressed device
[ 36.087224] usb 2-4: Disable of device-initiated U2 failed.
[ 36.087226] xhci_hcd :00:14.0: xHCI xhci_urb_enqueue called with
unaddressed device
[ 36.087227] usb 2-4: usb_reset_and_verify_device Failed to disable LTM


Yes, that's where the problem first seems to show up.  Apparently
usb_disable_ltm() fails because it can't communicate with the device,
and usb_reset_and_verify_device() then aborts because of that failure.
It shouldn't do this; after all, one very good reason for resetting the
device is because we're unable to communicate with it.

You could try editing the source code for usb_reset_and_verify_device()
in drivers/usb/core/hub.c, to see what happens if it doesn't give up
after usb_disable_ltm() fails.


For the following logs I modified the "Failed to disable LTM" message
and commented out the goto in the line below. Also I used kernel
version 4.15-rc9 this time. I omitted upgrading the out-of-tree
modules broadcom-wl and nouveau-fw, so don't mind errors related to
that.
The SD card reader is still missing after resume.

dmesg & usbmon:
https://gist.github.com/anonymous/fc597612d5ebbac40d7bef9f8f0b579a

`usb_reset_and_verify_device()` is executed around dmesg line 1524.
Again, the usbmon log has a major gap around that time.


It looks like the system is trying to carry out multiple warm resets,
or a single extremely long warm reset, when it really should give up
and do a cold reset instead.

It would be best to get Mathias's input on this.  I don't know what is
the right way to fix this problem.

Alan Stern



Just back form a week long sickleave, sorry about the delay.

First glance it looks like we end up in compliance mode a lot during
those warm resets.
I need to look at this in more detail

-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

Re: dvb usb issues since kernel 4.9

[Mauro Carvalho Chehab]

Em Fri, 26 Jan 2018 17:37:39 -0200
Mauro Carvalho Chehab  escreveu:

> Em Fri, 26 Jan 2018 12:17:37 -0200
> Mauro Carvalho Chehab  escreveu:
> 
> > Hi Alan,
> > 
> > Em Mon, 8 Jan 2018 14:15:35 -0500 (EST)
> > Alan Stern  escreveu:
> >   
> > > On Mon, 8 Jan 2018, Linus Torvalds wrote:
> > > 
> > > > Can somebody tell which softirq it is that dvb/usb cares about?  
> > > 
> > > I don't know about the DVB part.  The USB part is a little difficult to
> > > analyze, mostly because the bug reports I've seen are mostly from
> > > people running non-vanilla kernels. 
> > 
> > I suspect that the main reason for people not using non-vanilla Kernels
> > is that, among other bugs, the dwc2 upstream driver has serious troubles
> > handling ISOCH traffic.
> > 
> > Using Kernel 4.15-rc7 from this git tree:
> > https://git.linuxtv.org/mchehab/experimental.git/log/?h=softirq_fixup
> > 
> > (e. g. with the softirq bug partially reverted with Linux patch, and
> >  the DWC2 deferred probe fixed)
> > 
> > With a PCTV 461e device, with uses em28xx driver + Montage frontend
> > (with is the same used on dvbsky hardware - except for em28xx).
> > 
> > This device doesn't support bulk for DVB, just ISOCH. The drivers work 
> > fine on x86.
> > 
> > Using a test signal at the bit rate of 56698,4 Kbits/s, that's what
> > happens, when capturing less than one second of data:
> > 
> > $ dvbv5-zap -c ~/dvb_channel.conf "tv brasil" -l universal -X 100 -m 
> > -t2dvbv5-zap -c ~/dvb_channel.conf "tv brasil" -l universal -X 100 -m -t2
> > Using LNBf UNIVERSAL
> > Universal, Europe
> > Freqs : 10800 to 11800 MHz, LO: 9750 MHz
> > Freqs : 11600 to 12700 MHz, LO: 10600 MHz
> > using demux 'dvb0.demux0'
> > reading channels from file '/home/mchehab/dvb_channel.conf'
> > tuning to 11468000 Hz
> >(0x00) Signal= -33.90dBm
> > Lock   (0x1f) Signal= -33.90dBm C/N= 30.28dB postBER= 2.33x10^-6
> > dvb_dev_set_bufsize: buffer set to 6160384
> >   dvb_set_pesfilter to 0x2000
> > 354.08s: Starting capture
> > 354.73s: only read 59220 bytes
> > 354.73s: Stopping capture
> > 
> > [  354.000827] dwc2 3f98.usb: DWC OTG HCD EP DISABLE: 
> > bEndpointAddress=0x84, ep->hcpriv=116f41b2
> > [  354.000859] dwc2 3f98.usb: DWC OTG HCD EP RESET: 
> > bEndpointAddress=0x84
> > [  354.010744] dwc2 3f98.usb: --Host Channel 5 Interrupt: Frame 
> > Overrun--
> > ... (hundreds of thousands of Frame Overrun messages)
> > [  354.660857] dwc2 3f98.usb: --Host Channel 5 Interrupt: Frame 
> > Overrun--
> > [  354.660935] dwc2 3f98.usb: DWC OTG HCD URB Dequeue
> > [  354.660959] dwc2 3f98.usb: Called usb_hcd_giveback_urb()
> > [  354.660966] dwc2 3f98.usb:   urb->status = 0
> > [  354.660992] dwc2 3f98.usb: DWC OTG HCD URB Dequeue
> > [  354.661001] dwc2 3f98.usb: Called usb_hcd_giveback_urb()
> > [  354.661008] dwc2 3f98.usb:   urb->status = 0
> > [  354.661054] dwc2 3f98.usb: DWC OTG HCD URB Dequeue
> > [  354.661065] dwc2 3f98.usb: Called usb_hcd_giveback_urb()
> > [  354.661072] dwc2 3f98.usb:   urb->status = 0
> > [  354.661107] dwc2 3f98.usb: DWC OTG HCD URB Dequeue
> > [  354.661120] dwc2 3f98.usb: Called usb_hcd_giveback_urb()
> > [  354.661127] dwc2 3f98.usb:   urb->status = 0
> > [  354.661146] dwc2 3f98.usb: DWC OTG HCD URB Dequeue
> > [  354.661158] dwc2 3f98.usb: Called usb_hcd_giveback_urb()
> > [  354.661165] dwc2 3f98.usb:   urb->status = 0  
> 
> Btw, 
> 
> Just in case, I also applied all recent pending dwc2 patches I found at
> linux-usb (even trivial unrelated ones) at:
> 
>   https://git.linuxtv.org/mchehab/experimental.git/log/?h=dwc2_patches
> 
> No differences. ISOCH is still broken.
> 
> If anyone wants to see the full logs, it is there:
>   https://pastebin.com/XJYyTwPv

Someone pointed me in priv that applying a change at DWC2 BRCM profile to
enable uframe_sched might help.

So, I wrote this patch:

https://git.linuxtv.org/mchehab/experimental.git/commit/?h=v4.15%2bmedia%2bdwc2=19abf0026b7bf1bd44aa9d2add9f958935760ded

And applied on the top of this branch:

https://git.linuxtv.org/mchehab/experimental.git/log/?h=v4.15%2bmedia%2bdwc2

It is based on Kernel 4.15 vanilla. I applied:
- all media -next patches that will be sent to Kernel 4.16-rc1;
- DWC2 patches submitted by Gregor at linux-usb ML;
- Linus softirq test patch:

https://git.linuxtv.org/mchehab/experimental.git/commit/?h=v4.15%2bmedia%2bdwc2=ccf833fd4a5b99c3d3cf2c09c065670f74a230a7
- A DT patch that enables VCIQ (needed by some GPU drivers):

https://git.linuxtv.org/mchehab/experimental.git/commit/?h=v4.15%2bmedia%2bdwc2=fd4e9ca6f41d35b6234c30fa29937141e0c09570
- a few debug patches like this one:

uas failing on multiple disk access on a jmicron JMS567 bridge

[Menion]

Hello
I am trying to follow up on the original thread, opened on this issue
by Christoph Gohle May 2017 (same email subject)
I confirm that the same issue is still present on kernel 4.14.15
(Mainline build for Ubuntu xenial, amd64)
My enclosure is an Orico 9558RU3, using JMS567 USB 3.0 to SATA bridge
together with JMB394 multiplexer with RAID
As soon as more than one HD in inserted in the enclosure, when
parallel write operation are send to the HDs, you start to get
immediately CMD error on UAS driver, after a while the USB gets in an
inconsistent status and you are forced to reset.

Jan 27 08:59:53 Menionubuntu kernel: [  750.564095] sd 0:0:0:1: [sdb]
tag#22 CDB: Write(10) 2a 00 00 5e fb 10 00 04 00 00
Jan 27 08:59:53 Menionubuntu kernel: [  750.567579] sd 0:0:0:1: [sdb]
tag#17 uas_eh_abort_handler 0 uas-tag 18 inflight: CMD OUT
Jan 27 08:59:53 Menionubuntu kernel: [  750.567604] sd 0:0:0:1: [sdb]
tag#17 CDB: Write(10) 2a 00 00 5e f7 10 00 04 00 00
Jan 27 08:59:53 Menionubuntu kernel: [  750.571280] sd 0:0:0:1: [sdb]
tag#16 uas_eh_abort_handler 0 uas-tag 17 inflight: CMD OUT
Jan 27 08:59:53 Menionubuntu kernel: [  750.571299] sd 0:0:0:1: [sdb]
tag#16 CDB: Write(10) 2a 00 00 5e f3 10 00 04 00 00
Jan 27 08:59:53 Menionubuntu kernel: [  750.575292] sd 0:0:0:1: [sdb]
tag#15 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD OUT
Jan 27 08:59:53 Menionubuntu kernel: [  750.575304] sd 0:0:0:1: [sdb]
tag#15 CDB: Write(10) 2a 00 00 5e ef 10 00 04 00 00


With BTFS the things go even worst:

Jan 26 18:46:01 Menionubuntu kernel: [22961.078609] sd 0:0:0:0: [sda]
Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Jan 26 18:46:02 Menionubuntu kernel: [22961.160317] sd 0:0:0:0: [sda]
tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jan 26 18:46:02 Menionubuntu kernel: [22961.160378] sd 0:0:0:0: [sda]
tag#0 Sense Key : Aborted Command [current]
Jan 26 18:46:02 Menionubuntu kernel: [22961.160523] sd 0:0:0:0: [sda]
tag#0 Add. Sense: No additional sense information
Jan 26 18:46:02 Menionubuntu kernel: [22961.160544] sd 0:0:0:0: [sda]
tag#0 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00
Jan 26 18:46:02 Menionubuntu kernel: [22961.160558] print_req_error:
I/O error, dev sda, sector 0
Jan 26 18:46:02 Menionubuntu kernel: [22961.160597] Buffer I/O error
on dev sda, logical block 0, async page read
Jan 26 18:46:02 Menionubuntu kernel: [22961.244469] sd 0:0:0:0: [sda]
tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Jan 26 18:46:02 Menionubuntu kernel: [22961.244539] sd 0:0:0:0: [sda]
tag#0 Sense Key : Aborted Command [current]
Jan 26 18:46:02 Menionubuntu kernel: [22961.244556] sd 0:0:0:0: [sda]
tag#0 Add. Sense: No additional sense information
Jan 26 18:46:02 Menionubuntu kernel: [22961.244577] sd 0:0:0:0: [sda]
tag#0 CDB: Read(16) 88 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00
Jan 26 18:46:02 Menionubuntu kernel: [22961.244590] print_req_error:
I/O error, dev sda, sector 0


Putting in UAS blacklist the device so running old BOT mode is a valid
workaround, the same enclosure with the same HDs run for days with no
USB error.
Due to the fact that I am running JBOD on BTRFS, I really need to run
in BOT mode, but I can try to provide some logs, if anyone is willing
to pick up the issue.
Bye
--
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: Problem with xhci_hcd on Gigabyte Z170X Gaming 7-EK

[Mathias Nyman]

On 20.01.2018 06:20, Herbert Poetzl wrote:


I've recently acquired a Gigabyte Z170X Gaming 7-EK motherboard
with the Intel Z170 chipset and Sunrise Point-H USB 3.0 xHCI
Controller for running Linux.

Now most things seem to work fine (some problems with UEFI but
that was kind of expected), but the xhci_hcd module is filling
up my log files with a repeated message (ever 4 seconds):

   [ 2137.036187] usb usb2-port1: Cannot enable. Maybe the USB cable is bad?
   [ 2137.036981] xhci_hcd :00:14.0: Cannot set link state.
   [ 2137.037767] usb usb2-port1: cannot disable (err = -32)

Now I have no idea where usb2-port1 is or why it should have a
bad cable, the only USB devices I know of are the USB drive
I've booted the system from and the wireless keyboard/mouse
combo I'm using.

Both seem to work just fine and plugging those into different
USB ports doesn't change the message.

   Bus 002 Device 002: ID 1b1c:1a00 Corsair
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 003: ID 046d:c534 Logitech, Inc. Unifying Receiver
   Bus 001 Device 002: ID 045b:0209 Hitachi, Ltd
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Note: I have no idea what the Hitachi device is.

The current kernel is 4.14.13 (from Mageia 6).

Any idea what the problem here is and how I can fix or work
around it?

Please let me know if you need any additional information on
the system or environment.



lsusb -v could show more details about the misbehaving device.

Output of dmesg could tell something as well

-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

Re: Not enough bandwidth with Magewell XI100DUSB-HDMI

[Mathias Nyman]

On 19.01.2018 22:12, Philipp Zabel wrote:

Hi,

On Fri, Jan 19, 2018 at 2:10 PM, Michael Tretter
 wrote:

I found the old thread and it sounds exactly like my issue. Different
camera, but same xHCI controller.


I have exactly the same issue with the xHCI controller of my laptop and
"Oculus Sensor" USB3 isochronous mostly-UVC cameras:

00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI
Controller (rev 03) (prog-if 30 [XHCI])
 Subsystem: Lenovo Wildcat Point-LP USB xHCI Controller
 Flags: bus master, medium devsel, latency 0, IRQ 44
 Memory at f222 (64-bit, non-prefetchable) [size=64K]
 Capabilities: [70] Power Management version 2
 Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
 Kernel driver in use: xhci_hcd
 Kernel modules: xhci_pci

T:  Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  4 Spd=5000 MxCh= 0
D:  Ver= 3.00 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  1
P:  Vendor=2833 ProdID=0211 Rev= 0.00
S:  Manufacturer=Oculus VR
S:  Product=Rift Sensor
S:  SerialNumber=WMTD3034300BCT
C:* #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=800mA
A:  FirstIf#= 0 IfCount= 2 Cls=ff(vend.) Sub=03 Prot=00
I:* If#= 0 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=01 Prot=00 Driver=uvcvideo
E:  Ad=83(I) Atr=03(Int.) MxPS=  32 Ivl=128ms
I:* If#= 1 Alt= 0 #EPs= 0 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo
I:  If#= 1 Alt= 1 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo
E:  Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us
I:  If#= 1 Alt= 2 #EPs= 1 Cls=ff(vend.) Sub=02 Prot=00 Driver=uvcvideo
E:  Ad=81(I) Atr=05(Isoc) MxPS=1024 Ivl=125us

Any USB2 or USB3 device that I plug in while the first camera is streaming in
altsetting 1 or 2 causes the bandwidth error. The same happens when I try to
change the altsetting on an isochronous endpoint of an already plugged device.
While the camera is in altsetting 0, other devices can be probed and work.


For some tests, I changed the xhci_change_max_exit_latency() function
to ignore the requested MEL and set the MEL to 0. Now the USB devices
are detected correctly.


Exactly the same thing helps here, as well. With this hack, streaming from two
of those cameras at the same time works without any apparent problem:

--8<--
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 297536c9fd00..3cb4a60d8822 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -4025,7 +4025,7 @@ static int __maybe_unused
xhci_change_max_exit_latency(struct xhci_hcd *xhci,
 ctrl_ctx->add_flags |= cpu_to_le32(SLOT_FLAG);
 slot_ctx = xhci_get_slot_ctx(xhci, command->in_ctx);
 slot_ctx->dev_info2 &= cpu_to_le32(~((u32) MAX_EXIT));
-   slot_ctx->dev_info2 |= cpu_to_le32(max_exit_latency);
+   slot_ctx->dev_info2 |= cpu_to_le32(0);
 slot_ctx->dev_state = 0;

 xhci_dbg_trace(xhci, trace_xhci_dbg_context_change,
-->8--



Ok, back after a week on sickleave.
I'm getting the magewell capture device and try to reproduce this myself.

-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

Re: BUG: KASAN: use-after-free in xhci_trb_virt_to_dma.part.24+0x1c/0x80

[Mathias Nyman]

On 28.01.2018 23:43, Paul Menzel wrote:

Dear Linux folks,


Using Linux 4.15-rc9+ with KASAN enabled on the TUXEDO Book 1406, playing with 
Bluetooth – disabling a device – I was able to trigger the warning below.



Thanks, first guess is that btusb calls usb_set_interface() with URBs still 
scheduled for a endpoint.
So something like this happens:

btusb_work [btusb]
  usb_set_interface
usb_hcd_alloc_bandwidth
  xhci_check_bandwidth
 xhci_free_endpoint_ring   -> frees xhci endpoint ring.
usb_disable_interface
  usb_disable_endpoint
usb_hcd_flush_endpoint
  unlink1
xhci_urb_dequeue   -> tries to access xhci endpoint ring in URB

description for usb_set_interface() says:
* This call is synchronous, and may not be used in an interrupt context.
* Also, drivers must not change altsettings while urbs are scheduled for
* endpoints in that interface; all such urbs must first be completed
* (perhaps forced by unlinking).

Adding some bluetooth people

-Mathias



[ 7384.326627] 
==
[ 7384.326644] BUG: KASAN: use-after-free in 
xhci_trb_virt_to_dma.part.24+0x1c/0x80
[ 7384.326652] Read of size 8 at addr 88068c491c00 by task kworker/0:3/17280

[ 7384.326669] CPU: 0 PID: 17280 Comm: kworker/0:3 Not tainted 4.15.0-rc9+ #20
[ 7384.326675] Hardware name: Notebook 
N24_25BU/N24_25BU, BIOS 5.12 07/07/2017
[ 7384.326690] Workqueue: events btusb_work [btusb]
[ 7384.326699] Call Trace:
[ 7384.326711]  dump_stack+0xaf/0x125
[ 7384.326722]  ? dma_virt_map_sg+0x14b/0x14b
[ 7384.326733]  ? show_regs_print_info+0xa/0xa
[ 7384.326753]  print_address_description+0x7a/0x440
[ 7384.326768]  ? xhci_trb_virt_to_dma.part.24+0x1c/0x80
[ 7384.326778]  kasan_report+0x1dc/0x450
[ 7384.326796]  ? xhci_trb_virt_to_dma.part.24+0x1c/0x80
[ 7384.326811]  xhci_trb_virt_to_dma.part.24+0x1c/0x80
[ 7384.326824]  xhci_urb_dequeue+0x987/0xd70
[ 7384.326850]  ? ret_from_fork+0x35/0x40
[ 7384.326864]  ? xhci_get_endpoint_flag+0x80/0x80
[ 7384.326884]  ? trace_graph_entry+0x178/0x380
[ 7384.326891]  ? xhci_get_endpoint_flag+0x80/0x80
[ 7384.326905]  ? xhci_get_endpoint_flag+0x80/0x80
[ 7384.326926]  ? prepare_ftrace_return+0x1c5/0x2c0
[ 7384.326939]  ? usb_hcd_flush_endpoint+0x185/0x440
[ 7384.326949]  ? addr_from_call+0xe0/0xe0
[ 7384.326957]  ? ftrace_lookup_ip+0x154/0x250
[ 7384.326965]  ? xhci_get_endpoint_flag+0x80/0x80
[ 7384.326975]  ? is_ftrace_trampoline+0x10/0x10
[ 7384.327007]  ? ftrace_graph_caller+0x62/0xa0
[ 7384.327018]  ? usb_disable_endpoint+0x76/0x110
[ 7384.327025]  ? rcu_sched_qs.part.49+0x70/0x70
[ 7384.327033]  ? xhci_get_endpoint_flag+0x80/0x80
[ 7384.327038]  ? unlink1+0x79/0x270
[ 7384.327052]  usb_hcd_flush_endpoint+0x185/0x440
[ 7384.327064]  ? usb_hcd_unlink_urb+0x210/0x210
[ 7384.327069]  ? ftrace_graph_caller+0x62/0xa0
[ 7384.327076]  ? ftrace_graph_caller+0x62/0xa0
[ 7384.327087]  ? usb_disable_endpoint+0x64/0x110
[ 7384.327101]  usb_disable_endpoint+0x76/0x110
[ 7384.327110]  usb_disable_interface+0x98/0xf0
[ 7384.327124]  usb_set_interface+0x29d/0x630
[ 7384.327143]  btusb_work+0x400/0x881 [btusb]
[ 7384.327158]  process_one_work+0x677/0xd70
[ 7384.327174]  ? create_worker+0x360/0x360
[ 7384.327180]  ? compat_start_thread+0x70/0x70
[ 7384.327185]  ? __switch_to_asm+0x34/0x70
[ 7384.327196]  ? finish_task_switch+0x12b/0x540
[ 7384.327201]  ? ftrace_graph_caller+0x62/0xa0
[ 7384.327206]  ? __switch_to_asm+0x40/0x70
[ 7384.327211]  ? __switch_to_asm+0x34/0x70
[ 7384.327220]  ? trace_event_raw_event_sched_wake_idle_without_ipi+0x160/0x160
[ 7384.327226]  ? __switch_to_asm+0x34/0x70
[ 7384.327234]  ? ftrace_lookup_ip+0x154/0x250
[ 7384.327247]  ? __schedule+0x4f3/0x12f0
[ 7384.327267]  ? create_worker+0x360/0x360
[ 7384.327277]  ? create_worker+0x360/0x360
[ 7384.327285]  ? worker_thread+0x1f8/0xf70
[ 7384.327292]  ? addr_from_call+0xe0/0xe0
[ 7384.327298]  ? task_change_group_fair+0x5c0/0x5c0
[ 7384.327303]  ? create_worker+0x360/0x360
[ 7384.327315]  ? schedule+0xe5/0x2c0
[ 7384.327320]  ? move_linked_works+0x2e9/0x460
[ 7384.327326]  ? __schedule+0x12f0/0x12f0
[ 7384.327338]  ? ftrace_graph_caller+0x62/0xa0
[ 7384.327353]  ? worker_thread+0x6c5/0xf70
[ 7384.327367]  worker_thread+0x1f8/0xf70
[ 7384.327394]  ? process_one_work+0xd70/0xd70
[ 7384.327401]  ? trace_graph_entry+0x178/0x380
[ 7384.327406]  ? trace_event_raw_event_sched_wake_idle_without_ipi+0x160/0x160
[ 7384.327416]  ? prepare_ftrace_return+0x1c5/0x2c0
[ 7384.327424]  ? __schedule+0x4cb/0x12f0
[ 7384.327430]  ? addr_from_call+0xe0/0xe0
[ 7384.327437]  ? trace_event_raw_event_sched_wake_idle_without_ipi+0x160/0x160
[ 7384.327444]  ? __switch_to+0x443/0xad0
[ 7384.327457]  ? compat_start_thread+0x70/0x70
[ 7384.327462]  ? __switch_to_asm+0x34/0x70
[ 7384.327474]  ? finish_task_switch+0x12b/0x540
[ 7384.327480]  ? ftrace_graph_caller+0x62/0xa0
[ 7384.327488]  ? __switch_to_asm+0x40/0x70
[ 7384.327496]  ? 

[PATCH v2 1/1] usb: xhci: do not create and register shared_hcd when USB3.0 is disabled

[Thang Q. Nguyen]

From: Tung Nguyen 

Currently, hcd->shared_hcd always creates and registers to the usb-core.
If, for some reasons, USB3 downstream port is disabled, no roothub port for
USB3.0 is found. This causes kernel to display an error:
hub 2-0:1.0: config failed, hub doesn't have any ports! (err -19)
This patch checks and registers shared_hcd if USB3.0 downstream
port is available.

Signed-off-by: Tung Nguyen 
---
 drivers/usb/host/xhci-plat.c |  9 ++---
 drivers/usb/host/xhci.c  | 13 +
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 6f03830..bdb3975 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -293,9 +293,12 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
xhci->shared_hcd->can_do_streams = 1;
 
-   ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
-   if (ret)
-   goto dealloc_usb2_hcd;
+   /* Just add the shared_hcd when USB3.0 downstream port is available */
+   if (xhci->num_usb3_ports > 0) {
+   ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
+   if (ret)
+   goto dealloc_usb2_hcd;
+   }
 
device_enable_async_suspend(>dev);
pm_runtime_put_noidle(>dev);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 1eeb339..9d3b1ab 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -611,6 +611,19 @@ int xhci_run(struct usb_hcd *hcd)
if (ret)
xhci_free_command(xhci, command);
}
+   /*
+* In case that the USB3.0 downstream port is not available
+* No one triggers to start the xHC which should be done
+* before finishing xhci_run
+*/
+   if (xhci->num_usb3_ports == 0) {
+   if (xhci_start(xhci)) {
+   xhci_halt(xhci);
+   return -ENODEV;
+   }
+   xhci->cmd_ring_state = CMD_RING_STATE_RUNNING;
+   }
+
xhci_dbg_trace(xhci, trace_xhci_dbg_init,
"Finished xhci_run for USB2 roothub");
 
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: USB-C Devices only show up if connected at boot

[Mika Westerberg]

On Sat, Jan 27, 2018 at 01:31:00PM +, Mike Lothian wrote:
> On 26 January 2018 at 09:53, Mike Lothian  wrote:
> > On 26 January 2018 at 08:31, Mika Westerberg
> >  wrote:
> >> On Fri, Jan 26, 2018 at 08:07:56AM +, Mike Lothian wrote:
> >>> Whether CONFIG_HOTPLUG_PCI_ACPI=y or CONFIG_HOTPLUG_PCI_ACPI=n the
> >>> device doesn't show unless echo 1 > /sys/bus/pci/rescan is issued
> >>
> >> That's not how it is supposed to work. Please send me full dmesg and in
> >> addition acpidump of the system (or attach it to the bugzilla bug). Also
> >> share your .config.
> >
> > I've attached my full dmesg and .config to the bug. The acpidump info
> > can be found at https://bugzilla.kernel.org/show_bug.cgi?id=198051,
> > the current kernel has the attached patch to enable
> > AcpiGbl_ParseTableAsTermList, the bug also contains a dmesg without it
> 
> I've attached the dmesg to the bug
> https://bugzilla.kernel.org/show_bug.cgi?id=198557
> 
> The important lines I think are:
> 
> [   26.988174] ACPI: \_SB_.PCI0.RP01: acpiphp_glue: Bus check in 
> hotplug_event()
> [  129.086070] ACPI: \_SB_.PCI0.RP01: acpiphp_glue: Bus check in 
> hotplug_event()

Indeed. Thanks! Let's continue debugging on bugzilla.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] usb: chipidea: imx: Fix ULPI on imx53

[Peter Chen]

On Wed, Jan 24, 2018 at 06:14:39PM +0100, Sebastian Reichel wrote:
> Traditionally, PORTSC should be set before initializing ULPI phys. But
> setting PORTSC before powering on the phy results in a kernel freeze
> on imx53 based GE PPD. As a workaround this initializes the phy early
> in the imx platform code and disables phy power management from the
> core.
> 
> Signed-off-by: Fabien Lahoudere 
> Signed-off-by: Sebastian Reichel 
> ---
>  drivers/usb/chipidea/ci_hdrc_imx.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c 
> b/drivers/usb/chipidea/ci_hdrc_imx.c
> index de155c80eb70..e431c5aafe35 100644
> --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> @@ -83,6 +83,7 @@ struct ci_hdrc_imx_data {
>   struct clk *clk;
>   struct imx_usbmisc_data *usbmisc_data;
>   bool supports_runtime_pm;
> + bool override_phy_control;
>   bool in_lpm;
>   /* SoC before i.mx6 (except imx23/imx28) needs three clks */
>   bool need_three_clks;
> @@ -254,6 +255,7 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
>   int ret;
>   const struct of_device_id *of_id;
>   const struct ci_hdrc_imx_platform_flag *imx_platform_flag;
> + struct device_node *np = pdev->dev.of_node;
>  
>   of_id = of_match_device(ci_hdrc_imx_dt_ids, >dev);
>   if (!of_id)
> @@ -288,6 +290,14 @@ static int ci_hdrc_imx_probe(struct platform_device 
> *pdev)
>   }
>  
>   pdata.usb_phy = data->phy;
> +
> + if (of_device_is_compatible(np, "fsl,imx53-usb") && pdata.usb_phy &&
> + of_usb_get_phy_mode(np) == USBPHY_INTERFACE_MODE_ULPI) {
> + pdata.flags |= CI_HDRC_OVERRIDE_PHY_CONTROL;
> + data->override_phy_control = true;
> + usb_phy_init(pdata.usb_phy);
> + }
> +
>   pdata.flags |= imx_platform_flag->flags;
>   if (pdata.flags & CI_HDRC_SUPPORTS_RUNTIME_PM)
>   data->supports_runtime_pm = true;
> @@ -341,6 +351,8 @@ static int ci_hdrc_imx_remove(struct platform_device 
> *pdev)
>   pm_runtime_put_noidle(>dev);
>   }
>   ci_hdrc_remove_device(data->ci_pdev);
> + if (data->override_phy_control)
> + usb_phy_shutdown(data->phy);
>   imx_disable_unprepare_clks(>dev);
>  

Sebastian, I have a question, do you have any USB or generic PHY drivers
for ULPI bus, any power controls are needed for your ULPI peripheral?

-- 

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 2/3] usb: dwc3: of-simple: add support for shared and pulsed reset lines

[Felipe Balbi]

Hi,

Martin Blumenstingl  writes:
> Some SoCs (such as Amlogic Meson GXL for example) share the reset line
> with other components (in case of the Meson GXL example there's a shared
> reset line between the USB2 PHYs, USB3 PHYs and the dwc3 controller).
> Additionally SoC implementations may prefer a reset pulse over level
> resets.
>
> Add an internal per-of_device_id struct which can be used to configure
> whether the reset lines are shared and whether they use level or pulse
> resets.
>
> For now this falls back to the old defaults, which are:
> - reset lines are exclusive
> - level resets are being used
>
> Signed-off-by: Martin Blumenstingl 
> ---
>  drivers/usb/dwc3/dwc3-of-simple.c | 65 
> ---
>  1 file changed, 54 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/usb/dwc3/dwc3-of-simple.c 
> b/drivers/usb/dwc3/dwc3-of-simple.c
> index 7ae0eefc7cc7..ceb9f0cd822a 100644
> --- a/drivers/usb/dwc3/dwc3-of-simple.c
> +++ b/drivers/usb/dwc3/dwc3-of-simple.c
> @@ -22,11 +22,22 @@
>  #include 
>  #include 
>  
> +/**
> + * struct dwc3_of_simple_params - hardware specific parameters
> + * @shared_resets: indicates that the resets are shared or exclusive
> + * @pulse_resets: use a reset pulse instead of level based resets
> + */
> +struct dwc3_of_simple_params {
> + boolshared_resets;
> + boolpulse_resets;
> +};
> +
>  struct dwc3_of_simple {
>   struct device   *dev;
>   struct clk  **clks;
>   int num_clocks;
>   struct reset_control*resets;
> + const struct dwc3_of_simple_params  *params;

instead, you can add these two fields here:

bool shared_resets;
bool pulse_resets;

and ...

> @@ -90,17 +101,26 @@ static int dwc3_of_simple_probe(struct platform_device 
> *pdev)
>  
>   platform_set_drvdata(pdev, simple);
>   simple->dev = dev;
> + simple->params = of_device_get_match_data(dev);
>  
> - simple->resets = of_reset_control_array_get_optional_exclusive(np);
> + simple->resets = of_reset_control_array_get(np,
> + simple->params->shared_resets,
> + true);

wrap this with a of_device_is_compatible() check:

if (of_device_is_compatible(dev->of_node, "foobar")) {
simple->shared_resets = true;
simple->pulse_resets = true;
}

or something like that. Then we don't need to add a new
dwc3_of_simple_params for everybody.

Also, the why isn't the reset type (pulse vs level) handled by reset
framework itself? Why does dwc3-of-simple need to know about it?

-- 
balbi


signature.asc
Description: PGP signature