Re: [PATCH v2 11/12] dt-bindings: usb: add documentation for typec port controller(TCPCI)

[Rob Herring]

On Mon, Feb 26, 2018 at 07:49:18PM +0800, Li Jun wrote:
> TCPCI stands for typec port controller interface, its implementation
> has full typec port control with power delivery support, it's a
> standard i2c slave with GPIO input as irq interface, detail see spec
> "Universal Serial Bus Type-C Port Controller Interface Specification
> Revision 1.0, Version 1.1"
> 
> Signed-off-by: Li Jun 
> ---
> Change for v2:
> - Use usb connector sub-node accordingly to specify typec properties.
> 
>  .../devicetree/bindings/usb/typec-tcpci.txt| 35 
> ++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/usb/typec-tcpci.txt 
> b/Documentation/devicetree/bindings/usb/typec-tcpci.txt
> new file mode 100644
> index 000..318bf01
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/usb/typec-tcpci.txt
> @@ -0,0 +1,35 @@
> +TCPCI(Typec port cotroller interface) binding
> +-
> +
> +Required properties:
> +- compatible:   should be "usb,tcpci".

usb is not a vendor. I'd do "usb-tcpci".

This will need chip specific compatible strings too.

> +- reg:  the i2c slave address of typec port controller device.
> +- interrupt-parent: the phandle to the interrupt controller which provides
> +the interrupt.
> +- interrupts:   interrupt specification for tcpci alert.
> +
> +Required sub-node:
> +- connector: The "usb-c-connector" attached to the tcpci chip, the bindings
> +  of connector node are specified in
> +  Documentation/devicetree/bindings/connector/usb-connector.txt
> +
> +Example:
> +
> +ptn5110@50 {
> + compatible = "usb,tcpci";
> + reg = <0x50>;
> + interrupt-parent = <>;
> + interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
> +
> + usb_con: connector {
> + compatible = "usb-c-connector";
> + label = "USB-C";
> + port-type = "dual";
> + default-role = "sink";
> + src-pdos = <0x380190c8>;
> + snk-pdos = <0x380190c8 0x3802d0c8>;
> + max-snk-mv = <9000>;
> + max-snk-ma = <1000>;
> + op-snk-mw = <9000>;
> + };
> +};
> -- 
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 10/12] dt-bindings: connector: add properties for typec power delivery

[Rob Herring]

On Tue, Feb 27, 2018 at 09:41:19AM +0100, Andrzej Hajda wrote:
> On 26.02.2018 12:49, Li Jun wrote:
> > In case of usb-c-connector with power delivery support, add bingdings
> > supported by current typec driver, so user can pass all those properties
> > via dt.
> >
> > Signed-off-by: Li Jun 
> > ---
> > Changes for v2:
> > - Added typec properties are based on general usb connector bindings[1]
> >   proposed by Andrzej Hajda.
> > - Use the standard unit suffixes as defined in property-units.txt.
> >
> > [1] https://patchwork.kernel.org/patch/10231447/
> >
> >  .../bindings/connector/usb-connector.txt   | 43 
> > ++
> >  1 file changed, 43 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
> > b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > index e1463f1..242f6df 100644
> > --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> > +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> > @@ -15,6 +15,30 @@ Optional properties:
> >  - type: size of the connector, should be specified in case of USB-A, USB-B
> >non-fullsize connectors: "mini", "micro".
> >  
> > +Required properties for usb-c-connector with power delivery support:
> > +- port-type: should be one of "source", "sink" or "dual".
> > +- default-role: preferred power role if port-type is "dual"(drp), should be
> > +  "sink" or "source".
> 
> Since port carries data and power, it would be better to explicitly
> mention it in names of properties which can be ambiguous.
> Maybe instead of 'port-type' you can use 'power-role', for example.
> Other thing is that default-role is required only in case of DRP, so
> maybe better would be to squash it in power-role, for example:
>     power-role: should be on of "source", "sink", "dual-source",
> "dual-sink", in case of dual roles suffix determines preferred role.
> 
> 
> > +- src-pdos: An array of u32 with each entry providing supported power
> > +  source data object(PDO), the detailed bit definitions of PDO can be found
> > +  in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.2
> > +  Source_Capabilities Message, the order of each entry(PDO) should follow
> > +  the PD spec chapter 6.4.1. Required for power source and power dual role.
> > +- snk-pdos: An array of u32 with each entry providing supported power
> > +  sink data object(PDO), the detailed bit definitions of PDO can be found 
> > in
> > +  "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3 Sink
> > +  Capabilities Message, the order of each entry(PDO) should follow the PD
> > +  spec chapter 6.4.1. Required for power sink and power dual role.
> 
> We should avoid magic numbers, magic numbers are bad :)

I don't mind if there's a defined format for the data.

> If we really need to use PDOs here, I think we can re-use PDO_* macros
> [1] - DTC should be able to parse it, maybe some lifting will be necessary.
> 
> [1]:
> https://elixir.bootlin.com/linux/v4.16-rc3/source/include/linux/usb/pd.h#L161
> > +- max-snk-microvolt: The max voltage the sink can support in micro volts,
> > +  required for power sink and power dual role.
> > +- max-snk-microamp: The max current the sink can support in micro amps,
> > +  required for power sink and power dual role.
> > +- max-snk-microwatt-hours: The max power the sink can support in micro
> > +  Watt-hours, required for power sink and power dual role.
> > +- op-snk-microwatt-hours: Sink required operating power in micro 
> > Watt-hours,
> > +  if source offered power is less then it, Capability Mismatch is set,
> > +  required for power sink and power dual role.
> 
> What is the relation between above properties and PDOs specified earlier?
> Are you sure all these props are required?
> 
> And general remark regarding all above properties. For me, most of them
> are specific not to the port but to devices responsible for power
> management: chargers, pmics,
> In many cases these properties are redundant with devices capabilities.
> On the other side I guess in many cases it may be convenient to put them
> here, so I am not sure what is better :)

I debated that too, but decided if you had 2 connectors connected to a 
single power controller, then you'd want these in the connector.

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

Re: [PATCH v2 10/12] dt-bindings: connector: add properties for typec power delivery

[Rob Herring]

On Mon, Feb 26, 2018 at 07:49:17PM +0800, Li Jun wrote:
> In case of usb-c-connector with power delivery support, add bingdings
> supported by current typec driver, so user can pass all those properties
> via dt.
> 
> Signed-off-by: Li Jun 
> ---
> Changes for v2:
> - Added typec properties are based on general usb connector bindings[1]
>   proposed by Andrzej Hajda.
> - Use the standard unit suffixes as defined in property-units.txt.
> 
> [1] https://patchwork.kernel.org/patch/10231447/
> 
>  .../bindings/connector/usb-connector.txt   | 43 
> ++
>  1 file changed, 43 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.txt 
> b/Documentation/devicetree/bindings/connector/usb-connector.txt
> index e1463f1..242f6df 100644
> --- a/Documentation/devicetree/bindings/connector/usb-connector.txt
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.txt
> @@ -15,6 +15,30 @@ Optional properties:
>  - type: size of the connector, should be specified in case of USB-A, USB-B
>non-fullsize connectors: "mini", "micro".
>  
> +Required properties for usb-c-connector with power delivery support:
> +- port-type: should be one of "source", "sink" or "dual".
> +- default-role: preferred power role if port-type is "dual"(drp), should be
> +  "sink" or "source".
> +- src-pdos: An array of u32 with each entry providing supported power
> +  source data object(PDO), the detailed bit definitions of PDO can be found
> +  in "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.2
> +  Source_Capabilities Message, the order of each entry(PDO) should follow
> +  the PD spec chapter 6.4.1. Required for power source and power dual role.
> +- snk-pdos: An array of u32 with each entry providing supported power

Abbreviating sink to snk doesn't buy much. I'd also just do source 
instead of src.

> +  sink data object(PDO), the detailed bit definitions of PDO can be found in
> +  "Universal Serial Bus Power Delivery Specification" chapter 6.4.1.3 Sink
> +  Capabilities Message, the order of each entry(PDO) should follow the PD
> +  spec chapter 6.4.1. Required for power sink and power dual role.
> +- max-snk-microvolt: The max voltage the sink can support in micro volts,
> +  required for power sink and power dual role.
> +- max-snk-microamp: The max current the sink can support in micro amps,
> +  required for power sink and power dual role.
> +- max-snk-microwatt-hours: The max power the sink can support in micro
> +  Watt-hours, required for power sink and power dual role.
> +- op-snk-microwatt-hours: Sink required operating power in micro Watt-hours,
> +  if source offered power is less then it, Capability Mismatch is set,
> +  required for power sink and power dual role.

None of these properties are part of the PDO?

> +
>  Required nodes:
>  - any data bus to the connector should be modeled using the OF graph bindings
>specified in bindings/graph.txt, unless the bus is between parent node and
> @@ -73,3 +97,22 @@ ccic: s2mm005@33 {
>   };
>   };
>  };
> +
> +3. USB-C connector attached to a typec port controller(ptn5110), which has
> +power delivery support and enables drp.
> +
> +typec: ptn5110@50 {
> + ...
> + usb_con: connector {
> + compatible = "usb-c-connector";
> + label = "USB-C";
> + port-type = "dual";
> + default-role = "sink";
> + src-pdos = <0x380190c8>;
> + snk-pdos = <0x380190c8 0x3802d0c8>;
> + max-snk-microvolt = <9000>;
> + max-snk-microamp = <2000>;
> + max-snk-microwatt-hours = <18000>;
> + op-snk-microwatt-hours = <9000>;
> + };
> +};
> -- 
> 2.7.4
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" 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

libusbgx v0.2.0 released

[Krzysztof Opasiak]

Hello,

This is just a note to let you know that v0.2.0 of libusbg-neXt[1] has 
just been released.


Summary of changes:
- Use prefix for our enums
- Use string names similar to USB spec
- Get rid of static buffers
- Add support for HID function
- Add support for UAC2 function
- Add support for OS descriptors
- Fix C++ compilation issues
- Many smaller fixes

I encourage you to check out new release and contribute!

Footnotes:
1 - https://github.com/libusbgx/libusbgx

Cheers,
--
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics
--
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

howto debug xhci driver?

[Bin Liu]

Hi,

I am relatively new to xhci and its driver. I am trying to get a xhci
driver runtime log to understand how it handles usb transactions, but I
don't get much information with dynamic debug (module xhci_hcd) or
enabling xhci trace events. Is there any other methods you guys use to
debug xhci driver?

BTY, the issue I am trying to debug is when reading bulk IN data from a
USB2.0 device, if the device doesn't have data to transmit and NAKs the
IN packet, after 4 pairs of IN-NAK transactions, xhci stops sending
further IN tokens until the next SOF, which leaves ~90us gape on the
bus.

But when reading data from a USB2.0 thumb drive, this issue doesn't
happen, even if the device NAKs the IN tokens, xhci still keeps sending
IN tokens, which is way more than 4 pairs of IN-NAK transactions.

Any one has a clue on what causes xhci to stop sending IN tokens after
the device NAK'd 4 times?

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: [PATCH] staging: typec: handle vendor defined part and modify drp toggling flow

[李書帆]

Hi,

  Sorry, I modify it to plain text mode and send again

2018-03-03 2:39 GMT+08:00 李書帆 :
>
> Hi Jun,
>
>   I think this operation should be moved to vendor's operation after 
> rechecking the specification.
>
> 2018-03-02 22:38 GMT+08:00 Jun Li :
>>
>> Hi
>> > -Original Message-
>> > From: shufan_lee(李書帆) [mailto:shufan_...@richtek.com]
>> > Sent: 2018年3月1日 19:54
>> > To: Jun Li ; ShuFanLee ;
>> > heikki.kroge...@linux.intel.com; li...@roeck-us.net; g...@kroah.com
>> > Cc: cy_huang(黃啟原) ;
>> > linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org; dl-linux-imx
>> > 
>> > Subject: RE: [PATCH] staging: typec: handle vendor defined part and modify
>> > drp toggling flow
>> >
>> > Hi Jun,
>> >
>> > > -Original Message-
>> > > From: Jun Li [mailto:jun...@nxp.com]
>> > > Sent: Thursday, March 01, 2018 6:06 PM
>> > > To: shufan_lee(李書帆); ShuFanLee; heikki.kroge...@linux.intel.com;
>> > > li...@roeck-us.net; g...@kroah.com
>> > > Cc: cy_huang(黃啟原); linux-ker...@vger.kernel.org;
>> > > linux-usb@vger.kernel.org; dl-linux-imx
>> > > Subject: RE: [PATCH] staging: typec: handle vendor defined part and
>> > > modify drp toggling flow
>> > >
>> > > Hi Shufan
>> > >
>> > > Please don't top posting
>> > >
>> > > -Original Message-
>> > > From: shufan_lee(李書帆) [mailto:shufan_...@richtek.com]
>> > > Sent: 2018年3月1日 16:49
>> > > To: Jun Li ; ShuFanLee ;
>> > > heikki.kroge...@linux.intel.com; li...@roeck-us.net; g...@kroah.com
>> > > Cc: cy_huang(黃啟原) ;
>> > > linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org; dl-linux-imx
>> > > 
>> > > Subject: RE: [PATCH] staging: typec: handle vendor defined part and
>> > > modify drp toggling flow
>> > >
>> > > Hi Jun,
>> > >
>> > >   The attachment is waveform of the condition we met but I'm not sure
>> > > whether you can download the attachment.
>> > >   I add log in RT1711H it shows as following:
>> > >
>> > > You don't need add log by your own.
>> > > There is tcpm(./drivers/usb/typec/tcpm.c) log for debug already, which 
>> > > can
>> > show all the events and state transitions, you can get it by below command
>> > as I commented:
>> > >
>> > > cat /sys/kernel/debug/tcpm/x(your tcpc i2c device)
>> > >
>> > After applying your patch[2], TCPM log is as following:
>>
>> I assume you also applied my patch [1].
>> [1] https://www.spinics.net/lists/devicetree/msg216851.html
>>
> Yes, this patch is also applied.
>>
>> >
>> > [   53.050602] CC1: 0 -> 2, CC2: 0 -> 0 [state DRP_TOGGLING, polarity 0,
>> > connected]
>> > [   53.050613] state change DRP_TOGGLING -> SRC_ATTACH_WAIT
>> > [   53.050678] pending state change SRC_ATTACH_WAIT -> SNK_TRY @
>> > 200 ms
>> > => Rd is plugged out
>> > [   53.178804] CC1: 2 -> 0, CC2: 0 -> 0 [state SRC_ATTACH_WAIT, polarity 0,
>> > disconnected]
>> > [   53.178815] state change SRC_ATTACH_WAIT -> SRC_UNATTACHED
>> > => Rd is plugged in
>> > [   53.178874] Start DRP toggling
>> > [   53.188472] CC1: 0 -> 0, CC2: 0 -> 0 [state DRP_TOGGLING, polarity 0,
>> > disconnected]
>>
>> 1. The plug out and then plug in happens in 10ms? (53.188472 - 53.178804)
>> Was this done manually? Or by some special test method?
>
> It's done manually. If you can download the waveform attached in previous 
> email, you can see Rd is plugged out/in within ms level.
> We connect a bridge board with test points of CC1, CC2 and GND to our 
> platform's Typec receptacle. Then we can simulate a device plugging in/out by 
> connecting/disconnecting a 5.1k resistor between CC1 and GND.
>
>>
>> 2. This is all tcpm log if you finally keep the Rd-device connected on typec
>> port? There is no more tcpm log after 53.188472 if you plug in Rd-device
>>
>> and don't remove it?
>
> Yes, RT1711H reports open/open to TCPM in drp_toggling state and stops 
> toggling. Currently, TCPM does not restart drp_toggling if it receives 
> open/open in drp_toggling state.
> I remember the specification of TypeC does not depict what TCPM should do if 
> it receives open/open in drp_toggling state.
> Maybe restart toggling is an option.
>
>> 3. If the answer of Q2 is yes, then I must ask why you tcpc chip+internal 
>> firmware
>> can't report further cc change event after your drp toggling starts to 
>> present Rp(I know
>> it firstly present Rd after you write to LOOK4CONNECTION, but then it should 
>> change
>> to present Rp, so it should be able to detect the Rd-device finally)
>
> Because RT1711H's internal firmware changes to attached state when Rd is 
> re-plugged in(cc level is default Rp (around 400mV) now).
> Then, LOOK4CONNECTION is set and RT1711H changes CCx to Rd that makes it 
> reports open/open(because cc level changes from default Rp(around 400mV) to 
> 0mV)
>>
>>
>> >
>> > If TCPM does not enter SRC_ATTACHED state, RC.DRP will not be cleared.
>>
>> In this 

Re: patch 8466489ef5ba48272ba4fa4ea9f8f403306de4c7 breaks Renesas USB3 controller functionality

[Bockholdt Arne]

On Thu, 2018-03-01 at 17:37 +, Marc Zyngier wrote:
> On 01/03/18 08:01, Bockholdt Arne wrote:
> > 
> > On Thu, 2018-02-15 at 19:29 +, Marc Zyngier wrote:
> > > [+ Ard, who helped me chasing the initial issue]
> > > 
> > > On 15/02/18 06:43, Bockholdt Arne wrote:
> > > > Hi all,
> > > > 
> > > > on our Intel Atom C2578 server with a SuperMicro A1SAi board
> > > > and a
> > > > Renesas uPD720201 USB 3.0 host controller the controller has
> > > > stopped
> > > > working since kernel 4.13.x. Before that kernel the dmesg
> > > > messages
> > > > from
> > > > XHCI were:
> > > > 
> > > > dmesg-4.12.1-serverv4.log:xhci_hcd :03:00.0: xHCI Host
> > > > Controller
> > > > dmesg-4.12.1-serverv4.log:xhci_hcd :03:00.0: new USB bus
> > > > registered,
> > > > assigned bus number 2
> > > > dmesg-4.12.1-serverv4.log:xhci_hcd :03:00.0: hcc params
> > > > 0x014051cf
> > > > hci version 0x100 quirks 0x0010
> > > > dmesg-4.12.1-serverv4.log:usb usb2: Manufacturer: Linux 4.12.1-
> > > > serverv4
> > > > xhci-hcd
> > > > dmesg-4.12.1-serverv4.log:xhci_hcd :03:00.0: xHCI Host
> > > > Controller
> > > > dmesg-4.12.1-serverv4.log:xhci_hcd :03:00.0: new USB bus
> > > > registered,
> > > > assigned bus number 3
> > > > dmesg-4.12.1-serverv4.log:usb usb3: Manufacturer: Linux 4.12.1-
> > > > serverv4
> > > > xhci-hcd
> > > > 
> > > > After that the message look like that:
> > > > 
> > > > dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: Resetting
> > > > dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: Refused to
> > > > change
> > > > power
> > > > state, currently in D3
> > > > dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: xHCI Host
> > > > Controller
> > > > dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: new USB bus
> > > > registered,
> > > > assigned bus number 2
> > > > dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: Host halt
> > > > failed,
> > > > -19
> > > > dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: can't setup:
> > > > -19
> > > > dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: USB bus 2
> > > > deregistered
> > > > dmesg-4.13.1-serverv4.log:xhci_hcd :03:00.0: init
> > > > :03:00.0
> > > > fail, -19
> > > > 
> > > > I've tested it with 4.15.3 too, it's still the same. I've
> > > > narrowed
> > > > it
> > > > down to the following patch:
> > > > 
> > > > commit 8466489ef5ba48272ba4fa4ea9f8f403306de4c7
> > > > Author: Marc Zyngier  > > > @arm
> > > > .com>>
> > > > Date:   Tue Aug 1 20:11:08 2017 -0500
> > > > 
> > > > xhci: Reset Renesas uPD72020x USB controller for 32-bit DMA
> > > > issue
> > > > 
> > > > Reverting the patch on top of 4.15.3 restores the USB3
> > > > functionality on
> > > > our server. Please let me know if there is anything I can do to
> > > > fix
> > > > the
> > > > problem. Thank you.
> > > 
> > > Hi Arne,
> > > 
> > > This looks pretty bad. I suspect that once reset, the firmware is
> > > lost.
> > > I'll try to write a patch dumping some information about it.
> > > 
> > > Ard: Do you know if the Cello board has a SPI flash connected to
> > > the
> > > Renesas chip, from which it would load the firmware?
> > > 
> > > Another possibility is that power management kicks in, and that
> > > the
> > > endpoint is stuck there. Could also be firmware related, but not
> > > only.
> > > I'd welcome any idea on the subject, as I cannot reproduce this
> > > issue
> > > on
> > > the HW I have.
> > > 
> > > It we cannot work out what exactly is causing this, we may have
> > > to
> > > default to not resetting the part and rely on a command-line
> > > option
> > > to
> > > do it... I can't say I'm a fan.
> > > 
> > > Thanks,
> > > 
> > >   M.
> > > 
> > 
> > Hi Marc,
> > 
> > I've tested it with 4.15.7 and it's still there. Is there anything
> > that
> > I can do to help fixing this problem?
> 
> Would you mind trying the following patch and let me know if it
> helps?
> It is not exactly pretty, but we can polish it if that solves your
> issue.
> 
> Thanks,
> 
>   M.
> 
> From 9a253773b289f781b7114e887481939b3021bb30 Mon Sep 17 00:00:00
> 2001
> From: Marc Zyngier 
> Date: Thu, 1 Mar 2018 17:27:42 +
> Subject: [PATCH] xhci: Only reset uPD72020x if programmed with 64bit
> DMA
>  addresses
> 
> The Renesas uPD72020x USB controller misbehaves when switching
> from 64bit DMA addresses to 32bit ones, and can only accept a
> new programming if hard reset first.
> 
> But it also misbehaves (in a different way) if reset for no
> good reason. So let's restrict the resetting to the cases where
> we detect the 64/32 issue, and leave the device alone in the
> other cases.
> 
> Fixes: 8466489ef5ba ("xhci: Reset Renesas uPD72020x USB controller
> for 32-bit DMA issue")
> Signed-off-by: Marc Zyngier 
> ---
>  drivers/usb/host/pci-quirks.c | 33 ++---
>  1 file changed, 30 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/host/pci-quirks.c 

Re: usb: musb: "(null)" in sysfs mode file after disabling a gadget (and at other times, system hangs)

[Pali Rohár]

On Friday 02 March 2018 17:47:52 Merlijn Wajer wrote:
> >> I would expect it to state "b_idle" instead of "(null)".
> > 
> > Actually, I'd like to see (null) whenever a gadget driver is not loaded,
> > which indicates a gadget is not bound to the udc.
> 
> Hm... Sounds fine to me. I'm using this mode in combination with the usb
> phy (vbus property) to detect if the phone is detect to a 'dumb' charger
> of a PC, but I can just always have a gadget loaded -- same as before,
> really.

For detection if wallcharger or pc usb charger is connected, there is
isp1704_charger driver. It uses some standard ULPI interface. It reports
current_max and type (DCP - dedicated, CDP or just usb).

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: PGP signature

Re: usb: musb: "(null)" in sysfs mode file after disabling a gadget (and at other times, system hangs)

[Merlijn Wajer]

Hi,

On 02/03/18 16:27, Bin Liu wrote:
> Hi,
> 
> On Fri, Mar 02, 2018 at 12:47:07AM +0100, Merlijn Wajer wrote:
>> Hi,
>>
>> I found that the "mode" file in musb sys node will return "(null)" when
>> one would expect it show b_idle.
>>
>> Wrong /mode file:
>>
>> [Fresh boot, cable not connected yet]
>> root@n900devuan:~# modprobe g_nokia
>> [Insert cable connected to PC]
>> root@n900devuan:~# cat
>> /sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto/mode
>> b_peripheral
>> [Remove cable connected to PC]
>> root@n900devuan:~# cat
>> /sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto/mode
>> b_idle
>> root@n900devuan:~# rmmod g_nokia
>> root@n900devuan:~# cat
>> /sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto/mode
>> (null)
> 
> I can reproduce this on AM335x EVM,

>> [Insert cable connected to PC]
>> root@n900devuan:~# cat
>> /sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto/mode
>> b_idle
> 
> but not this, I still get (null). g_nokia is not loaded here, right?

I don't think so:

# cat
/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto/mode
b_peripheral
[unplug]
# cat
/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto/mode
b_idle
# rmmod g_nokia
# lsmod|grep nokia
nokia_modem16384  0
ssi_protocol   20480  2 nokia_modem,cmt_speech
hsi20480  5
hsi_char,omap_ssi,nokia_modem,cmt_speech,ssi_protocol
# cat
/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto/mode
(null)

... libcomposite is loaded, but nothing is in configfs (apart from the
empty usb_gadget):

root@n900devuan:~# zgrep COMPOSITE /proc/config.gz
# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
CONFIG_USB_LIBCOMPOSITE=m
CONFIG_USB_CDC_COMPOSITE=m
root@n900devuan:~# ls /sys/kernel/config/
usb_gadget
root@n900devuan:~# ls /sys/kernel/config/usb_gadget/

Do you have USB_LIBCOMPOSITE and USB_CONFIGFS enabled as module?

I tried to unload libcomposite and the usb_f_* modules:

# rmmod libcomposite
rmmod: ERROR: Module libcomposite is in use by: usb_f_ecm usb_f_phonet
usb_f_acm usb_f_mass_storage usb_f_obex
# rmmod usb_f_ecm usb_f_phonet usb_f_acm usb_f_mass_storage usb_f_obex
# rmmod libcomposite
# lsmod|grep libcom

Yet it now states this: (No change made in cable, was disconnected)

# cat
/sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto/mode
b_peripheral

And the mode doesn't change any more, even when I connect the cable.

Then, when I probe libcomposite and g_nokia again (in this order) the
mode changes to b_idle, with the cable plugged in. It doesn't change
when I plug the phone in again. When I remove g_nokia again, remove the
cable, modprobe it again, and connect the cable, it seems to work again
as expected and I can see some gadget.

I do not see any errors messages from the kernel.

Finally, when I issued 'rmmod g_nokia', the device hung and rebooted again.

>> I would expect it to state "b_idle" instead of "(null)".
> 
> Actually, I'd like to see (null) whenever a gadget driver is not loaded,
> which indicates a gadget is not bound to the udc.

Hm... Sounds fine to me. I'm using this mode in combination with the usb
phy (vbus property) to detect if the phone is detect to a 'dumb' charger
of a PC, but I can just always have a gadget loaded -- same as before,
really.

Cheers,
Merlijn



signature.asc
Description: OpenPGP digital signature

Re: Continuous USB resets on NXP i.MX 6ULL device

[Stefan Wahren]

Am 02.03.2018 um 04:03 schrieb Peter Chen:
  

For non-core registers, i.mx6ull can use i.mx6q as its base setting,
the bits you mentioned may also be reserved at imx6qdl RM.


just for my understanding: MX6_BM_NON_BURST_SETTING is a no-op on
i.MX6ULL or not properly documented in reference manual?

Not properly documented in reference manual.

Peter


Thanks, okay back to topic

@Stefan: Did you try to disable over-current detection via DT?
--
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: musb: "(null)" in sysfs mode file after disabling a gadget (and at other times, system hangs)

[Bin Liu]

Hi,

On Fri, Mar 02, 2018 at 12:47:07AM +0100, Merlijn Wajer wrote:
> Hi,
> 
> I found that the "mode" file in musb sys node will return "(null)" when
> one would expect it show b_idle.
> 
> Wrong /mode file:
> 
> [Fresh boot, cable not connected yet]
> root@n900devuan:~# modprobe g_nokia
> [Insert cable connected to PC]
> root@n900devuan:~# cat
> /sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto/mode
> b_peripheral
> [Remove cable connected to PC]
> root@n900devuan:~# cat
> /sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto/mode
> b_idle
> root@n900devuan:~# rmmod g_nokia
> root@n900devuan:~# cat
> /sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto/mode
> (null)

I can reproduce this on AM335x EVM,

> [Insert cable connected to PC]
> root@n900devuan:~# cat
> /sys/devices/platform/6800.ocp/480ab000.usb_otg_hs/musb-hdrc.0.auto/mode
> b_idle

but not this, I still get (null). g_nokia is not loaded here, right?

> 
> I would expect it to state "b_idle" instead of "(null)".

Actually, I'd like to see (null) whenever a gadget driver is not loaded,
which indicates a gadget is not bound to the udc.

Regards,
-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: [PATCH] net/usb/kalmia: use ARRAY_SIZE for various array sizing calculations

[David Miller]

From: Colin King 
Date: Fri,  2 Mar 2018 13:42:39 +

> From: Colin Ian King 
> 
> Use the ARRAY_SIZE macro on a couple of arrays to determine
> size of the arrays. Also fix up alignment to clean up a checkpatch
> warning. Improvement suggested by Coccinelle.
> 
> Signed-off-by: Colin Ian King 

Applied, thanks Colin.
--
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] staging: typec: handle vendor defined part and modify drp toggling flow

[Jun Li]

Hi
> -Original Message-
> From: shufan_lee(李書帆) [mailto:shufan_...@richtek.com]
> Sent: 2018年3月1日 19:54
> To: Jun Li ; ShuFanLee ;
> heikki.kroge...@linux.intel.com; li...@roeck-us.net; g...@kroah.com
> Cc: cy_huang(黃啟原) ;
> linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org; dl-linux-imx
> 
> Subject: RE: [PATCH] staging: typec: handle vendor defined part and modify
> drp toggling flow
> 
> Hi Jun,
> 
> > -Original Message-
> > From: Jun Li [mailto:jun...@nxp.com]
> > Sent: Thursday, March 01, 2018 6:06 PM
> > To: shufan_lee(李書帆); ShuFanLee; heikki.kroge...@linux.intel.com;
> > li...@roeck-us.net; g...@kroah.com
> > Cc: cy_huang(黃啟原); linux-ker...@vger.kernel.org;
> > linux-usb@vger.kernel.org; dl-linux-imx
> > Subject: RE: [PATCH] staging: typec: handle vendor defined part and
> > modify drp toggling flow
> >
> > Hi Shufan
> >
> > Please don't top posting
> >
> > -Original Message-
> > From: shufan_lee(李書帆) [mailto:shufan_...@richtek.com]
> > Sent: 2018年3月1日 16:49
> > To: Jun Li ; ShuFanLee ;
> > heikki.kroge...@linux.intel.com; li...@roeck-us.net; g...@kroah.com
> > Cc: cy_huang(黃啟原) ;
> > linux-ker...@vger.kernel.org; linux-usb@vger.kernel.org; dl-linux-imx
> > 
> > Subject: RE: [PATCH] staging: typec: handle vendor defined part and
> > modify drp toggling flow
> >
> > Hi Jun,
> >
> >   The attachment is waveform of the condition we met but I'm not sure
> > whether you can download the attachment.
> >   I add log in RT1711H it shows as following:
> >
> > You don't need add log by your own.
> > There is tcpm(./drivers/usb/typec/tcpm.c) log for debug already, which can
> show all the events and state transitions, you can get it by below command
> as I commented:
> >
> > cat /sys/kernel/debug/tcpm/x(your tcpc i2c device)
> >
> After applying your patch[2], TCPM log is as following:

I assume you also applied my patch [1].
[1] https://www.spinics.net/lists/devicetree/msg216851.html

> 
> [   53.050602] CC1: 0 -> 2, CC2: 0 -> 0 [state DRP_TOGGLING, polarity 0,
> connected]
> [   53.050613] state change DRP_TOGGLING -> SRC_ATTACH_WAIT
> [   53.050678] pending state change SRC_ATTACH_WAIT -> SNK_TRY @
> 200 ms
> => Rd is plugged out
> [   53.178804] CC1: 2 -> 0, CC2: 0 -> 0 [state SRC_ATTACH_WAIT, polarity 0,
> disconnected]
> [   53.178815] state change SRC_ATTACH_WAIT -> SRC_UNATTACHED
> => Rd is plugged in
> [   53.178874] Start DRP toggling
> [   53.188472] CC1: 0 -> 0, CC2: 0 -> 0 [state DRP_TOGGLING, polarity 0,
> disconnected]

1. The plug out and then plug in happens in 10ms? (53.188472 - 53.178804)
Was this done manually? Or by some special test method?
2. This is all tcpm log if you finally keep the Rd-device connected on typec
port? There is no more tcpm log after 53.188472 if you plug in Rd-device
and don't remove it? 
3. If the answer of Q2 is yes, then I must ask why you tcpc chip+internal 
firmware
can't report further cc change event after your drp toggling starts to present 
Rp(I know
it firstly present Rd after you write to LOOK4CONNECTION, but then it should 
change
to present Rp, so it should be able to detect the Rd-device finally)

> 
> If TCPM does not enter SRC_ATTACHED state, RC.DRP will not be cleared.

In this case, you don’t need clear RC.DRP, see TCPCI spec:
"Figure 4-18. Sink Disconnect"
TCPM sink doesn't clear it in whole sequence, just directly set it:
Restart DRP Toggling
PC.AutoDischargeDisconnect=0b
Set RC.DRP=1b (DRP)
Set RC.CC1=10b (Rd)
Set RC.CC2=10b (Rd)
COMMAND.Look4Connection (DRP toggle)

> When TCPM writes Rd/Rd or Rp/Rp in the drp_toggling function, it does not
> take effect until LOOK4CONNECTION command is set.
> The above condition causes RT1711H reports open/open at [53.188472]
> 
> > [ 914.937340] typec_rt1711h 2-004e: __rt1711h_irq_handler [
> > 914.943838] typec_rt1711h 2-004e: __tcpm_get_cc cc1 = Open, cc2 =
> Open
> > => Device(Rd) is plugged out
> >
> > [ 914.958041] typec_rt1711h 2-004e: tcpm_set_pd_rx 0 [ 914.963011]
> > typec_rt1711h 2-004e: tcpm_set_vbus vbus = 0 [ 914.968407]
> > typec_rt1711h
> > 2-004e: tcpm_set_vbus chg is already 0 [ 914.974541] typec_rt1711h
> 2-004e:
> > tcpm_set_vconn vconn is already 0 [ 914.980921] typec_rt1711h 2-004e:
> > tcpm_set_current_limit 0 ma, 0 mv (not implemented) [ 914.988894]
> > typec_rt1711h 2-004e: tcpm_set_polarity Polarity_CC1 [ 915.003201]
> > typec_rt1711h 2-004e: tcpm_set_roles Source Host [ 915.009264]
> > typec_rt1711h 2-004e: tcpm_start_drp_toggling => state_machine_work
> of
> > TCPM calls start_drp_toggling function but does not set
> > LOOK4CONNECTION command yet => (Note1) Device(Rd) is plugged in
> > (RT1711H's internal firmware detects Rd plugged in. cc_change is
> > triggered and it will be vRd-connected at this moment) => TCPM writes
> > LOOK4CONNECTION command
> > - Because RC.DRP is still 1, RT1711H will 

Re: [PATCHv2] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Tony Lindgren]

* Kishon Vijay Abraham I  [180302 08:04]:
> Hi Tony,
> 
> On Thursday 01 March 2018 09:20 AM, Tony Lindgren wrote:
> > Let's add support for the GPIO controlled USB PHY on the MDM6600 modem.
> > It is used on some Motorola Mapphone series of phones and tablets such
> > as Droid 4.
> 
> Generally PHY configuration is done for the PHYs that is connected to the USB
> controllers in the SoC. In that sense it differs from the usual case by
> programming the PHY in the device.

Yup in this case it's the MDM6600 that provides the PHY for the SoC :)

> > The MDM6600 is hardwired to the first OHCI port in the Droid 4 case, and
> > is controlled by several GPIOs. The USB PHY is integrated into the MDM6600
> > device it seems. We know this as we get L3 errors from omap-usb-host if
> > trying to use the PHY before MDM6600 is configured.
> 
> Do you know what phy is connected to the OHCI port. Previously we've seen for
> having USB devices on the board itself, phy less configurations was used.

We have MDM6600 on *HCI port 1 providing "ohci-phy-4pin-dpdm"
PHY for the SoC, so not TLL. Then there's another modem W3GLTE on
port 2 that is using "ehci-tll".

> > --- /dev/null
> > +++ b/drivers/phy/motorola/phy-mapphone-mdm6600.c
> .
> .
> 
> .
> .
> > +
> > +static int phy_mdm6600_probe(struct platform_device *pdev)
> > +{
> > +   struct phy_mdm6600 *ddata;
> > +   struct usb_otg *otg;
> 
> Since it is connected to a OHCI, not sure if we really need to add usb_otg 
> here.

OK yeah that's copy paste leftover from my earlier PHY driver I used
to start with. Will drop thanks.

Regards,

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

[PATCH] net/usb/kalmia: use ARRAY_SIZE for various array sizing calculations

[Colin King]

From: Colin Ian King 

Use the ARRAY_SIZE macro on a couple of arrays to determine
size of the arrays. Also fix up alignment to clean up a checkpatch
warning. Improvement suggested by Coccinelle.

Signed-off-by: Colin Ian King 
---
 drivers/net/usb/kalmia.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/usb/kalmia.c b/drivers/net/usb/kalmia.c
index ce0b0b4e3a57..2243da0aa991 100644
--- a/drivers/net/usb/kalmia.c
+++ b/drivers/net/usb/kalmia.c
@@ -114,14 +114,14 @@ kalmia_init_and_get_ethernet_addr(struct usbnet *dev, u8 
*ethernet_addr)
return -ENOMEM;
 
memcpy(usb_buf, init_msg_1, 12);
-   status = kalmia_send_init_packet(dev, usb_buf, sizeof(init_msg_1)
-   / sizeof(init_msg_1[0]), usb_buf, 24);
+   status = kalmia_send_init_packet(dev, usb_buf, ARRAY_SIZE(init_msg_1),
+usb_buf, 24);
if (status != 0)
return status;
 
memcpy(usb_buf, init_msg_2, 12);
-   status = kalmia_send_init_packet(dev, usb_buf, sizeof(init_msg_2)
-   / sizeof(init_msg_2[0]), usb_buf, 28);
+   status = kalmia_send_init_packet(dev, usb_buf, ARRAY_SIZE(init_msg_2),
+usb_buf, 28);
if (status != 0)
return status;
 
-- 
2.15.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: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

[Heikki Krogerus]

Hi,

On Tue, Feb 27, 2018 at 08:11:29AM +0100, Andrzej Hajda wrote:
> +2. USB-C connector attached to CC controller (s2mm005), HS lines routed
> +to companion PMIC (max77865), SS lines to USB3 PHY and SBU to DisplayPort.
> +DisplayPort video lines are routed to the connector via SS mux in USB3 PHY.
> +
> +ccic: s2mm005@33 {
> + ...
> + usb_con: connector {
> + compatible = "usb-c-connector";
> + label = "USB-C";

Is this child node really necessary? There will never be more then
one connector per CC line.

We should prefer device_graph* functions over of_graph* and
acpi_graph* functions in the drivers so we don't have to handle the
same thing multiple times with separate APIs. Is it still possible if
there is that connector child node?

> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + usb_con_hs: endpoint {
> + remote-endpoint = <_usbc_hs>;
> + };
> + };
> + port@1 {
> + reg = <1>;
> + usb_con_ss: endpoint {
> + remote-endpoint = <_phy_ss>;
> + };
> + };
> + port@2 {
> + reg = <2>;
> + usb_con_sbu: endpoint {
> + remote-endpoint = <_aux>;
> + };
> + };
> + };
> + };
> +};


Thanks,

-- 
heikki
--
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 report : TBR oveflow

[Mathias Nyman]

On 01.03.2018 22:56, ljoubl...@gmail.com wrote:

I'm a user of gentoo linux, and would like to raise a bug report. I hope these
are the correct channels; if not, I apologise in advance.

I'm using a realtek-based USB3 to RJ45 gigabit adapter. This plugs
directly into my laptop, which is a Toshiba Radius P20W-C-103, skylake
based, with the following controller:

```
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0
xHCI Controller (rev 21)
```

I am experiencing this on 4.9.79-r1, and also 4.14.22.

When I plug the device in, unless I disable power management on USB
hubs 3 and 4, I get errors saying 'root hub lost power or was reset'.
However, if I disable PM using powertop, I get the device to work
seemingly well. But, as soon as I start heavy transfers (in my case
distributed compile), the network device stops responding

The error messages that I'm receiving are very similar to a bug described
here: https://bugs.launchpad.net/dell-sputnik/+bug/1729674
But I've been told that it's unrelated.

First, these are the logs showing the dongle being plugged in.
```
Feb 26 20:17:09 nizuc kernel: usb usb3: root hub lost power or was reset
Feb 26 20:17:09 nizuc kernel: usb usb4: root hub lost power or was reset
Feb 26 20:17:41 nizuc kernel: usb 4-1: new SuperSpeed USB device
number 2 using xhci_hcd
Feb 26 20:17:41 nizuc kernel: usb 4-1: New USB device found,
idVendor=0bda, idProduct=8153
Feb 26 20:17:41 nizuc kernel: usb 4-1: New USB device strings: Mfr=1,
Product=2, SerialNumber=6
Feb 26 20:17:41 nizuc kernel: usb 4-1: Product: USB 10/100/1000 LAN
Feb 26 20:17:41 nizuc kernel: usb 4-1: Manufacturer: Realtek
Feb 26 20:17:41 nizuc kernel: usb 4-1: SerialNumber: 01
Feb 26 20:17:41 nizuc kernel: usb 4-1: reset SuperSpeed USB device
number 2 using xhci_hcd
Feb 26 20:17:41 nizuc NetworkManager[2049]:   [1519676261.9009]
manager: (eth0): new Ethernet device
(/org/freedesktop/NetworkManager/Devices/5)
Feb 26 20:17:41 nizuc kernel: r8152 4-1:1.0 eth0: v1.09.9
Feb 26 20:17:42 nizuc mtp-probe[3673]: checking bus 4, device 2:
"/sys/devices/pci:00/:00:1c.0/:01:00.0/usb4/4-1"
Feb 26 20:17:42 nizuc mtp-probe[3673]: bus: 4, device: 2 was not an MTP device
Feb 26 20:17:42 nizuc upowerd[2168]: unhandled action 'bind' on
/sys/devices/pci:00/:00:1c.0/:01:00.0/usb4/4-1
Feb 26 20:17:42 nizuc systemd-udevd[3676]: link_config:
autonegotiation is unset or enabled, the speed and duplex are not
writable.
Feb 26 20:17:42 nizuc kernel: r8152 4-1:1.0 enp1s0u1: renamed from eth0
Feb 26 20:17:42 nizuc NetworkManager[2049]:   [1519676262.2645]
device (eth0): interface index 4 renamed iface from 'eth0' to
'enp1s0u1'
Feb 26 20:17:42 nizuc kernel: IPv6: ADDRCONF(NETDEV_UP): enp1s0u1:
link is not ready
Feb 26 20:17:42 nizuc NetworkManager[2049]:   [1519676262.2829]
device (enp1s0u1): state change: unmanaged -> unavailable (reason
'managed', internal state 'external')
Feb 26 20:17:42 nizuc upowerd[2168]: unhandled action 'bind' on
/sys/devices/pci:00/:00:1c.0/:01:00.0/usb4/4-1/4-1:1.0
Feb 26 20:17:42 nizuc kernel: IPv6: ADDRCONF(NETDEV_UP): enp1s0u1:
link is not ready
Feb 26 20:17:46 nizuc kernel: r8152 4-1:1.0 enp1s0u1: carrier on
Feb 26 20:17:46 nizuc kernel: IPv6: ADDRCONF(NETDEV_CHANGE): enp1s0u1:
link becomes ready
```

but once I begin distrubted compile, the network drops, with the following
messages:

```
Feb 26 20:25:32 nizuc distccd[13928]: (dcc_r_token_int) got ARGV000f
Feb 26 20:25:32 nizuc distccd[13928]: (dcc_r_token_string) got '-Wa,-mtune=i686'
Feb 26 20:25:32 nizuc distccd[13928]: (dcc_r_argv) argv[22] = "-Wa,-mtune=i686"
Feb 26 20:25:32 nizuc distccd[13928]: (dcc_r_token_int) got ARGV0011
Feb 26 20:25:32 nizuc kernel: xhci_hcd :01:00.0: ERROR Transfer
event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
Feb 26 20:25:32 nizuc kernel: xhci_hcd :01:00.0: Looking for
event-dma 00020c8aea40 trb-start 00020c8aea20 trb-end
00020c8aea20 seg-start 00020c8ae000 s>


From xhci usb3 host controller point of view there are a couple usb transfer
blocks (TRB) sitting on the transfer ring that were not handled (at ..ea20 and 
--ea30).
but we get transfer events for the following transfer blocks starting (at 
..ea40)

Driver can't handle TRBs finishing out of order.


Feb 26 20:25:32 nizuc kernel: xhci_hcd :01:00.0: ERROR Transfer
event TRB DMA ptr not part of current TD ep_index 2 comp_code 13
Feb 26 20:25:32 nizuc kernel: xhci_hcd :01:00.0: Looking for
event-dma 00020c8aea50 trb-start 00020c8aea20 trb-end


This was for the next tranfer block (at ..ea50) so hw xHC hardware
seems to proceed normally anfter two TRBs are skipped



I hope somebody here can direct me as to how to best proceed. Should I try
modifying the aforementioned patch and see if it helps (note the patch only
activates for certain usb vendor/device IDs). Also, the ubuntu link suggests
that this may be the result of "offloading checksuming" which can be disabled

[PATCH 1/1] usb: gadget: f_fs: Fix use-after-free in ffs_fs_kill_sb()

[Xinyong]

When I debug a kernel crash issue in funcitonfs, found ffs_data.ref
overflowed, While functionfs is unmounting, ffs_data is put twice.

Commit 43938613c6fd ("drivers, usb: convert ffs_data.ref from atomic_t to
refcount_t") can avoid refcount overflow, but that is risk some situations.
So no need put ffs data in ffs_fs_kill_sb, already put in ffs_data_closed.

The issue can be reproduced in Mediatek mt6763 SoC, ffs for ADB device.
KASAN enabled configuration reports use-after-free errro.

BUG: KASAN: use-after-free in refcount_dec_and_test+0x14/0xe0 at addr 
ffc0579386a0
Read of size 4 by task umount/4650

BUG kmalloc-512 (Tainted: PW  O   ): kasan: bad access detected
-

INFO: Allocated in ffs_fs_mount+0x194/0x844 age=22856 cpu=2 pid=566
alloc_debug_processing+0x1ac/0x1e8
___slab_alloc.constprop.63+0x640/0x648
__slab_alloc.isra.57.constprop.62+0x24/0x34
kmem_cache_alloc_trace+0x1a8/0x2bc
ffs_fs_mount+0x194/0x844
mount_fs+0x6c/0x1d0
vfs_kern_mount+0x50/0x1b4
do_mount+0x258/0x1034
INFO: Freed in ffs_data_put+0x25c/0x320 age=0 cpu=3 pid=4650
free_debug_processing+0x22c/0x434
__slab_free+0x2d8/0x3a0
kfree+0x254/0x264
ffs_data_put+0x25c/0x320
ffs_data_closed+0x124/0x15c
ffs_fs_kill_sb+0xb8/0x110
deactivate_locked_super+0x6c/0x98
deactivate_super+0xb0/0xbc
INFO: Object 0xffc057938600 @offset=1536 fp=0x  (null)
..
Call trace:
[] dump_backtrace+0x0/0x250
[] show_stack+0x14/0x1c
[] dump_stack+0xa0/0xc8
[] print_trailer+0x158/0x260
[] object_err+0x3c/0x40
[] kasan_report_error+0x2a8/0x754
[] kasan_report+0x5c/0x60
[] __asan_load4+0x70/0x88
[] refcount_dec_and_test+0x14/0xe0
[] ffs_data_put+0x80/0x320
[] ffs_fs_kill_sb+0xc8/0x110
[] deactivate_locked_super+0x6c/0x98
[] deactivate_super+0xb0/0xbc
[] cleanup_mnt+0x64/0xec
[] __cleanup_mnt+0x10/0x18
[] task_work_run+0xcc/0x124
[] do_notify_resume+0x60/0x70
[] work_pending+0x10/0x14

Cc: sta...@vger.kernel.org
Signed-off-by: Xinyong 
---
 drivers/usb/gadget/function/f_fs.c |1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/usb/gadget/function/f_fs.c 
b/drivers/usb/gadget/function/f_fs.c
index c2592d8..d2428a9 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1538,7 +1538,6 @@ static int ffs_fs_parse_opts(struct ffs_sb_fill_data 
*data, char *opts)
if (sb->s_fs_info) {
ffs_release_dev(sb->s_fs_info);
ffs_data_closed(sb->s_fs_info);
-   ffs_data_put(sb->s_fs_info);
}
 }
 
-- 
1.7.9.5

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

[PATCH v6 04/12] usb: common: Small class for USB role switches

[Hans de Goede]

From: Heikki Krogerus 

USB role switch is a device that can be used to choose the
data role for USB connector. With dual-role capable USB
controllers, the controller itself will be the switch, but
on some platforms the USB host and device controllers are
separate IPs and there is a mux between them and the
connector. On those platforms the mux driver will need to
register the switch.

With USB Type-C connectors, the host-to-device relationship
is negotiated over the Configuration Channel (CC). That
means the USB Type-C drivers need to be in control of the
role switch. The class provides a simple API for the USB
Type-C drivers for the control.

For other types of USB connectors (mainly microAB) the class
provides user space control via sysfs attribute file that
can be used to request role swapping from the switch.

Signed-off-by: Heikki Krogerus 
Reviewed-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
---
Changes in v4:
-Consistently use IS_ERR_OR_NULL where applicable
-Add Andy's Reviewed-by

Changes in v2:
-Minor style fixes from review of v1
---
 Documentation/ABI/testing/sysfs-class-usb_role |  21 ++
 drivers/usb/Kconfig|   3 +
 drivers/usb/common/Makefile|   1 +
 drivers/usb/common/roles.c | 305 +
 include/linux/usb/role.h   |  51 +
 5 files changed, 381 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-class-usb_role
 create mode 100644 drivers/usb/common/roles.c
 create mode 100644 include/linux/usb/role.h

diff --git a/Documentation/ABI/testing/sysfs-class-usb_role 
b/Documentation/ABI/testing/sysfs-class-usb_role
new file mode 100644
index ..3b810a425a52
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-usb_role
@@ -0,0 +1,21 @@
+What:  /sys/class/usb_role/
+Date:  Jan 2018
+Contact:   Heikki Krogerus 
+Description:
+   Place in sysfs for USB Role Switches. USB Role Switch is a
+   device that can select the data role (host or device) for USB
+   port.
+
+What:  /sys/class/usb_role//role
+Date:  Jan 2018
+Contact:   Heikki Krogerus 
+Description:
+   The current role of the switch. This attribute can be used for
+   requesting role swapping with non-USB Type-C ports. With USB
+   Type-C ports, the ABI defined for USB Type-C connector class
+   must be used.
+
+   Valid values:
+   - none
+   - host
+   - device
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 148f3ee70286..f278958e04ca 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -203,4 +203,7 @@ config USB_ULPI_BUS
  To compile this driver as a module, choose M here: the module will
  be called ulpi.
 
+config USB_ROLE_SWITCH
+   tristate
+
 endif # USB_SUPPORT
diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
index 0a7c45e85481..fb4d5ef4165c 100644
--- a/drivers/usb/common/Makefile
+++ b/drivers/usb/common/Makefile
@@ -9,3 +9,4 @@ usb-common-$(CONFIG_USB_LED_TRIG) += led.o
 
 obj-$(CONFIG_USB_OTG_FSM) += usb-otg-fsm.o
 obj-$(CONFIG_USB_ULPI_BUS) += ulpi.o
+obj-$(CONFIG_USB_ROLE_SWITCH)  += roles.o
diff --git a/drivers/usb/common/roles.c b/drivers/usb/common/roles.c
new file mode 100644
index ..bd616042afca
--- /dev/null
+++ b/drivers/usb/common/roles.c
@@ -0,0 +1,305 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * USB Role Switch Support
+ *
+ * Copyright (C) 2018 Intel Corporation
+ * Author: Heikki Krogerus 
+ * Hans de Goede 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct class *role_class;
+
+struct usb_role_switch {
+   struct device dev;
+   struct mutex lock; /* device lock*/
+   enum usb_role role;
+
+   /* From descriptor */
+   struct device *usb2_port;
+   struct device *usb3_port;
+   struct device *udc;
+   usb_role_switch_set_t set;
+   usb_role_switch_get_t get;
+   bool allow_userspace_control;
+};
+
+#define to_role_switch(d)  container_of(d, struct usb_role_switch, dev)
+
+/**
+ * usb_role_switch_set_role - Set USB role for a switch
+ * @sw: USB role switch
+ * @role: USB role to be switched to
+ *
+ * Set USB role @role for @sw.
+ */
+int usb_role_switch_set_role(struct usb_role_switch *sw, enum usb_role role)
+{
+   int ret;
+
+   if (IS_ERR_OR_NULL(sw))
+   return 0;
+
+   mutex_lock(>lock);
+
+   ret = sw->set(sw->dev.parent, role);
+   if (!ret)
+   sw->role = role;
+
+   mutex_unlock(>lock);
+
+   

[PATCH v6 05/12] usb: typec: tcpm: Set USB role switch to device mode when configured as such

[Hans de Goede]

Setting the mux to MUX_NONE and the switch to USB_SWITCH_DISCONNECT when
the data-role is device is not correct. Plenty of devices support
operating as USB device through a (separate) USB device controller.

We really need 2 different versions of USB_SWITCH_CONNECT,
USB_SWITCH_CONNECT_HOST and USB_SWITCH_DEVICE. Rather then modifying the
tcpc_usb_switch enum for this, simply remove it and switch to the
usb_role enum which provides exactly this, this will save use needing to
convert betweent the 2 enums when calling an usb-role-switch driver later.

Besides switching to the usb_role type, this commit also actually sets the
mux to TYPEC_MUX_USB and the switch to USB_ROLE_DEVICE instead of setting
both to none when the data-role is device.

This commit also makes tcpm_reset_port() call tcpm_mux_set(port,
TYPEC_MUX_NONE, USB_ROLE_NONE) so that the mux and switch
do _not_ stay in their last mode after a detach.

Reviewed-by: Heikki Krogerus 
Reviewed-by: Guenter Roeck 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
---
Changes in v4:
-Add Andy's Reviewed-by

Changes in v3:
-Add Guenter's Reviewed-by

Changes in v2:
-Added Heikki's Reviewed-by
---
 drivers/usb/typec/tcpm.c | 22 +++---
 include/linux/usb/tcpm.h |  8 ++--
 2 files changed, 13 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 7cd28b700a7f..00ca2822432f 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -618,15 +618,15 @@ void tcpm_pd_transmit_complete(struct tcpm_port *port,
 EXPORT_SYMBOL_GPL(tcpm_pd_transmit_complete);
 
 static int tcpm_mux_set(struct tcpm_port *port, enum tcpc_mux_mode mode,
-   enum tcpc_usb_switch config)
+   enum usb_role usb_role)
 {
int ret = 0;
 
-   tcpm_log(port, "Requesting mux mode %d, config %d, polarity %d",
-mode, config, port->polarity);
+   tcpm_log(port, "Requesting mux mode %d, usb-role %d, polarity %d",
+mode, usb_role, port->polarity);
 
if (port->tcpc->mux)
-   ret = port->tcpc->mux->set(port->tcpc->mux, mode, config,
+   ret = port->tcpc->mux->set(port->tcpc->mux, mode, usb_role,
   port->polarity);
 
return ret;
@@ -742,14 +742,15 @@ static int tcpm_set_attached_state(struct tcpm_port 
*port, bool attached)
 static int tcpm_set_roles(struct tcpm_port *port, bool attached,
  enum typec_role role, enum typec_data_role data)
 {
+   enum usb_role usb_role;
int ret;
 
if (data == TYPEC_HOST)
-   ret = tcpm_mux_set(port, TYPEC_MUX_USB,
-  TCPC_USB_SWITCH_CONNECT);
+   usb_role = USB_ROLE_HOST;
else
-   ret = tcpm_mux_set(port, TYPEC_MUX_NONE,
-  TCPC_USB_SWITCH_DISCONNECT);
+   usb_role = USB_ROLE_DEVICE;
+
+   ret = tcpm_mux_set(port, TYPEC_MUX_USB, usb_role);
if (ret < 0)
return ret;
 
@@ -2096,7 +2097,7 @@ static int tcpm_src_attach(struct tcpm_port *port)
 out_disable_pd:
port->tcpc->set_pd_rx(port->tcpc, false);
 out_disable_mux:
-   tcpm_mux_set(port, TYPEC_MUX_NONE, TCPC_USB_SWITCH_DISCONNECT);
+   tcpm_mux_set(port, TYPEC_MUX_NONE, USB_ROLE_NONE);
return ret;
 }
 
@@ -2140,6 +2141,7 @@ static void tcpm_reset_port(struct tcpm_port *port)
tcpm_init_vconn(port);
tcpm_set_current_limit(port, 0, 0);
tcpm_set_polarity(port, TYPEC_POLARITY_CC1);
+   tcpm_mux_set(port, TYPEC_MUX_NONE, USB_ROLE_NONE);
tcpm_set_attached_state(port, false);
port->try_src_count = 0;
port->try_snk_count = 0;
@@ -2190,8 +2192,6 @@ static int tcpm_snk_attach(struct tcpm_port *port)
 static void tcpm_snk_detach(struct tcpm_port *port)
 {
tcpm_detach(port);
-
-   /* XXX: (Dis)connect SuperSpeed mux? */
 }
 
 static int tcpm_acc_attach(struct tcpm_port *port)
diff --git a/include/linux/usb/tcpm.h b/include/linux/usb/tcpm.h
index ca1c0b57f03f..268721bff2c1 100644
--- a/include/linux/usb/tcpm.h
+++ b/include/linux/usb/tcpm.h
@@ -16,6 +16,7 @@
 #define __LINUX_USB_TCPM_H
 
 #include 
+#include 
 #include 
 #include "pd.h"
 
@@ -97,11 +98,6 @@ struct tcpc_config {
const struct typec_altmode_desc *alt_modes;
 };
 
-enum tcpc_usb_switch {
-   TCPC_USB_SWITCH_CONNECT,
-   TCPC_USB_SWITCH_DISCONNECT,
-};
-
 /* Mux state attributes */
 #define TCPC_MUX_USB_ENABLED   BIT(0)  /* USB enabled */
 #define TCPC_MUX_DP_ENABLEDBIT(1)  /* DP enabled */
@@ -118,7 +114,7 @@ enum tcpc_mux_mode {
 
 struct tcpc_mux_dev {
int (*set)(struct tcpc_mux_dev *dev, enum tcpc_mux_mode mux_mode,
-  enum tcpc_usb_switch usb_config,
+  enum usb_role 

[PATCH v6 06/12] usb: typec: tcpm: Use new Type-C switch/mux and usb-role-switch functions

[Hans de Goede]

Remove the unused (not implemented anywhere) tcpc_mux_dev abstraction
and replace it with calling the new typec_set_orientation,
usb_role_switch_set and typec_set_mode functions.

Reviewed-by: Heikki Krogerus 
Reviewed-by: Guenter Roeck 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
---
Changes in v4:
-Add Andy's Reviewed-by

Changes in v3:
-Add Guenter's Reviewed-by

Changes in v2:
-Added Heikki's Reviewed-by
---
 drivers/usb/typec/Kconfig   |  1 +
 drivers/usb/typec/fusb302/fusb302.c |  1 -
 drivers/usb/typec/tcpm.c| 46 -
 include/linux/usb/tcpm.h| 10 
 4 files changed, 36 insertions(+), 22 deletions(-)

diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index bcb2744c5977..a2a0684e7c82 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -48,6 +48,7 @@ if TYPEC
 config TYPEC_TCPM
tristate "USB Type-C Port Controller Manager"
depends on USB
+   select USB_ROLE_SWITCH
help
  The Type-C Port Controller Manager provides a USB PD and USB Type-C
  state machine for use with Type-C Port Controllers.
diff --git a/drivers/usb/typec/fusb302/fusb302.c 
b/drivers/usb/typec/fusb302/fusb302.c
index dcd8ef085b30..a7b06053a538 100644
--- a/drivers/usb/typec/fusb302/fusb302.c
+++ b/drivers/usb/typec/fusb302/fusb302.c
@@ -1249,7 +1249,6 @@ static void init_tcpc_dev(struct tcpc_dev 
*fusb302_tcpc_dev)
fusb302_tcpc_dev->set_roles = tcpm_set_roles;
fusb302_tcpc_dev->start_drp_toggling = tcpm_start_drp_toggling;
fusb302_tcpc_dev->pd_transmit = tcpm_pd_transmit;
-   fusb302_tcpc_dev->mux = NULL;
 }
 
 static const char * const cc_polarity_name[] = {
diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index 00ca2822432f..bfcaf6618a1f 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -176,6 +177,7 @@ struct tcpm_port {
struct typec_port *typec_port;
 
struct tcpc_dev *tcpc;
+   struct usb_role_switch *role_sw;
 
enum typec_role vconn_role;
enum typec_role pwr_role;
@@ -618,18 +620,25 @@ void tcpm_pd_transmit_complete(struct tcpm_port *port,
 EXPORT_SYMBOL_GPL(tcpm_pd_transmit_complete);
 
 static int tcpm_mux_set(struct tcpm_port *port, enum tcpc_mux_mode mode,
-   enum usb_role usb_role)
+   enum usb_role usb_role,
+   enum typec_orientation orientation)
 {
-   int ret = 0;
+   int ret;
 
-   tcpm_log(port, "Requesting mux mode %d, usb-role %d, polarity %d",
-mode, usb_role, port->polarity);
+   tcpm_log(port, "Requesting mux mode %d, usb-role %d, orientation %d",
+mode, usb_role, orientation);
 
-   if (port->tcpc->mux)
-   ret = port->tcpc->mux->set(port->tcpc->mux, mode, usb_role,
-  port->polarity);
+   ret = typec_set_orientation(port->typec_port, orientation);
+   if (ret)
+   return ret;
 
-   return ret;
+   if (port->role_sw) {
+   ret = usb_role_switch_set_role(port->role_sw, usb_role);
+   if (ret)
+   return ret;
+   }
+
+   return typec_set_mode(port->typec_port, mode);
 }
 
 static int tcpm_set_polarity(struct tcpm_port *port,
@@ -742,15 +751,21 @@ static int tcpm_set_attached_state(struct tcpm_port 
*port, bool attached)
 static int tcpm_set_roles(struct tcpm_port *port, bool attached,
  enum typec_role role, enum typec_data_role data)
 {
+   enum typec_orientation orientation;
enum usb_role usb_role;
int ret;
 
+   if (port->polarity == TYPEC_POLARITY_CC1)
+   orientation = TYPEC_ORIENTATION_NORMAL;
+   else
+   orientation = TYPEC_ORIENTATION_REVERSE;
+
if (data == TYPEC_HOST)
usb_role = USB_ROLE_HOST;
else
usb_role = USB_ROLE_DEVICE;
 
-   ret = tcpm_mux_set(port, TYPEC_MUX_USB, usb_role);
+   ret = tcpm_mux_set(port, TYPEC_MUX_USB, usb_role, orientation);
if (ret < 0)
return ret;
 
@@ -2097,7 +2112,8 @@ static int tcpm_src_attach(struct tcpm_port *port)
 out_disable_pd:
port->tcpc->set_pd_rx(port->tcpc, false);
 out_disable_mux:
-   tcpm_mux_set(port, TYPEC_MUX_NONE, USB_ROLE_NONE);
+   tcpm_mux_set(port, TYPEC_MUX_NONE, USB_ROLE_NONE,
+TYPEC_ORIENTATION_NONE);
return ret;
 }
 
@@ -2141,7 +2157,8 @@ static void tcpm_reset_port(struct tcpm_port *port)
tcpm_init_vconn(port);
tcpm_set_current_limit(port, 0, 0);
tcpm_set_polarity(port, TYPEC_POLARITY_CC1);
-   tcpm_mux_set(port, 

[PATCH v6 01/12] drivers: base: Unified device connection lookup

[Hans de Goede]

From: Heikki Krogerus 

Several frameworks - clk, gpio, phy, pmw, etc. - maintain
lookup tables for describing connections and provide custom
API for handling them. This introduces a single generic
lookup table and API for the connections.

The motivation for this commit is centralizing the
connection lookup, but the goal is to ultimately extract the
connection descriptions also from firmware by using the
fwnode_graph_* functions and other mechanisms that are
available.

Signed-off-by: Heikki Krogerus 
Reviewed-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
---
Changes in v6:
-Fix data and match arguments being swapped in __device_find_connection()
 call in device_find_connection() (as noticed by Jun Li)

Changes in v5:
-Add missing documentation for @list struct devcon member

Changes in v4:
-Add Andy's Reviewed-by

Changes in v3:
-Various spelling and gramar fixes in the docs pointed out by Randy Dunlap

Changes in v2:
-Add a (struct devcon) cast to the DEVCON() macro
---
 Documentation/driver-api/device_connection.rst |  43 
 drivers/base/Makefile  |   3 +-
 drivers/base/devcon.c  | 139 +
 include/linux/connection.h |  34 ++
 4 files changed, 218 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/driver-api/device_connection.rst
 create mode 100644 drivers/base/devcon.c
 create mode 100644 include/linux/connection.h

diff --git a/Documentation/driver-api/device_connection.rst 
b/Documentation/driver-api/device_connection.rst
new file mode 100644
index ..64a3e5e9bb7c
--- /dev/null
+++ b/Documentation/driver-api/device_connection.rst
@@ -0,0 +1,43 @@
+==
+Device connections
+==
+
+Introduction
+
+
+Devices often have connections to other devices that are outside of the direct
+child/parent relationship. A serial or network communication controller, which
+could be a PCI device, may need to be able to get a reference to its PHY
+component, which could be attached for example to the I2C bus. Some device
+drivers need to be able to control the clocks or the GPIOs for their devices,
+and so on.
+
+Device connections are generic descriptions of any type of connection between
+two separate devices.
+
+Device connections alone do not create a dependency between the two devices.
+They are only descriptions which are not tied to either of the devices 
directly.
+A dependency between the two devices exists only if one of the two endpoint
+devices requests a reference to the other. The descriptions themselves can be
+defined in firmware (not yet supported) or they can be built-in.
+
+Usage
+-
+
+Device connections should exist before device ``->probe`` callback is called 
for
+either endpoint device in the description. If the connections are defined in
+firmware, this is not a problem. It should be considered if the connection
+descriptions are "built-in", and need to be added separately.
+
+The connection description consists of the names of the two devices with the
+connection, i.e. the endpoints, and unique identifier for the connection which
+is needed if there are multiple connections between the two devices.
+
+After a description exists, the devices in it can request reference to the 
other
+endpoint device, or they can request the description itself.
+
+API
+---
+
+.. kernel-doc:: drivers/base/devcon.c
+   : functions: __device_find_connection device_find_connection 
add_device_connection remove_device_connection
diff --git a/drivers/base/Makefile b/drivers/base/Makefile
index e32a52490051..12a7f64d35a9 100644
--- a/drivers/base/Makefile
+++ b/drivers/base/Makefile
@@ -5,7 +5,8 @@ obj-y   := component.o core.o bus.o dd.o 
syscore.o \
   driver.o class.o platform.o \
   cpu.o firmware.o init.o map.o devres.o \
   attribute_container.o transport_class.o \
-  topology.o container.o property.o cacheinfo.o
+  topology.o container.o property.o cacheinfo.o \
+  devcon.o
 obj-$(CONFIG_DEVTMPFS) += devtmpfs.o
 obj-$(CONFIG_DMA_CMA) += dma-contiguous.o
 obj-y  += power/
diff --git a/drivers/base/devcon.c b/drivers/base/devcon.c
new file mode 100644
index ..9f13092fa115
--- /dev/null
+++ b/drivers/base/devcon.c
@@ -0,0 +1,139 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * Device connections
+ *
+ * Copyright (C) 2018 Intel Corporation
+ * Author: Heikki Krogerus 
+ */
+
+#include 
+#include 
+
+static DEFINE_MUTEX(devcon_lock);
+static LIST_HEAD(devcon_list);
+
+/**
+ * __device_find_connection - Find physical connection to a device
+ * @dev: Device with the 

[PATCH v6 08/12] xhci: Add Intel extended cap / otg phy mux handling

[Hans de Goede]

The xHCI controller on various Intel SoCs has an extended cap mmio-range
which contains registers to control the muxing to the xHCI (host mode)
or the dwc3 (device mode) and vbus-detection for the otg usb-phy.

Having a role-sw driver included in the xHCI code (under drivers/usb/host)
is not desirable. So this commit adds a simple handler for this extended
capability, which creates a platform device with the caps mmio region as
resource, this allows us to write a separate platform role-sw driver for
the role-switch.

Note this commit adds a call to the new xhci_ext_cap_init() function
to xhci_pci_probe(), it is added here because xhci_ext_cap_init() must
be called only once. If in the future we also want to handle ext-caps
on non pci xHCI HCDs from xhci_ext_cap_init() a call to it should also
be added to other bus probe paths.

Acked-by: Mathias Nyman 
Reviewed-by: Heikki Krogerus 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
---
Changes in v4:
-Add Andy's Reviewed-by

Changes in v2:
-Use SPDX license header
-Various small style cleanups / changes
-Add Heikki's Reviewed-by

Changes from some time ago when this patch was part of another patch-set:
-Check xHCI controller PCI device-id instead of only checking for the
 Intel Extended capability ID, as the Extended capability ID is used on
 other model Intel xHCI controllers too
-Add a new generic xhci_ext_cap_init() function and handle the new
 XHCI_INTEL_CHT_USB_MUX quirk there.
-Stop using Cherry Trail / CHT in various places as other Intel SoCs
 (e.g. Broxton / Apollo Lake) also have this
---
 drivers/usb/host/Makefile|  2 +-
 drivers/usb/host/xhci-ext-caps.c | 90 
 drivers/usb/host/xhci-ext-caps.h |  2 +
 drivers/usb/host/xhci-pci.c  |  5 +++
 drivers/usb/host/xhci.h  |  2 +
 5 files changed, 100 insertions(+), 1 deletion(-)
 create mode 100644 drivers/usb/host/xhci-ext-caps.c

diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 4ede4ce12366..8a8cffe0b445 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -11,7 +11,7 @@ fhci-y += fhci-mem.o fhci-tds.o fhci-sched.o
 
 fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o
 
-xhci-hcd-y := xhci.o xhci-mem.o
+xhci-hcd-y := xhci.o xhci-mem.o xhci-ext-caps.o
 xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o
 xhci-hcd-y += xhci-trace.o
 
diff --git a/drivers/usb/host/xhci-ext-caps.c b/drivers/usb/host/xhci-ext-caps.c
new file mode 100644
index ..399113f9fc5c
--- /dev/null
+++ b/drivers/usb/host/xhci-ext-caps.c
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * XHCI extended capability handling
+ *
+ * Copyright (c) 2017 Hans de Goede 
+ */
+
+#include 
+#include "xhci.h"
+
+#define USB_SW_DRV_NAME"intel_xhci_usb_sw"
+#define USB_SW_RESOURCE_SIZE   0x400
+
+static void xhci_intel_unregister_pdev(void *arg)
+{
+   platform_device_unregister(arg);
+}
+
+static int xhci_create_intel_xhci_sw_pdev(struct xhci_hcd *xhci, u32 
cap_offset)
+{
+   struct usb_hcd *hcd = xhci_to_hcd(xhci);
+   struct device *dev = hcd->self.controller;
+   struct platform_device *pdev;
+   struct resource res = { 0, };
+   int ret;
+
+   pdev = platform_device_alloc(USB_SW_DRV_NAME, PLATFORM_DEVID_NONE);
+   if (!pdev) {
+   xhci_err(xhci, "couldn't allocate %s platform device\n",
+USB_SW_DRV_NAME);
+   return -ENOMEM;
+   }
+
+   res.start = hcd->rsrc_start + cap_offset;
+   res.end   = res.start + USB_SW_RESOURCE_SIZE - 1;
+   res.name  = USB_SW_DRV_NAME;
+   res.flags = IORESOURCE_MEM;
+
+   ret = platform_device_add_resources(pdev, , 1);
+   if (ret) {
+   dev_err(dev, "couldn't add resources to intel_xhci_usb_sw 
pdev\n");
+   platform_device_put(pdev);
+   return ret;
+   }
+
+   pdev->dev.parent = dev;
+
+   ret = platform_device_add(pdev);
+   if (ret) {
+   dev_err(dev, "couldn't register intel_xhci_usb_sw pdev\n");
+   platform_device_put(pdev);
+   return ret;
+   }
+
+   ret = devm_add_action_or_reset(dev, xhci_intel_unregister_pdev, pdev);
+   if (ret) {
+   dev_err(dev, "couldn't add unregister action for 
intel_xhci_usb_sw pdev\n");
+   return ret;
+   }
+
+   return 0;
+}
+
+int xhci_ext_cap_init(struct xhci_hcd *xhci)
+{
+   void __iomem *base = >cap_regs->hc_capbase;
+   u32 offset, val;
+   int ret;
+
+   offset = xhci_find_next_ext_cap(base, 0, 0);
+
+   while (offset) {
+   val = readl(base + offset);
+
+   switch (XHCI_EXT_CAPS_ID(val)) {
+   case XHCI_EXT_CAPS_VENDOR_INTEL:
+   if (xhci->quirks & XHCI_INTEL_USB_ROLE_SW) {
+  

[PATCH v6 07/12] xhci: Add option to get next extended capability in list by passing id = 0

[Hans de Goede]

From: Mathias Nyman 

Modify xhci_find_next_ext_cap(base, offset, id) to return the next
capability offset if 0 is passed for id. Otherwise it will behave as
previously and return the offset of the next capability with matching id

capability id 0 is not used by xHCI (reserved)

This is useful when we want to loop through all capabilities.

Signed-off-by: Mathias Nyman 
Reviewed-by: Heikki Krogerus 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
---
Changes in v4:
-Add Andy's Reviewed-by

Changes in v2:
-Added Heikki's Reviewed-by
---
 drivers/usb/host/xhci-ext-caps.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/host/xhci-ext-caps.h b/drivers/usb/host/xhci-ext-caps.h
index bf7316e130d3..631e7cc62604 100644
--- a/drivers/usb/host/xhci-ext-caps.h
+++ b/drivers/usb/host/xhci-ext-caps.h
@@ -84,7 +84,8 @@
  * @base   PCI MMIO registers base address.
  * @start  address at which to start looking, (0 or HCC_PARAMS to start at
  * beginning of list)
- * @id Extended capability ID to search for.
+ * @id Extended capability ID to search for, or 0 for the next
+ * capability
  *
  * Returns the offset of the next matching extended capability structure.
  * Some capabilities can occur several times, e.g., the XHCI_EXT_CAPS_PROTOCOL,
@@ -110,7 +111,7 @@ static inline int xhci_find_next_ext_cap(void __iomem 
*base, u32 start, int id)
val = readl(base + offset);
if (val == ~0)
return 0;
-   if (XHCI_EXT_CAPS_ID(val) == id && offset != start)
+   if (offset != start && (id == 0 || XHCI_EXT_CAPS_ID(val) == id))
return offset;
 
next = XHCI_EXT_CAPS_NEXT(val);
-- 
2.14.3

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

[PATCH v6 10/12] usb: typec: driver for Pericom PI3USB30532 Type-C cross switch

[Hans de Goede]

Add a driver for the Pericom PI3USB30532 Type-C cross switch /
mux chip found on some devices with a Type-C port.

Reviewed-by: Heikki Krogerus 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
---
Changes in v4:
-Add Andy's Reviewed-by

Changes in v2:
-Cleanup pi3usb30532_set_conf() error handling
-Add Heikki's Reviewed-by

Changes in v1:
-This is a rewrite of my previous driver which was using the
 drivers/mux framework to use the new drivers/usb/typec/mux framework
---
 MAINTAINERS |   6 ++
 drivers/usb/typec/Kconfig   |   2 +
 drivers/usb/typec/Makefile  |   1 +
 drivers/usb/typec/mux/Kconfig   |  10 ++
 drivers/usb/typec/mux/Makefile  |   3 +
 drivers/usb/typec/mux/pi3usb30532.c | 178 
 6 files changed, 200 insertions(+)
 create mode 100644 drivers/usb/typec/mux/Kconfig
 create mode 100644 drivers/usb/typec/mux/Makefile
 create mode 100644 drivers/usb/typec/mux/pi3usb30532.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 0a18231fde06..08718a86aa83 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14529,6 +14529,12 @@ F: drivers/usb/
 F: include/linux/usb.h
 F: include/linux/usb/
 
+USB TYPEC PI3USB30532 MUX DRIVER
+M: Hans de Goede 
+L: linux-usb@vger.kernel.org
+S: Maintained
+F: drivers/usb/typec/mux/pi3usb30532.c
+
 USB TYPEC SUBSYSTEM
 M: Heikki Krogerus 
 L: linux-usb@vger.kernel.org
diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
index a2a0684e7c82..030f88cb0c3f 100644
--- a/drivers/usb/typec/Kconfig
+++ b/drivers/usb/typec/Kconfig
@@ -85,4 +85,6 @@ config TYPEC_TPS6598X
  If you choose to build this driver as a dynamically linked module, the
  module will be called tps6598x.ko.
 
+source "drivers/usb/typec/mux/Kconfig"
+
 endif # TYPEC
diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
index 56b2e9516ec1..1f599a6c30cc 100644
--- a/drivers/usb/typec/Makefile
+++ b/drivers/usb/typec/Makefile
@@ -6,3 +6,4 @@ obj-y   += fusb302/
 obj-$(CONFIG_TYPEC_WCOVE)  += typec_wcove.o
 obj-$(CONFIG_TYPEC_UCSI)   += ucsi/
 obj-$(CONFIG_TYPEC_TPS6598X)   += tps6598x.o
+obj-$(CONFIG_TYPEC)+= mux/
diff --git a/drivers/usb/typec/mux/Kconfig b/drivers/usb/typec/mux/Kconfig
new file mode 100644
index ..9a954d2b8d8f
--- /dev/null
+++ b/drivers/usb/typec/mux/Kconfig
@@ -0,0 +1,10 @@
+menu "USB Type-C Multiplexer/DeMultiplexer Switch support"
+
+config TYPEC_MUX_PI3USB30532
+   tristate "Pericom PI3USB30532 Type-C cross switch driver"
+   depends on I2C
+   help
+ Say Y or M if your system has a Pericom PI3USB30532 Type-C cross
+ switch / mux chip found on some devices with a Type-C port.
+
+endmenu
diff --git a/drivers/usb/typec/mux/Makefile b/drivers/usb/typec/mux/Makefile
new file mode 100644
index ..1332e469b8a0
--- /dev/null
+++ b/drivers/usb/typec/mux/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+obj-$(CONFIG_TYPEC_MUX_PI3USB30532)+= pi3usb30532.o
diff --git a/drivers/usb/typec/mux/pi3usb30532.c 
b/drivers/usb/typec/mux/pi3usb30532.c
new file mode 100644
index ..86cda9f388f3
--- /dev/null
+++ b/drivers/usb/typec/mux/pi3usb30532.c
@@ -0,0 +1,178 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Pericom PI3USB30532 Type-C cross switch / mux driver
+ *
+ * Copyright (c) 2017-2018 Hans de Goede 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define PI3USB30532_CONF   0x00
+
+#define PI3USB30532_CONF_OPEN  0x00
+#define PI3USB30532_CONF_SWAP  0x01
+#define PI3USB30532_CONF_4LANE_DP  0x02
+#define PI3USB30532_CONF_USB3  0x04
+#define PI3USB30532_CONF_USB3_AND_2LANE_DP 0x06
+
+struct pi3usb30532 {
+   struct i2c_client *client;
+   struct mutex lock; /* protects the cached conf register */
+   struct typec_switch sw;
+   struct typec_mux mux;
+   u8 conf;
+};
+
+static int pi3usb30532_set_conf(struct pi3usb30532 *pi, u8 new_conf)
+{
+   int ret = 0;
+
+   if (pi->conf == new_conf)
+   return 0;
+
+   ret = i2c_smbus_write_byte_data(pi->client, PI3USB30532_CONF, new_conf);
+   if (ret) {
+   dev_err(>client->dev, "Error writing conf: %d\n", ret);
+   return ret;
+   }
+
+   pi->conf = new_conf;
+   return 0;
+}
+
+static int pi3usb30532_sw_set(struct typec_switch *sw,
+ enum typec_orientation orientation)
+{
+   struct pi3usb30532 *pi = container_of(sw, struct pi3usb30532, sw);
+   u8 new_conf;
+   int ret;
+
+   mutex_lock(>lock);
+   new_conf = pi->conf;
+
+   switch (orientation) {
+   case 

[PATCH v6 02/12] usb: typec: Start using ERR_PTR

[Hans de Goede]

From: Heikki Krogerus 

In order to allow the USB Type-C Class driver take care of
things like muxes and other possible dependencies for the
port drivers, returning ERR_PTR instead of NULL from the
registration functions in case of failure.

The reason for taking over control of the muxes for example
is because handling them in the port drivers would be just
boilerplate.

Signed-off-by: Heikki Krogerus 
Reviewed-by: Hans de Goede 
Reviewed-by: Guenter Roeck 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
---
Changes in v4:
-Add Andy's Reviewed-by

Changes in v3:
-Add Guenter's Reviewed-by

Changes in v2:
-Add IS_ERR_OR_NULL() checks to the unregister functions
---
 drivers/usb/typec/tcpm.c  | 16 +---
 drivers/usb/typec/tps6598x.c  | 15 ---
 drivers/usb/typec/typec.c | 44 +--
 drivers/usb/typec/ucsi/ucsi.c | 31 ++
 4 files changed, 58 insertions(+), 48 deletions(-)

diff --git a/drivers/usb/typec/tcpm.c b/drivers/usb/typec/tcpm.c
index f4d563ee7690..7cd28b700a7f 100644
--- a/drivers/usb/typec/tcpm.c
+++ b/drivers/usb/typec/tcpm.c
@@ -1044,7 +1044,7 @@ static int tcpm_pd_svdm(struct tcpm_port *port, const 
__le32 *payload, int cnt,
break;
case CMDT_RSP_ACK:
/* silently drop message if we are not connected */
-   if (!port->partner)
+   if (IS_ERR_OR_NULL(port->partner))
break;
 
switch (cmd) {
@@ -3743,8 +3743,8 @@ struct tcpm_port *tcpm_register_port(struct device *dev, 
struct tcpc_dev *tcpc)
port->port_type = tcpc->config->type;
 
port->typec_port = typec_register_port(port->dev, >typec_caps);
-   if (!port->typec_port) {
-   err = -ENOMEM;
+   if (IS_ERR(port->typec_port)) {
+   err = PTR_ERR(port->typec_port);
goto out_destroy_wq;
}
 
@@ -3753,15 +3753,17 @@ struct tcpm_port *tcpm_register_port(struct device 
*dev, struct tcpc_dev *tcpc)
 
i = 0;
while (paltmode->svid && i < ARRAY_SIZE(port->port_altmode)) {
-   port->port_altmode[i] =
- typec_port_register_altmode(port->typec_port,
- paltmode);
-   if (!port->port_altmode[i]) {
+   struct typec_altmode *alt;
+
+   alt = typec_port_register_altmode(port->typec_port,
+ paltmode);
+   if (IS_ERR(alt)) {
tcpm_log(port,
 "%s: failed to register port alternate 
mode 0x%x",
 dev_name(dev), paltmode->svid);
break;
}
+   port->port_altmode[i] = alt;
i++;
paltmode++;
}
diff --git a/drivers/usb/typec/tps6598x.c b/drivers/usb/typec/tps6598x.c
index 2719f5d382f7..37a15c14a6c6 100644
--- a/drivers/usb/typec/tps6598x.c
+++ b/drivers/usb/typec/tps6598x.c
@@ -158,15 +158,15 @@ static int tps6598x_connect(struct tps6598x *tps, u32 
status)
desc.identity = >partner_identity;
}
 
-   tps->partner = typec_register_partner(tps->port, );
-   if (!tps->partner)
-   return -ENODEV;
-
typec_set_pwr_opmode(tps->port, mode);
typec_set_pwr_role(tps->port, TPS_STATUS_PORTROLE(status));
typec_set_vconn_role(tps->port, TPS_STATUS_VCONN(status));
typec_set_data_role(tps->port, TPS_STATUS_DATAROLE(status));
 
+   tps->partner = typec_register_partner(tps->port, );
+   if (IS_ERR(tps->partner))
+   return PTR_ERR(tps->partner);
+
if (desc.identity)
typec_partner_set_identity(tps->partner);
 
@@ -175,7 +175,8 @@ static int tps6598x_connect(struct tps6598x *tps, u32 
status)
 
 static void tps6598x_disconnect(struct tps6598x *tps, u32 status)
 {
-   typec_unregister_partner(tps->partner);
+   if (!IS_ERR(tps->partner))
+   typec_unregister_partner(tps->partner);
tps->partner = NULL;
typec_set_pwr_opmode(tps->port, TYPEC_PWR_MODE_USB);
typec_set_pwr_role(tps->port, TPS_STATUS_PORTROLE(status));
@@ -418,8 +419,8 @@ static int tps6598x_probe(struct i2c_client *client)
tps->typec_cap.prefer_role = TYPEC_NO_PREFERRED_ROLE;
 
tps->port = typec_register_port(>dev, >typec_cap);
-   if (!tps->port)
-   return -ENODEV;
+   if (IS_ERR(tps->port))
+   return PTR_ERR(tps->port);
 
if (status & TPS_STATUS_PLUG_PRESENT) {
ret = 

[PATCH v6 12/12] extcon: axp288: Set USB role where necessary

[Hans de Goede]

The AXP288 BC1.2 charger detection / extcon code may seem like a strange
place to add code to control the USB role-switch on devices with an AXP288,
but there are 2 reasons to do this inside the axp288 extcon code:

1) On many devices the USB role is controlled by ACPI AML code, but the AML
   code only switches between the host and none roles, because of Windows
   not really using device mode. To make device mode work we need to toggle
   between the none/device roles based on Vbus presence, and the axp288
   extcon gets interrupts on Vbus insertion / removal.

2) In order for our BC1.2 charger detection to work properly the role
   mux must be properly set to device mode before we do the detection.

Also note the Kconfig help-text / obsolete depends on USB_PHY which are
remnants from older never upstreamed code also controlling the mux from
the axp288 extcon code.

This commit also adds code to get notifications from the INT3496 extcon
device, which is used on some devices to notify the kernel about id-pin
changes instead of them being handled through AML code.

This fixes:
-Device mode not working on most CHT devices with an AXP288
-Host mode not working on devices with an INT3496 ACPI device
-Charger-type misdetection (always SDP) on devices with an INT3496 when the
 USB role (always) gets initialized as host

Reviewed-by: Heikki Krogerus 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
---
Changes in v4:
-Add Andy's Reviewed-by

Changes in v2:
-Add depends on X86 to Kconfig (the AXP288 PMIC is only used on X86)
-Use new acpi_dev_get_first_match_name() helper to get the INT3496 device-name
-Add Heikki's Reviewed-by
---
 drivers/extcon/Kconfig |   3 +-
 drivers/extcon/extcon-axp288.c | 177 +++--
 2 files changed, 171 insertions(+), 9 deletions(-)

diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index a7bca4207f44..de15bf55895b 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -30,7 +30,8 @@ config EXTCON_ARIZONA
 
 config EXTCON_AXP288
tristate "X-Power AXP288 EXTCON support"
-   depends on MFD_AXP20X && USB_PHY
+   depends on MFD_AXP20X && USB_SUPPORT && X86
+   select USB_ROLE_SWITCH
help
  Say Y here to enable support for USB peripheral detection
  and USB MUX switching by X-Power AXP288 PMIC.
diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
index 3ec4c715e240..51e77c7a32c2 100644
--- a/drivers/extcon/extcon-axp288.c
+++ b/drivers/extcon/extcon-axp288.c
@@ -1,6 +1,7 @@
 /*
  * extcon-axp288.c - X-Power AXP288 PMIC extcon cable detection driver
  *
+ * Copyright (c) 2017-2018 Hans de Goede 
  * Copyright (C) 2015 Intel Corporation
  * Author: Ramakrishna Pallala 
  *
@@ -14,6 +15,8 @@
  * GNU General Public License for more details.
  */
 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -25,6 +28,11 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+
+#include 
+#include 
 
 /* Power source status register */
 #define PS_STAT_VBUS_TRIGGER   BIT(0)
@@ -97,9 +105,19 @@ struct axp288_extcon_info {
struct device *dev;
struct regmap *regmap;
struct regmap_irq_chip_data *regmap_irqc;
+   struct usb_role_switch *role_sw;
+   struct work_struct role_work;
int irq[EXTCON_IRQ_END];
struct extcon_dev *edev;
+   struct extcon_dev *id_extcon;
+   struct notifier_block id_nb;
unsigned int previous_cable;
+   bool vbus_attach;
+};
+
+static const struct x86_cpu_id cherry_trail_cpu_ids[] = {
+   { X86_VENDOR_INTEL, 6, INTEL_FAM6_ATOM_AIRMONT, X86_FEATURE_ANY },
+   {}
 };
 
 /* Power up/down reason string array */
@@ -137,20 +155,74 @@ static void axp288_extcon_log_rsi(struct 
axp288_extcon_info *info)
regmap_write(info->regmap, AXP288_PS_BOOT_REASON_REG, clear_mask);
 }
 
-static int axp288_handle_chrg_det_event(struct axp288_extcon_info *info)
+/*
+ * The below code to control the USB role-switch on devices with an AXP288
+ * may seem out of place, but there are 2 reasons why this is the best place
+ * to control the USB role-switch on such devices:
+ * 1) On many devices the USB role is controlled by AML code, but the AML code
+ *only switches between the host and none roles, because of Windows not
+ *really using device mode. To make device mode work we need to toggle
+ *between the none/device roles based on Vbus presence, and this driver
+ *gets interrupts on Vbus insertion / removal.
+ * 2) In order for our BC1.2 charger detection to work properly the role
+ *mux must be properly set to device mode before we do the detection.
+ */
+
+/* Returns the id-pin value, note pulled low / false == host-mode */
+static bool axp288_get_id_pin(struct axp288_extcon_info *info)
 {
-   int ret, stat, cfg, 

[PATCH v6 03/12] usb: typec: API for controlling USB Type-C Multiplexers

[Hans de Goede]

From: Heikki Krogerus 

USB Type-C connectors consist of various muxes and switches
that route the pins on the connector to the right locations.
The USB Type-C drivers need to be able to control the muxes,
as they are the ones that know things like the cable plug
orientation, and the current mode that was negotiated with
the partner.

This introduces a small API for registering and controlling
cable plug orientation switches, and separate small API for
registering and controlling pin multiplexer/demultiplexer
switches that are needed with Accessory/Alternate Modes.

Signed-off-by: Heikki Krogerus 
Reviewed-by: Hans de Goede 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
---
Changes in v4:
-Add Andy's Reviewed-by

Changes in v3:
-Add #include-s for a few missing headers to drivers/usb/typec/mux.c
-Various spelling and gramar fixes in the docs pointed out by Randy Dunlap
---
 Documentation/driver-api/usb/typec.rst |  73 +++--
 drivers/usb/typec/Makefile |   1 +
 drivers/usb/typec/{typec.c => class.c} |  70 
 drivers/usb/typec/mux.c| 190 +
 include/linux/usb/typec.h  |  14 +++
 include/linux/usb/typec_mux.h  |  55 ++
 6 files changed, 392 insertions(+), 11 deletions(-)
 rename drivers/usb/typec/{typec.c => class.c} (95%)
 create mode 100644 drivers/usb/typec/mux.c
 create mode 100644 include/linux/usb/typec_mux.h

diff --git a/Documentation/driver-api/usb/typec.rst 
b/Documentation/driver-api/usb/typec.rst
index 8a7249f2ff04..feb31946490b 100644
--- a/Documentation/driver-api/usb/typec.rst
+++ b/Documentation/driver-api/usb/typec.rst
@@ -61,7 +61,7 @@ Registering the ports
 The port drivers will describe every Type-C port they control with struct
 typec_capability data structure, and register them with the following API:
 
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_register_port typec_unregister_port
 
 When registering the ports, the prefer_role member in struct typec_capability
@@ -80,7 +80,7 @@ typec_partner_desc. The class copies the details of the 
partner during
 registration. The class offers the following API for registering/unregistering
 partners.
 
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_register_partner typec_unregister_partner
 
 The class will provide a handle to struct typec_partner if the registration was
@@ -92,7 +92,7 @@ should include handle to struct usb_pd_identity instance. The 
class will then
 create a sysfs directory for the identity under the partner device. The result
 of Discover Identity command can then be reported with the following API:
 
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_partner_set_identity
 
 Registering Cables
@@ -113,7 +113,7 @@ typec_cable_desc and about a plug in struct 
typec_plug_desc. The class copies
 the details during registration. The class offers the following API for
 registering/unregistering cables and their plugs:
 
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_register_cable typec_unregister_cable typec_register_plug 
typec_unregister_plug
 
 The class will provide a handle to struct typec_cable and struct typec_plug if
@@ -125,7 +125,7 @@ include handle to struct usb_pd_identity instance. The 
class will then create a
 sysfs directory for the identity under the cable device. The result of Discover
 Identity command can then be reported with the following API:
 
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_cable_set_identity
 
 Notifications
@@ -135,7 +135,7 @@ When the partner has executed a role change, or when the 
default roles change
 during connection of a partner or cable, the port driver must use the following
 APIs to report it to the class:
 
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_set_data_role typec_set_pwr_role typec_set_vconn_role 
typec_set_pwr_opmode
 
 Alternate Modes
@@ -150,7 +150,7 @@ and struct typec_altmode_desc which is a container for all 
the supported modes.
 Ports that support Alternate Modes need to register each SVID they support with
 the following API:
 
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_port_register_altmode
 
 If a partner or cable plug provides a list of SVIDs as response to USB Power
@@ -159,12 +159,12 @@ registered.
 
 API for the partners:
 
-.. kernel-doc:: drivers/usb/typec/typec.c
+.. kernel-doc:: drivers/usb/typec/class.c
:functions: typec_partner_register_altmode
 
 API for the Cable Plugs:
 

[PATCH v6 11/12] platform/x86: intel_cht_int33fe: Add device connections for the Type-C port

[Hans de Goede]

We need to add device-connections for the Type-C mux/switch and usb-role
code to be able to find the PI3USB30532 Type-C cross-switch and the
device/host role-switch integrated in the CHT SoC.

Reviewed-by: Heikki Krogerus 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
---
Changes in v4:
-Replace Andy's Acked-by with his Reviewed-by

Changes in v2:
-Add Andy's Acked-by
-Add Heikki's Reviewed-by
---
 drivers/platform/x86/intel_cht_int33fe.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/drivers/platform/x86/intel_cht_int33fe.c 
b/drivers/platform/x86/intel_cht_int33fe.c
index 380ef7ec094f..a3f8674f14da 100644
--- a/drivers/platform/x86/intel_cht_int33fe.c
+++ b/drivers/platform/x86/intel_cht_int33fe.c
@@ -21,6 +21,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -33,6 +34,8 @@ struct cht_int33fe_data {
struct i2c_client *max17047;
struct i2c_client *fusb302;
struct i2c_client *pi3usb30532;
+   /* Contain a list-head must be per device */
+   struct devcon connections[3];
 };
 
 /*
@@ -172,6 +175,20 @@ static int cht_int33fe_probe(struct i2c_client *client)
return -EPROBE_DEFER; /* Wait for i2c-adapter to load */
}
 
+   data->connections[0].endpoint[0] = "i2c-fusb302";
+   data->connections[0].endpoint[1] = "i2c-pi3usb30532";
+   data->connections[0].id = "typec-switch";
+   data->connections[1].endpoint[0] = "i2c-fusb302";
+   data->connections[1].endpoint[1] = "i2c-pi3usb30532";
+   data->connections[1].id = "typec-mux";
+   data->connections[2].endpoint[0] = "i2c-fusb302";
+   data->connections[2].endpoint[1] = "intel_xhci_usb_sw-role-switch";
+   data->connections[2].id = "usb-role-switch";
+
+   add_device_connection(>connections[0]);
+   add_device_connection(>connections[1]);
+   add_device_connection(>connections[2]);
+
memset(_info, 0, sizeof(board_info));
strlcpy(board_info.type, "typec_fusb302", I2C_NAME_SIZE);
board_info.dev_name = "fusb302";
@@ -201,6 +218,10 @@ static int cht_int33fe_probe(struct i2c_client *client)
if (data->max17047)
i2c_unregister_device(data->max17047);
 
+   remove_device_connection(>connections[2]);
+   remove_device_connection(>connections[1]);
+   remove_device_connection(>connections[0]);
+
return -EPROBE_DEFER; /* Wait for the i2c-adapter to load */
 }
 
@@ -213,6 +234,10 @@ static int cht_int33fe_remove(struct i2c_client *i2c)
if (data->max17047)
i2c_unregister_device(data->max17047);
 
+   remove_device_connection(>connections[2]);
+   remove_device_connection(>connections[1]);
+   remove_device_connection(>connections[0]);
+
return 0;
 }
 
-- 
2.14.3

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

[PATCH v6 09/12] usb: roles: Add Intel xHCI USB role switch driver

[Hans de Goede]

Various Intel SoCs (Cherry Trail, Broxton and others) have an internal USB
role switch for swiching the OTG USB data lines between the xHCI host
controller and the dwc3 gadget controller.

Note on some Cherry Trail systems there is ACPI/AML code listening to
edge interrupts on the id-pin (through an _AIE ACPI method) and switching
the role between ROLE_HOST and ROLE_NONE based on the id-pin. Note it does
not set the role to ROLE_DEVICE, because device-mode is usually not used
under Windows.

The presence of AML code which modifies the cfg0 reg (on some systems)
means that our read/write/modify of cfg0 may race with the AML code
doing the same to avoid this we take the global ACPI lock while doing
the read/write/modify.

Reviewed-by: Andy Shevchenko 
Reviewed-by: Heikki Krogerus 
Signed-off-by: Hans de Goede 
---
Changes in v4:
-Add Andy's Reviewed-by
-Add Heikki's Reviewed-by

Changes in v2:
-Drop unnecessary depends on EXTCON from Kconfig
-Use BIT(), resource_size()
-Various other small style fixes
---
 MAINTAINERS|   6 +
 drivers/usb/Kconfig|   2 +
 drivers/usb/Makefile   |   2 +
 drivers/usb/roles/Kconfig  |  14 ++
 drivers/usb/roles/Makefile |   1 +
 drivers/usb/roles/intel-xhci-usb-role-switch.c | 192 +
 6 files changed, 217 insertions(+)
 create mode 100644 drivers/usb/roles/Kconfig
 create mode 100644 drivers/usb/roles/Makefile
 create mode 100644 drivers/usb/roles/intel-xhci-usb-role-switch.c

diff --git a/MAINTAINERS b/MAINTAINERS
index ac4d5471af43..0a18231fde06 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14393,6 +14393,12 @@ S: Maintained
 F: Documentation/hid/hiddev.txt
 F: drivers/hid/usbhid/
 
+USB INTEL XHCI ROLE MUX DRIVER
+M: Hans de Goede 
+L: linux-usb@vger.kernel.org
+S: Maintained
+F: drivers/usb/roles/intel-xhci-usb-role-switch.c
+
 USB ISP116X DRIVER
 M: Olav Kongas 
 L: linux-usb@vger.kernel.org
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index f278958e04ca..75f7fb151f71 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -171,6 +171,8 @@ source "drivers/usb/gadget/Kconfig"
 
 source "drivers/usb/typec/Kconfig"
 
+source "drivers/usb/roles/Kconfig"
+
 config USB_LED_TRIG
bool "USB LED Triggers"
depends on LEDS_CLASS && LEDS_TRIGGERS
diff --git a/drivers/usb/Makefile b/drivers/usb/Makefile
index 060643a1b5c8..7d1b8c82b208 100644
--- a/drivers/usb/Makefile
+++ b/drivers/usb/Makefile
@@ -65,3 +65,5 @@ obj-$(CONFIG_USB_COMMON)  += common/
 obj-$(CONFIG_USBIP_CORE)   += usbip/
 
 obj-$(CONFIG_TYPEC)+= typec/
+
+obj-$(CONFIG_USB_ROLE_SWITCH)  += roles/
diff --git a/drivers/usb/roles/Kconfig b/drivers/usb/roles/Kconfig
new file mode 100644
index ..f5a5e6f79f1b
--- /dev/null
+++ b/drivers/usb/roles/Kconfig
@@ -0,0 +1,14 @@
+if USB_ROLE_SWITCH
+
+config USB_ROLES_INTEL_XHCI
+   tristate "Intel XHCI USB Role Switch"
+   depends on ACPI && X86
+   help
+ Driver for the internal USB role switch for switching the USB data
+ lines between the xHCI host controller and the dwc3 gadget controller
+ found on various Intel SoCs.
+
+ To compile the driver as a module, choose M here: the module will
+ be called intel-xhci-usb-role-switch.
+
+endif # USB_ROLE_SWITCH
diff --git a/drivers/usb/roles/Makefile b/drivers/usb/roles/Makefile
new file mode 100644
index ..e44b179ba275
--- /dev/null
+++ b/drivers/usb/roles/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_USB_ROLES_INTEL_XHCI) += intel-xhci-usb-role-switch.o
diff --git a/drivers/usb/roles/intel-xhci-usb-role-switch.c 
b/drivers/usb/roles/intel-xhci-usb-role-switch.c
new file mode 100644
index ..3d7be5eace49
--- /dev/null
+++ b/drivers/usb/roles/intel-xhci-usb-role-switch.c
@@ -0,0 +1,192 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Intel XHCI (Cherry Trail, Broxton and others) USB OTG role switch driver
+ *
+ * Copyright (c) 2016-2017 Hans de Goede 
+ *
+ * Loosely based on android x86 kernel code which is:
+ *
+ * Copyright (C) 2014 Intel Corp.
+ *
+ * Author: Wu, Hao
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* register definition */
+#define DUAL_ROLE_CFG0 0x68
+#define SW_VBUS_VALID  BIT(24)
+#define SW_IDPIN_ENBIT(21)
+#define SW_IDPIN   BIT(20)
+
+#define DUAL_ROLE_CFG1 0x6c
+#define HOST_MODE  BIT(29)
+
+#define DUAL_ROLE_CFG1_POLL_TIMEOUT1000
+
+#define DRV_NAME   "intel_xhci_usb_sw"
+
+struct intel_xhci_usb_data {
+   struct usb_role_switch *role_sw;
+   void __iomem *base;
+};
+

[PATCH v6 00/12] USB Type-C device-connection, mux and switch support

[Hans de Goede]

Hi All,

Here is version 6 of Heikki's and my USB Type-C device-connection, mux and
switch support series. Versions 2 - 5 bring various small code and style
fixes based on review (no major changes). Version 6 is rebased on top of
the latest usb-next and brings one small but important code fix in
the devcon code.

Here is the original cover-letter of v1:

Some devices with an USB Type-C connector have a bunch of muxes
behind that connector which need to be controlled by the kernel (rather
then having them controlled by firmware as on most devices).

Quite a while back I submitted a patch-series to tie together these muxes
and the Type-C Port Manager (tcpm) code, using the then new drivers/mux
framework. But the way I used the mux framework went against what it was
designed for, so in the end that series got nowhere.

Heikki Krogerus from Intel, who maintains the USB TYPEC subsystem, has
recently been working on solving the same problem for some boards he is
doing hardware-enablement for.

Heikki has come up with a number of infrastructure patches for this.
The first one is a new device-connection framework. This solves the
problem of describing non bus device-links on x86 in what in my experience
with this problematic area is a really nice simple, clean and *generic*
way. This could for example in the near future also replace the custom
lookup code in the pwm subsys and the custom pwm_add_table() /
pwm_remove_table() functions.

The other 3 patches add a framework for the different type of Type-C /
USB "muxes".

Heikki and I have gone through a number of iterations of these patches
together and we believe these are now ready for merging. Since merging
infrastructure patches without users is not done and Heikki's own use-case
for these is not yet ready for merging, the rest of this series consists
of patches by me to make the Type-C connector found on some Cherry Trail
devices (finally) be able to actually work as an USB port and not just
a charge port.

The last patch uses the new usb-role-switch framework to also do proper
devcie / host switching on CHT devices with a USB micro AB connector.
This is also a big feature for CHT users, because before this they had
to do a reboot to get an OTG-host cable recognized (on some devices).

Part of this series is an usb-role-switch driver for the role-switch
found inside the xhci controller on e.g. CHT devices, this is currently
implemented as the generic xhci controller instantiating a platform
child-device for this, since this really is a separate chunk of HW
which happens to sit in the XHCI mmio space. This approach may not be
universally liked, given that in this new series the role-switch driver
is much smaller and does not have any external deps anymore we could
just integrate it into the xhci code if that is preferred.

About merging this series (once everything is reviewed, etc.), there are
quite some interdependencies in it esp. a lot of the patches depend on
the first patch. Luckily patches 1-10 all apply to subsystems which are
maintained by Greg (most to the USB subsys). Which just leaves patches
11 and 12 once 1-10 are merged. Greg, can you create an immutable branch
for the platform/x86 and extcon maintainers to merge once this is done?

Regards,

Hans
--
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: Don't disable Latency tolerance Messaging (LTM) before port reset

[Mathias Nyman]

On 01.03.2018 20:07, Alan Stern wrote:

On Thu, 1 Mar 2018, Mathias Nyman wrote:


Disabing Latency Tolerance Messaging before port reset is unnecessary.
LTM is automatically disabled at port reset.

If host can't communicate with the device the LTM message will fail, and
the hub driver will unnecessarily do a logical disconnect.
Broken communication is ofter the reason for a reset in the first place.

Additionally we can't guarantee device is in a configured state,
epecially in reset-resume case when root hub lost power.
LTM can't be modified unless device is in a configured state.

Just remove LTM disabling before port reset.


That definitely sounds like the right approach.


Details about LTM and port reset in USB 3 specification:

USB 3 spec section 9.4.5
"The LTM Enable field can be modified by the SetFeature() and
ClearFeature() requests using the LTM_ENABLE feature selector.
This field is reset to zero when the device is reset."

USB 3 spec section 9.4.1
"The device shall process a Clear Feature (U1_Enable or U2_Enable or
LTM_Enable) only if the device is in the configured state."

Signed-off-by: Mathias Nyman 


Acked-by: Alan Stern 


---
  drivers/usb/core/hub.c | 12 +++-
  1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index c5c1f6c..ac7bab7 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -5505,21 +5505,15 @@ static int usb_reset_and_verify_device(struct 
usb_device *udev)
if (udev->usb2_hw_lpm_enabled == 1)
usb_set_usb2_hardware_lpm(udev, 0);
  
-	/* Disable LPM and LTM while we reset the device and reinstall the alt

-* settings.  Device-initiated LPM settings, and system exit latency
-* settings are cleared when the device is reset, so we have to set
-* them up again.
+   /* Disable LPM while we reset the device and reinstall the alt settings.
+* Device-initiated LPM, and system exit latency settings are cleared
+* when the device is reset, so we have to set them up again.
 */


In theory, since you're changing this comment anyway, it could be
reformatted into the more commonly accepted form:

/*
 * blah, blah, blah
 * blah, blah, blah
 */

But it's not a big deal.


Good point.
I'm trying to get rid of LPM disable before reset as well, then we can get of 
the whole comment.
just need to do some LPM testing first.
 
-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 v5 12/12] extcon: axp288: Set USB role where necessary

[Hans de Goede]

Hi,

On 02-03-18 01:39, Chanwoo Choi wrote:

Hi,

Basically, I have no objection. But I'll reply the my ack tag
after finishing the review of 'devcon and usb_role_switch' from USB maintainer.

And I have a question.
Before this patch, extcon-axp288 is used to detect charger connector
and extcon-intel-int3496 is used to detect the USB_HOST connector
on one h/w device?


Yes the ACPI tables of some devices with an AXP288 PMIC have an INT3496
ACPI device which gives access to the id-pin on the micro-AB connector
which the extcon-intel-int3496 exports as a USB_HOST connector, on these
devices we fully control the USB role.

On other devices the switching of the USB data lines is controlled by AML
code which switches the data lines, but never sets the VBus valid bit
in the USB PHY control registers, so it is effectively switching between
between the host and none roles, since the device role only works when
the VBus valid bit is set.

This patch addresses both types of devices / ACPI tables and makes
host *and* device mode work. This patch also makes switching between them
by plugging in a different cable after boot work.

Regards,

Hans





Best Regards,
Chanwoo Choi
Samsung Electronics

On 2018년 03월 01일 00:07, Hans de Goede wrote:

The AXP288 BC1.2 charger detection / extcon code may seem like a strange
place to add code to control the USB role-switch on devices with an AXP288,
but there are 2 reasons to do this inside the axp288 extcon code:

1) On many devices the USB role is controlled by ACPI AML code, but the AML
code only switches between the host and none roles, because of Windows
not really using device mode. To make device mode work we need to toggle
between the none/device roles based on Vbus presence, and the axp288
extcon gets interrupts on Vbus insertion / removal.

2) In order for our BC1.2 charger detection to work properly the role
mux must be properly set to device mode before we do the detection.

Also note the Kconfig help-text / obsolete depends on USB_PHY which are
remnants from older never upstreamed code also controlling the mux from
the axp288 extcon code.

This commit also adds code to get notifications from the INT3496 extcon
device, which is used on some devices to notify the kernel about id-pin
changes instead of them being handled through AML code.

This fixes:
-Device mode not working on most CHT devices with an AXP288
-Host mode not working on devices with an INT3496 ACPI device
-Charger-type misdetection (always SDP) on devices with an INT3496 when the
  USB role (always) gets initialized as host

Reviewed-by: Heikki Krogerus 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Hans de Goede 
---
Changes in v4:
-Add Andy's Reviewed-by

Changes in v2:
-Add depends on X86 to Kconfig (the AXP288 PMIC is only used on X86)
-Use new acpi_dev_get_first_match_name() helper to get the INT3496 device-name
-Add Heikki's Reviewed-by
---
  drivers/extcon/Kconfig |   3 +-
  drivers/extcon/extcon-axp288.c | 177 +++--
  2 files changed, 171 insertions(+), 9 deletions(-)

diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index a7bca4207f44..de15bf55895b 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -30,7 +30,8 @@ config EXTCON_ARIZONA
  
  config EXTCON_AXP288

tristate "X-Power AXP288 EXTCON support"
-   depends on MFD_AXP20X && USB_PHY
+   depends on MFD_AXP20X && USB_SUPPORT && X86
+   select USB_ROLE_SWITCH
help
  Say Y here to enable support for USB peripheral detection
  and USB MUX switching by X-Power AXP288 PMIC.
diff --git a/drivers/extcon/extcon-axp288.c b/drivers/extcon/extcon-axp288.c
index 3ec4c715e240..51e77c7a32c2 100644
--- a/drivers/extcon/extcon-axp288.c
+++ b/drivers/extcon/extcon-axp288.c
@@ -1,6 +1,7 @@
  /*
   * extcon-axp288.c - X-Power AXP288 PMIC extcon cable detection driver
   *
+ * Copyright (c) 2017-2018 Hans de Goede 
   * Copyright (C) 2015 Intel Corporation
   * Author: Ramakrishna Pallala 
   *
@@ -14,6 +15,8 @@
   * GNU General Public License for more details.
   */
  
+#include 

+#include 
  #include 
  #include 
  #include 
@@ -25,6 +28,11 @@
  #include 
  #include 
  #include 
+#include 
+#include 
+
+#include 
+#include 
  
  /* Power source status register */

  #define PS_STAT_VBUS_TRIGGER  BIT(0)
@@ -97,9 +105,19 @@ struct axp288_extcon_info {
struct device *dev;
struct regmap *regmap;
struct regmap_irq_chip_data *regmap_irqc;
+   struct usb_role_switch *role_sw;
+   struct work_struct role_work;
int irq[EXTCON_IRQ_END];
struct extcon_dev *edev;
+   struct extcon_dev *id_extcon;
+   struct notifier_block id_nb;
unsigned int previous_cable;
+   bool vbus_attach;
+};
+
+static const struct x86_cpu_id 

Re: [PATCHv2] phy: mapphone-mdm6600: Add USB PHY driver for MDM6600 on Droid 4

[Kishon Vijay Abraham I]

Hi Tony,

On Thursday 01 March 2018 09:20 AM, Tony Lindgren wrote:
> Let's add support for the GPIO controlled USB PHY on the MDM6600 modem.
> It is used on some Motorola Mapphone series of phones and tablets such
> as Droid 4.

Generally PHY configuration is done for the PHYs that is connected to the USB
controllers in the SoC. In that sense it differs from the usual case by
programming the PHY in the device.
> 
> The MDM6600 is hardwired to the first OHCI port in the Droid 4 case, and
> is controlled by several GPIOs. The USB PHY is integrated into the MDM6600
> device it seems. We know this as we get L3 errors from omap-usb-host if
> trying to use the PHY before MDM6600 is configured.

Do you know what phy is connected to the OHCI port. Previously we've seen for
having USB devices on the board itself, phy less configurations was used.
> 
> The GPIOs controlling MDM6600 are used to power device on and off, to
> configure the USB start-up mode (normal mode versus USB flashing), and
> they also tell the state of the MDM6600 device.
> 
> The two start-up mode GPIOs are dual-purposed and used for out of band
> (OOB) wake-up for USB and TS 27.010 serial mux. But we need to configure
> the USB start-up mode first to get MDM6600 booted in the right mode to
> be usable in the first place.
> 
> Note that the Motorola Mapphone Linux kernel tree has a "radio-ctrl"
> driver for modems. But it really does not control the radio at all, it
> just controls the modem power and start-up mode for USB. So I came to
> the conclusion that we're better off having this done in the USB PHY
> driver. For adding support for USB flashing mode, we can later on add
> a kernel module option for flash_mode=1 or something similar.
> 
> Also note that currently there is no PM runtime support for the OHCI
> on omap variant SoCs. So for low(er) power idle states, currenty both
> ohci-platform and phy-mapphone-mdm6600 must be unloaded or unbound.
> 
> For reference here is what I measured for total power consumption on
> an idle Droid 4 with and without USB related MDM6600 modules:
> 
> idle lcd off  phy-mapphone-mdm6600ohci-platform
> 153mW 284mW   344mW
> 
> So it seems that MDM6600 is currently not yet idling even with it's
> radio turned off, but that's something that is beyond the control of
> this USB PHY driver. This patch does get us to the point where modem
> data and GPS are usable with libqmi and ModemManager for example.
> Voice calls need more audio driver work.
> 
> Cc: devicet...@vger.kernel.org
> Cc: Mark Rutland 
> Cc: Marcel Partap 
> Cc: Michael Scott 
> Cc: Rob Herring 
> Cc: Sebastian Reichel 
> Signed-off-by: Tony Lindgren 
> ---
> 
> Changes since v1:
> - Fixed up issues noticed by Rob and Sebastian
> - Implemented wake irq handler (for debug use only for now)
> - Improved error handling based on more testing
> 
> ---
>  .../bindings/phy/phy-mapphone-mdm6600.txt  |  30 ++
>  drivers/phy/motorola/Kconfig   |   9 +
>  drivers/phy/motorola/Makefile  |   1 +
>  drivers/phy/motorola/phy-mapphone-mdm6600.c| 556 
> +
>  4 files changed, 596 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
>  create mode 100644 drivers/phy/motorola/phy-mapphone-mdm6600.c
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt 
> b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-mapphone-mdm6600.txt
> @@ -0,0 +1,30 @@
> +Device tree binding documentation for Motorola Mapphone MDM6600 USB PHY
> +
> +Required properties:
> +- compatible Must be "motorola,mapphone-mdm6600"
> +- enable-gpios   GPIO to enable the USB PHY
> +- power-gpiosGPIO to power on the device
> +- reset-gpiosGPIO to reset the device
> +- motorola,mode-gpiosTwo GPIOs to configure MDM6600 USB start-up 
> mode for
> + normal mode versus USB flashing mode
> +- motorola,cmd-gpios Three GPIOs to control the power state of the MDM6600
> +- motorola,status-gpios  Three GPIOs to read the power state of the 
> MDM6600
> +
> +Example:
> +
> +usb-phy {
> + compatible = "motorola,mapphone-mdm6600";
> + enable-gpios = < 31 GPIO_ACTIVE_LOW>;
> + power-gpios = < 22 GPIO_ACTIVE_HIGH>;
> + reset-gpios = < 17 GPIO_ACTIVE_HIGH>;
> + motorola,mode-gpios = < 20 GPIO_ACTIVE_HIGH>,
> +   < 21 GPIO_ACTIVE_HIGH>;
> + motorola,cmd-gpios = < 7 GPIO_ACTIVE_HIGH>,
> +  < 8 GPIO_ACTIVE_HIGH>,
> +  < 14 GPIO_ACTIVE_HIGH>;
> + motorola,status-gpios = < 20 GPIO_ACTIVE_HIGH>,
> + < 21 GPIO_ACTIVE_HIGH>,