RE: [PATCH 2/2] phy: fsl-imx8mq-usb: handle resettable hubs

[Jun Li]

Hi,
> -Original Message-
> From: Adrien Grassein 
> Sent: Friday, January 29, 2021 6:13 AM
> Cc: kis...@ti.com; vk...@kernel.org; robh...@kernel.org; shawn...@kernel.org;
> s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com; 
> dl-linux-imx
> ; rikard.falkeb...@gmail.com; Peter Chen 
> ;
> Jun Li ; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Adrien
> Grassein 
> Subject: [PATCH 2/2] phy: fsl-imx8mq-usb: handle resettable hubs
> 
> Add an optional GPIO in the dtb description that will be used to reset the 
> connected
> hub (if any).

Put the external usb device reset in host phy driver, this may not
the right way, there was some attempts to handle this case(on board
hub), I am not sure what's the status now.

Li Jun

> 
> Signed-off-by: Adrien Grassein 
> ---
>  drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> index a29b4a6f7c24..00abf7814fe9 100644
> --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> @@ -4,6 +4,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -36,6 +37,7 @@ struct imx8mq_usb_phy {
>   struct clk *clk;
>   void __iomem *base;
>   struct regulator *vbus;
> + struct gpio_desc *reset_gpio;
>  };
> 
>  static int imx8mq_usb_phy_init(struct phy *phy) @@ -111,6 +113,9 @@ static 
> int
> imx8mq_phy_power_on(struct phy *phy)
>   if (ret)
>   return ret;
> 
> + if (imx_phy->reset_gpio)
> + gpiod_set_value_cansleep(imx_phy->reset_gpio, 0);
> +
>   return clk_prepare_enable(imx_phy->clk);  }
> 
> @@ -120,6 +125,8 @@ static int imx8mq_phy_power_off(struct phy *phy)
> 
>   clk_disable_unprepare(imx_phy->clk);
>   regulator_disable(imx_phy->vbus);
> + if (imx_phy->reset_gpio)
> + gpiod_set_value_cansleep(imx_phy->reset_gpio, 1);
> 
>   return 0;
>  }
> @@ -153,6 +160,7 @@ static int imx8mq_usb_phy_probe(struct platform_device 
> *pdev)
>   struct device *dev = >dev;
>   struct imx8mq_usb_phy *imx_phy;
>   const struct phy_ops *phy_ops;
> + int ret;
> 
>   imx_phy = devm_kzalloc(dev, sizeof(*imx_phy), GFP_KERNEL);
>   if (!imx_phy)
> @@ -180,6 +188,15 @@ static int imx8mq_usb_phy_probe(struct platform_device 
> *pdev)
>   if (IS_ERR(imx_phy->vbus))
>   return PTR_ERR(imx_phy->vbus);
> 
> + imx_phy->reset_gpio = devm_gpiod_get_optional(dev, "reset", 
> GPIOD_OUT_HIGH);
> + if (IS_ERR(imx_phy->reset_gpio)) {
> + ret = PTR_ERR(imx_phy->reset_gpio);
> + if (ret == -ENXIO || ret == -ENODEV)
> + imx_phy->reset_gpio = NULL;
> + else
> + return PTR_ERR(imx_phy->reset_gpio);
> + }
> +
>   phy_set_drvdata(imx_phy->phy, imx_phy);
> 
>   phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> --
> 2.25.1

Re: [RESEND PATCH v3 1/4] dt-bindings: connector: add power-opmode optional property to usb-connector

[Jun Li]

Amelie DELAUNAY  于2020年11月5日周四 下午7:36写道：
>
> On 11/4/20 10:08 PM, Rob Herring wrote:
> > On Fri, Oct 30, 2020 at 04:27:14PM +0100, Amelie DELAUNAY wrote:
> >>
> >>
> >> On 10/30/20 3:29 PM, Rob Herring wrote:
> >>> On Thu, Oct 29, 2020 at 11:49 AM Amelie DELAUNAY  
> >>> wrote:
> 
> 
> 
>  On 10/29/20 4:40 PM, Rob Herring wrote:
> > On Thu, Oct 29, 2020 at 10:58:03AM +0100, Amelie Delaunay wrote:
> >> Power operation mode may depends on hardware design, so, add the 
> >> optional
> >> property power-opmode for usb-c connector to select the power operation
> >> mode capability.
> >>
> >> Signed-off-by: Amelie Delaunay 
> >> ---
> >> .../bindings/connector/usb-connector.yaml  | 18 
> >> ++
> >> 1 file changed, 18 insertions(+)
> >>
> >> diff --git 
> >> a/Documentation/devicetree/bindings/connector/usb-connector.yaml 
> >> b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> >> index 728f82db073d..200d19c60fd5 100644
> >> --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
> >> +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> >> @@ -93,6 +93,24 @@ properties:
> >>   - device
> >>   - dual
> >>
> >> +  power-opmode:
> >
> > I've acked this version:
> >
> > https://lore.kernel.org/r/20201020093627.256885-2-bad...@google.com
> >
> 
>  frs is used for Fast Role Swap defined in USB PD spec.
>  I understand it allows to get the same information but I'm wondering why
>  the property name is limited to -frs- in this case. What about a
>  non-power delivery USB-C connector ?
> >>>
> >>> I've got no idea. The folks that know USB-C and PD details need to get
> >>> together and work all this out. To me, it looks like the same thing...
> >>>
> >>
> >> It looks but...
> >>
> >> The purpose of power-opmode property is to configure the USB-C controllers,
> >> especially the non-PD USB-C controllers to determine the power operation
> >> mode that the Type C connector will support and will advertise through CC
> >> pins when it has no power delivery support, whatever the power role: Sink,
> >> Source or Dual
> >> The management of the property is the same that data-role and power-role
> >> properties, and done by USB Type-C Connector Class.
> >>
> >> new-source-frs-typec-current specifies initial current capability of the 
> >> new
> >> source when vSafe5V is applied during PD3.0 Fast Role Swap. So here, this
> >> property is not applied at usb-c controller configuration level, but during
> >> PD Fast Role Swap, so when the Sink become the Source.
> >> Moreover, the related driver code says FRS can only be supported by DRP
> >> ports. So new-source-frs-typec-current property, in addition to being
> >> specific to PD, is also dedicated to DRP usb-c controller.
> >> The property is managed by Type-C Port Controller Manager for PD.
> >
> > But it's the same set of possible values, right? So we can align the
> > values at least.
> >
>
> USB Power Delivery FRS values are defined in
> include/dt-bindings/usb/pd.h

I think this can be changed if both can be aligned.

>to fit with drivers/usb/typec/tcpm/tcpm.c
> frs_typec_current enum.
>
> USB-C power operation mode values are defined in
> include/linux/usb/typec.h with typec_pwr_opmode enum and matching with
> string values of typec_pwr_opmodes tab.
>
> USB PD requires USB-C.
> USB-C doesn't requires USB PD.
>
> drivers/usb/typec/tcpm/tcpm.c already used typec_pwr_opmode values.
>
> USB PD specification Table 6-14 Fixed Supply PDO says:
> Fast Role Swap required USB Type-C Current (see also [USB Type-C 2.0]):
> Value | Description
>   00b  | Fast Swap not supported (default)
>   01b  | Default USB Power
>   10b  | 1.5A @ 5V
>   11b  | 3.0A @ 5V

This is the value in PDO of sink, the FRS property value(or after translated)
actually is used to compare with above value.

So I think both properties can share the same "value", maybe string
like below

  10 static const char * const typec_pwr_opmodes[] = {
  11 [TYPEC_PWR_MODE_USB]= "default",
  12 [TYPEC_PWR_MODE_1_5A]   = "1.5A",
  13 [TYPEC_PWR_MODE_3_0A]   = "3.0A",

>
> Note the *see also USB Type-C 2.0*.
>
> USB Type-C specification 4.6.2.1 USB Type-C Current says:
> The USB Type-C connector uses CC pins for configuration including an
> ability for a Source to advertise to its port partner (Sink) the amount
> of current it shall supply:
> • Default is the as-configured for high-power operation current value as
> defined by the USB Specification (500 mA for USB 2.0 ports; 900 mA or
> 1,500 mA for USB 3.2 ports in single-lane or dual-lane operation,
> respectively)
> • 1.5 A
> • 3.0 A
>
> > Can we align the names in some way? power-opmode and frs-source-opmode
> > or ??

how about typec-power-opmode and frs-new-source-opmode

> >
>
> I let USB PD specialists answer.

Re: [PATCH 29/29] arm64: dts: qcom: Harmonize DWC USB3 DT nodes name

[Jun Li]

Serge Semin  于2020年10月20日周二 下午8:04写道：
>
> In accordance with the DWC USB3 bindings the corresponding node
> name is suppose to comply with the Generic USB HCD DT schema, which
> requires the USB nodes to have the name acceptable by the regexp:
> "^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
> named.

This need a counterpart driver change:
drivers/usb/dwc3/dwc3-qcom.c
dwc3_np = of_get_child_by_name(np, "dwc3");

Li Jun

Re: [RESEND PATCH v3 1/4] dt-bindings: connector: add power-opmode optional property to usb-connector

[Jun Li]

Amelie DELAUNAY  于2020年10月30日周五 上午12:52写道：
>
>
>
> On 10/29/20 4:40 PM, Rob Herring wrote:
> > On Thu, Oct 29, 2020 at 10:58:03AM +0100, Amelie Delaunay wrote:
> >> Power operation mode may depends on hardware design, so, add the optional
> >> property power-opmode for usb-c connector to select the power operation
> >> mode capability.
> >>
> >> Signed-off-by: Amelie Delaunay 
> >> ---
> >>   .../bindings/connector/usb-connector.yaml  | 18 ++
> >>   1 file changed, 18 insertions(+)
> >>
> >> diff --git 
> >> a/Documentation/devicetree/bindings/connector/usb-connector.yaml 
> >> b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> >> index 728f82db073d..200d19c60fd5 100644
> >> --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
> >> +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> >> @@ -93,6 +93,24 @@ properties:
> >> - device
> >> - dual
> >>
> >> +  power-opmode:
> >
> > I've acked this version:
> >
> > https://lore.kernel.org/r/20201020093627.256885-2-bad...@google.com

That is a different property only for FRS.

> >
>
> frs is used for Fast Role Swap defined in USB PD spec.
> I understand it allows to get the same information but I'm wondering why
> the property name is limited to -frs- in this case. What about a
> non-power delivery USB-C connector ?

It's only for FRS, FRS is in the scope of power delivery.

>
> Moreover, power-opmode property support is already merged in typec class:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/typec/class.c?h=v5.10-rc1=12f3467b0d28369d3add7a0deb65fdac9b503c90
> and stusb160x driver uses it :(
>
> So, do I need to modify stusb160x driver (and bindings) to take into
> account this USB PD specific property?

Only Type-C w/o PD need this "power-opmode" property, so this
property is still required.

Li Jun

>
> Regards,
> Amelie
>
> > Please ack it if you are okay with it.
> >
> > Rob
> >
> >
> >> +description: Determines the power operation mode that the Type C 
> >> connector
> >> +  will support and will advertise through CC pins when it has no power
> >> +  delivery support.
> >> +  - "default" corresponds to default USB voltage and current defined 
> >> by the
> >> +USB 2.0 and USB 3.2 specifications, 5V 500mA for USB 2.0 ports and
> >> +5V 900mA or 1500mA for USB 3.2 ports in single-lane or dual-lane
> >> +operation respectively.
> >> +  - "1.5A" and "3.0A", 5V 1.5A and 5V 3.0A respectively, as defined 
> >> in USB
> >> +Type-C Cable and Connector specification, when Power Delivery is 
> >> not
> >> +supported.
> >> +allOf:
> >> +  - $ref: /schemas/types.yaml#definitions/string
> >> +enum:
> >> +  - default
> >> +  - 1.5A
> >> +  - 3.0A
> >> +
> >> # The following are optional properties for "usb-c-connector" with 
> >> power
> >> # delivery support.
> >> source-pdos:
> >> --
> >> 2.17.1
> >>

RE: [PATCH] usb: typec: tcpm: Fix if vbus before cc, hard_reset_count not reset issue

[Jun Li]

> -Original Message-
> From: ChiYuan Huang 
> Sent: Monday, October 12, 2020 2:23 PM
> To: Guenter Roeck 
> Cc: Jun Li ; Jun Li ; Greg KH
> ; Heikki Krogerus
> ; Linux USB List
> ; lkml ;
> cy_huang 
> Subject: Re: [PATCH] usb: typec: tcpm: Fix if vbus before cc, hard_reset_count
> not reset issue
> 
> Guenter Roeck  於 2020年10月11日 週日 上午3:31寫道：
> >
> > On 10/10/20 4:21 AM, Jun Li wrote:
> > >
> > >
> > >> -Original Message-
> > >> From: ChiYuan Huang 
> > >> Sent: Saturday, October 10, 2020 12:06 AM
> > >> To: Jun Li 
> > >> Cc: Jun Li ; Guenter Roeck
> > >> ; Greg KH ; Heikki
> > >> Krogerus ; Linux USB List
> > >> ; lkml ;
> > >> cy_huang 
> > >> Subject: Re: [PATCH] usb: typec: tcpm: Fix if vbus before cc,
> > >> hard_reset_count not reset issue
> > >>
> > >> Jun Li  於 2020年10月9日 週五 下午2:12寫道：
> > >>>
> > >>>
> > >>>
> > >>>> -Original Message-
> > >>>> From: ChiYuan Huang 
> > >>>> Sent: Wednesday, October 7, 2020 6:13 PM
> > >>>> To: Jun Li 
> > >>>> Cc: Guenter Roeck ; Greg KH
> > >>>> ; Heikki Krogerus
> > >>>> ; Linux USB List
> > >>>> ; lkml ;
> > >>>> cy_huang ; Jun Li 
> > >>>> Subject: Re: [PATCH] usb: typec: tcpm: Fix if vbus before cc,
> > >>>> hard_reset_count not reset issue
> > >>>>
> > >>>> ChiYuan Huang  於 2020年10月7日 週三 上午1:39
> 寫
> > >> 道：
> > >>>>>
> > >>>>> Jun Li  於 2020年10月7日 週三 上午12:52
> 寫
> > >> 道：
> > >>>>>>
> > >>>>>> ChiYuan Huang  于2020年10月6日周二 下午12:38
> > >> 写
> > >>>> 道：
> > >>>>>>>
> > >>>>>>> Guenter Roeck  於 2020年10月5日 週一 下午
> > >> 11:30
> > >>>> 寫道：
> > >>>>>>>>
> > >>>>>>>> On 10/5/20 4:08 AM, Greg KH wrote:
> > >>>>>>>> [ ... ]
> > >>>>>>>>>>> What ever happened with this patch, is there still disagreement?
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>> Yes, there is. I wouldn't have added the conditional
> > >>>>>>>>>> without reason, and I am concerned that removing it
> > >>>>>>>>>> entirely will open
> > >>>> another problem.
> > >>>>>>>>>> Feel free to apply, though - I can't prove that my concern
> > >>>>>>>>>> is valid, and after all we'll get reports from the field
> > >>>>>>>>>> later if
> > >>>> it is.
> > >>>>>>>>>
> > >>>>>>>>> Ok, can I get an ack so I know who to come back to in the
> > >>>>>>>>> future if there are issues?  :)
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> Not from me, for the reasons I stated. I would be ok with
> > >>>>>>>> something
> > >>>> like:
> > >>>>>>>>
> > >>>>>>>> -   if (tcpm_port_is_disconnected(port))
> > >>>>>>>> +   if (tcpm_port_is_disconnected(port) ||
> > >>>>>>>> +   (tcpm_cc_is_open(port->cc1) &&
> > >>>>>>>> + tcpm_cc_is_open(port->cc2)))
> > >>>>>>>>
> > >>>>>>>> to narrow down the condition.
> > >>>>>>>
> > >>>>>>> I have tried the above comment and It doesn't work.
> > >>>>>>> How about to change the judgement like as below
> > >>>>>>>
> > >>>>>>> -   if (tcpm_port_is_disconnected(port))
> > >>>>>>> +   if (tcpm_port_is_disconnected(port) ||
> > >>>>>>> + !port->vbus_present)
> > >>>>>>>
> > >>>>>>> The hard_reset_count not reset issue is following by the below
> > >>>>>>> 

RE: [PATCH] usb: typec: tcpm: Fix if vbus before cc, hard_reset_count not reset issue

[Jun Li]

> -Original Message-
> From: Guenter Roeck  On Behalf Of Guenter Roeck
> Sent: Sunday, October 11, 2020 3:32 AM
> To: Jun Li ; ChiYuan Huang 
> Cc: Jun Li ; Greg KH ;
> Heikki Krogerus ; Linux USB List
> ; lkml ;
> cy_huang 
> Subject: Re: [PATCH] usb: typec: tcpm: Fix if vbus before cc, hard_reset_count
> not reset issue
> 
> On 10/10/20 4:21 AM, Jun Li wrote:

...

> >>
> >> Like I mentioned before, whatever the condition is, hard_reset_count
> >> must be reset to zero during tcpm_detach.
> >
> > This may not be so correct as you said, I think Guenter's concern is valid.
> >
> > tcpm_detach() is not *only* be called in cases of *physical* detach
> > like the function name suggests.
> >
> > The current proposals may *wrongly* reset this counter.
> >
> > Let me give an example:
> >
> > HARD_RESET_SEND -> HARD_RESET_START -> SNK_HARD_RESET_SINK_OFF ->
> > SNK_HARD_RESET_WAIT_VBUS -> SNK_UNATTACHED(in case of VBUS doesn't
> > come back in expected duration)
> > -> call to tcpm_detach()
> >
> > In this sequence, does the sink need keep the counter? From the PD
> > spec, I think the answer is yes, sink need this counter to judge if
> > need do hard reset again or error recovery on later try, see:
> >
> > Figure 8-67 Sink Port State Diagram
> >
> > The difference between your case and my example, is your case never
> > turn off vbus, so will not go to SNK_UNATTACHED, so will not call to
> > tcpm_detach() after first hard reset.
> >
> > So
> > if (tcpm_port_is_disconnected(port))
> > port->hard_reset_count = 0;
> >
> > should keep as it is, the counter can only be cleared if there is
> > really physical disconnect by *partner*.
> >
> > But current tcpm code may have some problem on keeping local CC state
> > if there is hard reset on-going(port->hard_reset_count > 0), because
> > the current handling of SNK_UNATTACHED may cause disconnection
> > generated by *local*(partner actually keeps its CC), e.g. reset
> > polarity and do drp_toggling, this should be fixed, but this is
> > another patch, I can try to do this later.
> >
> > Back to your problem, I think the issue is, at the first tcpm_detach()
> > the cc disconnect event hasn't happen, so the reset counter is left
> > there but the port->attached is cleared, then the following(real
> > disconnect)
> > tcpm_detach() will just return directly due to port->attached is false.
> >
> > So I guess this will resolve your problem:
> >
> > @@ -2885,6 +2885,9 @@ static void tcpm_reset_port(struct tcpm_port
> > *port)
> >
> >  static void tcpm_detach(struct tcpm_port *port)  {
> > +   if (tcpm_port_is_disconnected(port))
> > +   port->hard_reset_count = 0;
> > +
> > if (!port->attached)
> > return;
> >
> > @@ -2893,9 +2896,6 @@ static void tcpm_detach(struct tcpm_port *port)
> > port->tcpc->set_bist_data(port->tcpc, false);
> > }
> >
> > -   if (tcpm_port_is_disconnected(port))
> > -   port->hard_reset_count = 0;
> > -
> > tcpm_reset_port(port);
> >  }
> >
> >
> > Compared with current code's condition:
> >3 static bool tcpm_port_is_disconnected(struct tcpm_port *port)
> >4 {
> >5 return (!port->attached && port->cc1 == TYPEC_CC_OPEN &&
> >6 port->cc2 == TYPEC_CC_OPEN) ||
> >7(port->attached && ((port->polarity ==
> TYPEC_POLARITY_CC1 &&
> >8 port->cc1 == TYPEC_CC_OPEN) ||
> >9(port->polarity ==
> TYPEC_POLARITY_CC2 &&
> >   10 port->cc2 == TYPEC_CC_OPEN)));
> >   11 }
> >
> > My above change is only adding another condition to clear the reset counter:
> > (!port->attached && port->cc1 == TYPEC_CC_OPEN && port->cc2 ==
> > TYPEC_CC_OPEN)
> >
> > This condition is close to Guenter's suggestion in this thread:
> >
> > -   if (tcpm_port_is_disconnected(port))
> > +   if (tcpm_port_is_disconnected(port) ||
> > +   (tcpm_cc_is_open(port->cc1) &&
> > + tcpm_cc_is_open(port->cc2)))
> >
> > Hi Guenter, any comments on this?
> >
> 
> That makes sense, and I would agree to the change you suggest above.

Thanks.

Li Jun
> 
> Guenter
> 
> > Thanks
> > Li Jun
> >
> >>
> >> But refer to Guenter's mail,  he prefer to narrow down the condition
> >> to reset this counter.
> >>
> >> I think the original thought is important why to put this line there.
> >>
> >> Hi, Guenter:
> >>From the discussion, we really need to know why you put the reset
> >> line below port attached is false and also make some judgement.
> >> I think there may be ome condition that we don't considered.
> >
> > This condition was added at first place, I think my above
> >>
> >>>
> >>>>
> >>>>>>>>
> >>>>>>>> Guenter

RE: [PATCH] usb: typec: tcpm: Fix if vbus before cc, hard_reset_count not reset issue

[Jun Li]

> -Original Message-
> From: ChiYuan Huang 
> Sent: Saturday, October 10, 2020 12:06 AM
> To: Jun Li 
> Cc: Jun Li ; Guenter Roeck ;
> Greg KH ; Heikki Krogerus
> ; Linux USB List
> ; lkml ;
> cy_huang 
> Subject: Re: [PATCH] usb: typec: tcpm: Fix if vbus before cc, hard_reset_count
> not reset issue
> 
> Jun Li  於 2020年10月9日 週五 下午2:12寫道：
> >
> >
> >
> > > -Original Message-
> > > From: ChiYuan Huang 
> > > Sent: Wednesday, October 7, 2020 6:13 PM
> > > To: Jun Li 
> > > Cc: Guenter Roeck ; Greg KH
> > > ; Heikki Krogerus
> > > ; Linux USB List
> > > ; lkml ;
> > > cy_huang ; Jun Li 
> > > Subject: Re: [PATCH] usb: typec: tcpm: Fix if vbus before cc,
> > > hard_reset_count not reset issue
> > >
> > > ChiYuan Huang  於 2020年10月7日 週三 上午1:39寫
> 道：
> > > >
> > > > Jun Li  於 2020年10月7日 週三 上午12:52寫
> 道：
> > > > >
> > > > > ChiYuan Huang  于2020年10月6日周二 下午12:38
> 写
> > > 道：
> > > > > >
> > > > > > Guenter Roeck  於 2020年10月5日 週一 下午
> 11:30
> > > 寫道：
> > > > > > >
> > > > > > > On 10/5/20 4:08 AM, Greg KH wrote:
> > > > > > > [ ... ]
> > > > > > > >>> What ever happened with this patch, is there still 
> > > > > > > >>> disagreement?
> > > > > > > >>>
> > > > > > > >>
> > > > > > > >> Yes, there is. I wouldn't have added the conditional
> > > > > > > >> without reason, and I am concerned that removing it
> > > > > > > >> entirely will open
> > > another problem.
> > > > > > > >> Feel free to apply, though - I can't prove that my
> > > > > > > >> concern is valid, and after all we'll get reports from
> > > > > > > >> the field later if
> > > it is.
> > > > > > > >
> > > > > > > > Ok, can I get an ack so I know who to come back to in the
> > > > > > > > future if there are issues?  :)
> > > > > > > >
> > > > > > >
> > > > > > > Not from me, for the reasons I stated. I would be ok with
> > > > > > > something
> > > like:
> > > > > > >
> > > > > > > -   if (tcpm_port_is_disconnected(port))
> > > > > > > +   if (tcpm_port_is_disconnected(port) ||
> > > > > > > +   (tcpm_cc_is_open(port->cc1) &&
> > > > > > > + tcpm_cc_is_open(port->cc2)))
> > > > > > >
> > > > > > > to narrow down the condition.
> > > > > >
> > > > > > I have tried the above comment and It doesn't work.
> > > > > > How about to change the judgement like as below
> > > > > >
> > > > > > -   if (tcpm_port_is_disconnected(port))
> > > > > > +   if (tcpm_port_is_disconnected(port) ||
> > > > > > + !port->vbus_present)
> > > > > >
> > > > > > The hard_reset_count not reset issue is following by the below
> > > > > > order 1. VBUS off ( at the same time, cc is still detected as
> > > > > > attached)
> > > > > > port->attached become false and cc is not open
> > > > > > 2. After that, cc detached.
> > > > > > due to port->attached is false, tcpm_detach() directly return.
> > > > >
> > > > > If tcpm_detach() return directly, then how your patch can reset
> > > > > hard_reset_count?
> > > > >
> > > > Yes, it can. We know vbus_present change from true to false and cc
> > > > detach both trigger tcpm_detach.
> > > > My change is whenever tcpm_detach to be called, hard_reset_count
> > > > will be reset to zero.
> > > >
> > > > > I am seeing the same issue on my platform, the proposed change:
> > > > > -   if (tcpm_port_is_disconnected(port))
> > > > > -   port->hard_reset_count = 0;
> > > > > +   port->hard_reset_count = 0;
> > > > > can't resolve it on my platform.
> > > > >
> > > > I'm not sure what's your condition. Could you directly paste the
> > >

RE: [PATCH] usb: typec: tcpm: Fix if vbus before cc, hard_reset_count not reset issue

[Jun Li]

> -Original Message-
> From: ChiYuan Huang 
> Sent: Wednesday, October 7, 2020 6:13 PM
> To: Jun Li 
> Cc: Guenter Roeck ; Greg KH
> ; Heikki Krogerus
> ; Linux USB List
> ; lkml ;
> cy_huang ; Jun Li 
> Subject: Re: [PATCH] usb: typec: tcpm: Fix if vbus before cc, hard_reset_count
> not reset issue
> 
> ChiYuan Huang  於 2020年10月7日 週三 上午1:39寫道：
> >
> > Jun Li  於 2020年10月7日 週三 上午12:52寫道：
> > >
> > > ChiYuan Huang  于2020年10月6日周二 下午12:38写
> 道：
> > > >
> > > > Guenter Roeck  於 2020年10月5日 週一 下午11:30
> 寫道：
> > > > >
> > > > > On 10/5/20 4:08 AM, Greg KH wrote:
> > > > > [ ... ]
> > > > > >>> What ever happened with this patch, is there still disagreement?
> > > > > >>>
> > > > > >>
> > > > > >> Yes, there is. I wouldn't have added the conditional without
> > > > > >> reason, and I am concerned that removing it entirely will open
> another problem.
> > > > > >> Feel free to apply, though - I can't prove that my concern is
> > > > > >> valid, and after all we'll get reports from the field later if
> it is.
> > > > > >
> > > > > > Ok, can I get an ack so I know who to come back to in the
> > > > > > future if there are issues?  :)
> > > > > >
> > > > >
> > > > > Not from me, for the reasons I stated. I would be ok with something
> like:
> > > > >
> > > > > -   if (tcpm_port_is_disconnected(port))
> > > > > +   if (tcpm_port_is_disconnected(port) ||
> > > > > +   (tcpm_cc_is_open(port->cc1) &&
> > > > > + tcpm_cc_is_open(port->cc2)))
> > > > >
> > > > > to narrow down the condition.
> > > >
> > > > I have tried the above comment and It doesn't work.
> > > > How about to change the judgement like as below
> > > >
> > > > -   if (tcpm_port_is_disconnected(port))
> > > > +   if (tcpm_port_is_disconnected(port) ||
> > > > + !port->vbus_present)
> > > >
> > > > The hard_reset_count not reset issue is following by the below
> > > > order 1. VBUS off ( at the same time, cc is still detected as
> > > > attached)
> > > > port->attached become false and cc is not open
> > > > 2. After that, cc detached.
> > > > due to port->attached is false, tcpm_detach() directly return.
> > >
> > > If tcpm_detach() return directly, then how your patch can reset
> > > hard_reset_count?
> > >
> > Yes, it can. We know vbus_present change from true to false and cc
> > detach both trigger tcpm_detach.
> > My change is whenever tcpm_detach to be called, hard_reset_count will
> > be reset to zero.
> >
> > > I am seeing the same issue on my platform, the proposed change:
> > > -   if (tcpm_port_is_disconnected(port))
> > > -   port->hard_reset_count = 0;
> > > +   port->hard_reset_count = 0;
> > > can't resolve it on my platform.
> > >
> > I'm not sure what's your condition. Could you directly paste the tcpm
> > log for the check?
> > > How about reset hard_reset_count in SNK_READY?
> > > @@ -3325,6 +3329,7 @@ static void run_state_machine(struct tcpm_port
> *port)
> > > case SNK_READY:
> > > port->try_snk_count = 0;
> > > port->update_sink_caps = false;
> > > +   port->hard_reset_count = 0;
> > > if (port->explicit_contract) {
> > > typec_set_pwr_opmode(port->typec_port,
> > >  TYPEC_PWR_MODE_PD);
> > >
> > > can this resolve your problem?
> > I'm not sure. It need to have a try, then I can answer you.
> > But from USBPD spec, the hard_reset_count need to reset zero only when
> > 1. At src state, pe_src_send_cap and receive GoodCRC 2. At snk state,
> > pe_snk_evaluate_cap need to reset hard_reset_count

3. 
8.3.3.3.8 PE_SNK_Hard_Reset state
"Note: The HardResetCounter is reset on a power cycle or Detach."

> > >
> > > Li Jun
> > > >
> > > > And that's why hard_reset_count is not reset to 0.
> 
> I tried in snk_ready to reset hard_reset_count.
> At normal case, it works.
> But it seems still the possible fail case like as below.
> 200ms -> cc debounce max time
> 240ms -> snk_waitcap max time
> If the plugin/out period is between (200+240) and (200+ 2* 240)ms , and the
> src side plug out like as the described scenario.
> From this case, hard_reset_count may still 1.
> And we expect the next plugin hard_reset_count is 0. But not, actually it
> never reset.
> So at next plugin, only one hard_reset will be sent and reach hard_reset_count
> max (2).
> 
> This case is hard to reproduce. But actually it's possible.

Make sense.

Then I propose doing this at SNK_UNATTACHED
@@ -3156,6 +3156,7 @@ static void run_state_machine(struct tcpm_port *port)
if (!port->non_pd_role_swap)
tcpm_swap_complete(port, -ENOTCONN);
tcpm_pps_complete(port, -ENOTCONN);
+   port->hard_reset_count = 0;
tcpm_snk_detach(port);
if (tcpm_start_toggling(port, TYPEC_CC_RD)) {
tcpm_set_state(port, TOGGLING, 0);
Li Jun

> 
> > > > >
> > > > > Guenter

RE: [PATCH] usb: typec: tcpm: Fix if vbus before cc, hard_reset_count not reset issue

[Jun Li]

> -Original Message-
> From: ChiYuan Huang 
> Sent: Wednesday, October 7, 2020 1:39 AM
> To: Jun Li 
> Cc: Guenter Roeck ; Greg KH
> ; Heikki Krogerus
> ; Linux USB List
> ; lkml ;
> cy_huang ; Jun Li 
> Subject: Re: [PATCH] usb: typec: tcpm: Fix if vbus before cc, hard_reset_count
> not reset issue
> 
> Jun Li  於 2020年10月7日 週三 上午12:52寫道：
> >
> > ChiYuan Huang  于2020年10月6日周二 下午12:38写道：
> > >
> > > Guenter Roeck  於 2020年10月5日 週一 下午11:30寫
> 道：
> > > >
> > > > On 10/5/20 4:08 AM, Greg KH wrote:
> > > > [ ... ]
> > > > >>> What ever happened with this patch, is there still disagreement?
> > > > >>>
> > > > >>
> > > > >> Yes, there is. I wouldn't have added the conditional without
> > > > >> reason, and I am concerned that removing it entirely will open 
> > > > >> another
> problem.
> > > > >> Feel free to apply, though - I can't prove that my concern is
> > > > >> valid, and after all we'll get reports from the field later if it
> is.
> > > > >
> > > > > Ok, can I get an ack so I know who to come back to in the future
> > > > > if there are issues?  :)
> > > > >
> > > >
> > > > Not from me, for the reasons I stated. I would be ok with something
> like:
> > > >
> > > > -   if (tcpm_port_is_disconnected(port))
> > > > +   if (tcpm_port_is_disconnected(port) ||
> > > > +   (tcpm_cc_is_open(port->cc1) &&
> > > > + tcpm_cc_is_open(port->cc2)))
> > > >
> > > > to narrow down the condition.
> > >
> > > I have tried the above comment and It doesn't work.
> > > How about to change the judgement like as below
> > >
> > > -   if (tcpm_port_is_disconnected(port))
> > > +   if (tcpm_port_is_disconnected(port) || !port->vbus_present)
> > >
> > > The hard_reset_count not reset issue is following by the below order
> > > 1. VBUS off ( at the same time, cc is still detected as attached)
> > > port->attached become false and cc is not open
> > > 2. After that, cc detached.
> > > due to port->attached is false, tcpm_detach() directly return.
> >
> > If tcpm_detach() return directly, then how your patch can reset
> > hard_reset_count?
> >
> Yes, it can. We know vbus_present change from true to false and cc detach
> both trigger tcpm_detach.
> My change is whenever tcpm_detach to be called, hard_reset_count will be
> reset to zero.

Your patch is based on the assumption that tcpm_detach() is called with
port->attached is true, but tcpm_reset_port() may happen before that,
in that case, tcpm_reset_port() clear port->attached flag so tcpm_detach
will return directly.

> 
> > I am seeing the same issue on my platform, the proposed change:
> > -   if (tcpm_port_is_disconnected(port))
> > -   port->hard_reset_count = 0;
> > +   port->hard_reset_count = 0;
> > can't resolve it on my platform.
> >
> I'm not sure what's your condition. Could you directly paste the tcpm log
> for the check?

[   47.127729] Setting voltage/current limit 0 mV 0 mA
[   47.127739] polarity 0
[   47.129333] Requesting mux state 0, usb-role 0, orientation 0
[   47.130516] state change SNK_READY -> SNK_UNATTACHED
[   47.131181] CC1: 0 -> 0, CC2: 3 -> 0 [state SNK_UNATTACHED, polarity 0, 
disconnected]
[   47.131194] state change SNK_UNATTACHED -> PORT_RESET
[   47.134701] Setting voltage/current limit 0 mV 0 mA
[   47.134709] polarity 0
[   47.136291] Requesting mux state 0, usb-role 0, orientation 0
[   47.136873] cc:=0
[   47.137446] pending state change PORT_RESET -> PORT_RESET_WAIT_OFF @ 100 ms
[   47.138084] CC1: 0 -> 0, CC2: 0 -> 0 [state PORT_RESET, polarity 0, 
disconnected]
[   47.239143] state change PORT_RESET -> PORT_RESET_WAIT_OFF [delayed 100 ms]
[   47.239151] state change PORT_RESET_WAIT_OFF -> SNK_UNATTACHED
[   47.239154] Entering tcpm_detach directly return here <
[   47.239157] Start toggling
[   47.240150] state change SNK_UNATTACHED -> TOGGLING

Li Jun
> > How about reset hard_reset_count in SNK_READY?
> > @@ -3325,6 +3329,7 @@ static void run_state_machine(struct tcpm_port
> *port)
> > case SNK_READY:
> > port->try_snk_count = 0;
> > port->update_sink_caps = false;
> > +   port->hard_reset_count = 0;
> > if (port->explicit_contract) {
> > typec_set_pwr_opmode(port->typec_port,
> >  TYPEC_PWR_MODE_PD);
> >
> > can this resolve your problem?
> I'm not sure. It need to have a try, then I can answer you.
> But from USBPD spec, the hard_reset_count need to reset zero only when 1.
> At src state, pe_src_send_cap and receive GoodCRC 2. At snk state,
> pe_snk_evaluate_cap need to reset hard_reset_count
> >
> > Li Jun
> > >
> > > And that's why hard_reset_count is not reset to 0.
> > > >
> > > > Guenter

Re: [PATCH] usb: typec: tcpm: Fix if vbus before cc, hard_reset_count not reset issue

[Jun Li]

ChiYuan Huang  于2020年10月6日周二 下午12:38写道：
>
> Guenter Roeck  於 2020年10月5日 週一 下午11:30寫道：
> >
> > On 10/5/20 4:08 AM, Greg KH wrote:
> > [ ... ]
> > >>> What ever happened with this patch, is there still disagreement?
> > >>>
> > >>
> > >> Yes, there is. I wouldn't have added the conditional without reason,
> > >> and I am concerned that removing it entirely will open another problem.
> > >> Feel free to apply, though - I can't prove that my concern is valid,
> > >> and after all we'll get reports from the field later if it is.
> > >
> > > Ok, can I get an ack so I know who to come back to in the future if
> > > there are issues?  :)
> > >
> >
> > Not from me, for the reasons I stated. I would be ok with something like:
> >
> > -   if (tcpm_port_is_disconnected(port))
> > +   if (tcpm_port_is_disconnected(port) ||
> > +   (tcpm_cc_is_open(port->cc1) && tcpm_cc_is_open(port->cc2)))
> >
> > to narrow down the condition.
>
> I have tried the above comment and It doesn't work.
> How about to change the judgement like as below
>
> -   if (tcpm_port_is_disconnected(port))
> +   if (tcpm_port_is_disconnected(port) || !port->vbus_present)
>
> The hard_reset_count not reset issue is following by the below order
> 1. VBUS off ( at the same time, cc is still detected as attached)
> port->attached become false and cc is not open
> 2. After that, cc detached.
> due to port->attached is false, tcpm_detach() directly return.

If tcpm_detach() return directly, then how your patch can reset
hard_reset_count?

I am seeing the same issue on my platform, the proposed change:
-   if (tcpm_port_is_disconnected(port))
-   port->hard_reset_count = 0;
+   port->hard_reset_count = 0;
can't resolve it on my platform.

How about reset hard_reset_count in SNK_READY?
@@ -3325,6 +3329,7 @@ static void run_state_machine(struct tcpm_port *port)
case SNK_READY:
port->try_snk_count = 0;
port->update_sink_caps = false;
+   port->hard_reset_count = 0;
if (port->explicit_contract) {
typec_set_pwr_opmode(port->typec_port,
 TYPEC_PWR_MODE_PD);

can this resolve your problem?

Li Jun
>
> And that's why hard_reset_count is not reset to 0.
> >
> > Guenter

Re: [PATCH v8 05/11] dt-bindings: connector: Add property to set initial current cap for FRS

[Jun Li]

Badhri Jagan Sridharan  于2020年9月24日周四 下午6:09写道：
>
> Hi Jun,
>
> Thanks for the feedback !
> The sink PDO from current source reflects the current source's(i.e.
> transmitter of the FRS signal) power requirement during fr swap.
> The current sink (i.e. receiver of the FRS signal) should check if it
> will be able to satisfy the current source's
> requirement during frswap before enabling the frs signal reception.
> The property in this patch refers to maximum current capability
> that the current sink can satisfy.

In this case I agree a new property is required.

Rob mentioned another similar property for typec[1], which is
for typec source(without power delivery) to define its power
capability to present its Rp, so a different usage.

[1]https://lore.kernel.org/linux-arm-kernel/20200902075707.9052-2-amelie.delau...@st.com/

> Perhaps, I should name it
> sink-frs-typec-current. Does that make sense to you ?

it looks better, thanks.

Li Jun
>
> Thanks,
> Badhri
>
> On Wed, Sep 23, 2020 at 3:43 AM Jun Li  wrote:
> >
> > Badhri Jagan Sridharan  于2020年9月22日周二 上午3:57写道：
> > >
> > > This change adds frs-typec-current which allows setting the initial 
> > > current
> > > capability of the new source when vSafe5V is applied during PD3.0
> > > sink Fast Role Swap.
> > >
> > > Signed-off-by: Badhri Jagan Sridharan 
> > > ---
> > > Changes since v1:
> > > - Changing patch version to v6 to fix version number confusion.
> > >
> > > Changes since v6:
> > > - Removed the redundant usb-connector.txt that I created by mistake.
> > > - Moved to yaml.
> > >
> > > Changes since v7:
> > > - Rebase
> > > ---
> > >  .../devicetree/bindings/connector/usb-connector.yaml   |  8 
> > >  include/dt-bindings/usb/pd.h   | 10 ++
> > >  2 files changed, 18 insertions(+)
> > >
> > > diff --git 
> > > a/Documentation/devicetree/bindings/connector/usb-connector.yaml 
> > > b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> > > index 9bd52e63c935..1ca8e6a337e5 100644
> > > --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
> > > +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> > > @@ -142,6 +142,14 @@ properties:
> > >  required:
> > >- port@0
> > >
> > > +  frs-typec-current:
> > > +description: Initial current capability of the new source when 
> > > vSafe5V
> > > +  is applied during PD3.0 Fast Role Swap. "Table 6-14 Fixed Supply 
> > > PDO - Sink"
> > > +  of "USB Power Delivery Specification Revision 3.0, Version 1.2" 
> > > provides the
> > > +  different power levels and "6.4.1.3.1.6 Fast Role Swap USB Type-C 
> > > Current"
> > > +  provides a detailed description of the field.
> > > +$ref: /schemas/types.yaml#/definitions/uint32
> >
> > If it's a part of sink PDO, I think you don't need a new property for this, 
> > just
> > define it directly into sink-pdos by adding a new PDO define for PD 3.0,
> > something like:
> >
> > sink-pdos =  > FRS_CURRENT_1P5A)>;
> >
> > Li Jun
> > > +
> > >  required:
> > >- compatible
> > >
> > > diff --git a/include/dt-bindings/usb/pd.h b/include/dt-bindings/usb/pd.h
> > > index 985f2bbd4d24..db1ad4532197 100644
> > > --- a/include/dt-bindings/usb/pd.h
> > > +++ b/include/dt-bindings/usb/pd.h
> > > @@ -35,6 +35,16 @@
> > >
> > >  #define VSAFE5V 5000 /* mv units */
> > >
> > > +/*
> > > + * Based on "Table 6-14 Fixed Supply PDO - Sink" of "USB Power Delivery 
> > > Specification Revision 3.0,
> > > + * Version 1.2"
> > > + * Initial current capability of the new source when vSafe5V is applied.
> > > + */
> > > +#define FRS_NOT_SUPPORTED  0
> > > +#define FRS_DEFAULT_POWER  1
> > > +#define FRS_5V_1P5A2
> > > +#define FRS_5V_3A  3
> > > +
> > >  #define PDO_BATT_MAX_VOLT_SHIFT20  /* 50mV units */
> > >  #define PDO_BATT_MIN_VOLT_SHIFT10  /* 50mV units */
> > >  #define PDO_BATT_MAX_PWR_SHIFT 0   /* 250mW units */
> > > --
> > > 2.28.0.681.g6f77f65b4e-goog
> > >

Re: [PATCH v8 05/11] dt-bindings: connector: Add property to set initial current cap for FRS

[Jun Li]

Badhri Jagan Sridharan  于2020年9月22日周二 上午3:57写道：
>
> This change adds frs-typec-current which allows setting the initial current
> capability of the new source when vSafe5V is applied during PD3.0
> sink Fast Role Swap.
>
> Signed-off-by: Badhri Jagan Sridharan 
> ---
> Changes since v1:
> - Changing patch version to v6 to fix version number confusion.
>
> Changes since v6:
> - Removed the redundant usb-connector.txt that I created by mistake.
> - Moved to yaml.
>
> Changes since v7:
> - Rebase
> ---
>  .../devicetree/bindings/connector/usb-connector.yaml   |  8 
>  include/dt-bindings/usb/pd.h   | 10 ++
>  2 files changed, 18 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml 
> b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> index 9bd52e63c935..1ca8e6a337e5 100644
> --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> @@ -142,6 +142,14 @@ properties:
>  required:
>- port@0
>
> +  frs-typec-current:
> +description: Initial current capability of the new source when vSafe5V
> +  is applied during PD3.0 Fast Role Swap. "Table 6-14 Fixed Supply PDO - 
> Sink"
> +  of "USB Power Delivery Specification Revision 3.0, Version 1.2" 
> provides the
> +  different power levels and "6.4.1.3.1.6 Fast Role Swap USB Type-C 
> Current"
> +  provides a detailed description of the field.
> +$ref: /schemas/types.yaml#/definitions/uint32

If it's a part of sink PDO, I think you don't need a new property for this, just
define it directly into sink-pdos by adding a new PDO define for PD 3.0,
something like:

sink-pdos = ;

Li Jun
> +
>  required:
>- compatible
>
> diff --git a/include/dt-bindings/usb/pd.h b/include/dt-bindings/usb/pd.h
> index 985f2bbd4d24..db1ad4532197 100644
> --- a/include/dt-bindings/usb/pd.h
> +++ b/include/dt-bindings/usb/pd.h
> @@ -35,6 +35,16 @@
>
>  #define VSAFE5V 5000 /* mv units */
>
> +/*
> + * Based on "Table 6-14 Fixed Supply PDO - Sink" of "USB Power Delivery 
> Specification Revision 3.0,
> + * Version 1.2"
> + * Initial current capability of the new source when vSafe5V is applied.
> + */
> +#define FRS_NOT_SUPPORTED  0
> +#define FRS_DEFAULT_POWER  1
> +#define FRS_5V_1P5A2
> +#define FRS_5V_3A  3
> +
>  #define PDO_BATT_MAX_VOLT_SHIFT20  /* 50mV units */
>  #define PDO_BATT_MIN_VOLT_SHIFT10  /* 50mV units */
>  #define PDO_BATT_MAX_PWR_SHIFT 0   /* 250mW units */
> --
> 2.28.0.681.g6f77f65b4e-goog
>

Re: [RESEND PATCH v2 1/6] dt-bindings: connector: add power-opmode optional property to usb-connector

[Jun Li]

Amelie DELAUNAY  于2020年9月23日周三 下午5:31写道：
>
>
>
> On 9/23/20 11:08 AM, Jun Li wrote:
> > Amelie Delaunay  于2020年9月2日周三 下午4:01写道：
> >>
> >> Power operation mode may depends on hardware design, so, add the optional
> >> property power-opmode for usb-c connector to select the power operation
> >> mode capability.
> >>
> >> Signed-off-by: Amelie Delaunay 
> >> ---
> >> Changes in v2:
> >> - Add description for possible operation current values
> >> ---
> >>   .../bindings/connector/usb-connector.yaml | 20 +++
> >>   1 file changed, 20 insertions(+)
> >>
> >> diff --git 
> >> a/Documentation/devicetree/bindings/connector/usb-connector.yaml 
> >> b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> >> index 9bd52e63c935..2fd85b9a7e1a 100644
> >> --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
> >> +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> >> @@ -88,6 +88,26 @@ properties:
> >> - device
> >> - dual
> >>
> >> +  power-opmode:
> >> +description: Determines the power operation mode that the Type C 
> >> connector
> >> +  will support and will advertise through CC pins.
> >> +  - "default" corresponds to default USB voltage and current defined 
> >> by the
> >> +USB 2.0 and USB 3.2 specifications, 5V 500mA for USB 2.0 ports and
> >> +5V 900mA or 1500mA for USB 3.2 ports in single-lane or dual-lane
> >> +operation respectively.
> >> +  - "1.5A" and "3.0A", 5V 1.5A and 5V 3.0A respectively, as defined 
> >> in USB
> >> +Type-C Cable and Connector specification, when Power Delivery is 
> >> not
> >> +supported.
> >> +  - "usb_power_delivery" when Power Delivery is supported, as defined 
> >> in
> >> +USB Power Delivery specification.
> >
> > Why need "usb_power_delivery"? isn't this information can be implied by
> > existing properties like if "source-pdos" is present?
> >
>
> power-opmode is an optional property.
> usb_power_delivery, as 3.0A, 1.5A or default here, only reflect the
> possible power operation mode you can set and that are understood by
> typec class:
> static const char * const typec_pwr_opmodes[] = {
> [TYPEC_PWR_MODE_USB]= "default",
> [TYPEC_PWR_MODE_1_5A]   = "1.5A",
> [TYPEC_PWR_MODE_3_0A]   = "3.0A",
> [TYPEC_PWR_MODE_PD] = "usb_power_delivery",
> };
>
> But I guess that a Type-C controller with usb power delivery support
> won't use power-opmode property but rather source/sink-pdos.
>
> power-opmode shows what will be advertised through CC pins. I can remove
> usb_power_delivery from the possible values, but what about the user who
> will add power-opmode property to configure his Type-C controller with
> USB power delivery support (sink and/or source by the way) ?

With power delivery support, this information should be abstracted from
source-pdos.

> Should I restrict the use of power-opmode to non-USB power delivery
> Type-C controllers ?

I think Yes. only need it for non-PD(power source/DRP).

Li Jun
> Please advise.
>
> Regards,
> Amelie
>
>
> > Li Jun
> >> +allOf:
> >> +  - $ref: /schemas/types.yaml#definitions/string
> >> +enum:
> >> +  - default
> >> +  - 1.5A
> >> +  - 3.0A
> >> +  - usb_power_delivery
> >> +
> >> # The following are optional properties for "usb-c-connector" with 
> >> power
> >> # delivery support.
> >> source-pdos:
> >> --
> >> 2.17.1
> >>

Re: [RESEND PATCH v2 1/6] dt-bindings: connector: add power-opmode optional property to usb-connector

[Jun Li]

Amelie Delaunay  于2020年9月2日周三 下午4:01写道：
>
> Power operation mode may depends on hardware design, so, add the optional
> property power-opmode for usb-c connector to select the power operation
> mode capability.
>
> Signed-off-by: Amelie Delaunay 
> ---
> Changes in v2:
> - Add description for possible operation current values
> ---
>  .../bindings/connector/usb-connector.yaml | 20 +++
>  1 file changed, 20 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml 
> b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> index 9bd52e63c935..2fd85b9a7e1a 100644
> --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml
> +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml
> @@ -88,6 +88,26 @@ properties:
>- device
>- dual
>
> +  power-opmode:
> +description: Determines the power operation mode that the Type C 
> connector
> +  will support and will advertise through CC pins.
> +  - "default" corresponds to default USB voltage and current defined by 
> the
> +USB 2.0 and USB 3.2 specifications, 5V 500mA for USB 2.0 ports and
> +5V 900mA or 1500mA for USB 3.2 ports in single-lane or dual-lane
> +operation respectively.
> +  - "1.5A" and "3.0A", 5V 1.5A and 5V 3.0A respectively, as defined in 
> USB
> +Type-C Cable and Connector specification, when Power Delivery is not
> +supported.
> +  - "usb_power_delivery" when Power Delivery is supported, as defined in
> +USB Power Delivery specification.

Why need "usb_power_delivery"? isn't this information can be implied by
existing properties like if "source-pdos" is present?

Li Jun
> +allOf:
> +  - $ref: /schemas/types.yaml#definitions/string
> +enum:
> +  - default
> +  - 1.5A
> +  - 3.0A
> +  - usb_power_delivery
> +
># The following are optional properties for "usb-c-connector" with power
># delivery support.
>source-pdos:
> --
> 2.17.1
>

RE: drivers/usb/chipidea/core.c:657 ci_usb_role_switch_set() error: double unlocked 'ci->lock' (orig line 638)

[Jun Li]

Hi,

> -Original Message-
> From: kernel test robot 
> Sent: Friday, August 7, 2020 6:00 PM
> To: Jun Li 
> Cc: kbuild-...@lists.01.org; linux-kernel@vger.kernel.org; Peter Chen
> 
> Subject: drivers/usb/chipidea/core.c:657 ci_usb_role_switch_set() error: 
> double
> unlocked 'ci->lock' (orig line 638)
> 
> tree:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.o
> rg%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.gitdata=02%7C01%
> 7Cjun.li%40nxp.com%7Ce261827f14f6446b3e8308d83ab8c407%7C686ea1d3bc2b4c6fa92cd9
> 9c5c301635%7C0%7C0%7C637323912694699319sdata=ioDexF9tIACz%2BlnZC%2BzZsiFz
> iOeeLembxqr9PwE%2Fpgg%3Dreserved=0 master
> head:   86cfccb66937dd6cbf26ed619958b9e587e6a115
> commit: 05559f10ed797b79f7fa47313682c48919a2b111 usb: chipidea: add role 
> switch
> class support
> date:   12 months ago
> config: parisc-randconfig-m031-20200807 (attached as .config)
> compiler: hppa-linux-gcc (GCC) 9.3.0
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
> 
> smatch warnings:
> drivers/usb/chipidea/core.c:657 ci_usb_role_switch_set() error: double 
> unlocked
> 'ci->lock' (orig line 638)
> 
> vim +657 drivers/usb/chipidea/core.c
> 
>615
>616static int ci_usb_role_switch_set(struct device *dev, enum 
> usb_role role)
>617{
>618struct ci_hdrc *ci = dev_get_drvdata(dev);
>619struct ci_hdrc_cable *cable = NULL;
>620enum usb_role current_role = ci_role_to_usb_role(ci);
>621unsigned long flags;
>622
>623if (current_role == role)
>624return 0;
>625
>626pm_runtime_get_sync(ci->dev);
>627/* Stop current role */
>628spin_lock_irqsave(>lock, flags);
>629if (current_role == USB_ROLE_DEVICE)
>630cable = >platdata->vbus_extcon;
>631else if (current_role == USB_ROLE_HOST)
>632cable = >platdata->id_extcon;
>633
>634if (cable) {
>635cable->changed = true;
>636cable->connected = false;
>637ci_irq(ci->irq, ci);
>  > 638spin_unlock_irqrestore(>lock, flags);
>639if (ci->wq && role != USB_ROLE_NONE)
>640flush_workqueue(ci->wq);
>641spin_lock_irqsave(>lock, flags);

Here we hold the lock again.

>642}
>643
>644cable = NULL;
>645
>646/* Start target role */
>647if (role == USB_ROLE_DEVICE)
>648cable = >platdata->vbus_extcon;
>649else if (role == USB_ROLE_HOST)
>650cable = >platdata->id_extcon;
>651
>652if (cable) {
>653cable->changed = true;
>654cable->connected = true;
>655ci_irq(ci->irq, ci);
>656}
>  > 657spin_unlock_irqrestore(>lock, flags);

So it's fine to unlock here.

Thanks
Li Jun
>658pm_runtime_put_sync(ci->dev);
>659
>660return 0;
>661}
>662
> 
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.01.org
> %2Fhyperkitty%2Flist%2Fkbuild-all%40lists.01.orgdata=02%7C01%7Cjun.li%40n
> xp.com%7Ce261827f14f6446b3e8308d83ab8c407%7C686ea1d3bc2b4c6fa92cd99c5c301635%7
> C0%7C0%7C637323912694709319sdata=tAxmh6eq3yT3A89mY2RrGQxwdkUN4A9r708lFQJW
> gcI%3Dreserved=0

Re: [PATCH 1/3] usb: typec: Add QCOM PMIC typec detection driver

[Jun Li]

Hi,
Wesley Cheng  于2020年6月10日周三 上午5:00写道：
>
> The QCOM SPMI typec driver handles the role and orientation detection, and
> notifies client drivers using the USB role switch framework.   It registers
> as a typec port, so orientation can be communicated using the typec switch
> APIs.  The driver also registers the VBUS output regulator, so client
> drivers can enable the VBUS source when acting as a source/host.
>
> Signed-off-by: Wesley Cheng 
> ---
>  drivers/usb/typec/Kconfig   |  11 ++
>  drivers/usb/typec/Makefile  |   1 +
>  drivers/usb/typec/qcom-pmic-typec.c | 278 
> 
>  3 files changed, 290 insertions(+)
>  create mode 100644 drivers/usb/typec/qcom-pmic-typec.c
>
> diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
> index 559dd06..8de2520 100644
> --- a/drivers/usb/typec/Kconfig
> +++ b/drivers/usb/typec/Kconfig
> @@ -73,6 +73,17 @@ config TYPEC_TPS6598X
>   If you choose to build this driver as a dynamically linked module, 
> the
>   module will be called tps6598x.ko.
>
> +config TYPEC_QCOM_PMIC
> +   tristate "Qualcomm PMIC USB typec driver"
> +   depends on ARCH_QCOM
> +   help
> + Driver for supporting role switch over the Qualcomm PMIC.  This will
> + handle the type C role and orientation detection reported by the 
> QCOM
> + PMIC if the PMIC has the capability to handle type C detection.
> +
> + It will also enable the VBUS output to connected devices when a
> + DFP connection is made.
> +
>  source "drivers/usb/typec/mux/Kconfig"
>
>  source "drivers/usb/typec/altmodes/Kconfig"
> diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
> index 7753a5c3..cceffd9 100644
> --- a/drivers/usb/typec/Makefile
> +++ b/drivers/usb/typec/Makefile
> @@ -6,4 +6,5 @@ obj-$(CONFIG_TYPEC_TCPM)+= tcpm/
>  obj-$(CONFIG_TYPEC_UCSI)   += ucsi/
>  obj-$(CONFIG_TYPEC_HD3SS3220)  += hd3ss3220.o
>  obj-$(CONFIG_TYPEC_TPS6598X)   += tps6598x.o
> +obj-$(CONFIG_TYPEC_QCOM_PMIC)  += qcom-pmic-typec.o
>  obj-$(CONFIG_TYPEC)+= mux/
> diff --git a/drivers/usb/typec/qcom-pmic-typec.c 
> b/drivers/usb/typec/qcom-pmic-typec.c
> new file mode 100644
> index 000..ce6319c
> --- /dev/null
> +++ b/drivers/usb/typec/qcom-pmic-typec.c
> @@ -0,0 +1,278 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020, The Linux Foundation. All rights reserved.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DCDC_BASE  0x1100
> +#define CMD_OTG(DCDC_BASE + 0x40)
> +#define OTG_EN BIT(0)
> +#define OTG_CFG(DCDC_BASE + 0x53)
> +#define OTG_EN_SRC_CFG BIT(1)
> +
> +#define USB_BASE   0x1300
> +#define TYPE_C_CFG_REG (USB_BASE + 0x58)
> +#define BC12_START_ON_CC   BIT(7)
> +
> +#define TYPEC_BASE 0x1500
> +#define TYPEC_MISC_STATUS  (TYPEC_BASE + 0xb)
> +#define CC_ATTACHEDBIT(0)
> +#define CC_ORIENTATION BIT(1)
> +#define SNK_SRC_MODE   BIT(6)
> +#define TYPEC_MODE_CFG (TYPEC_BASE + 0x44)
> +#define TYPEC_DISABLE_CMD  BIT(0)
> +#define EN_SNK_ONLYBIT(1)
> +#define EN_SRC_ONLYBIT(2)
> +#define EN_TRY_SNK BIT(4)
> +#define TYPEC_VCONN_CONTROL(TYPEC_BASE + 0x46)
> +#define VCONN_EN_SRC   BIT(0)
> +#define VCONN_EN_VAL   BIT(1)
> +#define TYPEC_EXIT_STATE_CFG   (TYPEC_BASE + 0x50)
> +#define SEL_SRC_UPPER_REF  BIT(2)
> +#define TYPEC_INTR_EN_CFG_1(TYPEC_BASE + 0x5e)
> +#define TYPEC_INTR_EN_CFG_1_MASK   GENMASK(0, 7)
> +
> +struct qcom_pmic_typec {
> +   struct device   *dev;
> +   struct fwnode_handle*fwnode;
> +   struct regmap   *regmap;
> +   struct work_struct  bh_work;
> +
> +   struct typec_capability *cap;
> +   struct typec_port   *port;
> +   struct usb_role_switch *role_sw;
> +
> +   struct regulator_desc usb_vbus_rdesc;
> +   struct regulator_dev *usb_vbus_reg;
> +};
> +
> +static int qcom_pmic_typec_vbus_enable(struct qcom_pmic_typec *qcom_usb)
> +{
> +   int rc;
> +
> +   rc = regmap_update_bits(qcom_usb->regmap, CMD_OTG, OTG_EN, OTG_EN);
> +   if (rc)
> +   dev_err(qcom_usb->dev, "failed to update OTG_CTL\n");
> +
> +   return rc;
> +}
> +
> +static int qcom_pmic_typec_vbus_disable(struct qcom_pmic_typec *qcom_usb)
> +{
> +   int rc;
> +
> +   rc = regmap_update_bits(qcom_usb->regmap, CMD_OTG, OTG_EN, 0);
> +   if (rc)
> +   

Re: [RFC][PATCH] usb: typec: tcpci_rt1711h: Try to avoid screaming irq causing boot hangs

[Jun Li]

Hi,
John Stultz  于2020年6月2日周二 上午4:39写道：
>
> On Sat, May 30, 2020 at 3:30 AM Jun Li  wrote:
> >
> > Hi John,
> >
> > John Stultz  于2020年5月30日周六 下午12:02写道：
> > >
> > > I've recently (since 5.7-rc1) started noticing very rare hangs
> > > pretty early in bootup on my HiKey960 board.
> > >
> > > They have been particularly difficult to debug, as the system
> > > seems to not respond at all to sysrq- commands. However, the
> > > system is alive as I'll occaionally see firmware loading timeout
> > > errors after awhile. Adding changes like initcall_debug and
> > > lockdep weren't informative, as it tended to cause the problem
> > > to hide.
> > >
> > > I finally tried to dig in a bit more on this today, and noticed
> > > that the last dmesg output before the hang was usually:
> > >   "random: crng init done"
> > >
> > > So I dumped the stack at that point, and saw it was being called
> > > from the pl061 gpio irq, and the hang always occurred when the
> > > crng init finished on cpu 0. Instrumenting that more I could see
> > > that when the issue triggered, we were getting a stream of irqs.
> > >
> > > Chasing further, I found the screaming irq was for the rt1711h,
> > > and narrowed down that we were hitting the !chip->tcpci check
> > > which immediately returns IRQ_HANDLED, but does not stop the
> > > irq from triggering immediately afterwards.
> > >
> > > This patch slightly reworks the logic, so if we hit the irq
> > > before the chip->tcpci has been assigned, we still read and
> > > write the alert register, but just skip calling tcpci_irq().
> > >
> > > With this change, I haven't managed to trip over the problem
> > > (though it hasn't been super long - but I did confirm I hit
> > > the error case and it didn't hang the system).
> > >
> > > I still have some concern that I don't know why this cropped
> > > up since 5.7-rc, as there haven't been any changes to the
> > > driver since 5.4 (or before). It may just be the initialization
> > > timing has changed due to something else, and its just exposed
> > > this issue? I'm not sure, and that's not super re-assuring.
> > >
> > > Anyway, I'd love to hear your thoughts if this looks like a sane
> > > fix or not.
> >
> > I think a better solution may be move the irq request after port register,
> > we should fire the irq after everything is setup.
> > does below change works for you?
>
> Unfortunately the patch didn't seem to apply, but I recreated it by
> hand. I agree this looks like it should address the issue and I've not
> managed to trigger the problem in my (admittedly somewhat brief)
> attempts at testing.
>
> Thanks for sending it out. Do you want to submit the patch and I'll
> provide a Tested-by tag, or would it help for me to submit your
> suggested change?

OK, I will send out a patch against Greg's tree.

Li Jun
>
> thanks
> -john

Re: [RFC][PATCH] usb: typec: tcpci_rt1711h: Try to avoid screaming irq causing boot hangs

[Jun Li]

Hi John,

John Stultz  于2020年5月30日周六 下午12:02写道：
>
> I've recently (since 5.7-rc1) started noticing very rare hangs
> pretty early in bootup on my HiKey960 board.
>
> They have been particularly difficult to debug, as the system
> seems to not respond at all to sysrq- commands. However, the
> system is alive as I'll occaionally see firmware loading timeout
> errors after awhile. Adding changes like initcall_debug and
> lockdep weren't informative, as it tended to cause the problem
> to hide.
>
> I finally tried to dig in a bit more on this today, and noticed
> that the last dmesg output before the hang was usually:
>   "random: crng init done"
>
> So I dumped the stack at that point, and saw it was being called
> from the pl061 gpio irq, and the hang always occurred when the
> crng init finished on cpu 0. Instrumenting that more I could see
> that when the issue triggered, we were getting a stream of irqs.
>
> Chasing further, I found the screaming irq was for the rt1711h,
> and narrowed down that we were hitting the !chip->tcpci check
> which immediately returns IRQ_HANDLED, but does not stop the
> irq from triggering immediately afterwards.
>
> This patch slightly reworks the logic, so if we hit the irq
> before the chip->tcpci has been assigned, we still read and
> write the alert register, but just skip calling tcpci_irq().
>
> With this change, I haven't managed to trip over the problem
> (though it hasn't been super long - but I did confirm I hit
> the error case and it didn't hang the system).
>
> I still have some concern that I don't know why this cropped
> up since 5.7-rc, as there haven't been any changes to the
> driver since 5.4 (or before). It may just be the initialization
> timing has changed due to something else, and its just exposed
> this issue? I'm not sure, and that's not super re-assuring.
>
> Anyway, I'd love to hear your thoughts if this looks like a sane
> fix or not.

I think a better solution may be move the irq request after port register,
we should fire the irq after everything is setup.
does below change works for you?

diff --git a/drivers/usb/typec/tcpm/tcpci_rt1711h.c
b/drivers/usb/typec/tcpm/tcpci_rt1711h.c
index 0173890..b56a088 100644
--- a/drivers/usb/typec/tcpm/tcpci_rt1711h.c
+++ b/drivers/usb/typec/tcpm/tcpci_rt1711h.c
@@ -179,26 +179,6 @@ static irqreturn_t rt1711h_irq(int irq, void *dev_id)
return tcpci_irq(chip->tcpci);
 }

-static int rt1711h_init_alert(struct rt1711h_chip *chip,
- struct i2c_client *client)
-{
-   int ret;
-
-   /* Disable chip interrupts before requesting irq */
-   ret = rt1711h_write16(chip, TCPC_ALERT_MASK, 0);
-   if (ret < 0)
-   return ret;
-
-   ret = devm_request_threaded_irq(chip->dev, client->irq, NULL,
-   rt1711h_irq,
-   IRQF_ONESHOT | IRQF_TRIGGER_LOW,
-   dev_name(chip->dev), chip);
-   if (ret < 0)
-   return ret;
-   enable_irq_wake(client->irq);
-   return 0;
-}
-
 static int rt1711h_sw_reset(struct rt1711h_chip *chip)
 {
int ret;
@@ -260,7 +240,8 @@ static int rt1711h_probe(struct i2c_client *client,
if (ret < 0)
return ret;

-   ret = rt1711h_init_alert(chip, client);
+   /* Disable chip interrupts before requesting irq */
+   ret = rt1711h_write16(chip, TCPC_ALERT_MASK, 0);
if (ret < 0)
return ret;

@@ -271,6 +252,14 @@ static int rt1711h_probe(struct i2c_client *client,
if (IS_ERR_OR_NULL(chip->tcpci))
return PTR_ERR(chip->tcpci);

+   ret = devm_request_threaded_irq(chip->dev, client->irq, NULL,
+   rt1711h_irq,
+   IRQF_ONESHOT | IRQF_TRIGGER_LOW,
+   dev_name(chip->dev), chip);
+   if (ret < 0)
+   return ret;
+   enable_irq_wake(client->irq);
+
return 0;
 }

Li Jun
>
> Cc: Guenter Roeck 
> Cc: Heikki Krogerus 
> Cc: Greg Kroah-Hartman 
> Cc: YongQin Liu 
> Cc: linux-...@vger.kernel.org
> Signed-off-by: John Stultz 
> ---
>  drivers/usb/typec/tcpm/tcpci_rt1711h.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/typec/tcpm/tcpci_rt1711h.c 
> b/drivers/usb/typec/tcpm/tcpci_rt1711h.c
> index 017389021b96..530fd2c111ad 100644
> --- a/drivers/usb/typec/tcpm/tcpci_rt1711h.c
> +++ b/drivers/usb/typec/tcpm/tcpci_rt1711h.c
> @@ -159,9 +159,6 @@ static irqreturn_t rt1711h_irq(int irq, void *dev_id)
> u8 status;
> struct rt1711h_chip *chip = dev_id;
>
> -   if (!chip->tcpci)
> -   return IRQ_HANDLED;
> -
> ret = rt1711h_read16(chip, TCPC_ALERT, );
> if (ret < 0)
> goto out;
> @@ -176,6 +173,9 @@ static irqreturn_t rt1711h_irq(int irq, void *dev_id)
> }
>
>  out:
> +   if (!chip->tcpci)
> +  

RE: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller

[Jun Li]

Hi Felipe,

> -Original Message-
> From: Felipe Balbi  On Behalf Of Felipe Balbi
> Sent: 2020年5月21日 14:23
> To: Thinh Nguyen ; Jun Li ; Jun Li
> 
> Cc: John Stultz ; lkml 
> ; Yu
> Chen ; Greg Kroah-Hartman ; 
> Rob
> Herring ; Mark Rutland ; ShuFan Lee
> ; Heikki Krogerus ;
> Suzuki K Poulose ; Chunfeng Yun
> ; Hans de Goede ; Andy 
> Shevchenko
> ; Valentin Schneider ;
> Jack Pham ; Linux USB List ; 
> open
> list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS 
> ;
> Peter Chen 
> Subject: Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by 
> device
> controller
> 
> 
> Hi Jun,
> 
> Felipe Balbi  writes:
> >> In any case, increasing the timeout should be fine with me. It maybe
> >> difficult to determine the max timeout base on the slowest clock rate
> >> and number of cycles. Different controller and controller versions
> >> behave differently and may have different number of clock cycles to
> >> complete a command.
> >>
> >> The RTL engineer recommended timeout to be at least 1ms (which maybe
> >> more than the polling rate of this patch). I'm fine with either the
> >> rate provided by this tested patch or higher.
> >
> > A whole ms waiting for a command to complete? Wow, that's a lot of
> > time blocking the CPU. It looks like, perhaps, we should move to
> > command completion interrupts. The difficulty here is that we issue
> > commands from within the interrupt handler and, as such, can't
> > wait_for_completion().
> >
> > Meanwhile, we will take the timeout increase I guess, otherwise NXP
> > won't have a working setup.
> 
> patch 1 in this series doesn't apply to testing/next. Care to rebase and 
> resend?

Sure, I will rebase and resend this patch with timeout loop 5000.

Thanks
Li Jun
> 
> Thank you
> 
> --
> balbi

RE: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller

[Jun Li]

Hi Thinh,
> -Original Message-
> From: Thinh Nguyen 
> Sent: 2020年5月21日 9:56
> To: Jun Li ; Felipe Balbi ; Jun Li
> 
> Cc: John Stultz ; lkml 
> ; Yu
> Chen ; Greg Kroah-Hartman ; 
> Rob
> Herring ; Mark Rutland ; ShuFan Lee
> ; Heikki Krogerus ;
> Suzuki K Poulose ; Chunfeng Yun
> ; Hans de Goede ; Andy 
> Shevchenko
> ; Valentin Schneider ;
> Jack Pham ; Linux USB List ; 
> open
> list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS 
> ;
> Peter Chen 
> Subject: Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by 
> device
> controller
> 
> Thinh Nguyen wrote:
> > Jun Li wrote:
> >> Hi
> >>
> >>> -Original Message-
> >>> From: Thinh Nguyen 
> >>> Sent: 2020年5月19日 14:46
> >>> To: Jun Li ; Felipe Balbi ; Jun Li
> >>> 
> >>> Cc: John Stultz ; lkml
> >>> ; Yu Chen ; Greg
> >>> Kroah-Hartman ; Rob Herring
> >>> ; Mark Rutland ; ShuFan
> >>> Lee ; Heikki Krogerus
> >>> ;
> >>> Suzuki K Poulose ; Chunfeng Yun
> >>> ; Hans de Goede ;
> >>> Andy Shevchenko ; Valentin Schneider
> >>> ; Jack Pham ;
> >>> Linux USB List ; open list:OPEN FIRMWARE
> >>> AND FLATTENED DEVICE TREE BINDINGS ;
> >>> Peter Chen 
> >>> Subject: Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct
> >>> cleared by device controller
> >>>
> >>> Thinh Nguyen wrote:
> >>>> Jun Li wrote:
> >>>>>> -Original Message-
> >>>>>> From: Felipe Balbi  On Behalf Of Felipe Balbi
> >>>>>> Sent: 2020年5月16日 19:57
> >>>>>> To: Jun Li ; Thinh Nguyen
> >>>>>> ; Jun Li 
> >>>>>> Cc: John Stultz ; lkml
> >>>>>> ; Yu Chen ;
> >>>>>> Greg Kroah-Hartman ; Rob Herring
> >>>>>> ; Mark Rutland ; ShuFan
> >>>>>> Lee ; Heikki Krogerus
> >>>>>> ;
> >>>>>> Suzuki K Poulose ; Chunfeng Yun
> >>>>>> ; Hans de Goede ;
> >>>>>> Andy Shevchenko ; Valentin Schneider
> >>>>>> ; Jack Pham ;
> >>>>>> Linux USB List ; open list:OPEN
> >>>>>> FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
> >>>>>> ; Peter Chen ;
> >>>>>> Thinh Nguyen 
> >>>>>> Subject: RE: [PATCH v4 3/9] usb: dwc3: Increase timeout for
> >>>>>> CmdAct cleared by device controller
> >>>>>>
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> Jun Li  writes:
> >>>>>>>>>> Hi Thinh, could you comment this?
> >>>>>>>>> You only need to wake up the usb2 phy when issuing the command
> >>>>>>>>> while running in highspeed or below. If you're running in SS
> >>>>>>>>> or higher, internally the controller does it for you for usb3 phy.
> >>>>>>>>> In Jun's case, it seems like it takes longer for his phy to wake up.
> >>>>>>>>>
> >>>>>>>>> IMO, in this case, I think it's fine to increase the command 
> >>>>>>>>> timeout.
> >>>>>>>> Is there an upper limit to this? Is 32k clock the slowest that
> >>>>>>>> can be fed to the PHY as a suspend clock?
> >>>>>>> Yes, 32K clock is the slowest, Per DWC3 document on Power Down
> >>>>>>> Scale (bits 31:19 of GCTL):
> >>>>>>>
> >>>>>>> "Power Down Scale (PwrDnScale)
> >>>>>>> The USB3 suspend_clk input replaces pipe3_rx_pclk as a clock
> >>>>>>> source to a small part of the USB3 controller that operates when
> >>>>>>> the SS PHY is in its lowest power (P3) state, and therefore does not 
> >>>>>>> provide
> a clock.
> >>>>>>> The Power Down Scale field specifies how many suspend_clk
> >>>>>>> periods fit into a 16 kHz clock period. When performing the
> >>>>>>> division, round up the remainder.
> >>>>>>> For example, when using an 8-bit/16-bit/32-bit PHY and 25-MHz
> >>>>>>> Suspend clock, Power Down Scale = 25000 kHz/16 kHz = 13'd1563
> 

RE: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller

[Jun Li]

Hi

> -Original Message-
> From: Thinh Nguyen 
> Sent: 2020年5月19日 14:46
> To: Jun Li ; Felipe Balbi ; Jun Li
> 
> Cc: John Stultz ; lkml 
> ; Yu
> Chen ; Greg Kroah-Hartman ; 
> Rob
> Herring ; Mark Rutland ; ShuFan Lee
> ; Heikki Krogerus ;
> Suzuki K Poulose ; Chunfeng Yun
> ; Hans de Goede ; Andy 
> Shevchenko
> ; Valentin Schneider ;
> Jack Pham ; Linux USB List ; 
> open
> list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS 
> ;
> Peter Chen 
> Subject: Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by 
> device
> controller
> 
> Thinh Nguyen wrote:
> > Jun Li wrote:
> >>> -Original Message-
> >>> From: Felipe Balbi  On Behalf Of Felipe Balbi
> >>> Sent: 2020年5月16日 19:57
> >>> To: Jun Li ; Thinh Nguyen
> >>> ; Jun Li 
> >>> Cc: John Stultz ; lkml
> >>> ; Yu Chen ; Greg
> >>> Kroah-Hartman ; Rob Herring
> >>> ; Mark Rutland ; ShuFan
> >>> Lee ; Heikki Krogerus
> >>> ;
> >>> Suzuki K Poulose ; Chunfeng Yun
> >>> ; Hans de Goede ;
> >>> Andy Shevchenko ; Valentin Schneider
> >>> ; Jack Pham ;
> >>> Linux USB List ; open list:OPEN FIRMWARE
> >>> AND FLATTENED DEVICE TREE BINDINGS ;
> >>> Peter Chen ; Thinh Nguyen
> >>> 
> >>> Subject: RE: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct
> >>> cleared by device controller
> >>>
> >>>
> >>> Hi,
> >>>
> >>> Jun Li  writes:
> >>>>>>> Hi Thinh, could you comment this?
> >>>>>> You only need to wake up the usb2 phy when issuing the command
> >>>>>> while running in highspeed or below. If you're running in SS or
> >>>>>> higher, internally the controller does it for you for usb3 phy.
> >>>>>> In Jun's case, it seems like it takes longer for his phy to wake up.
> >>>>>>
> >>>>>> IMO, in this case, I think it's fine to increase the command timeout.
> >>>>> Is there an upper limit to this? Is 32k clock the slowest that can
> >>>>> be fed to the PHY as a suspend clock?
> >>>> Yes, 32K clock is the slowest, Per DWC3 document on Power Down
> >>>> Scale (bits 31:19 of GCTL):
> >>>>
> >>>> "Power Down Scale (PwrDnScale)
> >>>> The USB3 suspend_clk input replaces pipe3_rx_pclk as a clock source
> >>>> to a small part of the USB3 controller that operates when the SS
> >>>> PHY is in its lowest power (P3) state, and therefore does not provide a 
> >>>> clock.
> >>>> The Power Down Scale field specifies how many suspend_clk periods
> >>>> fit into a 16 kHz clock period. When performing the division, round
> >>>> up the remainder.
> >>>> For example, when using an 8-bit/16-bit/32-bit PHY and 25-MHz
> >>>> Suspend clock, Power Down Scale = 25000 kHz/16 kHz = 13'd1563
> >>>> (rounder up)
> >>>> Note:
> >>>> - Minimum Suspend clock frequency is 32 kHz
> >>>> - Maximum Suspend clock frequency is 125 MHz"
> >>> Cool, now do we have an upper bound for how many clock cycles it
> >>> takes to wake up the PHY?
> >> My understanding is this ep command does not wake up the SS PHY, the
> >> SS PHY still stays at P3 when execute this ep command. The time
> >> required here is to wait controller complete something for this ep
> >> command with 32K clock.
> > Sorry I made a mistake. You're right. Just checked with one of the RTL
> > engineers, and it doesn't need to wake up the phy. However, if it is
> > eSS speed, it may take longer time as the command may be completing
> > with the suspend clock.
> >
> 
> What's the value for GCTL[7:6]?

2'b00

Thanks
Li Jun
> 
> BR,
> Thinh

RE: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller

[Jun Li]

> -Original Message-
> From: Felipe Balbi  On Behalf Of Felipe Balbi
> Sent: 2020年5月16日 19:57
> To: Jun Li ; Thinh Nguyen ; Jun Li
> 
> Cc: John Stultz ; lkml 
> ; Yu
> Chen ; Greg Kroah-Hartman ; 
> Rob
> Herring ; Mark Rutland ; ShuFan Lee
> ; Heikki Krogerus ;
> Suzuki K Poulose ; Chunfeng Yun
> ; Hans de Goede ; Andy 
> Shevchenko
> ; Valentin Schneider ;
> Jack Pham ; Linux USB List ; 
> open
> list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS 
> ;
> Peter Chen ; Thinh Nguyen 
> Subject: RE: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by 
> device
> controller
> 
> 
> Hi,
> 
> Jun Li  writes:
> >> >> Hi Thinh, could you comment this?
> >> >
> >> > You only need to wake up the usb2 phy when issuing the command
> >> > while running in highspeed or below. If you're running in SS or
> >> > higher, internally the controller does it for you for usb3 phy. In
> >> > Jun's case, it seems like it takes longer for his phy to wake up.
> >> >
> >> > IMO, in this case, I think it's fine to increase the command timeout.
> >>
> >> Is there an upper limit to this? Is 32k clock the slowest that can be
> >> fed to the PHY as a suspend clock?
> >
> > Yes, 32K clock is the slowest, Per DWC3 document on Power Down Scale
> > (bits 31:19 of GCTL):
> >
> > "Power Down Scale (PwrDnScale)
> > The USB3 suspend_clk input replaces pipe3_rx_pclk as a clock source to
> > a small part of the USB3 controller that operates when the SS PHY is
> > in its lowest power (P3) state, and therefore does not provide a clock.
> > The Power Down Scale field specifies how many suspend_clk periods fit
> > into a 16 kHz clock period. When performing the division, round up the
> > remainder.
> > For example, when using an 8-bit/16-bit/32-bit PHY and 25-MHz Suspend
> > clock, Power Down Scale = 25000 kHz/16 kHz = 13'd1563 (rounder up)
> > Note:
> > - Minimum Suspend clock frequency is 32 kHz
> > - Maximum Suspend clock frequency is 125 MHz"
> 
> Cool, now do we have an upper bound for how many clock cycles it takes to 
> wake up
> the PHY? 
My understanding is this ep command does not wake up the SS PHY,
the SS PHY still stays at P3 when execute this ep command. The time
required here is to wait controller complete something for this ep
command with 32K clock.

> Then we can just set the time to that upper bound.
Per my test with trace, the time is about 400us(~13 cycles).

Thanks
Li Jun
> 
> --
> balbi

RE: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller

[Jun Li]

Hi,
> -Original Message-
> From: Felipe Balbi  On Behalf Of Felipe Balbi
> Sent: 2020年5月16日 15:13
> To: Thinh Nguyen ; Jun Li ; Jun Li
> 
> Cc: John Stultz ; lkml 
> ; Yu
> Chen ; Greg Kroah-Hartman ; 
> Rob
> Herring ; Mark Rutland ; ShuFan Lee
> ; Heikki Krogerus ;
> Suzuki K Poulose ; Chunfeng Yun
> ; Hans de Goede ; Andy 
> Shevchenko
> ; Valentin Schneider ;
> Jack Pham ; Linux USB List ; 
> open
> list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS 
> ;
> Peter Chen ; Thinh Nguyen 
> Subject: Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by 
> device
> controller
> 
> 
> Hi,
> 
> Thinh Nguyen  writes:
> > Jun Li wrote:
> >>> -Original Message-
> >>> From: Felipe Balbi  On Behalf Of Felipe Balbi
> >>> Sent: 2020年5月15日 17:31
> >>> To: Jun Li 
> >>> Cc: John Stultz ; lkml
> >>> ; Yu Chen ; Greg
> >>> Kroah-Hartman ; Rob Herring
> >>> ; Mark Rutland ; ShuFan
> >>> Lee ; Heikki Krogerus
> >>> ;
> >>> Suzuki K Poulose ; Chunfeng Yun
> >>> ; Hans de Goede ;
> >>> Andy Shevchenko ; Valentin Schneider
> >>> ; Jack Pham ;
> >>> Linux USB List ; open list:OPEN FIRMWARE
> >>> AND FLATTENED DEVICE TREE BINDINGS ;
> >>> Peter Chen ; Jun Li ; Thinh
> >>> Nguyen 
> >>> Subject: Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct
> >>> cleared by device controller
> >>>
> >>>
> >>> Hi,
> >>>
> >>> Jun Li  writes:
> >>>>> @@ -397,12 +407,18 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep
> >>>>> *dep, unsigned
> >>> cmd,
> >>>>>  dwc3_gadget_ep_get_transfer_index(dep);
> >>>>>  }
> >>>>>
> >>>>> -   if (saved_config) {
> >>>>> +   if (saved_hs_config) {
> >>>>>  reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
> >>>>> -   reg |= saved_config;
> >>>>> +   reg |= saved_hs_config;
> >>>>>  dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
> >>>>>  }
> >>>>>
> >>>>> +   if (saved_ss_config) {
> >>>>> +   reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
> >>>>> +   reg |= saved_ss_config;
> >>>>> +   dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
> >>>>> +   }
> >>>>> +
> >>>>>  return ret;
> >>>>>   }
> >>>> Unfortunately this way can't work, once the SS PHY enters P3,
> >>>> disable suspend_en can't force SS PHY exit P3, unless do this at
> >>>> the very beginning to prevent SS PHY entering P3(e.g. add
> >>>> "snps,dis_u3_susphy_quirk" for
> >>> test).
> >>>
> >>> It sounds like you have a quirky PHY.
> >>  From what I got from the IC design, the behavior of
> >> DWC3_GUSB3PIPECTL_SUSPHY bit should be as what I said, not a quirky.
> >>
> >> Hi Thinh, could you comment this?
> >
> > You only need to wake up the usb2 phy when issuing the command while
> > running in highspeed or below. If you're running in SS or higher,
> > internally the controller does it for you for usb3 phy. In Jun's case,
> > it seems like it takes longer for his phy to wake up.
> >
> > IMO, in this case, I think it's fine to increase the command timeout.
> 
> Is there an upper limit to this? Is 32k clock the slowest that can be fed to 
> the
> PHY as a suspend clock?

Yes, 32K clock is the slowest, Per DWC3 document on Power Down Scale
(bits 31:19 of GCTL):

"Power Down Scale (PwrDnScale)
The USB3 suspend_clk input replaces pipe3_rx_pclk as a clock source
to a small part of the USB3 controller that operates when the SS PHY
is in its lowest power (P3) state, and therefore does not provide a clock.
The Power Down Scale field specifies how many suspend_clk periods
fit into a 16 kHz clock period. When performing the division, round up
the remainder.
For example, when using an 8-bit/16-bit/32-bit PHY and 25-MHz Suspend clock,
Power Down Scale = 25000 kHz/16 kHz = 13'd1563 (rounder up)
Note:
- Minimum Suspend clock frequency is 32 kHz
- Maximum Suspend clock frequency is 125 MHz"

Li Jun
> 
> --
> balbi

RE: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller

[Jun Li]

> -Original Message-
> From: Felipe Balbi  On Behalf Of Felipe Balbi
> Sent: 2020年5月15日 17:31
> To: Jun Li 
> Cc: John Stultz ; lkml 
> ; Yu
> Chen ; Greg Kroah-Hartman ; 
> Rob
> Herring ; Mark Rutland ; ShuFan Lee
> ; Heikki Krogerus ;
> Suzuki K Poulose ; Chunfeng Yun
> ; Hans de Goede ; Andy 
> Shevchenko
> ; Valentin Schneider ;
> Jack Pham ; Linux USB List ; 
> open
> list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS 
> ;
> Peter Chen ; Jun Li ; Thinh Nguyen
> 
> Subject: Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by 
> device
> controller
> 
> 
> Hi,
> 
> Jun Li  writes:
> >> @@ -397,12 +407,18 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, 
> >> unsigned
> cmd,
> >> dwc3_gadget_ep_get_transfer_index(dep);
> >> }
> >>
> >> -   if (saved_config) {
> >> +   if (saved_hs_config) {
> >> reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
> >> -   reg |= saved_config;
> >> +   reg |= saved_hs_config;
> >> dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
> >> }
> >>
> >> +   if (saved_ss_config) {
> >> +   reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
> >> +   reg |= saved_ss_config;
> >> +   dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
> >> +   }
> >> +
> >> return ret;
> >>  }
> >
> > Unfortunately this way can't work, once the SS PHY enters P3, disable
> > suspend_en can't force SS PHY exit P3, unless do this at the very
> > beginning to prevent SS PHY entering P3(e.g. add "snps,dis_u3_susphy_quirk" 
> > for
> test).
> 
> It sounds like you have a quirky PHY. 

From what I got from the IC design, the behavior of DWC3_GUSB3PIPECTL_SUSPHY
bit should be as what I said, not a quirky.

Hi Thinh, could you comment this?

> If that's the case, then you probably need
> to use the flag you mentioned above. Please verify with that.

With quirk of "snps,dis_u3_susphy_quirk", I had verified it can
resolve the problem, but this will make USB3 Super Speed PHY
never enter P3, this is a huge impact on USB power consumption.

The timeout increase has no impact on those platforms which have
no this problem, but can give chance for platform with very low
supspend clk(like my case 32k) to work.

Thanks
Li Jun
> 
> --
> balbi

Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller

[Jun Li]

Felipe Balbi  于2020年5月8日周五 下午8:35写道：
>
>
> Hi,
>
> Jun Li  writes:
> > Jun Li  于2020年5月7日周四 上午11:08写道：
> >>
> >> John Stultz  于2020年5月7日周四 上午6:27写道：
> >> >
> >> > On Wed, May 6, 2020 at 2:00 AM Jun Li  wrote:
> >> > > John Stultz  于2019年10月30日周三 上午5:18写道：
> >> > > > On Tue, Oct 29, 2019 at 2:11 AM Felipe Balbi  
> >> > > > wrote:
> >> > > > > John Stultz  writes:
> >> > > > > > From: Yu Chen 
> >> > > > > >
> >> > > > > > It needs more time for the device controller to clear the CmdAct 
> >> > > > > > of
> >> > > > > > DEPCMD on Hisilicon Kirin Soc.
> >> > > > >
> >> > > > > Why does it need more time? Why is it so that no other platform 
> >> > > > > needs
> >> > > > > more time, only this one? And which command, specifically, causes
> >> > > > > problem?
> >> > >
> >> > > Sorry for my back to this so late.
> >> > >
> >> > > This change is required on my dwc3 based HW too, I gave a check
> >> > > and the reason is suspend_clk is used in case the PIPE phy is at P3,
> >> > > this slow clock makes my EP command below timeout.
> >> > >
> >> > > dwc3_gadget_ep_cmd: ep0out: cmd 'Set Endpoint Configuration' [401]
> >> > > params 1000 0500  --> status: Timed Out
> >> > >
> >> > > Success case takes about 400us to complete, see below trace(44.286278
> >> > > - 44.285897 = 0.000381):
> >> > >
> >> > > configfs_acm.sh-822   [000] d..144.285896: dwc3_writel: addr
> >> > > 6d59aae1 value 0401
> >> > > configfs_acm.sh-822   [000] d..144.285897: dwc3_readl: addr
> >> > > 6d59aae1 value 0401
> >> > > ... ...
> >> > > configfs_acm.sh-822   [000] d..144.286278: dwc3_readl: addr
> >> > > 6d59aae1 value 0001
> >> > > configfs_acm.sh-822   [000] d..144.286279: dwc3_gadget_ep_cmd:
> >> > > ep0out: cmd 'Set Endpoint Configuration' [401] params 1000
> >> > > 0500  --> status: Successful
> >> > >
> >> > > Hi John,
> >> > >
> >> > > Do you still have this problem? if yes, What's the value of
> >> > > USBLNKST[21:18] when the timeout happens?
> >> >
> >> > Sorry. As I mentioned, I was working to upstream a patchset that I
> >> > hadn't created, so the context I had was limited. As I couldn't
> >> > reproduce an issue without the change on the device I had, I figured
> >> > it would be best to drop it.
> >>
> >> That was fine.
> >> >
> >> > However, as you have some analysis and rational for why such a change
> >> > would be needed, I don't have an objection to it. Do you want to
> >> > resubmit the patch with your explanation and detailed log above in the
> >> > commit message?
> >>
> >> Sure, I will resubmit the patch with my explanation added in commit 
> >> message.
> >
> > Hi John
> >
> > A second think of this, I feel use readl_poll_timeout_atomic() to wait by 
> > time
> > is more proper here, so I create a new patch to address this also other
> > registers polling, see below patch with you CCed:
> >
> > https://patchwork.kernel.org/patch/11536081/
>
> Fixing a bug has nothing to do with using
> readl_poll_timeout_atomic(). Please don't mix things as it just makes
> review time consuming.
>
> Let's find out what the bug is all about, only then should we consider
> moving over to readl_poll_timeout_atomic().

Agreed, sorry about that, I will hold on my readl_poll_timeout_atomic() changes
until we have a conclusion on this issue fix.

thanks
Li Jun
>
> --
> balbi

Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller

[Jun Li]

Hi,

Felipe Balbi  于2020年5月8日周五 下午8:33写道：
>
>
> Hi,
>
> Jun Li  writes:
> > John Stultz  于2019年10月30日周三 上午5:18写道：
> >>
> >> On Tue, Oct 29, 2019 at 2:11 AM Felipe Balbi  wrote:
> >> > John Stultz  writes:
> >> > > From: Yu Chen 
> >> > >
> >> > > It needs more time for the device controller to clear the CmdAct of
> >> > > DEPCMD on Hisilicon Kirin Soc.
> >> >
> >> > Why does it need more time? Why is it so that no other platform needs
> >> > more time, only this one? And which command, specifically, causes
> >> > problem?
> >
> > Sorry for my back to this so late.
> >
> > This change is required on my dwc3 based HW too, I gave a check
> > and the reason is suspend_clk is used in case the PIPE phy is at P3,
> > this slow clock makes my EP command below timeout.
>
> The phy needs to woken up before the command is triggered. Currently we
> only wake up the HS PHY. Does it help you if we wake up the SS phy as
> well?
>
> Something like below ought to do it:
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index a0555252dee0..ee46c2dacaeb 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -274,7 +274,8 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, unsigned 
> cmd,
> const struct usb_endpoint_descriptor *desc = dep->endpoint.desc;
> struct dwc3 *dwc = dep->dwc;
> u32 timeout = 1000;
> -   u32 saved_config = 0;
> +   u32 saved_hs_config = 0;
> +   u32 saved_ss_config = 0;
> u32 reg;
>
> int cmd_status = 0;
> @@ -293,19 +294,28 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, 
> unsigned cmd,
> if (dwc->gadget.speed <= USB_SPEED_HIGH) {
> reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
> if (unlikely(reg & DWC3_GUSB2PHYCFG_SUSPHY)) {
> -   saved_config |= DWC3_GUSB2PHYCFG_SUSPHY;
> +   saved_hs_config |= DWC3_GUSB2PHYCFG_SUSPHY;
> reg &= ~DWC3_GUSB2PHYCFG_SUSPHY;
> }
>
> if (reg & DWC3_GUSB2PHYCFG_ENBLSLPM) {
> -   saved_config |= DWC3_GUSB2PHYCFG_ENBLSLPM;
> +   saved_hs_config |= DWC3_GUSB2PHYCFG_ENBLSLPM;
> reg &= ~DWC3_GUSB2PHYCFG_ENBLSLPM;
> }
>
> -   if (saved_config)
> +   if (saved_hs_config)
> dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
> }
>
> +   reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
> +   if (unlikely(reg & DWC3_GUSB3PIPECTL_SUSPHY)) {
> +   saved_ss_config |= DWC3_GUSB3PIPECTL_SUSPHY;
> +   reg &= ~DWC3_GUSB3PIPECTL_SUSPHY;
> +   }
> +
> +   if (saved_ss_config)
> +   dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
> +
> if (DWC3_DEPCMD_CMD(cmd) == DWC3_DEPCMD_STARTTRANSFER) {
> int needs_wakeup;
>
> @@ -397,12 +407,18 @@ int dwc3_send_gadget_ep_cmd(struct dwc3_ep *dep, 
> unsigned cmd,
> dwc3_gadget_ep_get_transfer_index(dep);
> }
>
> -   if (saved_config) {
> +   if (saved_hs_config) {
> reg = dwc3_readl(dwc->regs, DWC3_GUSB2PHYCFG(0));
> -   reg |= saved_config;
> +   reg |= saved_hs_config;
> dwc3_writel(dwc->regs, DWC3_GUSB2PHYCFG(0), reg);
> }
>
> +   if (saved_ss_config) {
> +   reg = dwc3_readl(dwc->regs, DWC3_GUSB3PIPECTL(0));
> +   reg |= saved_ss_config;
> +   dwc3_writel(dwc->regs, DWC3_GUSB3PIPECTL(0), reg);
> +   }
> +
> return ret;
>  }

Unfortunately this way can't work, once the SS PHY enters P3, disable
suspend_en can't force SS PHY exit P3, unless do this at the very beginning
to prevent SS PHY entering P3(e.g. add "snps,dis_u3_susphy_quirk" for test).

thanks
Li Jun
>
> --
> balbi

Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller

[Jun Li]

Jun Li  于2020年5月7日周四 上午11:08写道：
>
> John Stultz  于2020年5月7日周四 上午6:27写道：
> >
> > On Wed, May 6, 2020 at 2:00 AM Jun Li  wrote:
> > > John Stultz  于2019年10月30日周三 上午5:18写道：
> > > > On Tue, Oct 29, 2019 at 2:11 AM Felipe Balbi  wrote:
> > > > > John Stultz  writes:
> > > > > > From: Yu Chen 
> > > > > >
> > > > > > It needs more time for the device controller to clear the CmdAct of
> > > > > > DEPCMD on Hisilicon Kirin Soc.
> > > > >
> > > > > Why does it need more time? Why is it so that no other platform needs
> > > > > more time, only this one? And which command, specifically, causes
> > > > > problem?
> > >
> > > Sorry for my back to this so late.
> > >
> > > This change is required on my dwc3 based HW too, I gave a check
> > > and the reason is suspend_clk is used in case the PIPE phy is at P3,
> > > this slow clock makes my EP command below timeout.
> > >
> > > dwc3_gadget_ep_cmd: ep0out: cmd 'Set Endpoint Configuration' [401]
> > > params 1000 0500  --> status: Timed Out
> > >
> > > Success case takes about 400us to complete, see below trace(44.286278
> > > - 44.285897 = 0.000381):
> > >
> > > configfs_acm.sh-822   [000] d..144.285896: dwc3_writel: addr
> > > 6d59aae1 value 0401
> > > configfs_acm.sh-822   [000] d..144.285897: dwc3_readl: addr
> > > 6d59aae1 value 0401
> > > ... ...
> > > configfs_acm.sh-822   [000] d..144.286278: dwc3_readl: addr
> > > 6d59aae1 value 0001
> > > configfs_acm.sh-822   [000] d..144.286279: dwc3_gadget_ep_cmd:
> > > ep0out: cmd 'Set Endpoint Configuration' [401] params 1000
> > > 0500  --> status: Successful
> > >
> > > Hi John,
> > >
> > > Do you still have this problem? if yes, What's the value of
> > > USBLNKST[21:18] when the timeout happens?
> >
> > Sorry. As I mentioned, I was working to upstream a patchset that I
> > hadn't created, so the context I had was limited. As I couldn't
> > reproduce an issue without the change on the device I had, I figured
> > it would be best to drop it.
>
> That was fine.
> >
> > However, as you have some analysis and rational for why such a change
> > would be needed, I don't have an objection to it. Do you want to
> > resubmit the patch with your explanation and detailed log above in the
> > commit message?
>
> Sure, I will resubmit the patch with my explanation added in commit message.

Hi John

A second think of this, I feel use readl_poll_timeout_atomic() to wait by time
is more proper here, so I create a new patch to address this also other
registers polling, see below patch with you CCed:

https://patchwork.kernel.org/patch/11536081/

thanks
Li Jun
>
> thanks
> Li Jun
> >
> > thanks
> > -john

Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller

[Jun Li]

John Stultz  于2020年5月7日周四 上午6:27写道：
>
> On Wed, May 6, 2020 at 2:00 AM Jun Li  wrote:
> > John Stultz  于2019年10月30日周三 上午5:18写道：
> > > On Tue, Oct 29, 2019 at 2:11 AM Felipe Balbi  wrote:
> > > > John Stultz  writes:
> > > > > From: Yu Chen 
> > > > >
> > > > > It needs more time for the device controller to clear the CmdAct of
> > > > > DEPCMD on Hisilicon Kirin Soc.
> > > >
> > > > Why does it need more time? Why is it so that no other platform needs
> > > > more time, only this one? And which command, specifically, causes
> > > > problem?
> >
> > Sorry for my back to this so late.
> >
> > This change is required on my dwc3 based HW too, I gave a check
> > and the reason is suspend_clk is used in case the PIPE phy is at P3,
> > this slow clock makes my EP command below timeout.
> >
> > dwc3_gadget_ep_cmd: ep0out: cmd 'Set Endpoint Configuration' [401]
> > params 1000 0500  --> status: Timed Out
> >
> > Success case takes about 400us to complete, see below trace(44.286278
> > - 44.285897 = 0.000381):
> >
> > configfs_acm.sh-822   [000] d..144.285896: dwc3_writel: addr
> > 6d59aae1 value 0401
> > configfs_acm.sh-822   [000] d..144.285897: dwc3_readl: addr
> > 6d59aae1 value 0401
> > ... ...
> > configfs_acm.sh-822   [000] d..144.286278: dwc3_readl: addr
> > 6d59aae1 value 0001
> > configfs_acm.sh-822   [000] d..144.286279: dwc3_gadget_ep_cmd:
> > ep0out: cmd 'Set Endpoint Configuration' [401] params 1000
> > 0500  --> status: Successful
> >
> > Hi John,
> >
> > Do you still have this problem? if yes, What's the value of
> > USBLNKST[21:18] when the timeout happens?
>
> Sorry. As I mentioned, I was working to upstream a patchset that I
> hadn't created, so the context I had was limited. As I couldn't
> reproduce an issue without the change on the device I had, I figured
> it would be best to drop it.

That was fine.
>
> However, as you have some analysis and rational for why such a change
> would be needed, I don't have an objection to it. Do you want to
> resubmit the patch with your explanation and detailed log above in the
> commit message?

Sure, I will resubmit the patch with my explanation added in commit message.

thanks
Li Jun
>
> thanks
> -john

Re: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller

[Jun Li]

John Stultz  于2019年10月30日周三 上午5:18写道：
>
> On Tue, Oct 29, 2019 at 2:11 AM Felipe Balbi  wrote:
> > John Stultz  writes:
> > > From: Yu Chen 
> > >
> > > It needs more time for the device controller to clear the CmdAct of
> > > DEPCMD on Hisilicon Kirin Soc.
> >
> > Why does it need more time? Why is it so that no other platform needs
> > more time, only this one? And which command, specifically, causes
> > problem?

Sorry for my back to this so late.

This change is required on my dwc3 based HW too, I gave a check
and the reason is suspend_clk is used in case the PIPE phy is at P3,
this slow clock makes my EP command below timeout.

dwc3_gadget_ep_cmd: ep0out: cmd 'Set Endpoint Configuration' [401]
params 1000 0500  --> status: Timed Out

Success case takes about 400us to complete, see below trace(44.286278
- 44.285897 = 0.000381):

configfs_acm.sh-822   [000] d..144.285896: dwc3_writel: addr
6d59aae1 value 0401
configfs_acm.sh-822   [000] d..144.285897: dwc3_readl: addr
6d59aae1 value 0401
... ...
configfs_acm.sh-822   [000] d..144.286278: dwc3_readl: addr
6d59aae1 value 0001
configfs_acm.sh-822   [000] d..144.286279: dwc3_gadget_ep_cmd:
ep0out: cmd 'Set Endpoint Configuration' [401] params 1000
0500  --> status: Successful

Hi John,

Do you still have this problem? if yes, What's the value of
USBLNKST[21:18] when the timeout happens?

thanks
Li Jun
>
> Hrm. Sadly I don't have that context (again I'm picking up a
> semi-abandoned patchset here), which is unfortunate, as I'm sure
> someone spent a number of hours debugging things to come up with this.
> :)
>
> But alas, I've dropped this for now in my stack, and things seem to be
> working ok so far. I suspect there's some edge case I'll run into, but
> hopefully I'll be able to debug and get more details when that
> happens.
>
> I do appreciate the review and pushback here!
>
> thanks
> -john

Re: [PATCH] usb: dwc3: move core validatation after clock enable and reset deassert

[Jun Li]

There is already one identical patch for this:
https://patchwork.kernel.org/patch/10934937/
either one is okay.

Li Jun

Masahiro Yamada  于2019年5月20日周一 下午6:45写道：
>
> Since commit b873e2d0ea1e ("usb: dwc3: Do core validation early on
> probe"), the DWC3 USB3 does not work for Socionext UniPhier platform.
>
> It moved dwc3_core_is_valid() really early, where no clock is enabled,
> no reset is deasserted. Any attempt to register access causes the
> system stall on my platform.
>
> Move it after clk_bulk_enable(), and still before dwc3_get_dr_mode().
>
> Fixes: b873e2d0ea1e ("usb: dwc3: Do core validation early on probe")
> Signed-off-by: Masahiro Yamada 
> ---
>
>  drivers/usb/dwc3/core.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 4aff1d8dbc4f..93b96e6abddb 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -1423,11 +1423,6 @@ static int dwc3_probe(struct platform_device *pdev)
> dwc->regs   = regs;
> dwc->regs_size  = resource_size(_res);
>
> -   if (!dwc3_core_is_valid(dwc)) {
> -   dev_err(dwc->dev, "this is not a DesignWare USB3 DRD Core\n");
> -   return -ENODEV;
> -   }
> -
> dwc3_get_properties(dwc);
>
> dwc->reset = devm_reset_control_get_optional_shared(dev, NULL);
> @@ -1460,6 +1455,12 @@ static int dwc3_probe(struct platform_device *pdev)
> if (ret)
> goto unprepare_clks;
>
> +   if (!dwc3_core_is_valid(dwc)) {
> +   dev_err(dwc->dev, "this is not a DesignWare USB3 DRD Core\n");
> +   ret = -ENODEV;
> +   goto disable_clks;
> +   }
> +
> platform_set_drvdata(pdev, dwc);
> dwc3_cache_hwparams(dwc);
>
> @@ -1524,7 +1525,7 @@ static int dwc3_probe(struct platform_device *pdev)
>  err1:
> pm_runtime_put_sync(>dev);
> pm_runtime_disable(>dev);
> -
> +disable_clks:
> clk_bulk_disable(dwc->num_clks, dwc->clks);
>  unprepare_clks:
> clk_bulk_unprepare(dwc->num_clks, dwc->clks);
> --
> 2.17.1
>

Re: [PATCH v2 07/10] usb: dwc3: Registering a role switch in the DRD code.

[Jun Li]

Hi
Yu Chen  于2019年2月18日周一 下午7:34写道：
>
> The Type-C drivers use USB role switch API to inform the
> system about the negotiated data role, so registering a role
> switch in the DRD code in order to support platforms with
> USB Type-C connectors.
>
> Cc: John Stultz 
> Cc: Felipe Balbi 
> Cc: Greg Kroah-Hartman 
> Cc: Heikki Krogerus 
> Suggested-by: Heikki Krogerus 
> Signed-off-by: Yu Chen 
> ---
> v2:
> * Assign fwnode in dwc3_role_switch.
> ---
> ---
>  drivers/usb/dwc3/core.h |  2 ++
>  drivers/usb/dwc3/drd.c  | 45 +
>  2 files changed, 47 insertions(+)
>
> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
> index 402b3c29eb26..7385544b9936 100644
> --- a/drivers/usb/dwc3/core.h
> +++ b/drivers/usb/dwc3/core.h
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #include 
> @@ -1083,6 +1084,7 @@ struct dwc3 {
> struct extcon_dev   *edev;
> struct notifier_block   edev_nb;
> enum usb_phy_interface  hsphy_mode;
> +   struct usb_role_switch  *role_sw;
>
> u32 fladj;
> u32 irq_gadget;
> diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
> index 869725d15c74..cf977bb0d62e 100644
> --- a/drivers/usb/dwc3/drd.c
> +++ b/drivers/usb/dwc3/drd.c
> @@ -474,8 +474,42 @@ static struct extcon_dev *dwc3_get_extcon(struct dwc3 
> *dwc)
> return edev;
>  }
>
> +static int dwc3_usb_role_switch_set(struct device *dev, enum usb_role role)
> +{
> +   u32 mode;
> +
> +   switch (role) {
> +   case USB_ROLE_HOST:
> +   mode = DWC3_GCTL_PRTCAP_HOST;
> +   break;
> +   case USB_ROLE_DEVICE:
> +   mode = DWC3_GCTL_PRTCAP_DEVICE;
> +   break;
> +   default:
> +   mode = DWC3_GCTL_PRTCAP_HOST;

I'd propose let dwc3 stay at device mode at default case.

> +   break;
> +   };
> +
> +   dwc3_set_mode(dev_get_drvdata(dev), mode);
> +   return 0;
> +}
> +
> +static enum usb_role dwc3_usb_role_switch_get(struct device *dev)
> +{
> +   struct dwc3 *dwc = dev_get_drvdata(dev);
> +   unsigned long flags;
> +   enum usb_role role;
> +
> +   spin_lock_irqsave(>lock, flags);
> +   role = dwc->current_otg_role;
> +   spin_unlock_irqrestore(>lock, flags);
> +
> +   return role;
> +}
> +
>  int dwc3_drd_init(struct dwc3 *dwc)
>  {
> +   struct usb_role_switch_desc dwc3_role_switch = {0};
> int ret, irq;
>
> dwc->edev = dwc3_get_extcon(dwc);
> @@ -522,6 +556,15 @@ int dwc3_drd_init(struct dwc3 *dwc)
> dwc3_set_mode(dwc, DWC3_GCTL_PRTCAP_OTG);
> }
>
> +   dwc3_role_switch.fwnode = dev_fwnode(dwc->dev);
> +   dwc3_role_switch.set = dwc3_usb_role_switch_set;
> +   dwc3_role_switch.get = dwc3_usb_role_switch_get;
> +   dwc->role_sw = usb_role_switch_register(dwc->dev, _role_switch);
> +   if (ret) {
> +   dwc3_drd_exit(dwc);
> +   return PTR_ERR(dwc->role_sw);
> +   }
> +

My understanding is, if you use usb role switch, you don't need either edev or
OTG block event, so this should be like:

if (device_property_read_bool(dwc->dev, "usb-role-switch")) {
   usb role switch register;
} else if (edev) {
...
} else {
...
}

Jun
> return 0;
>  }
>
> @@ -557,4 +600,6 @@ void dwc3_drd_exit(struct dwc3 *dwc)
>
> if (!dwc->edev)
> free_irq(dwc->otg_irq, dwc);
> +
> +   usb_role_switch_unregister(dwc->role_sw);
>  }
> --
> 2.15.0-rc2
>

RE: [PATCH v2 0/9] device connection: Add support for device graphs

[Jun Li]

Hi
> -Original Message-
> From: Heikki Krogerus 
> Sent: 2019年1月31日 0:03
> To: Greg Kroah-Hartman 
> Cc: Andy Shevchenko ; Chen Yu
> ; Jun Li ; Hans de Goede
> ; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: [PATCH v2 0/9] device connection: Add support for device graphs
> 
> Hi,
> 
> This is the second version of this series. On top the two code style 
> improvements
> requested by Andy, I also renamed the connection identifiers used with the USB
> Type-C muxes for something that I felt are better, especially after we start 
> using
> them to name reference device properties in fwnodes. That's why the first 
> patch is
> now split in two, 1/9 and 3/9.
> 
> Hans! Please note that there is no functional change. The alt mode device is 
> still
> getting a handle to the mux, just like before.
> That was actually happening also in the first version of the series.
> 
> The commit message from v1:
> 
> This series adds support for OF and ACPI device graph parsing to the device
> connection API.
> 
> Handling the graph is straightforward, but because I'm adding that fwnode 
> member
> to struct device_connection, I had to make sure all the existing users 
> consider it.
> 
> The plan is to only support matching with fwnode in the future, so no more 
> device
> name matching. The software fwnodes that we now have in kernel should make 
> that
> possible, once we add support for references to them.
> 
> The original RFC:
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.org%
> 2Flkml%2F2018%2F10%2F24%2F619data=02%7C01%7Cjun.li%40nxp.co
> m%7C2fd7c8c28d67434354be08d686cc6b55%7C686ea1d3bc2b4c6fa92cd99c5c
> 301635%7C0%7C0%7C636844609858846167sdata=AWDD9WaO%2BXxM
> Izlli6GUNEq%2FqUpa5hSyLbBsjICdLIo%3Dreserved=0
> 
> thanks,
> 
> Heikki Krogerus (9):
>   platform/x86: intel_cht_int33fe: Prepare for better mux naming scheme
>   usb: typec: Rationalize the API for the muxes
>   platform/x86: intel_cht_int33fe: Remove old style mux connections
>   device connection: Add fwnode member to struct device_connection
>   usb: typec: mux: Find the muxes by also matching against the device
> node
>   usb: roles: Find the muxes by also matching against the device node
>   usb: typec: Find the ports by also matching against the device node
>   device connection: Prepare support for firmware described connections
>   device connection: Find device connections also from device graphs
> 
>  drivers/base/devcon.c| 62 ++-
>  drivers/platform/x86/intel_cht_int33fe.c | 15 ++--
>  drivers/usb/roles/class.c| 21 +-
>  drivers/usb/typec/class.c| 31 ++--
>  drivers/usb/typec/mux.c  | 96 
>  include/linux/device.h   |  6 ++
>  include/linux/usb/role.h |  1 +
>  include/linux/usb/typec_mux.h    |  3 +-
>  8 files changed, 195 insertions(+), 40 deletions(-)
> 
> --
> 2.20.1

I tested this series on dwc3+typec, for usb role switch and typec switch common 
part
Reviewed-by: Jun Li 
Tested-by: Jun Li 

RE: [PATCH v2 6/9] usb: roles: Find the muxes by also matching against the device node

[Jun Li]

Hi
> -Original Message-
> From: Heikki Krogerus 
> Sent: 2019年2月12日 16:51
> To: Jun Li 
> Cc: Greg Kroah-Hartman ; Andy Shevchenko
> ; Chen Yu ; Hans de
> Goede ; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 6/9] usb: roles: Find the muxes by also matching 
> against the
> device node
> 
> Hi,
> 
> On Tue, Feb 12, 2019 at 06:03:42AM +, Jun Li wrote:
> > > > return dev_fwnode(dev->parent) == fwnode;
> > >
> > > That's actually not the case. struct usb_role_switch_desc has a
> > > member for fwnode, and that's what we use with the actual mux
> > > device. Check
> > > usb_role_switch_register():
> > >
> > > ...
> > > sw->dev.fwnode = desc->fwnode;
> > > ...
> > >
> > > Sorry for not realizing it before.
> >
> > So desc->fwnode should be initialized before do usb_role_switch_register()?
> > But seems usb_role_switch_desc is a read-only object so can't be set at 
> > runtime.
> 
> It can. Even though usb_role_switch_register() takes read-only parameter, 
> nothing's
> preventing you from passing data even from the stack (the content of the 
> descriptor
> is copied in any case).
> 
> Expecting the descriptor to be read-only just means it can be read-only, but 
> it does
> not have to be.

Understood, thanks.

> @@ -32,6 +32,7 @@ typedef enum usb_role (*usb_role_switch_get_t)(struct
> device *dev);
>   * usb_role_switch_register() before registering the switch.
>   */
>  struct usb_role_switch_desc {
> + struct fwnode_handle *fwnode;
You may add some description for this new member
/**
 * struct usb_role_switch_desc - USB Role Switch Descriptor
 * @ fwnode 

> 
> > usb_controller_node {
> > ...
> > usb-role-switch;
> >
> > port {
> > sw_provider_node: endpoint {
> > remote-endpoint = <_consumer_node>;
> > };
> > };
> > };
> >
> > typec_node {
> > ...
> > port {
> > sw_consumer_node: endpoint {
> > remote-endpoint = <_provider_node>;
> > };
> > };
> > };
> 
> That looks roughly correct to me.
> 
> 
> thanks,
> 
> --
> heikki

RE: [PATCH v2 6/9] usb: roles: Find the muxes by also matching against the device node

[Jun Li]

> -Original Message-
> From: Heikki Krogerus 
> Sent: 2019年2月11日 18:46
> To: Jun Li 
> Cc: Greg Kroah-Hartman ; Andy Shevchenko
> ; Chen Yu ; Hans de
> Goede ; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v2 6/9] usb: roles: Find the muxes by also matching 
> against the
> device node
> 
> On Mon, Feb 11, 2019 at 09:58:04AM +, Jun Li wrote:
> > Hi Heikki,
> >
> > > @@ -84,7 +85,12 @@ enum usb_role usb_role_switch_get_role(struct
> > > usb_role_switch *sw)  }
> > > EXPORT_SYMBOL_GPL(usb_role_switch_get_role);
> > >
> > > -static int __switch_match(struct device *dev, const void *name)
> > > +static int switch_fwnode_match(struct device *dev, const void
> > > +*fwnode) {
> > > + return dev_fwnode(dev) == fwnode;
> >
> > You missed the comment
> > https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkm
> >
> l.org%2Flkml%2F2019%2F1%2F22%2F437data=02%7C01%7Cjun.li%40nx
> p.com
> > %7C8c2d40d5e5d246da34ad08d6900e31cf%7C686ea1d3bc2b4c6fa92cd99c5
> c301635
> > %7C0%7C0%7C636854788040965224sdata=db4gvXKc9InWiltsweetxXYr
> tPbtfX
> > jshPh%2FnvA24ig%3Dreserved=0
> >
> > return dev_fwnode(dev->parent) == fwnode;
> 
> That's actually not the case. struct usb_role_switch_desc has a member for 
> fwnode,
> and that's what we use with the actual mux device. Check
> usb_role_switch_register():
> 
> ...
> sw->dev.fwnode = desc->fwnode;
> ...
> 
> Sorry for not realizing it before.

So desc->fwnode should be initialized before do usb_role_switch_register()?
But seems usb_role_switch_desc is a read-only object so can't be set at runtime.

usb_controller_node {
...
usb-role-switch;

port {
sw_provider_node: endpoint {
remote-endpoint = <_consumer_node>;
};
};
};

typec_node {
...
port {
sw_consumer_node: endpoint {
remote-endpoint = <_provider_node>;
};
};
};

Is my understanding correct?

Thanks
Jun
> 
> 
> thanks,
> 
> --
> heikki

RE: [PATCH v2 6/9] usb: roles: Find the muxes by also matching against the device node

[Jun Li]

Hi Heikki,

> @@ -84,7 +85,12 @@ enum usb_role usb_role_switch_get_role(struct
> usb_role_switch *sw)  }  EXPORT_SYMBOL_GPL(usb_role_switch_get_role);
> 
> -static int __switch_match(struct device *dev, const void *name)
> +static int switch_fwnode_match(struct device *dev, const void *fwnode)
> +{
> + return dev_fwnode(dev) == fwnode;

You missed the comment
https://lkml.org/lkml/2019/1/22/437

return dev_fwnode(dev->parent) == fwnode;

Jun

Re: [RFC PATCH 3/5] usb: roles: Find the muxes by also matching against the device node

[Jun Li]

Hi Heikki,
Heikki Krogerus  于2018年10月24日周三 下午11:06写道：
>
> When the connections are defined in firmware, struct
> device_connection will have the fwnode member pointing to
> the device node (struct fwnode_handle) of the requested
> device, and the endpoint will not be used at all in that
> case.
>
> Signed-off-by: Heikki Krogerus 
> ---
>  drivers/usb/common/roles.c | 16 +---
>  1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/common/roles.c b/drivers/usb/common/roles.c
> index 99116af07f1d..bb52e006d203 100644
> --- a/drivers/usb/common/roles.c
> +++ b/drivers/usb/common/roles.c
> @@ -8,6 +8,7 @@
>   */
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -84,7 +85,12 @@ enum usb_role usb_role_switch_get_role(struct 
> usb_role_switch *sw)
>  }
>  EXPORT_SYMBOL_GPL(usb_role_switch_get_role);
>
> -static int __switch_match(struct device *dev, const void *name)
> +static int switch_fwnode_match(struct device *dev, const void *fwnode)
> +{
> +   return dev_fwnode(dev) == fwnode;

Seems this should be dev_fwnode(dev->parent) == fwnode;
The role switch is the child dev of the caller of usb_role_switch_register().

Li Jun

> +}
> +
> +static int switch_name_match(struct device *dev, const void *name)
>  {
> return !strcmp((const char *)name, dev_name(dev));
>  }
> @@ -94,8 +100,12 @@ static void *usb_role_switch_match(struct 
> device_connection *con, int ep,
>  {
> struct device *dev;
>
> -   dev = class_find_device(role_class, NULL, con->endpoint[ep],
> -   __switch_match);
> +   if (con->fwnode)
> +   dev = class_find_device(role_class, NULL, con->fwnode,
> +   switch_fwnode_match);
> +   else
> +   dev = class_find_device(role_class, NULL, con->endpoint[ep],
> +   switch_name_match);
>
> return dev ? to_role_switch(dev) : ERR_PTR(-EPROBE_DEFER);
>  }
> --
> 2.19.1
>

RE: [PATCH v7] staging: typec: handle vendor defined part and modify drp toggling flow

[Jun Li]

> -Original Message-
> From: 李書帆 [mailto:leechu...@gmail.com]
> Sent: 2018年3月12日 14:57
> To: Jun Li <jun...@nxp.com>
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>;
> heikki.kroge...@linux.intel.com; li...@roeck-us.net; g...@kroah.com;
> shufan_...@richtek.com; cy_hu...@richtek.com;
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH v7] staging: typec: handle vendor defined part and modify
> drp toggling flow
> 
> Hi Jun,
> 
> 2018-03-12 13:58 GMT+08:00 Jun Li <jun...@nxp.com>:
> > Hi
> >> -Original Message-
> >> From: 李書帆 [mailto:leechu...@gmail.com]
> >> Sent: 2018年3月12日 13:22
> >> To: Jun Li <jun...@nxp.com>
> >> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>;
> >> heikki.kroge...@linux.intel.com; li...@roeck-us.net; g...@kroah.com;
> >> shufan_...@richtek.com; cy_hu...@richtek.com;
> >> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
> >> Subject: Re: [PATCH v7] staging: typec: handle vendor defined part
> >> and modify drp toggling flow
> >>
> >> Hi Jun,
> >>
> >>   Thank you.
> >>
> >> 2018-03-12 12:33 GMT+08:00 Jun Li <jun...@nxp.com>:
> >> > Hi,
> >> >
> >> >> +static irqreturn_t _tcpci_irq(int irq, void *dev_id) {
> >> >> + struct tcpci *tcpci = dev_id;
> >> >> +
> >> >> + return tcpci_irq(tcpci);
> >> >> +}
> >> >>
> >> > ...
> >> >
> >> >> + err = devm_request_threaded_irq(>dev, client->irq, NULL,
> >> >> + _tcpci_irq,
> >> >>   IRQF_ONESHOT |
> >> IRQF_TRIGGER_LOW,
> >> >> - dev_name(tcpci->dev),
> tcpci);
> >> >> + dev_name(>dev),
> >> >> + chip);
> >> >
> >> > - dev_name(>dev), chip);
> >> > + dev_name(>dev), chip->tcpci);
> >> >
> >> > Did you ever test this patch?
> >> I've tested this patch with tcpci_rt1711h.c that will be sent out for
> >> reviewing in the next patch after tcpci's modification is passed.
> >> Because interrupt handler is registered in tcpci_rt1711h.c, here is
> >> the place I didn't notice.
> >
> > Understood.
> >
> >> The interrupt handler for tcpci.c should be modified as following:
> >>  static irqreturn_t _tcpci_irq(int irq, void *dev_id)  {
> >> -   struct tcpci *tcpci = dev_id;
> >> +   struct tcpci_chip *chip = dev_id;
> >>
> >> -   return tcpci_irq(tcpci);
> >> +   return tcpci_irq(chip->tcpci);
> >>  }
> >>
> >
> > Either way is OK to fix it.
> > You may send out your v8 and notify Greg to drop your v7 version.
> >
> > Jun Li
> 
> May I add you in the Reported-by list?

I just gave a run with your patch on my HW, so for your new version,
you can directly add:

Reviewed-by: Li Jun <jun...@nxp.com>
Tested-by: Li Jun <jun...@nxp.com>

> 
> --
> Best Regards,
> 書帆

RE: [PATCH v7] staging: typec: handle vendor defined part and modify drp toggling flow

[Jun Li]

> -Original Message-
> From: 李書帆 [mailto:leechu...@gmail.com]
> Sent: 2018年3月12日 14:57
> To: Jun Li 
> Cc: Greg Kroah-Hartman ;
> heikki.kroge...@linux.intel.com; li...@roeck-us.net; g...@kroah.com;
> shufan_...@richtek.com; cy_hu...@richtek.com;
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH v7] staging: typec: handle vendor defined part and modify
> drp toggling flow
> 
> Hi Jun,
> 
> 2018-03-12 13:58 GMT+08:00 Jun Li :
> > Hi
> >> -Original Message-
> >> From: 李書帆 [mailto:leechu...@gmail.com]
> >> Sent: 2018年3月12日 13:22
> >> To: Jun Li 
> >> Cc: Greg Kroah-Hartman ;
> >> heikki.kroge...@linux.intel.com; li...@roeck-us.net; g...@kroah.com;
> >> shufan_...@richtek.com; cy_hu...@richtek.com;
> >> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
> >> Subject: Re: [PATCH v7] staging: typec: handle vendor defined part
> >> and modify drp toggling flow
> >>
> >> Hi Jun,
> >>
> >>   Thank you.
> >>
> >> 2018-03-12 12:33 GMT+08:00 Jun Li :
> >> > Hi,
> >> >
> >> >> +static irqreturn_t _tcpci_irq(int irq, void *dev_id) {
> >> >> + struct tcpci *tcpci = dev_id;
> >> >> +
> >> >> + return tcpci_irq(tcpci);
> >> >> +}
> >> >>
> >> > ...
> >> >
> >> >> + err = devm_request_threaded_irq(>dev, client->irq, NULL,
> >> >> + _tcpci_irq,
> >> >>   IRQF_ONESHOT |
> >> IRQF_TRIGGER_LOW,
> >> >> - dev_name(tcpci->dev),
> tcpci);
> >> >> + dev_name(>dev),
> >> >> + chip);
> >> >
> >> > - dev_name(>dev), chip);
> >> > + dev_name(>dev), chip->tcpci);
> >> >
> >> > Did you ever test this patch?
> >> I've tested this patch with tcpci_rt1711h.c that will be sent out for
> >> reviewing in the next patch after tcpci's modification is passed.
> >> Because interrupt handler is registered in tcpci_rt1711h.c, here is
> >> the place I didn't notice.
> >
> > Understood.
> >
> >> The interrupt handler for tcpci.c should be modified as following:
> >>  static irqreturn_t _tcpci_irq(int irq, void *dev_id)  {
> >> -   struct tcpci *tcpci = dev_id;
> >> +   struct tcpci_chip *chip = dev_id;
> >>
> >> -   return tcpci_irq(tcpci);
> >> +   return tcpci_irq(chip->tcpci);
> >>  }
> >>
> >
> > Either way is OK to fix it.
> > You may send out your v8 and notify Greg to drop your v7 version.
> >
> > Jun Li
> 
> May I add you in the Reported-by list?

I just gave a run with your patch on my HW, so for your new version,
you can directly add:

Reviewed-by: Li Jun 
Tested-by: Li Jun 

> 
> --
> Best Regards,
> 書帆

RE: [PATCH v7] staging: typec: handle vendor defined part and modify drp toggling flow

[Jun Li]

Hi
> -Original Message-
> From: 李書帆 [mailto:leechu...@gmail.com]
> Sent: 2018年3月12日 13:22
> To: Jun Li <jun...@nxp.com>
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>;
> heikki.kroge...@linux.intel.com; li...@roeck-us.net; g...@kroah.com;
> shufan_...@richtek.com; cy_hu...@richtek.com;
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH v7] staging: typec: handle vendor defined part and modify
> drp toggling flow
> 
> Hi Jun,
> 
>   Thank you.
> 
> 2018-03-12 12:33 GMT+08:00 Jun Li <jun...@nxp.com>:
> > Hi,
> >
> >> +static irqreturn_t _tcpci_irq(int irq, void *dev_id) {
> >> + struct tcpci *tcpci = dev_id;
> >> +
> >> + return tcpci_irq(tcpci);
> >> +}
> >>
> > ...
> >
> >> + err = devm_request_threaded_irq(>dev, client->irq, NULL,
> >> + _tcpci_irq,
> >>   IRQF_ONESHOT |
> IRQF_TRIGGER_LOW,
> >> - dev_name(tcpci->dev), tcpci);
> >> + dev_name(>dev), chip);
> >
> > - dev_name(>dev), chip);
> > + dev_name(>dev), chip->tcpci);
> >
> > Did you ever test this patch?
> I've tested this patch with tcpci_rt1711h.c that will be sent out for 
> reviewing in
> the next patch after tcpci's modification is passed.
> Because interrupt handler is registered in tcpci_rt1711h.c, here is the place 
> I
> didn't notice.

Understood.

> The interrupt handler for tcpci.c should be modified as following:
>  static irqreturn_t _tcpci_irq(int irq, void *dev_id)  {
> -   struct tcpci *tcpci = dev_id;
> +   struct tcpci_chip *chip = dev_id;
> 
> -   return tcpci_irq(tcpci);
> +   return tcpci_irq(chip->tcpci);
>  }
> 

Either way is OK to fix it.
You may send out your v8 and notify Greg to drop your v7 version.

Jun Li

RE: [PATCH v7] staging: typec: handle vendor defined part and modify drp toggling flow

[Jun Li]

Hi
> -Original Message-
> From: 李書帆 [mailto:leechu...@gmail.com]
> Sent: 2018年3月12日 13:22
> To: Jun Li 
> Cc: Greg Kroah-Hartman ;
> heikki.kroge...@linux.intel.com; li...@roeck-us.net; g...@kroah.com;
> shufan_...@richtek.com; cy_hu...@richtek.com;
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
> Subject: Re: [PATCH v7] staging: typec: handle vendor defined part and modify
> drp toggling flow
> 
> Hi Jun,
> 
>   Thank you.
> 
> 2018-03-12 12:33 GMT+08:00 Jun Li :
> > Hi,
> >
> >> +static irqreturn_t _tcpci_irq(int irq, void *dev_id) {
> >> + struct tcpci *tcpci = dev_id;
> >> +
> >> + return tcpci_irq(tcpci);
> >> +}
> >>
> > ...
> >
> >> + err = devm_request_threaded_irq(>dev, client->irq, NULL,
> >> + _tcpci_irq,
> >>   IRQF_ONESHOT |
> IRQF_TRIGGER_LOW,
> >> - dev_name(tcpci->dev), tcpci);
> >> + dev_name(>dev), chip);
> >
> > - dev_name(>dev), chip);
> > + dev_name(>dev), chip->tcpci);
> >
> > Did you ever test this patch?
> I've tested this patch with tcpci_rt1711h.c that will be sent out for 
> reviewing in
> the next patch after tcpci's modification is passed.
> Because interrupt handler is registered in tcpci_rt1711h.c, here is the place 
> I
> didn't notice.

Understood.

> The interrupt handler for tcpci.c should be modified as following:
>  static irqreturn_t _tcpci_irq(int irq, void *dev_id)  {
> -   struct tcpci *tcpci = dev_id;
> +   struct tcpci_chip *chip = dev_id;
> 
> -   return tcpci_irq(tcpci);
> +   return tcpci_irq(chip->tcpci);
>  }
> 

Either way is OK to fix it.
You may send out your v8 and notify Greg to drop your v7 version.

Jun Li

RE: [PATCH v7] staging: typec: handle vendor defined part and modify drp toggling flow

[Jun Li]

Hi,

> +static irqreturn_t _tcpci_irq(int irq, void *dev_id) {
> + struct tcpci *tcpci = dev_id;
> +
> + return tcpci_irq(tcpci);
> +}
> 
...

> + err = devm_request_threaded_irq(>dev, client->irq, NULL,
> + _tcpci_irq,
>   IRQF_ONESHOT | IRQF_TRIGGER_LOW,
> - dev_name(tcpci->dev), tcpci);
> + dev_name(>dev), chip);

- dev_name(>dev), chip);
+ dev_name(>dev), chip->tcpci); 

Did you ever test this patch?

I noticed Greg already picked this patch[1]:
[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-testing=8f94390226487bcb86c554ddc12eef0d27bdec3b

One more minor comment below.

Jun Li

> diff --git a/drivers/staging/typec/tcpci.h b/drivers/staging/typec/tcpci.h 
> index
> fdfb06c..a2c1754 100644
> --- a/drivers/staging/typec/tcpci.h
> +++ b/drivers/staging/typec/tcpci.h
> @@ -59,6 +59,7 @@
>  #define TCPC_POWER_CTRL_VCONN_ENABLE BIT(0)
> 
>  #define TCPC_CC_STATUS   0x1d
> +#define TCPC_CC_STATUS_DRPRSTBIT(5)

Defined but not used.

>  #define TCPC_CC_STATUS_TERM  BIT(4)
>  #define TCPC_CC_STATUS_CC2_SHIFT 2
>  #define TCPC_CC_STATUS_CC2_MASK  0x3
> @@ -121,4 +122,18 @@
>  #define TCPC_VBUS_VOLTAGE_ALARM_HI_CFG   0x76
>  #define TCPC_VBUS_VOLTAGE_ALARM_LO_CFG   0x78
> 
> +struct tcpci;
> +struct tcpci_data {
> + struct regmap *regmap;
> + int (*init)(struct tcpci *tcpci, struct tcpci_data *data);
> + int (*set_vconn)(struct tcpci *tcpci, struct tcpci_data *data,
> +  bool enable);
> + int (*start_drp_toggling)(struct tcpci *tcpci, struct tcpci_data *data,
> +   enum typec_cc_status cc);
> +};
> +
> +struct tcpci *tcpci_register_port(struct device *dev, struct tcpci_data
> +*data); void tcpci_unregister_port(struct tcpci *tcpci); irqreturn_t
> +tcpci_irq(struct tcpci *tcpci);
> +
>  #endif /* __LINUX_USB_TCPCI_H */
> --
> 1.9.1

RE: [PATCH v7] staging: typec: handle vendor defined part and modify drp toggling flow

[Jun Li]

Hi,

> +static irqreturn_t _tcpci_irq(int irq, void *dev_id) {
> + struct tcpci *tcpci = dev_id;
> +
> + return tcpci_irq(tcpci);
> +}
> 
...

> + err = devm_request_threaded_irq(>dev, client->irq, NULL,
> + _tcpci_irq,
>   IRQF_ONESHOT | IRQF_TRIGGER_LOW,
> - dev_name(tcpci->dev), tcpci);
> + dev_name(>dev), chip);

- dev_name(>dev), chip);
+ dev_name(>dev), chip->tcpci); 

Did you ever test this patch?

I noticed Greg already picked this patch[1]:
[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-testing=8f94390226487bcb86c554ddc12eef0d27bdec3b

One more minor comment below.

Jun Li

> diff --git a/drivers/staging/typec/tcpci.h b/drivers/staging/typec/tcpci.h 
> index
> fdfb06c..a2c1754 100644
> --- a/drivers/staging/typec/tcpci.h
> +++ b/drivers/staging/typec/tcpci.h
> @@ -59,6 +59,7 @@
>  #define TCPC_POWER_CTRL_VCONN_ENABLE BIT(0)
> 
>  #define TCPC_CC_STATUS   0x1d
> +#define TCPC_CC_STATUS_DRPRSTBIT(5)

Defined but not used.

>  #define TCPC_CC_STATUS_TERM  BIT(4)
>  #define TCPC_CC_STATUS_CC2_SHIFT 2
>  #define TCPC_CC_STATUS_CC2_MASK  0x3
> @@ -121,4 +122,18 @@
>  #define TCPC_VBUS_VOLTAGE_ALARM_HI_CFG   0x76
>  #define TCPC_VBUS_VOLTAGE_ALARM_LO_CFG   0x78
> 
> +struct tcpci;
> +struct tcpci_data {
> + struct regmap *regmap;
> + int (*init)(struct tcpci *tcpci, struct tcpci_data *data);
> + int (*set_vconn)(struct tcpci *tcpci, struct tcpci_data *data,
> +  bool enable);
> + int (*start_drp_toggling)(struct tcpci *tcpci, struct tcpci_data *data,
> +   enum typec_cc_status cc);
> +};
> +
> +struct tcpci *tcpci_register_port(struct device *dev, struct tcpci_data
> +*data); void tcpci_unregister_port(struct tcpci *tcpci); irqreturn_t
> +tcpci_irq(struct tcpci *tcpci);
> +
>  #endif /* __LINUX_USB_TCPCI_H */
> --
> 1.9.1

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 <jun...@nxp.com>; ShuFanLee <leechu...@gmail.com>;
> heikki.kroge...@linux.intel.com; li...@roeck-us.net; g...@kroah.com
> Cc: cy_huang(黃啟原) <cy_hu...@richtek.com>;
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; dl-linux-imx
> <linux-...@nxp.com>
> 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-kernel@vger.kernel.org;
> > linux-...@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 <jun...@nxp.com>; ShuFanLee <leechu...@gmail.com>;
> > heikki.kroge...@linux.intel.com; li...@roeck-us.net; g...@kroah.com
> > Cc: cy_huang(黃啟原) <cy_hu...@richtek.com>;
> > linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; dl-linux-imx
> > <linux-...@nxp.com>
> > 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.0

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-kernel@vger.kernel.org; linux-...@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-kernel@vger.kernel.org;
> > linux-...@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-kernel@vger.kernel.org; linux-...@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 

RE: [PATCH] staging: typec: handle vendor defined part and modify drp toggling flow

[Jun Li]

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 <jun...@nxp.com>; ShuFanLee <leechu...@gmail.com>;
> heikki.kroge...@linux.intel.com; li...@roeck-us.net; g...@kroah.com
> Cc: cy_huang(黃啟原) <cy_hu...@richtek.com>;
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; dl-linux-imx
> <linux-...@nxp.com>
> 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)

> [ 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 not pull cc1/cc2 to Rd while writing
> Rd/Rd to RC.CC1/RC.CC2.
> - (Note2) Right after LOOK4CONNECTION command is written, RT1711H
> pulls CC to Rd's level (because RC.Role is Rd/Rd), stop toggling (because
> device(Rd) is already connected) and CC status will be open/open now
> (because RT1711H presents Rd and device is connected(Rd))
> 
> [ 915.037263] typec_rt1711h 2-004e: __tcpm_get_cc cc1 = Open, cc2 =
> Open => Enter RT1711H's irq handler and it reports open/open
> 
> I think the point is to write RC.DRP = 0 at the beginning of drp_toggling so
> that RT1711H will pull cc1/cc2 to Rd while writing Rd/Rd to RC.CC1/RC.CC2
> This operation will make RT1711H's internal firmware restarts from
> disconnected state and toggles correctly.
> 
> According to TCPCI spec (4.4.5.2):
> It is recommended the TCPM write ROLE_CONTROL.DRP=0 before writing to
> POWER_CONTROL.AutoDischargeDisconnect and starting the DRP toggling
> using COMMAND.Look4Connection Restart DRP Toggling => It is
> recommended the TCPM write ROLE_CONTROL.DRP=0 here Set

This statement is_not_ recommend you do this(RC.DRP=0) for start drp toggling,
Please carefully check the whole sentence:
"... as shown in Figure 4-16, "
If you look at "Figure 4-16. DRP Initialization and Connection Detection"
It gives clear drp toggling start operations:

Set TCPC to DRP
- Read PS.TCPCInitializationStatus
- Write ROLE_CONTROL
- RC.DRP = 1b
- RC.CC2=01b or 10b
- RC.CC1=01b or 10b
- RC.CC1=RC.CC2
- Write COMMAND.Look4ConnectionPS.

Above is all operations required to start drp toggling. You also
can see RC.CCx = 01b or 10b, not fixed to be Rd, right?

Go on to check the Figure 4-16 
After debounce, we need do following:

ConnectionDetermine CC & VCONN
- Write RC.CC1 & RC.CC2 per decision
- Write RC.DRP=0
- Write TCPC_CONTROl.PlugOrientation
- Write PC.AutoDischargeDisconnect=1
 & PC.EnableVconnConnection

Current existing tcpm+tcpci will not clear RC.DRP after attach,
That means RC.DRP clear may be done after attach, not in start_drp_toggling.
I am not sure if this can resolve your problem, but I think it deserve
a try, you can follow above operation sequence while entering
attach state, refer to my patch[2]:

[2] https://www.spinics.net/lists/devicetree/msg216852.html

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 530a5d7..7145771 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -184,6 +184,7 @@ static int tcpci_set_polarity(struct tcpc_dev *tcpc,
  enum typec_cc_polarity polarity)
 {
struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
+   unsigned int reg;
int ret;

ret = regmap_write(tcpci->regmap, TCPC_TCPC_C

RE: [PATCH] staging: typec: handle vendor defined part and modify drp toggling flow

[Jun Li]

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-kernel@vger.kernel.org; linux-...@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)

> [ 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 not pull cc1/cc2 to Rd while writing
> Rd/Rd to RC.CC1/RC.CC2.
> - (Note2) Right after LOOK4CONNECTION command is written, RT1711H
> pulls CC to Rd's level (because RC.Role is Rd/Rd), stop toggling (because
> device(Rd) is already connected) and CC status will be open/open now
> (because RT1711H presents Rd and device is connected(Rd))
> 
> [ 915.037263] typec_rt1711h 2-004e: __tcpm_get_cc cc1 = Open, cc2 =
> Open => Enter RT1711H's irq handler and it reports open/open
> 
> I think the point is to write RC.DRP = 0 at the beginning of drp_toggling so
> that RT1711H will pull cc1/cc2 to Rd while writing Rd/Rd to RC.CC1/RC.CC2
> This operation will make RT1711H's internal firmware restarts from
> disconnected state and toggles correctly.
> 
> According to TCPCI spec (4.4.5.2):
> It is recommended the TCPM write ROLE_CONTROL.DRP=0 before writing to
> POWER_CONTROL.AutoDischargeDisconnect and starting the DRP toggling
> using COMMAND.Look4Connection Restart DRP Toggling => It is
> recommended the TCPM write ROLE_CONTROL.DRP=0 here Set

This statement is_not_ recommend you do this(RC.DRP=0) for start drp toggling,
Please carefully check the whole sentence:
"... as shown in Figure 4-16, "
If you look at "Figure 4-16. DRP Initialization and Connection Detection"
It gives clear drp toggling start operations:

Set TCPC to DRP
- Read PS.TCPCInitializationStatus
- Write ROLE_CONTROL
- RC.DRP = 1b
- RC.CC2=01b or 10b
- RC.CC1=01b or 10b
- RC.CC1=RC.CC2
- Write COMMAND.Look4ConnectionPS.

Above is all operations required to start drp toggling. You also
can see RC.CCx = 01b or 10b, not fixed to be Rd, right?

Go on to check the Figure 4-16 
After debounce, we need do following:

ConnectionDetermine CC & VCONN
- Write RC.CC1 & RC.CC2 per decision
- Write RC.DRP=0
- Write TCPC_CONTROl.PlugOrientation
- Write PC.AutoDischargeDisconnect=1
 & PC.EnableVconnConnection

Current existing tcpm+tcpci will not clear RC.DRP after attach,
That means RC.DRP clear may be done after attach, not in start_drp_toggling.
I am not sure if this can resolve your problem, but I think it deserve
a try, you can follow above operation sequence while entering
attach state, refer to my patch[2]:

[2] https://www.spinics.net/lists/devicetree/msg216852.html

diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
index 530a5d7..7145771 100644
--- a/drivers/staging/typec/tcpci.c
+++ b/drivers/staging/typec/tcpci.c
@@ -184,6 +184,7 @@ static int tcpci_set_polarity(struct tcpc_dev *tcpc,
  enum typec_cc_polarity polarity)
 {
struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
+   unsigned int reg;
int ret;

ret = regmap_write(tcpci->regmap, TCPC_TCPC_CTRL,
@@ -192,6 +193,20 @@ static int tcpci_set_polarity(struct tcpc_dev *tcpc,
if (ret < 0)
   

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年2月28日 11:41
> To: Jun Li <jun...@nxp.com>; ShuFanLee <leechu...@gmail.com>;
> heikki.kroge...@linux.intel.com; li...@roeck-us.net; g...@kroah.com
> Cc: cy_huang(�S�⒃�) <cy_hu...@richtek.com>;
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; dl-linux-imx
> <linux-...@nxp.com>
> Subject: 回覆: [PATCH] staging: typec: handle vendor defined part and
> modify drp toggling flow
> 
> Hi Jun,
> 
>   For the questions of drp_toggling, our test is as following:
> 
>   According to TCPCI 4.4.5.2
> It is recommended the TCPM write ROLE_CONTROL.DRP=0 before writing to
> POWER_CONTROL.AutoDischargeDisconnect and starting the DRP toggling
> using COMMAND.Look4Connection.
> 
>   We've encounter a situation while testing with RT1711H as following:
>   We repeatedly plug in/out a device (with Rd), and not to provide VBUS(5V)
> while plugging in.
>   If we plug out the device right after TCPC detects it and stops toggling,
> TCPM will try to restart drp_toggling.
>   Here, we re-plug in the device before TCPM calls drp_toggling. Under this
> circumstance, RT1711H reports open/open after drp_toggling is called.

Why RT1711H reports open/open after drp_toggling is enabled?
This open/open is for you plug out the device, right?
Why RT1711H can't report new cc change events after you plug in the device?

Please use tcpm log to show all the events and state transitions for your
above corner case.
cat /sys/kernel/debug/tcpm/x

>   For current TCPM, it stops if open/open is reported at drp_toggling state.
> 
>   The detailed flow that causes RT1711H reporting open/open is described
> as following:
>   1. RT1711H detects the device, stops toggling and reports to TCPM.
>   2. Rd is plugged out before set_cc is called. So, ROLE_CONTROL.DRP is
> still 1.

So open/open cc change will generate.
 
>   3. Plug in the device before TCPM restarts drp_toggling
>   4. The device is detected by RT1711H's internal firmware again(TCPC
> chip's internal firmware).

What cc change event tcpc will report on step 4?

>   5. TCPM calls drp_toggling before cc_change triggered by step 4 is
> handled.
>   6. TCPM sets ROLE_CONTROL.DRP = 1, Rd/Rd and start drp_toggling.
> According to TCPCI 4.4.5.2
> The TCPM shall write B6 (DRP) = 0b and B3..0 (CC1/CC2) if it wishes to
> control the Rp/Rd directly instead of having the TCPC perform DRP toggling
> autonomousl.
> So, Rd/Rd set in step 6 will not work. (Because ROLE_CONTROL.DRP is 1
> since the first step.)
>   7. RT1711H will stop toggling immediately (Because it's internal firmware
> already detects device at step 4) and report open/open (Because CC1/CC2
> will be changed to Rd by RT1711H after LOOK4CONNECTION is set. RT1711H
> sets to Rd and device is Rd so open is reported)
>   8. TCPCI reports open/open to TCPM at drp_toggling state
> 
>   That's why we always set ROLE_CONTROL.DRP to 0 while setting Rd/Rd.
>   If this circumstance is not a general case, we can also use a vendor ops to
> replace it.

Thanks for the detailed description, the tcpm full log is required to know
what's going on here, you can apply my drp_toggling change patch[1] and
run your problem case again, then post the full tcpm log. 

Generally, I think you need check further this is a problem on the current
tcpm _or_ your tcpc chip, if the problem on the tcpm, you should resolve
this issue by improve tcpm, if the problem on your tcpc chip, you can add
a vendor ops.

I tested my tcpc HW with my drp_toggling change patch[1] (w/o your change)
by quickly pulg-in & plug-out a sink, no problem found.
Did you verify your change can pass the typec compliance test?

[1] https://www.spinics.net/lists/devicetree/msg216851.html
> ==
> ==
> 
> I don't catch the point of how you handle private events by above change,
> maybe post your RT1711H part as a user in one series can make it clear, I
> assume this can be done in existing tcpci_irq like above vender specific
> handling as well:
> 
> For every glue driver, it registers its own irq handler and calls tcpci_irq 
> in the
> handler.
> 
> Take RT1711H as an example:
> It registers its own irq handler in probe function and handle vendor defined
> interrupts before calling general tcpci_irq:
> 
> static irqreturn_t _tcpci_irq(int irq, void *dev_id) {
> struct rt1711h_chip *chip = dev_id;
> 
> /* handle vendor defined interrupts here */
> 
> /* call general tcpci_irq */
> return tcpci_irq(chip->tcpci);
> }
> 
> static int rt1711h_probe(struct i2c_client *client, const struct i2c_device_id
> *i2c_id) {
>   

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年2月28日 11:41
> To: Jun Li ; ShuFanLee ;
> heikki.kroge...@linux.intel.com; li...@roeck-us.net; g...@kroah.com
> Cc: cy_huang(�S�⒃�) ;
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; dl-linux-imx
> 
> Subject: 回覆: [PATCH] staging: typec: handle vendor defined part and
> modify drp toggling flow
> 
> Hi Jun,
> 
>   For the questions of drp_toggling, our test is as following:
> 
>   According to TCPCI 4.4.5.2
> It is recommended the TCPM write ROLE_CONTROL.DRP=0 before writing to
> POWER_CONTROL.AutoDischargeDisconnect and starting the DRP toggling
> using COMMAND.Look4Connection.
> 
>   We've encounter a situation while testing with RT1711H as following:
>   We repeatedly plug in/out a device (with Rd), and not to provide VBUS(5V)
> while plugging in.
>   If we plug out the device right after TCPC detects it and stops toggling,
> TCPM will try to restart drp_toggling.
>   Here, we re-plug in the device before TCPM calls drp_toggling. Under this
> circumstance, RT1711H reports open/open after drp_toggling is called.

Why RT1711H reports open/open after drp_toggling is enabled?
This open/open is for you plug out the device, right?
Why RT1711H can't report new cc change events after you plug in the device?

Please use tcpm log to show all the events and state transitions for your
above corner case.
cat /sys/kernel/debug/tcpm/x

>   For current TCPM, it stops if open/open is reported at drp_toggling state.
> 
>   The detailed flow that causes RT1711H reporting open/open is described
> as following:
>   1. RT1711H detects the device, stops toggling and reports to TCPM.
>   2. Rd is plugged out before set_cc is called. So, ROLE_CONTROL.DRP is
> still 1.

So open/open cc change will generate.
 
>   3. Plug in the device before TCPM restarts drp_toggling
>   4. The device is detected by RT1711H's internal firmware again(TCPC
> chip's internal firmware).

What cc change event tcpc will report on step 4?

>   5. TCPM calls drp_toggling before cc_change triggered by step 4 is
> handled.
>   6. TCPM sets ROLE_CONTROL.DRP = 1, Rd/Rd and start drp_toggling.
> According to TCPCI 4.4.5.2
> The TCPM shall write B6 (DRP) = 0b and B3..0 (CC1/CC2) if it wishes to
> control the Rp/Rd directly instead of having the TCPC perform DRP toggling
> autonomousl.
> So, Rd/Rd set in step 6 will not work. (Because ROLE_CONTROL.DRP is 1
> since the first step.)
>   7. RT1711H will stop toggling immediately (Because it's internal firmware
> already detects device at step 4) and report open/open (Because CC1/CC2
> will be changed to Rd by RT1711H after LOOK4CONNECTION is set. RT1711H
> sets to Rd and device is Rd so open is reported)
>   8. TCPCI reports open/open to TCPM at drp_toggling state
> 
>   That's why we always set ROLE_CONTROL.DRP to 0 while setting Rd/Rd.
>   If this circumstance is not a general case, we can also use a vendor ops to
> replace it.

Thanks for the detailed description, the tcpm full log is required to know
what's going on here, you can apply my drp_toggling change patch[1] and
run your problem case again, then post the full tcpm log. 

Generally, I think you need check further this is a problem on the current
tcpm _or_ your tcpc chip, if the problem on the tcpm, you should resolve
this issue by improve tcpm, if the problem on your tcpc chip, you can add
a vendor ops.

I tested my tcpc HW with my drp_toggling change patch[1] (w/o your change)
by quickly pulg-in & plug-out a sink, no problem found.
Did you verify your change can pass the typec compliance test?

[1] https://www.spinics.net/lists/devicetree/msg216851.html
> ==
> ==
> 
> I don't catch the point of how you handle private events by above change,
> maybe post your RT1711H part as a user in one series can make it clear, I
> assume this can be done in existing tcpci_irq like above vender specific
> handling as well:
> 
> For every glue driver, it registers its own irq handler and calls tcpci_irq 
> in the
> handler.
> 
> Take RT1711H as an example:
> It registers its own irq handler in probe function and handle vendor defined
> interrupts before calling general tcpci_irq:
> 
> static irqreturn_t _tcpci_irq(int irq, void *dev_id) {
> struct rt1711h_chip *chip = dev_id;
> 
> /* handle vendor defined interrupts here */
> 
> /* call general tcpci_irq */
> return tcpci_irq(chip->tcpci);
> }
> 
> static int rt1711h_probe(struct i2c_client *client, const struct i2c_device_id
> *i2c_id) {
> 
> ret = devm_request_threaded_irq(chip->dev, 

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

[Jun Li]

Hi,
> -Original Message-

> +struct device *device_find_connection(struct device *dev, const char
> +*con_id) {
> + return __device_find_connection(dev, con_id, generic_match, NULL); }

-   return __device_find_connection(dev, con_id, generic_match, NULL);
+   return __device_find_connection(dev, con_id, NULL, generic_match);

Jun Li
> +EXPORT_SYMBOL_GPL(device_find_connection);

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

[Jun Li]

Hi,
> -Original Message-

> +struct device *device_find_connection(struct device *dev, const char
> +*con_id) {
> + return __device_find_connection(dev, con_id, generic_match, NULL); }

-   return __device_find_connection(dev, con_id, generic_match, NULL);
+   return __device_find_connection(dev, con_id, NULL, generic_match);

Jun Li
> +EXPORT_SYMBOL_GPL(device_find_connection);

RE: [PATCH] staging: typec: handle vendor defined part and modify drp toggling flow

[Jun Li]

Hi,

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org
> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of ShuFanLee
> Sent: 2018年2月21日 23:02
> To: heikki.kroge...@linux.intel.com; li...@roeck-us.net; g...@kroah.com
> Cc: shufan_...@richtek.com; cy_hu...@richtek.com;
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
> Subject: [PATCH] staging: typec: handle vendor defined part and modify drp
> toggling flow
> 
> From: ShuFanLee 
> 
> Handle vendor defined behavior in tcpci_init, tcpci_set_vconn and export
> tcpci_irq.
> More operations can be extended in tcpci_data if needed.
> According to TCPCI specification, 4.4.5.2 ROLE_CONTROL, TCPC shall not
> start DRP toggling until subsequently the TCPM writes to the COMMAND
> register to start DRP toggling.

My understanding of above statement is TCPM(this Linux driver) can enable
DRP and CC1/CC2 in one shot, but TCPC(your typec chip internal firmware)
needs wait until TCPM writes to COMMAND register to start drp toggling.

> DRP toggling flow is chagned as following:
>   - Write DRP = 0 & Rd/Rd

Why fixed to be Rd/Rd? in this case, it means the starting value:

Tcpci 4.4.5.2:
"When initiating autonomous DRP toggling, the TCPM shall write B6 (DRP) =1b
and the starting value of Rp/Rd to B3..0 (CC1/CC2) to indicate DRP autonomous
toggling mode to the TCPC."

>   - Write DRP = 1

What's your problem if combine above 2 in one shot?

>   - Set LOOK4CONNECTION command
> 
> Signed-off-by: ShuFanLee 
> ---
>  drivers/staging/typec/tcpci.c | 128
> +-
>  drivers/staging/typec/tcpci.h |  13 +
>  2 files changed, 115 insertions(+), 26 deletions(-)
> 
>  patch changelogs between v1 & v2
>  - Remove unnecessary i2c_client in the structure of tcpci
>  - Rename structure of tcpci_vendor_data to tcpci_data
>  - Not exporting tcpci read/write wrappers but register i2c regmap in glue
> driver
>  - Add set_vconn ops in tcpci_data
>(It is necessary for RT1711H to enable/disable idle mode before
> disabling/enabling vconn)
>  - Export tcpci_irq so that vendor can call it in their own IRQ handler
> 
>  patch changelogs between v2 & v3
>  - Change the return type of tcpci_irq from int to irqreturn_t
> 
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> index 9bd4412..4959c69 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -21,7 +21,6 @@
> 
>  struct tcpci {
>   struct device *dev;
> - struct i2c_client *client;
> 
>   struct tcpm_port *port;
> 
> @@ -30,6 +29,12 @@ struct tcpci {
>   bool controls_vbus;
> 
>   struct tcpc_dev tcpc;
> + struct tcpci_data *data;
> +};
> +
> +struct tcpci_chip {
> + struct tcpci *tcpci;
> + struct tcpci_data data;
>  };
> 
>  static inline struct tcpci *tcpc_to_tcpci(struct tcpc_dev *tcpc) @@ -37,8
> +42,7 @@ static inline struct tcpci *tcpc_to_tcpci(struct tcpc_dev *tcpc)
>   return container_of(tcpc, struct tcpci, tcpc);  }
> 
> -static int tcpci_read16(struct tcpci *tcpci, unsigned int reg,
> - u16 *val)
> +static int tcpci_read16(struct tcpci *tcpci, unsigned int reg, u16
> +*val)
>  {
>   return regmap_raw_read(tcpci->regmap, reg, val, sizeof(u16));  } @@
> -98,8 +102,10 @@ static int tcpci_set_cc(struct tcpc_dev *tcpc, enum
> typec_cc_status cc)  static int tcpci_start_drp_toggling(struct tcpc_dev
> *tcpc,
>   enum typec_cc_status cc)
>  {
> + int ret;
>   struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
> - unsigned int reg = TCPC_ROLE_CTRL_DRP;
> + unsigned int reg = (TCPC_ROLE_CTRL_CC_RD <<
> TCPC_ROLE_CTRL_CC1_SHIFT) |
> +(TCPC_ROLE_CTRL_CC_RD <<
> TCPC_ROLE_CTRL_CC2_SHIFT);
> 
>   switch (cc) {
>   default:
> @@ -117,7 +123,19 @@ static int tcpci_start_drp_toggling(struct tcpc_dev
> *tcpc,
>   break;
>   }
> 
> - return regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
> + ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
> + if (ret < 0)
> + return ret;
> + usleep_range(500, 1000);

Why need a wait here? It seems you actually don't want to do autonomously 
toggling
from the very beginning, instead, you begin with a directly control on CC, keep 
it(Rd)
for some time, then switch to use autonomously toggling, why you need such kind 
of
sequence? I think it's special and not following tcpci spec.
 
> + reg |= TCPC_ROLE_CTRL_DRP;
> + ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
> + if (ret < 0)
> + return ret;
> + ret = regmap_write(tcpci->regmap, TCPC_COMMAND,
> +TCPC_CMD_LOOK4CONNECTION);
> + if (ret < 0)
> + return ret;
> + return 0;
>  }
> 
>  static enum typec_cc_status tcpci_to_typec_cc(unsigned int cc, bool sink)
> @@ -178,6 +196,16 @@ static int tcpci_set_vconn(struct tcpc_dev *tcpc,
> 

RE: [PATCH] staging: typec: handle vendor defined part and modify drp toggling flow

[Jun Li]

Hi,

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org
> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of ShuFanLee
> Sent: 2018年2月21日 23:02
> To: heikki.kroge...@linux.intel.com; li...@roeck-us.net; g...@kroah.com
> Cc: shufan_...@richtek.com; cy_hu...@richtek.com;
> linux-kernel@vger.kernel.org; linux-...@vger.kernel.org
> Subject: [PATCH] staging: typec: handle vendor defined part and modify drp
> toggling flow
> 
> From: ShuFanLee 
> 
> Handle vendor defined behavior in tcpci_init, tcpci_set_vconn and export
> tcpci_irq.
> More operations can be extended in tcpci_data if needed.
> According to TCPCI specification, 4.4.5.2 ROLE_CONTROL, TCPC shall not
> start DRP toggling until subsequently the TCPM writes to the COMMAND
> register to start DRP toggling.

My understanding of above statement is TCPM(this Linux driver) can enable
DRP and CC1/CC2 in one shot, but TCPC(your typec chip internal firmware)
needs wait until TCPM writes to COMMAND register to start drp toggling.

> DRP toggling flow is chagned as following:
>   - Write DRP = 0 & Rd/Rd

Why fixed to be Rd/Rd? in this case, it means the starting value:

Tcpci 4.4.5.2:
"When initiating autonomous DRP toggling, the TCPM shall write B6 (DRP) =1b
and the starting value of Rp/Rd to B3..0 (CC1/CC2) to indicate DRP autonomous
toggling mode to the TCPC."

>   - Write DRP = 1

What's your problem if combine above 2 in one shot?

>   - Set LOOK4CONNECTION command
> 
> Signed-off-by: ShuFanLee 
> ---
>  drivers/staging/typec/tcpci.c | 128
> +-
>  drivers/staging/typec/tcpci.h |  13 +
>  2 files changed, 115 insertions(+), 26 deletions(-)
> 
>  patch changelogs between v1 & v2
>  - Remove unnecessary i2c_client in the structure of tcpci
>  - Rename structure of tcpci_vendor_data to tcpci_data
>  - Not exporting tcpci read/write wrappers but register i2c regmap in glue
> driver
>  - Add set_vconn ops in tcpci_data
>(It is necessary for RT1711H to enable/disable idle mode before
> disabling/enabling vconn)
>  - Export tcpci_irq so that vendor can call it in their own IRQ handler
> 
>  patch changelogs between v2 & v3
>  - Change the return type of tcpci_irq from int to irqreturn_t
> 
> diff --git a/drivers/staging/typec/tcpci.c b/drivers/staging/typec/tcpci.c
> index 9bd4412..4959c69 100644
> --- a/drivers/staging/typec/tcpci.c
> +++ b/drivers/staging/typec/tcpci.c
> @@ -21,7 +21,6 @@
> 
>  struct tcpci {
>   struct device *dev;
> - struct i2c_client *client;
> 
>   struct tcpm_port *port;
> 
> @@ -30,6 +29,12 @@ struct tcpci {
>   bool controls_vbus;
> 
>   struct tcpc_dev tcpc;
> + struct tcpci_data *data;
> +};
> +
> +struct tcpci_chip {
> + struct tcpci *tcpci;
> + struct tcpci_data data;
>  };
> 
>  static inline struct tcpci *tcpc_to_tcpci(struct tcpc_dev *tcpc) @@ -37,8
> +42,7 @@ static inline struct tcpci *tcpc_to_tcpci(struct tcpc_dev *tcpc)
>   return container_of(tcpc, struct tcpci, tcpc);  }
> 
> -static int tcpci_read16(struct tcpci *tcpci, unsigned int reg,
> - u16 *val)
> +static int tcpci_read16(struct tcpci *tcpci, unsigned int reg, u16
> +*val)
>  {
>   return regmap_raw_read(tcpci->regmap, reg, val, sizeof(u16));  } @@
> -98,8 +102,10 @@ static int tcpci_set_cc(struct tcpc_dev *tcpc, enum
> typec_cc_status cc)  static int tcpci_start_drp_toggling(struct tcpc_dev
> *tcpc,
>   enum typec_cc_status cc)
>  {
> + int ret;
>   struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
> - unsigned int reg = TCPC_ROLE_CTRL_DRP;
> + unsigned int reg = (TCPC_ROLE_CTRL_CC_RD <<
> TCPC_ROLE_CTRL_CC1_SHIFT) |
> +(TCPC_ROLE_CTRL_CC_RD <<
> TCPC_ROLE_CTRL_CC2_SHIFT);
> 
>   switch (cc) {
>   default:
> @@ -117,7 +123,19 @@ static int tcpci_start_drp_toggling(struct tcpc_dev
> *tcpc,
>   break;
>   }
> 
> - return regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
> + ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
> + if (ret < 0)
> + return ret;
> + usleep_range(500, 1000);

Why need a wait here? It seems you actually don't want to do autonomously 
toggling
from the very beginning, instead, you begin with a directly control on CC, keep 
it(Rd)
for some time, then switch to use autonomously toggling, why you need such kind 
of
sequence? I think it's special and not following tcpci spec.
 
> + reg |= TCPC_ROLE_CTRL_DRP;
> + ret = regmap_write(tcpci->regmap, TCPC_ROLE_CTRL, reg);
> + if (ret < 0)
> + return ret;
> + ret = regmap_write(tcpci->regmap, TCPC_COMMAND,
> +TCPC_CMD_LOOK4CONNECTION);
> + if (ret < 0)
> + return ret;
> + return 0;
>  }
> 
>  static enum typec_cc_status tcpci_to_typec_cc(unsigned int cc, bool sink)
> @@ -178,6 +196,16 @@ static int tcpci_set_vconn(struct tcpc_dev *tcpc,
> bool enable)
>   struct tcpci *tcpci = 

RE: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver

[Jun Li]

Hi
> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of ShuFanLee
> Sent: Wednesday, January 10, 2018 2:59 PM
> To: heikki.kroge...@linux.intel.com
> Cc: cy_hu...@richtek.com; shufan_...@richtek.com; linux-
> ker...@vger.kernel.org; linux-...@vger.kernel.org
> Subject: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver
> 
> From: ShuFanLee 
> 
> Richtek RT1711H Type-C chip driver that works with
> Type-C Port Controller Manager to provide USB PD and
> USB Type-C functionalities.

A general question, is this Rt1711h type-c chip compatible with TCPCI
(Universal Serial Bus Type-C Port Controller Interface Specification)?
looks like it has the same register map and has some extension, can
the existing ./drivers/staging/typec/tcpic.c basically work for you?

+Guenter

Li Jun 

> 
> Signed-off-by: ShuFanLee 
> ---
>  .../devicetree/bindings/usb/richtek,rt1711h.txt|   38 +
>  arch/arm64/boot/dts/hisilicon/rt1711h.dtsi |   11 +
>  drivers/usb/typec/Kconfig  |2 +
>  drivers/usb/typec/Makefile |1 +
>  drivers/usb/typec/rt1711h/Kconfig  |7 +
>  drivers/usb/typec/rt1711h/Makefile |2 +
>  drivers/usb/typec/rt1711h/rt1711h.c| 2241 
> 
>  drivers/usb/typec/rt1711h/rt1711h.h|  300 +++
>  8 files changed, 2602 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/usb/richtek,rt1711h.txt
>  create mode 100644 arch/arm64/boot/dts/hisilicon/rt1711h.dtsi
>  create mode 100644 drivers/usb/typec/rt1711h/Kconfig
>  create mode 100644 drivers/usb/typec/rt1711h/Makefile
>  create mode 100644 drivers/usb/typec/rt1711h/rt1711h.c
>  create mode 100644 drivers/usb/typec/rt1711h/rt1711h.h
> 

RE: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver

[Jun Li]

Hi
> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of ShuFanLee
> Sent: Wednesday, January 10, 2018 2:59 PM
> To: heikki.kroge...@linux.intel.com
> Cc: cy_hu...@richtek.com; shufan_...@richtek.com; linux-
> ker...@vger.kernel.org; linux-...@vger.kernel.org
> Subject: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver
> 
> From: ShuFanLee 
> 
> Richtek RT1711H Type-C chip driver that works with
> Type-C Port Controller Manager to provide USB PD and
> USB Type-C functionalities.

A general question, is this Rt1711h type-c chip compatible with TCPCI
(Universal Serial Bus Type-C Port Controller Interface Specification)?
looks like it has the same register map and has some extension, can
the existing ./drivers/staging/typec/tcpic.c basically work for you?

+Guenter

Li Jun 

> 
> Signed-off-by: ShuFanLee 
> ---
>  .../devicetree/bindings/usb/richtek,rt1711h.txt|   38 +
>  arch/arm64/boot/dts/hisilicon/rt1711h.dtsi |   11 +
>  drivers/usb/typec/Kconfig  |2 +
>  drivers/usb/typec/Makefile |1 +
>  drivers/usb/typec/rt1711h/Kconfig  |7 +
>  drivers/usb/typec/rt1711h/Makefile |2 +
>  drivers/usb/typec/rt1711h/rt1711h.c| 2241 
> 
>  drivers/usb/typec/rt1711h/rt1711h.h|  300 +++
>  8 files changed, 2602 insertions(+)
>  create mode 100644
> Documentation/devicetree/bindings/usb/richtek,rt1711h.txt
>  create mode 100644 arch/arm64/boot/dts/hisilicon/rt1711h.dtsi
>  create mode 100644 drivers/usb/typec/rt1711h/Kconfig
>  create mode 100644 drivers/usb/typec/rt1711h/Makefile
>  create mode 100644 drivers/usb/typec/rt1711h/rt1711h.c
>  create mode 100644 drivers/usb/typec/rt1711h/rt1711h.h
> 

RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Jun Li]

Hi,

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Monday, March 13, 2017 4:44 PM
> To: Jun Li <jun...@nxp.com>
> Cc: NeilBrown <ne...@suse.com>; Felipe Balbi <ba...@kernel.org>; Greg KH
> <gre...@linuxfoundation.org>; Sebastian Reichel <s...@kernel.org>; Dmitry
> Eremin-Solenikov <dbarysh...@gmail.com>; David Woodhouse
> <dw...@infradead.org>; r...@kernel.org; Marek Szyprowski
> <m.szyprow...@samsung.com>; Ruslan Bilovol <ruslan.bilo...@gmail.com>;
> Peter Chen <peter.c...@freescale.com>; Alan Stern
> <st...@rowland.harvard.edu>; grygorii.stras...@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda...@renesas.com>; Lee Jones <lee.jo...@linaro.org>;
> Mark Brown <broo...@kernel.org>; John Stultz <john.stu...@linaro.org>;
> Charles Keepax <ckee...@opensource.wolfsonmicro.com>;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB <linux-...@vger.kernel.org>; device-
> mainlin...@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
... ...
> >> That is same what USB charger did, from this point, we need USB
> >> charger to send out vbus draw information according to speed and usb
> >> state. But I should listen to other guys suggestion. Peter and Felipe, what
> do you think?

Instead of waiting for maintainer's comments on this long discussion, I'd 
suggest
you directly post the patches for the required change, so they can easily know
what's the conclusion/solution looks like.

Li Jun

> >
> > So now the only to do work is to find a common place to send the
> > notification out (based on gadget speed and sate).
> 
> Yes.
> 
> --
> Baolin.wang
> Best Regards

RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Jun Li]

Hi,

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Monday, March 13, 2017 4:44 PM
> To: Jun Li 
> Cc: NeilBrown ; Felipe Balbi ; Greg KH
> ; Sebastian Reichel ; Dmitry
> Eremin-Solenikov ; David Woodhouse
> ; r...@kernel.org; Marek Szyprowski
> ; Ruslan Bilovol ;
> Peter Chen ; Alan Stern
> ; grygorii.stras...@ti.com; Yoshihiro Shimoda
> ; Lee Jones ;
> Mark Brown ; John Stultz ;
> Charles Keepax ;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB ; device-
> mainlin...@lists.linuxfoundation.org; LKML 
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
... ...
> >> That is same what USB charger did, from this point, we need USB
> >> charger to send out vbus draw information according to speed and usb
> >> state. But I should listen to other guys suggestion. Peter and Felipe, what
> do you think?

Instead of waiting for maintainer's comments on this long discussion, I'd 
suggest
you directly post the patches for the required change, so they can easily know
what's the conclusion/solution looks like.

Li Jun

> >
> > So now the only to do work is to find a common place to send the
> > notification out (based on gadget speed and sate).
> 
> Yes.
> 
> --
> Baolin.wang
> Best Regards

RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Jun Li]

Hi,

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Friday, March 10, 2017 6:52 PM
> To: Jun Li <jun...@nxp.com>
> Cc: NeilBrown <ne...@suse.com>; Felipe Balbi <ba...@kernel.org>; Greg KH
> <gre...@linuxfoundation.org>; Sebastian Reichel <s...@kernel.org>; Dmitry
> Eremin-Solenikov <dbarysh...@gmail.com>; David Woodhouse
> <dw...@infradead.org>; r...@kernel.org; Marek Szyprowski
> <m.szyprow...@samsung.com>; Ruslan Bilovol <ruslan.bilo...@gmail.com>;
> Peter Chen <peter.c...@freescale.com>; Alan Stern
> <st...@rowland.harvard.edu>; grygorii.stras...@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda...@renesas.com>; Lee Jones <lee.jo...@linaro.org>;
> Mark Brown <broo...@kernel.org>; John Stultz <john.stu...@linaro.org>;
> Charles Keepax <ckee...@opensource.wolfsonmicro.com>;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB <linux-...@vger.kernel.org>; device-
> mainlin...@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> On 10 March 2017 at 16:27, Jun Li <jun...@nxp.com> wrote:
> > Hi
> >
> >> -Original Message-
> >> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> >> Sent: Friday, March 10, 2017 3:15 PM
> >> To: Jun Li <jun...@nxp.com>
> >> Cc: NeilBrown <ne...@suse.com>; Felipe Balbi <ba...@kernel.org>; Greg
> >> KH <gre...@linuxfoundation.org>; Sebastian Reichel <s...@kernel.org>;
> >> Dmitry Eremin-Solenikov <dbarysh...@gmail.com>; David Woodhouse
> >> <dw...@infradead.org>; r...@kernel.org; Marek Szyprowski
> >> <m.szyprow...@samsung.com>; Ruslan Bilovol
> >> <ruslan.bilo...@gmail.com>; Peter Chen <peter.c...@freescale.com>;
> >> Alan Stern <st...@rowland.harvard.edu>; grygorii.stras...@ti.com;
> >> Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>; Lee Jones
> >> <lee.jo...@linaro.org>; Mark Brown <broo...@kernel.org>; John Stultz
> >> <john.stu...@linaro.org>; Charles Keepax
> >> <ckee...@opensource.wolfsonmicro.com>;
> >> patc...@opensource.wolfsonmicro.com; Linux PM list  >> p...@vger.kernel.org>; USB <linux-...@vger.kernel.org>; device-
> >> mainlin...@lists.linuxfoundation.org; LKML
> >> <linux-kernel@vger.kernel.org>
> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal
> >> with the usb gadget power negotation
> >>
> >> On 10 March 2017 at 14:30, Jun Li <jun...@nxp.com> wrote:
> >> >> >> >
> >> >> >> > Will generic phy need add extcon as well?
> >> >> >>
> >> >> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which
> >> >> >> will be common code.
> >> >> >>
> >> >> >
> >> >> > I mean the common code need add 'struct extcon_dev' into both
> >> >> > 'struct phy' and 'struct usb_phy', right? as some/new usb phy
> >> >> > use that generic phy
> >> >> driver.
> >> >>
> >> >> Ah, you remind me. Seems we need also add one 'struct extcon_dev'
> >> >> into 'struct phy'.
> >> >>
> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >> Secondly, I also agreed with Peter's comments: Not only
> >> >> >> >> >> USB PHY to register an extcon, but also for the drivers
> >> >> >> >> >> which can detect USB charger type, it may be USB
> >> >> >> >> >> controller driver, USB type-c driver, pmic driver, and
> >> >> >> >> >> these drivers may not have an extcon device since the
> >> >> >> >> >> internal part can finish
> >> the vbus detect.
> >> >> >> >> >
> >> >> >> >> > Whichever part can detect vbus, the driver for that part
> >> >> >> >> > must be able to find the extcon and trigger a notification.
> >> >> >> >> > Maybe one part can detect VBUS, another can measure the
> >> >> >> >> > resistance on ID and a third can work through the state
> >> >> >> >> > 

RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Jun Li]

Hi,

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Friday, March 10, 2017 6:52 PM
> To: Jun Li 
> Cc: NeilBrown ; Felipe Balbi ; Greg KH
> ; Sebastian Reichel ; Dmitry
> Eremin-Solenikov ; David Woodhouse
> ; r...@kernel.org; Marek Szyprowski
> ; Ruslan Bilovol ;
> Peter Chen ; Alan Stern
> ; grygorii.stras...@ti.com; Yoshihiro Shimoda
> ; Lee Jones ;
> Mark Brown ; John Stultz ;
> Charles Keepax ;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB ; device-
> mainlin...@lists.linuxfoundation.org; LKML 
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> On 10 March 2017 at 16:27, Jun Li  wrote:
> > Hi
> >
> >> -Original Message-
> >> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> >> Sent: Friday, March 10, 2017 3:15 PM
> >> To: Jun Li 
> >> Cc: NeilBrown ; Felipe Balbi ; Greg
> >> KH ; Sebastian Reichel ;
> >> Dmitry Eremin-Solenikov ; David Woodhouse
> >> ; r...@kernel.org; Marek Szyprowski
> >> ; Ruslan Bilovol
> >> ; Peter Chen ;
> >> Alan Stern ; grygorii.stras...@ti.com;
> >> Yoshihiro Shimoda ; Lee Jones
> >> ; Mark Brown ; John Stultz
> >> ; Charles Keepax
> >> ;
> >> patc...@opensource.wolfsonmicro.com; Linux PM list  >> p...@vger.kernel.org>; USB ; device-
> >> mainlin...@lists.linuxfoundation.org; LKML
> >> 
> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal
> >> with the usb gadget power negotation
> >>
> >> On 10 March 2017 at 14:30, Jun Li  wrote:
> >> >> >> >
> >> >> >> > Will generic phy need add extcon as well?
> >> >> >>
> >> >> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which
> >> >> >> will be common code.
> >> >> >>
> >> >> >
> >> >> > I mean the common code need add 'struct extcon_dev' into both
> >> >> > 'struct phy' and 'struct usb_phy', right? as some/new usb phy
> >> >> > use that generic phy
> >> >> driver.
> >> >>
> >> >> Ah, you remind me. Seems we need also add one 'struct extcon_dev'
> >> >> into 'struct phy'.
> >> >>
> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >> Secondly, I also agreed with Peter's comments: Not only
> >> >> >> >> >> USB PHY to register an extcon, but also for the drivers
> >> >> >> >> >> which can detect USB charger type, it may be USB
> >> >> >> >> >> controller driver, USB type-c driver, pmic driver, and
> >> >> >> >> >> these drivers may not have an extcon device since the
> >> >> >> >> >> internal part can finish
> >> the vbus detect.
> >> >> >> >> >
> >> >> >> >> > Whichever part can detect vbus, the driver for that part
> >> >> >> >> > must be able to find the extcon and trigger a notification.
> >> >> >> >> > Maybe one part can detect VBUS, another can measure the
> >> >> >> >> > resistance on ID and a third can work through the state
> >> >> >> >> > machine to determine if D+ and D- are shorted together.
> >> >> >> >> > Somehow these three need to work together to determine
> >> >> >> >> > what is
> >> >> >> >> plugged
> >> >> >> >> > in to the external connection port.  Somewhere there much
> >> >> >> >> > an
> >> >> 'extcon'
> >> >> >> >> > device which represents that port and which the three
> >> >> >> >> > devices can find and can interact with.
> >> >> >> >> > I think it makes sense for the usb_phy to be the connection
> point.
> >> >> >> >> > Each of the devices can get to the phy, and the phy can
> >> >> >> >> > get to the
> >> >> >> extcon.
> >> >> >> >> > It doesn't matter very much if the usb phy driver creates
> >> >> >> >> > the extcon, or if something else creates the extcon a

RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Jun Li]

Hi

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Friday, March 10, 2017 3:15 PM
> To: Jun Li <jun...@nxp.com>
> Cc: NeilBrown <ne...@suse.com>; Felipe Balbi <ba...@kernel.org>; Greg KH
> <gre...@linuxfoundation.org>; Sebastian Reichel <s...@kernel.org>; Dmitry
> Eremin-Solenikov <dbarysh...@gmail.com>; David Woodhouse
> <dw...@infradead.org>; r...@kernel.org; Marek Szyprowski
> <m.szyprow...@samsung.com>; Ruslan Bilovol <ruslan.bilo...@gmail.com>;
> Peter Chen <peter.c...@freescale.com>; Alan Stern
> <st...@rowland.harvard.edu>; grygorii.stras...@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda...@renesas.com>; Lee Jones <lee.jo...@linaro.org>;
> Mark Brown <broo...@kernel.org>; John Stultz <john.stu...@linaro.org>;
> Charles Keepax <ckee...@opensource.wolfsonmicro.com>;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB <linux-...@vger.kernel.org>; device-
> mainlin...@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> On 10 March 2017 at 14:30, Jun Li <jun...@nxp.com> wrote:
> >> >> >
> >> >> > Will generic phy need add extcon as well?
> >> >>
> >> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which
> >> >> will be common code.
> >> >>
> >> >
> >> > I mean the common code need add 'struct extcon_dev' into both
> >> > 'struct phy' and 'struct usb_phy', right? as some/new usb phy use
> >> > that generic phy
> >> driver.
> >>
> >> Ah, you remind me. Seems we need also add one 'struct extcon_dev'
> >> into 'struct phy'.
> >>
> >> >> >
> >> >> >> >
> >> >> >> >> Secondly, I also agreed with Peter's comments: Not only USB
> >> >> >> >> PHY to register an extcon, but also for the drivers which
> >> >> >> >> can detect USB charger type, it may be USB controller
> >> >> >> >> driver, USB type-c driver, pmic driver, and these drivers
> >> >> >> >> may not have an extcon device since the internal part can finish
> the vbus detect.
> >> >> >> >
> >> >> >> > Whichever part can detect vbus, the driver for that part must
> >> >> >> > be able to find the extcon and trigger a notification.
> >> >> >> > Maybe one part can detect VBUS, another can measure the
> >> >> >> > resistance on ID and a third can work through the state
> >> >> >> > machine to determine if D+ and D- are shorted together.
> >> >> >> > Somehow these three need to work together to determine what
> >> >> >> > is
> >> >> >> plugged
> >> >> >> > in to the external connection port.  Somewhere there much an
> >> 'extcon'
> >> >> >> > device which represents that port and which the three devices
> >> >> >> > can find and can interact with.
> >> >> >> > I think it makes sense for the usb_phy to be the connection point.
> >> >> >> > Each of the devices can get to the phy, and the phy can get
> >> >> >> > to the
> >> >> extcon.
> >> >> >> > It doesn't matter very much if the usb phy driver creates the
> >> >> >> > extcon, or if something else creates the extcon and the phy
> >> >> >> > driver performs a lookup to find it (e.g. based on devicetree 
> >> >> >> > info).
> >> >> >> >
> >> >> >> > The point is that there is obviously an external physical
> >> >> >> > connection, and so there should be an 'extcon' device that
> >> represents it.
> >> >> >>
> >> >> >> Peter & Jun, is it OK for you every phy has one extcon device
> >> >> >> to receive VBUS notification, especially for detecting the
> >> >> >> charger type by
> >> >> software?
> >> >> >>
> >> >> >
> >> >> > My understanding is phy/usb_phy as the connection point, will
> >> >> > send the notification to PMIC driver which actuall

RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Jun Li]

Hi

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Friday, March 10, 2017 3:15 PM
> To: Jun Li 
> Cc: NeilBrown ; Felipe Balbi ; Greg KH
> ; Sebastian Reichel ; Dmitry
> Eremin-Solenikov ; David Woodhouse
> ; r...@kernel.org; Marek Szyprowski
> ; Ruslan Bilovol ;
> Peter Chen ; Alan Stern
> ; grygorii.stras...@ti.com; Yoshihiro Shimoda
> ; Lee Jones ;
> Mark Brown ; John Stultz ;
> Charles Keepax ;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB ; device-
> mainlin...@lists.linuxfoundation.org; LKML 
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> On 10 March 2017 at 14:30, Jun Li  wrote:
> >> >> >
> >> >> > Will generic phy need add extcon as well?
> >> >>
> >> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which
> >> >> will be common code.
> >> >>
> >> >
> >> > I mean the common code need add 'struct extcon_dev' into both
> >> > 'struct phy' and 'struct usb_phy', right? as some/new usb phy use
> >> > that generic phy
> >> driver.
> >>
> >> Ah, you remind me. Seems we need also add one 'struct extcon_dev'
> >> into 'struct phy'.
> >>
> >> >> >
> >> >> >> >
> >> >> >> >> Secondly, I also agreed with Peter's comments: Not only USB
> >> >> >> >> PHY to register an extcon, but also for the drivers which
> >> >> >> >> can detect USB charger type, it may be USB controller
> >> >> >> >> driver, USB type-c driver, pmic driver, and these drivers
> >> >> >> >> may not have an extcon device since the internal part can finish
> the vbus detect.
> >> >> >> >
> >> >> >> > Whichever part can detect vbus, the driver for that part must
> >> >> >> > be able to find the extcon and trigger a notification.
> >> >> >> > Maybe one part can detect VBUS, another can measure the
> >> >> >> > resistance on ID and a third can work through the state
> >> >> >> > machine to determine if D+ and D- are shorted together.
> >> >> >> > Somehow these three need to work together to determine what
> >> >> >> > is
> >> >> >> plugged
> >> >> >> > in to the external connection port.  Somewhere there much an
> >> 'extcon'
> >> >> >> > device which represents that port and which the three devices
> >> >> >> > can find and can interact with.
> >> >> >> > I think it makes sense for the usb_phy to be the connection point.
> >> >> >> > Each of the devices can get to the phy, and the phy can get
> >> >> >> > to the
> >> >> extcon.
> >> >> >> > It doesn't matter very much if the usb phy driver creates the
> >> >> >> > extcon, or if something else creates the extcon and the phy
> >> >> >> > driver performs a lookup to find it (e.g. based on devicetree 
> >> >> >> > info).
> >> >> >> >
> >> >> >> > The point is that there is obviously an external physical
> >> >> >> > connection, and so there should be an 'extcon' device that
> >> represents it.
> >> >> >>
> >> >> >> Peter & Jun, is it OK for you every phy has one extcon device
> >> >> >> to receive VBUS notification, especially for detecting the
> >> >> >> charger type by
> >> >> software?
> >> >> >>
> >> >> >
> >> >> > My understanding is phy/usb_phy as the connection point, will
> >> >> > send the notification to PMIC driver which actually control the
> >> >> > charge current, also this will be done in your common framework,
> right?
> >> >>
> >> >> Not in USB charger framework. If we are all agree every usb_phy
> >> >> can register one extcon device, can get correct charger type and
> >> >> send out correct vbus_draw information, then we don't need USB
> >> >> charger framework as Neil suggested. So this will be okay for your
> >> >> case (especially for detecting the charger type by softw

RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Jun Li]

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Thursday, March 09, 2017 7:23 PM
> To: Jun Li <jun...@nxp.com>
> Cc: NeilBrown <ne...@suse.com>; Felipe Balbi <ba...@kernel.org>; Greg KH
> <gre...@linuxfoundation.org>; Sebastian Reichel <s...@kernel.org>; Dmitry
> Eremin-Solenikov <dbarysh...@gmail.com>; David Woodhouse
> <dw...@infradead.org>; r...@kernel.org; Marek Szyprowski
> <m.szyprow...@samsung.com>; Ruslan Bilovol <ruslan.bilo...@gmail.com>;
> Peter Chen <peter.c...@freescale.com>; Alan Stern
> <st...@rowland.harvard.edu>; grygorii.stras...@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda...@renesas.com>; Lee Jones <lee.jo...@linaro.org>;
> Mark Brown <broo...@kernel.org>; John Stultz <john.stu...@linaro.org>;
> Charles Keepax <ckee...@opensource.wolfsonmicro.com>;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB <linux-...@vger.kernel.org>; device-
> mainlin...@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> On 9 March 2017 at 18:34, Jun Li <jun...@nxp.com> wrote:
> >
> >
> >> -Original Message-
> >> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> >> Sent: Thursday, March 09, 2017 2:11 PM
> >> To: Jun Li <jun...@nxp.com>
> >> Cc: NeilBrown <ne...@suse.com>; Felipe Balbi <ba...@kernel.org>; Greg
> >> KH <gre...@linuxfoundation.org>; Sebastian Reichel <s...@kernel.org>;
> >> Dmitry Eremin-Solenikov <dbarysh...@gmail.com>; David Woodhouse
> >> <dw...@infradead.org>; r...@kernel.org; Marek Szyprowski
> >> <m.szyprow...@samsung.com>; Ruslan Bilovol
> >> <ruslan.bilo...@gmail.com>; Peter Chen <peter.c...@freescale.com>;
> >> Alan Stern <st...@rowland.harvard.edu>; grygorii.stras...@ti.com;
> >> Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>; Lee Jones
> >> <lee.jo...@linaro.org>; Mark Brown <broo...@kernel.org>; John Stultz
> >> <john.stu...@linaro.org>; Charles Keepax
> >> <ckee...@opensource.wolfsonmicro.com>;
> >> patc...@opensource.wolfsonmicro.com; Linux PM list  >> p...@vger.kernel.org>; USB <linux-...@vger.kernel.org>; device-
> >> mainlin...@lists.linuxfoundation.org; LKML
> >> <linux-kernel@vger.kernel.org>
> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal
> >> with the usb gadget power negotation
> >>
> >> Hi,
> >>
> >> On 9 March 2017 at 09:50, Jun Li <jun...@nxp.com> wrote:
> >> > Hi,
> >> >
> >> >> -Original Message-
> >> >> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> >> >> Sent: Tuesday, March 07, 2017 5:39 PM
> >> >> To: NeilBrown <ne...@suse.com>
> >> >> Cc: Felipe Balbi <ba...@kernel.org>; Greg KH
> >> >> <gre...@linuxfoundation.org>; Sebastian Reichel <s...@kernel.org>;
> >> >> Dmitry Eremin-Solenikov <dbarysh...@gmail.com>; David
> Woodhouse
> >> >> <dw...@infradead.org>; r...@kernel.org; Jun Li <jun...@nxp.com>;
> >> >> Marek Szyprowski <m.szyprow...@samsung.com>; Ruslan Bilovol
> >> >> <ruslan.bilo...@gmail.com>; Peter Chen
> <peter.c...@freescale.com>;
> >> >> Alan Stern <st...@rowland.harvard.edu>; grygorii.stras...@ti.com;
> >> >> Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>; Lee Jones
> >> >> <lee.jo...@linaro.org>; Mark Brown <broo...@kernel.org>; John
> >> >> Stultz <john.stu...@linaro.org>; Charles Keepax
> >> >> <ckee...@opensource.wolfsonmicro.com>;
> >> >> patc...@opensource.wolfsonmicro.com; Linux PM list  >> >> p...@vger.kernel.org>; USB <linux-...@vger.kernel.org>; device-
> >> >> mainlin...@lists.linuxfoundation.org; LKML
> >> >> <linux-kernel@vger.kernel.org>
> >> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to
> >> >> deal with the usb gadget power negotation
> >> >>
> >> >> On 3 March 2017 at 10:23, NeilBrown <ne...@suse.com> wrote:
> >> >> > On Mon, Feb 20 2017, Baolin Wang wrote:
> >> >> >
> >> >> >> Currently the Linux kerne

RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Jun Li]

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Thursday, March 09, 2017 7:23 PM
> To: Jun Li 
> Cc: NeilBrown ; Felipe Balbi ; Greg KH
> ; Sebastian Reichel ; Dmitry
> Eremin-Solenikov ; David Woodhouse
> ; r...@kernel.org; Marek Szyprowski
> ; Ruslan Bilovol ;
> Peter Chen ; Alan Stern
> ; grygorii.stras...@ti.com; Yoshihiro Shimoda
> ; Lee Jones ;
> Mark Brown ; John Stultz ;
> Charles Keepax ;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB ; device-
> mainlin...@lists.linuxfoundation.org; LKML 
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> On 9 March 2017 at 18:34, Jun Li  wrote:
> >
> >
> >> -Original Message-
> >> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> >> Sent: Thursday, March 09, 2017 2:11 PM
> >> To: Jun Li 
> >> Cc: NeilBrown ; Felipe Balbi ; Greg
> >> KH ; Sebastian Reichel ;
> >> Dmitry Eremin-Solenikov ; David Woodhouse
> >> ; r...@kernel.org; Marek Szyprowski
> >> ; Ruslan Bilovol
> >> ; Peter Chen ;
> >> Alan Stern ; grygorii.stras...@ti.com;
> >> Yoshihiro Shimoda ; Lee Jones
> >> ; Mark Brown ; John Stultz
> >> ; Charles Keepax
> >> ;
> >> patc...@opensource.wolfsonmicro.com; Linux PM list  >> p...@vger.kernel.org>; USB ; device-
> >> mainlin...@lists.linuxfoundation.org; LKML
> >> 
> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal
> >> with the usb gadget power negotation
> >>
> >> Hi,
> >>
> >> On 9 March 2017 at 09:50, Jun Li  wrote:
> >> > Hi,
> >> >
> >> >> -Original Message-
> >> >> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> >> >> Sent: Tuesday, March 07, 2017 5:39 PM
> >> >> To: NeilBrown 
> >> >> Cc: Felipe Balbi ; Greg KH
> >> >> ; Sebastian Reichel ;
> >> >> Dmitry Eremin-Solenikov ; David
> Woodhouse
> >> >> ; r...@kernel.org; Jun Li ;
> >> >> Marek Szyprowski ; Ruslan Bilovol
> >> >> ; Peter Chen
> ;
> >> >> Alan Stern ; grygorii.stras...@ti.com;
> >> >> Yoshihiro Shimoda ; Lee Jones
> >> >> ; Mark Brown ; John
> >> >> Stultz ; Charles Keepax
> >> >> ;
> >> >> patc...@opensource.wolfsonmicro.com; Linux PM list  >> >> p...@vger.kernel.org>; USB ; device-
> >> >> mainlin...@lists.linuxfoundation.org; LKML
> >> >> 
> >> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to
> >> >> deal with the usb gadget power negotation
> >> >>
> >> >> On 3 March 2017 at 10:23, NeilBrown  wrote:
> >> >> > On Mon, Feb 20 2017, Baolin Wang wrote:
> >> >> >
> >> >> >> Currently the Linux kernel does not provide any standard
> >> >> >> integration of this feature that integrates the USB subsystem
> >> >> >> with the system power regulation provided by PMICs meaning that
> >> >> >> either vendors must add this in their kernels or USB gadget
> >> >> >> devices based on Linux (such as mobile phones) may not behave as
> they should.
> >> >> >> Thus provide a
> >> >> standard framework for doing this in kernel.
> >> >> >>
> >> >> >> Now introduce one user with wm831x_power to support and test
> >> >> >> the usb
> >> >> charger.
> >> >> >> Another user introduced to support charger detection by Jun Li:
> >> >> >> https://www.spinics.net/lists/linux-usb/msg139425.html
> >> >> >> Moreover there may be other potential users will use it in future.
> >> >> >>
> >> >> >> 1. Before v19 patchset we've fixed below issues in extcon
> >> >> >> subsystem and usb phy driver, now all were merged. (Thanks for
> >> >> >> Neil's
> >> >> >> suggestion)
> >> >> >> (1) Have fixed the inconsistencies with USB connector types in
> >> >> >> extcon subsystem by following links:
> >> >> >> https://lkml.org/lkml/2016/12/21/13
> >> >> >> https://lkml.org/lkml/2016/12/21/15
> >> >> >> https://lkml.org/lkml/2016/12/21/79
> >

RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Jun Li]

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Thursday, March 09, 2017 2:11 PM
> To: Jun Li <jun...@nxp.com>
> Cc: NeilBrown <ne...@suse.com>; Felipe Balbi <ba...@kernel.org>; Greg KH
> <gre...@linuxfoundation.org>; Sebastian Reichel <s...@kernel.org>; Dmitry
> Eremin-Solenikov <dbarysh...@gmail.com>; David Woodhouse
> <dw...@infradead.org>; r...@kernel.org; Marek Szyprowski
> <m.szyprow...@samsung.com>; Ruslan Bilovol <ruslan.bilo...@gmail.com>;
> Peter Chen <peter.c...@freescale.com>; Alan Stern
> <st...@rowland.harvard.edu>; grygorii.stras...@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda...@renesas.com>; Lee Jones <lee.jo...@linaro.org>;
> Mark Brown <broo...@kernel.org>; John Stultz <john.stu...@linaro.org>;
> Charles Keepax <ckee...@opensource.wolfsonmicro.com>;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB <linux-...@vger.kernel.org>; device-
> mainlin...@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> Hi,
> 
> On 9 March 2017 at 09:50, Jun Li <jun...@nxp.com> wrote:
> > Hi,
> >
> >> -Original Message-
> >> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> >> Sent: Tuesday, March 07, 2017 5:39 PM
> >> To: NeilBrown <ne...@suse.com>
> >> Cc: Felipe Balbi <ba...@kernel.org>; Greg KH
> >> <gre...@linuxfoundation.org>; Sebastian Reichel <s...@kernel.org>;
> >> Dmitry Eremin-Solenikov <dbarysh...@gmail.com>; David Woodhouse
> >> <dw...@infradead.org>; r...@kernel.org; Jun Li <jun...@nxp.com>;
> >> Marek Szyprowski <m.szyprow...@samsung.com>; Ruslan Bilovol
> >> <ruslan.bilo...@gmail.com>; Peter Chen <peter.c...@freescale.com>;
> >> Alan Stern <st...@rowland.harvard.edu>; grygorii.stras...@ti.com;
> >> Yoshihiro Shimoda <yoshihiro.shimoda...@renesas.com>; Lee Jones
> >> <lee.jo...@linaro.org>; Mark Brown <broo...@kernel.org>; John Stultz
> >> <john.stu...@linaro.org>; Charles Keepax
> >> <ckee...@opensource.wolfsonmicro.com>;
> >> patc...@opensource.wolfsonmicro.com; Linux PM list  >> p...@vger.kernel.org>; USB <linux-...@vger.kernel.org>; device-
> >> mainlin...@lists.linuxfoundation.org; LKML
> >> <linux-kernel@vger.kernel.org>
> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal
> >> with the usb gadget power negotation
> >>
> >> On 3 March 2017 at 10:23, NeilBrown <ne...@suse.com> wrote:
> >> > On Mon, Feb 20 2017, Baolin Wang wrote:
> >> >
> >> >> Currently the Linux kernel does not provide any standard
> >> >> integration of this feature that integrates the USB subsystem with
> >> >> the system power regulation provided by PMICs meaning that either
> >> >> vendors must add this in their kernels or USB gadget devices based
> >> >> on Linux (such as mobile phones) may not behave as they should.
> >> >> Thus provide a
> >> standard framework for doing this in kernel.
> >> >>
> >> >> Now introduce one user with wm831x_power to support and test the
> >> >> usb
> >> charger.
> >> >> Another user introduced to support charger detection by Jun Li:
> >> >> https://www.spinics.net/lists/linux-usb/msg139425.html
> >> >> Moreover there may be other potential users will use it in future.
> >> >>
> >> >> 1. Before v19 patchset we've fixed below issues in extcon
> >> >> subsystem and usb phy driver, now all were merged. (Thanks for
> >> >> Neil's
> >> >> suggestion)
> >> >> (1) Have fixed the inconsistencies with USB connector types in
> >> >> extcon subsystem by following links:
> >> >> https://lkml.org/lkml/2016/12/21/13
> >> >> https://lkml.org/lkml/2016/12/21/15
> >> >> https://lkml.org/lkml/2016/12/21/79
> >> >> https://lkml.org/lkml/2017/1/3/13
> >> >>
> >> >> (2) Instead of using 'set_power' callback in phy drivers, we will
> >> >> introduce USB charger to set PMIC current drawn from USB
> >> >> configuration, moreover some 'set_power' callbacks did not
> >> >> implement anything to set PMIC current, thus rem

RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Jun Li]

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Thursday, March 09, 2017 2:11 PM
> To: Jun Li 
> Cc: NeilBrown ; Felipe Balbi ; Greg KH
> ; Sebastian Reichel ; Dmitry
> Eremin-Solenikov ; David Woodhouse
> ; r...@kernel.org; Marek Szyprowski
> ; Ruslan Bilovol ;
> Peter Chen ; Alan Stern
> ; grygorii.stras...@ti.com; Yoshihiro Shimoda
> ; Lee Jones ;
> Mark Brown ; John Stultz ;
> Charles Keepax ;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB ; device-
> mainlin...@lists.linuxfoundation.org; LKML 
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> Hi,
> 
> On 9 March 2017 at 09:50, Jun Li  wrote:
> > Hi,
> >
> >> -Original Message-
> >> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> >> Sent: Tuesday, March 07, 2017 5:39 PM
> >> To: NeilBrown 
> >> Cc: Felipe Balbi ; Greg KH
> >> ; Sebastian Reichel ;
> >> Dmitry Eremin-Solenikov ; David Woodhouse
> >> ; r...@kernel.org; Jun Li ;
> >> Marek Szyprowski ; Ruslan Bilovol
> >> ; Peter Chen ;
> >> Alan Stern ; grygorii.stras...@ti.com;
> >> Yoshihiro Shimoda ; Lee Jones
> >> ; Mark Brown ; John Stultz
> >> ; Charles Keepax
> >> ;
> >> patc...@opensource.wolfsonmicro.com; Linux PM list  >> p...@vger.kernel.org>; USB ; device-
> >> mainlin...@lists.linuxfoundation.org; LKML
> >> 
> >> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal
> >> with the usb gadget power negotation
> >>
> >> On 3 March 2017 at 10:23, NeilBrown  wrote:
> >> > On Mon, Feb 20 2017, Baolin Wang wrote:
> >> >
> >> >> Currently the Linux kernel does not provide any standard
> >> >> integration of this feature that integrates the USB subsystem with
> >> >> the system power regulation provided by PMICs meaning that either
> >> >> vendors must add this in their kernels or USB gadget devices based
> >> >> on Linux (such as mobile phones) may not behave as they should.
> >> >> Thus provide a
> >> standard framework for doing this in kernel.
> >> >>
> >> >> Now introduce one user with wm831x_power to support and test the
> >> >> usb
> >> charger.
> >> >> Another user introduced to support charger detection by Jun Li:
> >> >> https://www.spinics.net/lists/linux-usb/msg139425.html
> >> >> Moreover there may be other potential users will use it in future.
> >> >>
> >> >> 1. Before v19 patchset we've fixed below issues in extcon
> >> >> subsystem and usb phy driver, now all were merged. (Thanks for
> >> >> Neil's
> >> >> suggestion)
> >> >> (1) Have fixed the inconsistencies with USB connector types in
> >> >> extcon subsystem by following links:
> >> >> https://lkml.org/lkml/2016/12/21/13
> >> >> https://lkml.org/lkml/2016/12/21/15
> >> >> https://lkml.org/lkml/2016/12/21/79
> >> >> https://lkml.org/lkml/2017/1/3/13
> >> >>
> >> >> (2) Instead of using 'set_power' callback in phy drivers, we will
> >> >> introduce USB charger to set PMIC current drawn from USB
> >> >> configuration, moreover some 'set_power' callbacks did not
> >> >> implement anything to set PMIC current, thus remove them by
> following links:
> >> >> https://lkml.org/lkml/2017/1/18/436
> >> >> https://lkml.org/lkml/2017/1/18/439
> >> >> https://lkml.org/lkml/2017/1/18/438
> >> >> Now only two phy drivers (phy-isp1301-omap.c and
> >> >> phy-gpio-vbus-usb.c) still used 'set_power' callback to set
> >> >> current, we can remove them in future. (I have no platform with
> >> >> enabling these two phy drivers, so I can not test them if I
> >> >> converted 'set_power' callback to USB
> >> >> charger.)
> >> >>
> >> >> 2. Some issues pointed by Neil Brown were sill kept in this v19
> >> >> patchset, and I expalined each issue and may be need discuss again:
> >> >> (1) Change all usb phys to register an extcon and to send
> >> >> appropriate
> >> notifications.
> >> >> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c,
> >> >> phy-omap-otg.c and
> >> >> phy-ms

RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Jun Li]

Hi,

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Tuesday, March 07, 2017 5:39 PM
> To: NeilBrown <ne...@suse.com>
> Cc: Felipe Balbi <ba...@kernel.org>; Greg KH <gre...@linuxfoundation.org>;
> Sebastian Reichel <s...@kernel.org>; Dmitry Eremin-Solenikov
> <dbarysh...@gmail.com>; David Woodhouse <dw...@infradead.org>;
> r...@kernel.org; Jun Li <jun...@nxp.com>; Marek Szyprowski
> <m.szyprow...@samsung.com>; Ruslan Bilovol <ruslan.bilo...@gmail.com>;
> Peter Chen <peter.c...@freescale.com>; Alan Stern
> <st...@rowland.harvard.edu>; grygorii.stras...@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda...@renesas.com>; Lee Jones <lee.jo...@linaro.org>;
> Mark Brown <broo...@kernel.org>; John Stultz <john.stu...@linaro.org>;
> Charles Keepax <ckee...@opensource.wolfsonmicro.com>;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB <linux-...@vger.kernel.org>; device-
> mainlin...@lists.linuxfoundation.org; LKML <linux-kernel@vger.kernel.org>
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> On 3 March 2017 at 10:23, NeilBrown <ne...@suse.com> wrote:
> > On Mon, Feb 20 2017, Baolin Wang wrote:
> >
> >> Currently the Linux kernel does not provide any standard integration
> >> of this feature that integrates the USB subsystem with the system
> >> power regulation provided by PMICs meaning that either vendors must
> >> add this in their kernels or USB gadget devices based on Linux (such
> >> as mobile phones) may not behave as they should. Thus provide a
> standard framework for doing this in kernel.
> >>
> >> Now introduce one user with wm831x_power to support and test the usb
> charger.
> >> Another user introduced to support charger detection by Jun Li:
> >> https://www.spinics.net/lists/linux-usb/msg139425.html
> >> Moreover there may be other potential users will use it in future.
> >>
> >> 1. Before v19 patchset we've fixed below issues in extcon subsystem
> >> and usb phy driver, now all were merged. (Thanks for Neil's
> >> suggestion)
> >> (1) Have fixed the inconsistencies with USB connector types in extcon
> >> subsystem by following links:
> >> https://lkml.org/lkml/2016/12/21/13
> >> https://lkml.org/lkml/2016/12/21/15
> >> https://lkml.org/lkml/2016/12/21/79
> >> https://lkml.org/lkml/2017/1/3/13
> >>
> >> (2) Instead of using 'set_power' callback in phy drivers, we will
> >> introduce USB charger to set PMIC current drawn from USB
> >> configuration, moreover some 'set_power' callbacks did not implement
> >> anything to set PMIC current, thus remove them by following links:
> >> https://lkml.org/lkml/2017/1/18/436
> >> https://lkml.org/lkml/2017/1/18/439
> >> https://lkml.org/lkml/2017/1/18/438
> >> Now only two phy drivers (phy-isp1301-omap.c and phy-gpio-vbus-usb.c)
> >> still used 'set_power' callback to set current, we can remove them in
> >> future. (I have no platform with enabling these two phy drivers, so I
> >> can not test them if I converted 'set_power' callback to USB
> >> charger.)
> >>
> >> 2. Some issues pointed by Neil Brown were sill kept in this v19
> >> patchset, and I expalined each issue and may be need discuss again:
> >> (1) Change all usb phys to register an extcon and to send appropriate
> notifications.
> >> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c,
> >> phy-omap-otg.c and
> >> phy-msm-usb.c) had registered an extcon, mostly did not. I can not
> >> change all usb phys to register an extcon, since there are no extcon
> >> device to register for these different phy drivers.
> >
> > You don't have to change every driver.  You just need to make it easy
> > and obvious how to change drivers in a consistent coherent way.
> > For a start you would add a 'struct extcon_dev' to 'struct usb_phy',
> > and possibly add or extend some 'static inline's in linux/usb/phy.h to
> > send notification on that extcon (if it is non-NULL).
> > e.g. usb_phy_vbus_on() could send an extcon notification.
> >
> > Then any phy driver which adds support for setting phy->extcon_dev
> > appropriately, immediately gets the relevant notifications sent.
> 
> OK. We can make these extcon related code into phy common part.
>   

Will generic phy need add extcon as well?

> >
> >> Secondly, I also agreed

RE: [PATCH v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Jun Li]

Hi,

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Tuesday, March 07, 2017 5:39 PM
> To: NeilBrown 
> Cc: Felipe Balbi ; Greg KH ;
> Sebastian Reichel ; Dmitry Eremin-Solenikov
> ; David Woodhouse ;
> r...@kernel.org; Jun Li ; Marek Szyprowski
> ; Ruslan Bilovol ;
> Peter Chen ; Alan Stern
> ; grygorii.stras...@ti.com; Yoshihiro Shimoda
> ; Lee Jones ;
> Mark Brown ; John Stultz ;
> Charles Keepax ;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB ; device-
> mainlin...@lists.linuxfoundation.org; LKML 
> Subject: Re: [PATCH v19 0/4] Introduce usb charger framework to deal with
> the usb gadget power negotation
> 
> On 3 March 2017 at 10:23, NeilBrown  wrote:
> > On Mon, Feb 20 2017, Baolin Wang wrote:
> >
> >> Currently the Linux kernel does not provide any standard integration
> >> of this feature that integrates the USB subsystem with the system
> >> power regulation provided by PMICs meaning that either vendors must
> >> add this in their kernels or USB gadget devices based on Linux (such
> >> as mobile phones) may not behave as they should. Thus provide a
> standard framework for doing this in kernel.
> >>
> >> Now introduce one user with wm831x_power to support and test the usb
> charger.
> >> Another user introduced to support charger detection by Jun Li:
> >> https://www.spinics.net/lists/linux-usb/msg139425.html
> >> Moreover there may be other potential users will use it in future.
> >>
> >> 1. Before v19 patchset we've fixed below issues in extcon subsystem
> >> and usb phy driver, now all were merged. (Thanks for Neil's
> >> suggestion)
> >> (1) Have fixed the inconsistencies with USB connector types in extcon
> >> subsystem by following links:
> >> https://lkml.org/lkml/2016/12/21/13
> >> https://lkml.org/lkml/2016/12/21/15
> >> https://lkml.org/lkml/2016/12/21/79
> >> https://lkml.org/lkml/2017/1/3/13
> >>
> >> (2) Instead of using 'set_power' callback in phy drivers, we will
> >> introduce USB charger to set PMIC current drawn from USB
> >> configuration, moreover some 'set_power' callbacks did not implement
> >> anything to set PMIC current, thus remove them by following links:
> >> https://lkml.org/lkml/2017/1/18/436
> >> https://lkml.org/lkml/2017/1/18/439
> >> https://lkml.org/lkml/2017/1/18/438
> >> Now only two phy drivers (phy-isp1301-omap.c and phy-gpio-vbus-usb.c)
> >> still used 'set_power' callback to set current, we can remove them in
> >> future. (I have no platform with enabling these two phy drivers, so I
> >> can not test them if I converted 'set_power' callback to USB
> >> charger.)
> >>
> >> 2. Some issues pointed by Neil Brown were sill kept in this v19
> >> patchset, and I expalined each issue and may be need discuss again:
> >> (1) Change all usb phys to register an extcon and to send appropriate
> notifications.
> >> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c,
> >> phy-omap-otg.c and
> >> phy-msm-usb.c) had registered an extcon, mostly did not. I can not
> >> change all usb phys to register an extcon, since there are no extcon
> >> device to register for these different phy drivers.
> >
> > You don't have to change every driver.  You just need to make it easy
> > and obvious how to change drivers in a consistent coherent way.
> > For a start you would add a 'struct extcon_dev' to 'struct usb_phy',
> > and possibly add or extend some 'static inline's in linux/usb/phy.h to
> > send notification on that extcon (if it is non-NULL).
> > e.g. usb_phy_vbus_on() could send an extcon notification.
> >
> > Then any phy driver which adds support for setting phy->extcon_dev
> > appropriately, immediately gets the relevant notifications sent.
> 
> OK. We can make these extcon related code into phy common part.
>   

Will generic phy need add extcon as well?

> >
> >> Secondly, I also agreed with Peter's comments: Not only USB PHY to
> >> register an extcon, but also for the drivers which can detect USB
> >> charger type, it may be USB controller driver, USB type-c driver,
> >> pmic driver, and these drivers may not have an extcon device since
> >> the internal part can finish the vbus detect.
> >
> > Whichever part can detect vbus, the driver for that part must be able
> > to find the extcon and trigger a notification.
> > Maybe one part can detect VBUS, another can measure the resistance o

RE: [RFC PATCH v3 2/2] usb: typec: Type-C Port Controller Interface driver (tcpci)

[Jun Li]

Hi,
> -Original Message-
> From: Guenter Roeck [mailto:gro...@google.com]
> Sent: Saturday, October 01, 2016 2:45 AM
> To: Jun Li <jun...@nxp.com>
> Cc: Guenter Roeck <gro...@chromium.org>; Felipe Balbi
> <felipe.ba...@linux.intel.com>; Chandra Sekhar Anagani
> <chandra.sekhar.anag...@intel.com>; Bruce Ashfield
> <bruce.ashfi...@windriver.com>; Bin Gao <bin@intel.com>; Pranav Tipnis
> <pranav.tip...@intel.com>; Heikki Krogerus
> <heikki.kroge...@linux.intel.com>; linux-kernel@vger.kernel.org; linux-
> u...@vger.kernel.org
> Subject: Re: [RFC PATCH v3 2/2] usb: typec: Type-C Port Controller
> Interface driver (tcpci)
> 
> On Thu, Sep 29, 2016 at 11:24 PM, Jun Li <jun...@nxp.com> wrote:
> > Hi Guenter,
> >
> >> -Original Message-
> >> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> >> ow...@vger.kernel.org] On Behalf Of Guenter Roeck
> >> Sent: Wednesday, August 24, 2016 5:11 AM
> >> To: Felipe Balbi <felipe.ba...@linux.intel.com>
> >> Cc: Chandra Sekhar Anagani <chandra.sekhar.anag...@intel.com>; Bruce
> >> Ashfield <bruce.ashfi...@windriver.com>; Bin Gao <bin@intel.com>;
> >> Pranav Tipnis <pranav.tip...@intel.com>; Heikki Krogerus
> >> <heikki.kroge...@linux.intel.com>; linux-kernel@vger.kernel.org;
> >> linux- u...@vger.kernel.org; Guenter Roeck <gro...@chromium.org>
> >> Subject: [RFC PATCH v3 2/2] usb: typec: Type-C Port Controller
> >> Interface driver (tcpci)
> >>
> >> The port controller interface driver interconnects the Type-C Port
> >> Manager with a Type-C Port Controller Interface (TCPCI) compliant port
> controller.
> >>
> >> Signed-off-by: Guenter Roeck <gro...@chromium.org>
> >> ---
> >> v3:
> >> - No change
> >>
> >> v2:
> >> - Adjust to modified callbacks into tcpm code
> >>
> >>  drivers/usb/typec/Kconfig  |   9 +
> >>  drivers/usb/typec/Makefile |   1 +
> >>  drivers/usb/typec/tcpci.c  | 487
> >> +
> >>  drivers/usb/typec/tcpci.h  | 133 +
> >>  4 files changed, 630 insertions(+)
> >>  create mode 100644 drivers/usb/typec/tcpci.c  create mode 100644
> >> drivers/usb/typec/tcpci.h
> >>
> >> diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
> >> index
> >> 113bb1b3589c..a92c9d1a3e00 100644
> >> --- a/drivers/usb/typec/Kconfig
> >> +++ b/drivers/usb/typec/Kconfig
> >> @@ -25,4 +25,13 @@ config TYPEC_TCPM
> >> The Type-C Port Controller Manager provides a USB PD and USB
> Type-C
> >> state machine for use with Type-C Port Controllers.
> >>
> >> +if TYPEC_TCPM
> >> +
> >> +config TYPEC_TCPCI
> >> + tristate "Type-C Port Controller Interface driver"
> >> + help
> >> +   Type-C Port Controller driver for TCPCI-compliant controller.
> >> +
> >> +endif
> >> +
> >>  endmenu
> >> diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
> >> index bbe45721cf52..7dbaf8c3911d 100644
> >> --- a/drivers/usb/typec/Makefile
> >> +++ b/drivers/usb/typec/Makefile
> >> @@ -1,3 +1,4 @@
> >>  obj-$(CONFIG_TYPEC)  += typec.o
> >>  obj-$(CONFIG_TYPEC_WCOVE)+= typec_wcove.o
> >>  obj-$(CONFIG_TYPEC_TCPM) += tcpm.o
> >> +obj-$(CONFIG_TYPEC_TCPCI)+= tcpci.o
> >> diff --git a/drivers/usb/typec/tcpci.c b/drivers/usb/typec/tcpci.c
> >> new file mode 100644 index ..af338218a1f3
> >> --- /dev/null
> >> +++ b/drivers/usb/typec/tcpci.c
> >> @@ -0,0 +1,487 @@
> >> +/*
> >> + * Copyright 2015-2016 Google, Inc
> >> + *
> >> + * This program is free software; you can redistribute it and/or
> >> +modify
> >> + * it under the terms of the GNU General Public License as published
> >> +by
> >> + * the Free Software Foundation; either version 2 of the License, or
> >> + * (at your option) any later version.
> >> + *
> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >> + * GNU General Public License for more details.
> >> + *
> >> + * USB Type-C Port Controller Interface.
> >> + */
>

RE: [RFC PATCH v3 2/2] usb: typec: Type-C Port Controller Interface driver (tcpci)

[Jun Li]

Hi,
> -Original Message-
> From: Guenter Roeck [mailto:gro...@google.com]
> Sent: Saturday, October 01, 2016 2:45 AM
> To: Jun Li 
> Cc: Guenter Roeck ; Felipe Balbi
> ; Chandra Sekhar Anagani
> ; Bruce Ashfield
> ; Bin Gao ; Pranav Tipnis
> ; Heikki Krogerus
> ; linux-kernel@vger.kernel.org; linux-
> u...@vger.kernel.org
> Subject: Re: [RFC PATCH v3 2/2] usb: typec: Type-C Port Controller
> Interface driver (tcpci)
> 
> On Thu, Sep 29, 2016 at 11:24 PM, Jun Li  wrote:
> > Hi Guenter,
> >
> >> -Original Message-
> >> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> >> ow...@vger.kernel.org] On Behalf Of Guenter Roeck
> >> Sent: Wednesday, August 24, 2016 5:11 AM
> >> To: Felipe Balbi 
> >> Cc: Chandra Sekhar Anagani ; Bruce
> >> Ashfield ; Bin Gao ;
> >> Pranav Tipnis ; Heikki Krogerus
> >> ; linux-kernel@vger.kernel.org;
> >> linux- u...@vger.kernel.org; Guenter Roeck 
> >> Subject: [RFC PATCH v3 2/2] usb: typec: Type-C Port Controller
> >> Interface driver (tcpci)
> >>
> >> The port controller interface driver interconnects the Type-C Port
> >> Manager with a Type-C Port Controller Interface (TCPCI) compliant port
> controller.
> >>
> >> Signed-off-by: Guenter Roeck 
> >> ---
> >> v3:
> >> - No change
> >>
> >> v2:
> >> - Adjust to modified callbacks into tcpm code
> >>
> >>  drivers/usb/typec/Kconfig  |   9 +
> >>  drivers/usb/typec/Makefile |   1 +
> >>  drivers/usb/typec/tcpci.c  | 487
> >> +
> >>  drivers/usb/typec/tcpci.h  | 133 +
> >>  4 files changed, 630 insertions(+)
> >>  create mode 100644 drivers/usb/typec/tcpci.c  create mode 100644
> >> drivers/usb/typec/tcpci.h
> >>
> >> diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig
> >> index
> >> 113bb1b3589c..a92c9d1a3e00 100644
> >> --- a/drivers/usb/typec/Kconfig
> >> +++ b/drivers/usb/typec/Kconfig
> >> @@ -25,4 +25,13 @@ config TYPEC_TCPM
> >> The Type-C Port Controller Manager provides a USB PD and USB
> Type-C
> >> state machine for use with Type-C Port Controllers.
> >>
> >> +if TYPEC_TCPM
> >> +
> >> +config TYPEC_TCPCI
> >> + tristate "Type-C Port Controller Interface driver"
> >> + help
> >> +   Type-C Port Controller driver for TCPCI-compliant controller.
> >> +
> >> +endif
> >> +
> >>  endmenu
> >> diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
> >> index bbe45721cf52..7dbaf8c3911d 100644
> >> --- a/drivers/usb/typec/Makefile
> >> +++ b/drivers/usb/typec/Makefile
> >> @@ -1,3 +1,4 @@
> >>  obj-$(CONFIG_TYPEC)  += typec.o
> >>  obj-$(CONFIG_TYPEC_WCOVE)+= typec_wcove.o
> >>  obj-$(CONFIG_TYPEC_TCPM) += tcpm.o
> >> +obj-$(CONFIG_TYPEC_TCPCI)+= tcpci.o
> >> diff --git a/drivers/usb/typec/tcpci.c b/drivers/usb/typec/tcpci.c
> >> new file mode 100644 index ..af338218a1f3
> >> --- /dev/null
> >> +++ b/drivers/usb/typec/tcpci.c
> >> @@ -0,0 +1,487 @@
> >> +/*
> >> + * Copyright 2015-2016 Google, Inc
> >> + *
> >> + * This program is free software; you can redistribute it and/or
> >> +modify
> >> + * it under the terms of the GNU General Public License as published
> >> +by
> >> + * the Free Software Foundation; either version 2 of the License, or
> >> + * (at your option) any later version.
> >> + *
> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >> + * GNU General Public License for more details.
> >> + *
> >> + * USB Type-C Port Controller Interface.
> >> + */
> >> +
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +#include 
> >> +
> >> +#include "tcpci.h"
> >> +#include "tcpm.h"
> >> +
> >> +#define PD_RETRY_COUNT 3
> >> +
> >> +struct tcpci {
> >> + struct device *dev;
> >> + struct i2c_client *client;
> >&g

RE: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

[Jun Li]

Hi,

> -Original Message-
> From: Guenter Roeck [mailto:gro...@google.com]
> Sent: Friday, September 30, 2016 12:37 AM
> To: Jun Li <jun...@nxp.com>
> Cc: Guenter Roeck <gro...@chromium.org>; Felipe Balbi
> <felipe.ba...@linux.intel.com>; Chandra Sekhar Anagani
> <chandra.sekhar.anag...@intel.com>; Bruce Ashfield
> <bruce.ashfi...@windriver.com>; Bin Gao <bin@intel.com>; Pranav Tipnis
> <pranav.tip...@intel.com>; Heikki Krogerus
> <heikki.kroge...@linux.intel.com>; linux-kernel@vger.kernel.org; linux-
> u...@vger.kernel.org
> Subject: Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)
> 
> On Thu, Sep 29, 2016 at 7:35 AM, Jun Li <jun...@nxp.com> wrote:
> > Hi Guenter,
> >
> >> -Original Message-
> >> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> >> ow...@vger.kernel.org] On Behalf Of Guenter Roeck
> >> Sent: Wednesday, August 24, 2016 5:11 AM
> >> To: Felipe Balbi <felipe.ba...@linux.intel.com>
> >> Cc: Chandra Sekhar Anagani <chandra.sekhar.anag...@intel.com>; Bruce
> >> Ashfield <bruce.ashfi...@windriver.com>; Bin Gao <bin@intel.com>;
> >> Pranav Tipnis <pranav.tip...@intel.com>; Heikki Krogerus
> >> <heikki.kroge...@linux.intel.com>; linux-kernel@vger.kernel.org;
> >> linux- u...@vger.kernel.org; Guenter Roeck <gro...@chromium.org>
> >> Subject: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager
> >> (tcpm)
> >>
> >> This driver implements the USB Type-C Power Delivery state machine
> >> for both source and sink ports. Alternate mode support is not fully
> >> implemented.
> >>
> >> The driver attaches to the USB Type-C class code implemented in the
> >> following patches.
> >>
> >>   usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY
> >>   usb: USB Type-C connector class
> >>
> >> This driver only implements the state machine. Lower level drivers
> >> are responsible for
> >> - Reporting VBUS status and activating VBUS
> >> - Setting CC lines and providing CC line status
> >> - Setting line polarity
> >> - Activating and deactivating VCONN
> >> - Setting the current limit
> >> - Activating and deactivating PD message transfers
> >> - Sending and receiving PD messages
> >>
> >> The driver provides both a functional API as well as callbacks for
> >> lower level drivers.
> >>
> >> Signed-off-by: Guenter Roeck <gro...@chromium.org>
> >> ---
> >> v3:
> >> - Improve TCPM state machine resiliency if there are spurious CC line
> >> changes
> >>   while the state machine is in a transient change (waiting for a
> >> timeout)
> >> - Update current limit after CC voltage level changes on a port which
> >> is not
> >>   PD capable.
> >>
> >> v2:
> >> - Only update polarity if setting it was successful
> >>   If setting the CC line polarity in the driver was not successful,
> >>   don't update the internal polarity state.
> >> - All PD messages are little endian; convert to and from CPU endianness.
> >> - Avoid comparisons against NULL.
> >> - Use u8/u16/u32 instead of uint8_t/uint16_t/uint32_t consistently.
> >> - Callbacks into tcpm need to be lockless to avoid timing problems
> >>   in low level drivers.
> >> - Simplify callbacks; tcpm can request the current state of cc/vbus
> >>   when it is ready to use it.
> >>
> >>  drivers/usb/typec/Kconfig  |7 +
> >>  drivers/usb/typec/Makefile |1 +
> >>  drivers/usb/typec/tcpm.c   | 3163
> >> 
> >>  drivers/usb/typec/tcpm.h   |  137 ++
> >>  include/linux/usb/pd.h |  282 
> >>  include/linux/usb/pd_bdo.h |   31 +
> >>  include/linux/usb/pd_vdo.h |  412 ++
> >>  7 files changed, 4033 insertions(+)
> >>  create mode 100644 drivers/usb/typec/tcpm.c  create mode 100644
> >> drivers/usb/typec/tcpm.h  create mode 100644 include/linux/usb/pd.h
> >> create mode 100644 include/linux/usb/pd_bdo.h  create mode 100644
> >> include/linux/usb/pd_vdo.h
> >>
> >
> > ...
> >
> >> +
> >> +static void run_state_machine(struct tcpm_port *port) {
> >> + int ret;
> >> +
> >> + port->enter_state = port->state;
> >> + switch (port->state) {
> >> +  

RE: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

[Jun Li]

Hi,

> -Original Message-
> From: Guenter Roeck [mailto:gro...@google.com]
> Sent: Friday, September 30, 2016 12:37 AM
> To: Jun Li 
> Cc: Guenter Roeck ; Felipe Balbi
> ; Chandra Sekhar Anagani
> ; Bruce Ashfield
> ; Bin Gao ; Pranav Tipnis
> ; Heikki Krogerus
> ; linux-kernel@vger.kernel.org; linux-
> u...@vger.kernel.org
> Subject: Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)
> 
> On Thu, Sep 29, 2016 at 7:35 AM, Jun Li  wrote:
> > Hi Guenter,
> >
> >> -Original Message-
> >> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> >> ow...@vger.kernel.org] On Behalf Of Guenter Roeck
> >> Sent: Wednesday, August 24, 2016 5:11 AM
> >> To: Felipe Balbi 
> >> Cc: Chandra Sekhar Anagani ; Bruce
> >> Ashfield ; Bin Gao ;
> >> Pranav Tipnis ; Heikki Krogerus
> >> ; linux-kernel@vger.kernel.org;
> >> linux- u...@vger.kernel.org; Guenter Roeck 
> >> Subject: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager
> >> (tcpm)
> >>
> >> This driver implements the USB Type-C Power Delivery state machine
> >> for both source and sink ports. Alternate mode support is not fully
> >> implemented.
> >>
> >> The driver attaches to the USB Type-C class code implemented in the
> >> following patches.
> >>
> >>   usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY
> >>   usb: USB Type-C connector class
> >>
> >> This driver only implements the state machine. Lower level drivers
> >> are responsible for
> >> - Reporting VBUS status and activating VBUS
> >> - Setting CC lines and providing CC line status
> >> - Setting line polarity
> >> - Activating and deactivating VCONN
> >> - Setting the current limit
> >> - Activating and deactivating PD message transfers
> >> - Sending and receiving PD messages
> >>
> >> The driver provides both a functional API as well as callbacks for
> >> lower level drivers.
> >>
> >> Signed-off-by: Guenter Roeck 
> >> ---
> >> v3:
> >> - Improve TCPM state machine resiliency if there are spurious CC line
> >> changes
> >>   while the state machine is in a transient change (waiting for a
> >> timeout)
> >> - Update current limit after CC voltage level changes on a port which
> >> is not
> >>   PD capable.
> >>
> >> v2:
> >> - Only update polarity if setting it was successful
> >>   If setting the CC line polarity in the driver was not successful,
> >>   don't update the internal polarity state.
> >> - All PD messages are little endian; convert to and from CPU endianness.
> >> - Avoid comparisons against NULL.
> >> - Use u8/u16/u32 instead of uint8_t/uint16_t/uint32_t consistently.
> >> - Callbacks into tcpm need to be lockless to avoid timing problems
> >>   in low level drivers.
> >> - Simplify callbacks; tcpm can request the current state of cc/vbus
> >>   when it is ready to use it.
> >>
> >>  drivers/usb/typec/Kconfig  |7 +
> >>  drivers/usb/typec/Makefile |1 +
> >>  drivers/usb/typec/tcpm.c   | 3163
> >> 
> >>  drivers/usb/typec/tcpm.h   |  137 ++
> >>  include/linux/usb/pd.h |  282 
> >>  include/linux/usb/pd_bdo.h |   31 +
> >>  include/linux/usb/pd_vdo.h |  412 ++
> >>  7 files changed, 4033 insertions(+)
> >>  create mode 100644 drivers/usb/typec/tcpm.c  create mode 100644
> >> drivers/usb/typec/tcpm.h  create mode 100644 include/linux/usb/pd.h
> >> create mode 100644 include/linux/usb/pd_bdo.h  create mode 100644
> >> include/linux/usb/pd_vdo.h
> >>
> >
> > ...
> >
> >> +
> >> +static void run_state_machine(struct tcpm_port *port) {
> >> + int ret;
> >> +
> >> + port->enter_state = port->state;
> >> + switch (port->state) {
> >> + /* SRC states */
> >> + case SRC_UNATTACHED:
> >> + tcpm_swap_complete(port, -ENOTCONN);
> >> + tcpm_src_detach(port);
> >> + tcpm_set_cc(port, TYPEC_CC_RP_DEF);
> >> + if (port->typec_caps.type == TYPEC_PORT_DRP)
> >> + tcpm_set_state(port, SNK_UNATTACHED,
> >> + PD_T_DRP_SNK);
> >
> > With this and below, after disconnect, the DRP port state machine 

RE: [RFC PATCH v3 2/2] usb: typec: Type-C Port Controller Interface driver (tcpci)

[Jun Li]

Hi Guenter,

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Guenter Roeck
> Sent: Wednesday, August 24, 2016 5:11 AM
> To: Felipe Balbi 
> Cc: Chandra Sekhar Anagani ; Bruce
> Ashfield ; Bin Gao ;
> Pranav Tipnis ; Heikki Krogerus
> ; linux-kernel@vger.kernel.org; linux-
> u...@vger.kernel.org; Guenter Roeck 
> Subject: [RFC PATCH v3 2/2] usb: typec: Type-C Port Controller Interface
> driver (tcpci)
> 
> The port controller interface driver interconnects the Type-C Port Manager
> with a Type-C Port Controller Interface (TCPCI) compliant port controller.
> 
> Signed-off-by: Guenter Roeck 
> ---
> v3:
> - No change
> 
> v2:
> - Adjust to modified callbacks into tcpm code
> 
>  drivers/usb/typec/Kconfig  |   9 +
>  drivers/usb/typec/Makefile |   1 +
>  drivers/usb/typec/tcpci.c  | 487
> +
>  drivers/usb/typec/tcpci.h  | 133 +
>  4 files changed, 630 insertions(+)
>  create mode 100644 drivers/usb/typec/tcpci.c  create mode 100644
> drivers/usb/typec/tcpci.h
> 
> diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig index
> 113bb1b3589c..a92c9d1a3e00 100644
> --- a/drivers/usb/typec/Kconfig
> +++ b/drivers/usb/typec/Kconfig
> @@ -25,4 +25,13 @@ config TYPEC_TCPM
> The Type-C Port Controller Manager provides a USB PD and USB Type-C
> state machine for use with Type-C Port Controllers.
> 
> +if TYPEC_TCPM
> +
> +config TYPEC_TCPCI
> + tristate "Type-C Port Controller Interface driver"
> + help
> +   Type-C Port Controller driver for TCPCI-compliant controller.
> +
> +endif
> +
>  endmenu
> diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile index
> bbe45721cf52..7dbaf8c3911d 100644
> --- a/drivers/usb/typec/Makefile
> +++ b/drivers/usb/typec/Makefile
> @@ -1,3 +1,4 @@
>  obj-$(CONFIG_TYPEC)  += typec.o
>  obj-$(CONFIG_TYPEC_WCOVE)+= typec_wcove.o
>  obj-$(CONFIG_TYPEC_TCPM) += tcpm.o
> +obj-$(CONFIG_TYPEC_TCPCI)+= tcpci.o
> diff --git a/drivers/usb/typec/tcpci.c b/drivers/usb/typec/tcpci.c new
> file mode 100644 index ..af338218a1f3
> --- /dev/null
> +++ b/drivers/usb/typec/tcpci.c
> @@ -0,0 +1,487 @@
> +/*
> + * Copyright 2015-2016 Google, Inc
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * USB Type-C Port Controller Interface.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "tcpci.h"
> +#include "tcpm.h"
> +
> +#define PD_RETRY_COUNT 3
> +
> +struct tcpci {
> + struct device *dev;
> + struct i2c_client *client;
> +
> + struct tcpm_port *port;
> +
> + struct regmap *regmap;
> +
> + bool controls_vbus;
> +
> + struct tcpc_dev tcpc;
> +};
> +
> +static inline struct tcpci *tcpc_to_tcpci(struct tcpc_dev *tcpc) {
> + return container_of(tcpc, struct tcpci, tcpc); }
> +
> +static int tcpci_read16(struct tcpci *tcpci, unsigned int reg,
> + unsigned int *val)
> +{
> + return regmap_raw_read(tcpci->regmap, reg, val, sizeof(u16)); }
> +
> +static int tcpci_write16(struct tcpci *tcpci, unsigned int reg, u16
> +val) {
> + return regmap_raw_write(tcpci->regmap, reg, , sizeof(u16)); }
> +
> +static int tcpci_set_cc(struct tcpc_dev *tcpc, enum typec_cc_status cc)
> +{
> + struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
> + unsigned int reg;
> + int ret;
> +
> + switch (cc) {
> + case TYPEC_CC_RA:
> + reg = (TCPC_ROLE_CTRL_CC_RA << TCPC_ROLE_CTRL_CC1_SHIFT) |
> + (TCPC_ROLE_CTRL_CC_RA << TCPC_ROLE_CTRL_CC2_SHIFT);
> + break;
> + case TYPEC_CC_RD:
> + reg = (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC1_SHIFT) |
> + (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC2_SHIFT);
> + break;
> + case TYPEC_CC_RP_DEF:
> + reg = (TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC1_SHIFT) |
> + (TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC2_SHIFT) |
> + (TCPC_ROLE_CTRL_RP_VAL_DEF <<
> +  TCPC_ROLE_CTRL_RP_VAL_SHIFT);
> + break;
> + case TYPEC_CC_RP_1_5:
> + reg = (TCPC_ROLE_CTRL_CC_RP << 

RE: [RFC PATCH v3 2/2] usb: typec: Type-C Port Controller Interface driver (tcpci)

[Jun Li]

Hi Guenter,

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Guenter Roeck
> Sent: Wednesday, August 24, 2016 5:11 AM
> To: Felipe Balbi 
> Cc: Chandra Sekhar Anagani ; Bruce
> Ashfield ; Bin Gao ;
> Pranav Tipnis ; Heikki Krogerus
> ; linux-kernel@vger.kernel.org; linux-
> u...@vger.kernel.org; Guenter Roeck 
> Subject: [RFC PATCH v3 2/2] usb: typec: Type-C Port Controller Interface
> driver (tcpci)
> 
> The port controller interface driver interconnects the Type-C Port Manager
> with a Type-C Port Controller Interface (TCPCI) compliant port controller.
> 
> Signed-off-by: Guenter Roeck 
> ---
> v3:
> - No change
> 
> v2:
> - Adjust to modified callbacks into tcpm code
> 
>  drivers/usb/typec/Kconfig  |   9 +
>  drivers/usb/typec/Makefile |   1 +
>  drivers/usb/typec/tcpci.c  | 487
> +
>  drivers/usb/typec/tcpci.h  | 133 +
>  4 files changed, 630 insertions(+)
>  create mode 100644 drivers/usb/typec/tcpci.c  create mode 100644
> drivers/usb/typec/tcpci.h
> 
> diff --git a/drivers/usb/typec/Kconfig b/drivers/usb/typec/Kconfig index
> 113bb1b3589c..a92c9d1a3e00 100644
> --- a/drivers/usb/typec/Kconfig
> +++ b/drivers/usb/typec/Kconfig
> @@ -25,4 +25,13 @@ config TYPEC_TCPM
> The Type-C Port Controller Manager provides a USB PD and USB Type-C
> state machine for use with Type-C Port Controllers.
> 
> +if TYPEC_TCPM
> +
> +config TYPEC_TCPCI
> + tristate "Type-C Port Controller Interface driver"
> + help
> +   Type-C Port Controller driver for TCPCI-compliant controller.
> +
> +endif
> +
>  endmenu
> diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile index
> bbe45721cf52..7dbaf8c3911d 100644
> --- a/drivers/usb/typec/Makefile
> +++ b/drivers/usb/typec/Makefile
> @@ -1,3 +1,4 @@
>  obj-$(CONFIG_TYPEC)  += typec.o
>  obj-$(CONFIG_TYPEC_WCOVE)+= typec_wcove.o
>  obj-$(CONFIG_TYPEC_TCPM) += tcpm.o
> +obj-$(CONFIG_TYPEC_TCPCI)+= tcpci.o
> diff --git a/drivers/usb/typec/tcpci.c b/drivers/usb/typec/tcpci.c new
> file mode 100644 index ..af338218a1f3
> --- /dev/null
> +++ b/drivers/usb/typec/tcpci.c
> @@ -0,0 +1,487 @@
> +/*
> + * Copyright 2015-2016 Google, Inc
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * USB Type-C Port Controller Interface.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "tcpci.h"
> +#include "tcpm.h"
> +
> +#define PD_RETRY_COUNT 3
> +
> +struct tcpci {
> + struct device *dev;
> + struct i2c_client *client;
> +
> + struct tcpm_port *port;
> +
> + struct regmap *regmap;
> +
> + bool controls_vbus;
> +
> + struct tcpc_dev tcpc;
> +};
> +
> +static inline struct tcpci *tcpc_to_tcpci(struct tcpc_dev *tcpc) {
> + return container_of(tcpc, struct tcpci, tcpc); }
> +
> +static int tcpci_read16(struct tcpci *tcpci, unsigned int reg,
> + unsigned int *val)
> +{
> + return regmap_raw_read(tcpci->regmap, reg, val, sizeof(u16)); }
> +
> +static int tcpci_write16(struct tcpci *tcpci, unsigned int reg, u16
> +val) {
> + return regmap_raw_write(tcpci->regmap, reg, , sizeof(u16)); }
> +
> +static int tcpci_set_cc(struct tcpc_dev *tcpc, enum typec_cc_status cc)
> +{
> + struct tcpci *tcpci = tcpc_to_tcpci(tcpc);
> + unsigned int reg;
> + int ret;
> +
> + switch (cc) {
> + case TYPEC_CC_RA:
> + reg = (TCPC_ROLE_CTRL_CC_RA << TCPC_ROLE_CTRL_CC1_SHIFT) |
> + (TCPC_ROLE_CTRL_CC_RA << TCPC_ROLE_CTRL_CC2_SHIFT);
> + break;
> + case TYPEC_CC_RD:
> + reg = (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC1_SHIFT) |
> + (TCPC_ROLE_CTRL_CC_RD << TCPC_ROLE_CTRL_CC2_SHIFT);
> + break;
> + case TYPEC_CC_RP_DEF:
> + reg = (TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC1_SHIFT) |
> + (TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC2_SHIFT) |
> + (TCPC_ROLE_CTRL_RP_VAL_DEF <<
> +  TCPC_ROLE_CTRL_RP_VAL_SHIFT);
> + break;
> + case TYPEC_CC_RP_1_5:
> + reg = (TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC1_SHIFT) |
> + (TCPC_ROLE_CTRL_CC_RP << TCPC_ROLE_CTRL_CC2_SHIFT) |
> + (TCPC_ROLE_CTRL_RP_VAL_1_5 <<
> +  TCPC_ROLE_CTRL_RP_VAL_SHIFT);
> + 

RE: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

[Jun Li]

Hi Guenter,
> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Guenter Roeck
> Sent: Wednesday, August 24, 2016 5:11 AM
> To: Felipe Balbi 
> Cc: Chandra Sekhar Anagani ; Bruce
> Ashfield ; Bin Gao ;
> Pranav Tipnis ; Heikki Krogerus
> ; linux-kernel@vger.kernel.org; linux-
> u...@vger.kernel.org; Guenter Roeck 
> Subject: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)
> 
...
> diff --git a/include/linux/usb/pd.h b/include/linux/usb/pd.h
> new file mode 100644
> index ..6b1679af7a25
> --- /dev/null
> +++ b/include/linux/usb/pd.h

...

> +#define PDO_VAR(min_mv, max_mv, max_ma)  
> \
> + ((PDO_TYPE_VAR << PDO_TYPE_SHIFT) | \
> +  min_mv) / 50) & PDO_VAR_MIN_VOLT_MASK) <<  \
> +   PDO_VAR_MIN_VOLT_SHIFT) | \
> +  max_mv) / 50) & PDO_VAR_MAX_VOLT_MASK) <<  \
> +   PDO_VAR_MAX_VOLT_SHIFT) | \
> +  max_ma) / 50) & PDO_VAR_MAX_CURR_MASK) <<  \

max_ma) / 10) & PDO_VAR_MAX_CURR_MASK) <<  \

Li Jun

RE: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

[Jun Li]

Hi Guenter,
> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Guenter Roeck
> Sent: Wednesday, August 24, 2016 5:11 AM
> To: Felipe Balbi 
> Cc: Chandra Sekhar Anagani ; Bruce
> Ashfield ; Bin Gao ;
> Pranav Tipnis ; Heikki Krogerus
> ; linux-kernel@vger.kernel.org; linux-
> u...@vger.kernel.org; Guenter Roeck 
> Subject: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)
> 
...
> diff --git a/include/linux/usb/pd.h b/include/linux/usb/pd.h
> new file mode 100644
> index ..6b1679af7a25
> --- /dev/null
> +++ b/include/linux/usb/pd.h

...

> +#define PDO_VAR(min_mv, max_mv, max_ma)  
> \
> + ((PDO_TYPE_VAR << PDO_TYPE_SHIFT) | \
> +  min_mv) / 50) & PDO_VAR_MIN_VOLT_MASK) <<  \
> +   PDO_VAR_MIN_VOLT_SHIFT) | \
> +  max_mv) / 50) & PDO_VAR_MAX_VOLT_MASK) <<  \
> +   PDO_VAR_MAX_VOLT_SHIFT) | \
> +  max_ma) / 50) & PDO_VAR_MAX_CURR_MASK) <<  \

max_ma) / 10) & PDO_VAR_MAX_CURR_MASK) <<  \

Li Jun

RE: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

[Jun Li]

Hi Guenter,

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Guenter Roeck
> Sent: Wednesday, August 24, 2016 5:11 AM
> To: Felipe Balbi 
> Cc: Chandra Sekhar Anagani ; Bruce
> Ashfield ; Bin Gao ;
> Pranav Tipnis ; Heikki Krogerus
> ; linux-kernel@vger.kernel.org; linux-
> u...@vger.kernel.org; Guenter Roeck 
> Subject: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)
> 
> This driver implements the USB Type-C Power Delivery state machine
> for both source and sink ports. Alternate mode support is not
> fully implemented.
> 
> The driver attaches to the USB Type-C class code implemented in
> the following patches.
> 
>   usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY
>   usb: USB Type-C connector class
> 
> This driver only implements the state machine. Lower level drivers are
> responsible for
> - Reporting VBUS status and activating VBUS
> - Setting CC lines and providing CC line status
> - Setting line polarity
> - Activating and deactivating VCONN
> - Setting the current limit
> - Activating and deactivating PD message transfers
> - Sending and receiving PD messages
> 
> The driver provides both a functional API as well as callbacks for
> lower level drivers.
> 
> Signed-off-by: Guenter Roeck 
> ---
> v3:
> - Improve TCPM state machine resiliency if there are spurious CC line
> changes
>   while the state machine is in a transient change (waiting for a timeout)
> - Update current limit after CC voltage level changes on a port which is
> not
>   PD capable.
> 
> v2:
> - Only update polarity if setting it was successful
>   If setting the CC line polarity in the driver was not successful,
>   don't update the internal polarity state.
> - All PD messages are little endian; convert to and from CPU endianness.
> - Avoid comparisons against NULL.
> - Use u8/u16/u32 instead of uint8_t/uint16_t/uint32_t consistently.
> - Callbacks into tcpm need to be lockless to avoid timing problems
>   in low level drivers.
> - Simplify callbacks; tcpm can request the current state of cc/vbus
>   when it is ready to use it.
> 
>  drivers/usb/typec/Kconfig  |7 +
>  drivers/usb/typec/Makefile |1 +
>  drivers/usb/typec/tcpm.c   | 3163
> 
>  drivers/usb/typec/tcpm.h   |  137 ++
>  include/linux/usb/pd.h |  282 
>  include/linux/usb/pd_bdo.h |   31 +
>  include/linux/usb/pd_vdo.h |  412 ++
>  7 files changed, 4033 insertions(+)
>  create mode 100644 drivers/usb/typec/tcpm.c
>  create mode 100644 drivers/usb/typec/tcpm.h
>  create mode 100644 include/linux/usb/pd.h
>  create mode 100644 include/linux/usb/pd_bdo.h
>  create mode 100644 include/linux/usb/pd_vdo.h
> 

...

> +
> +static void run_state_machine(struct tcpm_port *port)
> +{
> + int ret;
> +
> + port->enter_state = port->state;
> + switch (port->state) {
> + /* SRC states */
> + case SRC_UNATTACHED:
> + tcpm_swap_complete(port, -ENOTCONN);
> + tcpm_src_detach(port);
> + tcpm_set_cc(port, TYPEC_CC_RP_DEF);
> + if (port->typec_caps.type == TYPEC_PORT_DRP)
> + tcpm_set_state(port, SNK_UNATTACHED, PD_T_DRP_SNK);

With this and below, after disconnect, the DRP port state machine will be
in infinite loop of state transition between SRC_UNATTACHED <--> SNK_UNATTACHED,
correct?

Li Jun
...

> + /* SNK states */
> + case SNK_UNATTACHED:
> + tcpm_swap_complete(port, -ENOTCONN);
> + tcpm_snk_detach(port);
> + tcpm_set_cc(port, TYPEC_CC_RD);
> + if (port->typec_caps.type == TYPEC_PORT_DRP)
> + tcpm_set_state(port, SRC_UNATTACHED, PD_T_DRP_SRC);
> + break;
> 

RE: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

[Jun Li]

Hi Guenter,

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Guenter Roeck
> Sent: Wednesday, August 24, 2016 5:11 AM
> To: Felipe Balbi 
> Cc: Chandra Sekhar Anagani ; Bruce
> Ashfield ; Bin Gao ;
> Pranav Tipnis ; Heikki Krogerus
> ; linux-kernel@vger.kernel.org; linux-
> u...@vger.kernel.org; Guenter Roeck 
> Subject: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)
> 
> This driver implements the USB Type-C Power Delivery state machine
> for both source and sink ports. Alternate mode support is not
> fully implemented.
> 
> The driver attaches to the USB Type-C class code implemented in
> the following patches.
> 
>   usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY
>   usb: USB Type-C connector class
> 
> This driver only implements the state machine. Lower level drivers are
> responsible for
> - Reporting VBUS status and activating VBUS
> - Setting CC lines and providing CC line status
> - Setting line polarity
> - Activating and deactivating VCONN
> - Setting the current limit
> - Activating and deactivating PD message transfers
> - Sending and receiving PD messages
> 
> The driver provides both a functional API as well as callbacks for
> lower level drivers.
> 
> Signed-off-by: Guenter Roeck 
> ---
> v3:
> - Improve TCPM state machine resiliency if there are spurious CC line
> changes
>   while the state machine is in a transient change (waiting for a timeout)
> - Update current limit after CC voltage level changes on a port which is
> not
>   PD capable.
> 
> v2:
> - Only update polarity if setting it was successful
>   If setting the CC line polarity in the driver was not successful,
>   don't update the internal polarity state.
> - All PD messages are little endian; convert to and from CPU endianness.
> - Avoid comparisons against NULL.
> - Use u8/u16/u32 instead of uint8_t/uint16_t/uint32_t consistently.
> - Callbacks into tcpm need to be lockless to avoid timing problems
>   in low level drivers.
> - Simplify callbacks; tcpm can request the current state of cc/vbus
>   when it is ready to use it.
> 
>  drivers/usb/typec/Kconfig  |7 +
>  drivers/usb/typec/Makefile |1 +
>  drivers/usb/typec/tcpm.c   | 3163
> 
>  drivers/usb/typec/tcpm.h   |  137 ++
>  include/linux/usb/pd.h |  282 
>  include/linux/usb/pd_bdo.h |   31 +
>  include/linux/usb/pd_vdo.h |  412 ++
>  7 files changed, 4033 insertions(+)
>  create mode 100644 drivers/usb/typec/tcpm.c
>  create mode 100644 drivers/usb/typec/tcpm.h
>  create mode 100644 include/linux/usb/pd.h
>  create mode 100644 include/linux/usb/pd_bdo.h
>  create mode 100644 include/linux/usb/pd_vdo.h
> 

...

> +
> +static void run_state_machine(struct tcpm_port *port)
> +{
> + int ret;
> +
> + port->enter_state = port->state;
> + switch (port->state) {
> + /* SRC states */
> + case SRC_UNATTACHED:
> + tcpm_swap_complete(port, -ENOTCONN);
> + tcpm_src_detach(port);
> + tcpm_set_cc(port, TYPEC_CC_RP_DEF);
> + if (port->typec_caps.type == TYPEC_PORT_DRP)
> + tcpm_set_state(port, SNK_UNATTACHED, PD_T_DRP_SNK);

With this and below, after disconnect, the DRP port state machine will be
in infinite loop of state transition between SRC_UNATTACHED <--> SNK_UNATTACHED,
correct?

Li Jun
...

> + /* SNK states */
> + case SNK_UNATTACHED:
> + tcpm_swap_complete(port, -ENOTCONN);
> + tcpm_snk_detach(port);
> + tcpm_set_cc(port, TYPEC_CC_RD);
> + if (port->typec_caps.type == TYPEC_PORT_DRP)
> + tcpm_set_state(port, SRC_UNATTACHED, PD_T_DRP_SRC);
> + break;
> 

RE: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

[Jun Li]

Hi Guenter

> -Original Message-
> From: Guenter Roeck [mailto:gro...@google.com]
> Sent: Saturday, September 10, 2016 10:23 AM
> To: Jun Li <jun...@nxp.com>
> Cc: Guenter Roeck <gro...@chromium.org>; Felipe Balbi
> <felipe.ba...@linux.intel.com>; Chandra Sekhar Anagani
> <chandra.sekhar.anag...@intel.com>; Bruce Ashfield
> <bruce.ashfi...@windriver.com>; Bin Gao <bin@intel.com>; Pranav Tipnis
> <pranav.tip...@intel.com>; Heikki Krogerus
> <heikki.kroge...@linux.intel.com>; linux-kernel@vger.kernel.org; linux-
> u...@vger.kernel.org
> Subject: Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)
> 
> On Fri, Sep 9, 2016 at 5:26 PM, Jun Li <jun...@nxp.com> wrote:
> > Hi Guenter,
> >
> >> -Original Message-
> >> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> >> ow...@vger.kernel.org] On Behalf Of Guenter Roeck
> >> Sent: Wednesday, August 24, 2016 5:11 AM
> >> To: Felipe Balbi <felipe.ba...@linux.intel.com>
> >> Cc: Chandra Sekhar Anagani <chandra.sekhar.anag...@intel.com>; Bruce
> >> Ashfield <bruce.ashfi...@windriver.com>; Bin Gao <bin@intel.com>;
> >> Pranav Tipnis <pranav.tip...@intel.com>; Heikki Krogerus
> >> <heikki.kroge...@linux.intel.com>; linux-kernel@vger.kernel.org;
> >> linux- u...@vger.kernel.org; Guenter Roeck <gro...@chromium.org>
> >> Subject: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager
> >> (tcpm)
> >>
> >> This driver implements the USB Type-C Power Delivery state machine
> >> for both source and sink ports. Alternate mode support is not fully
> >> implemented.
> >>
> >> The driver attaches to the USB Type-C class code implemented in the
> >> following patches.
> >>
> >>   usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY
> >>   usb: USB Type-C connector class
> >>
> >> This driver only implements the state machine. Lower level drivers
> >> are responsible for
> >> - Reporting VBUS status and activating VBUS
> >> - Setting CC lines and providing CC line status
> >> - Setting line polarity
> >> - Activating and deactivating VCONN
> >> - Setting the current limit
> >> - Activating and deactivating PD message transfers
> >> - Sending and receiving PD messages
> >>
> >> The driver provides both a functional API as well as callbacks for
> >> lower level drivers.
> >>
> >> Signed-off-by: Guenter Roeck <gro...@chromium.org>
> >> ---
> >
> > A specific question, if power sink wants to request a new power level
> > after SNK_READY, how to handle it with this tcpm?
> >
> 
> So far I have considered the required power level to be static, based on
> our curent implementations. That should be easy to change, though, with an
> additional API function, to be called from a low level driver.
> Do you have that requirement, and would such a function meet your needs ?
> 

So you are going to make port->tcpc->config to be dynamic to meet my need?

Li Jun
 
> Thanks,
> Guenter

RE: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

[Jun Li]

Hi Guenter

> -Original Message-
> From: Guenter Roeck [mailto:gro...@google.com]
> Sent: Saturday, September 10, 2016 10:23 AM
> To: Jun Li 
> Cc: Guenter Roeck ; Felipe Balbi
> ; Chandra Sekhar Anagani
> ; Bruce Ashfield
> ; Bin Gao ; Pranav Tipnis
> ; Heikki Krogerus
> ; linux-kernel@vger.kernel.org; linux-
> u...@vger.kernel.org
> Subject: Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)
> 
> On Fri, Sep 9, 2016 at 5:26 PM, Jun Li  wrote:
> > Hi Guenter,
> >
> >> -Original Message-
> >> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> >> ow...@vger.kernel.org] On Behalf Of Guenter Roeck
> >> Sent: Wednesday, August 24, 2016 5:11 AM
> >> To: Felipe Balbi 
> >> Cc: Chandra Sekhar Anagani ; Bruce
> >> Ashfield ; Bin Gao ;
> >> Pranav Tipnis ; Heikki Krogerus
> >> ; linux-kernel@vger.kernel.org;
> >> linux- u...@vger.kernel.org; Guenter Roeck 
> >> Subject: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager
> >> (tcpm)
> >>
> >> This driver implements the USB Type-C Power Delivery state machine
> >> for both source and sink ports. Alternate mode support is not fully
> >> implemented.
> >>
> >> The driver attaches to the USB Type-C class code implemented in the
> >> following patches.
> >>
> >>   usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY
> >>   usb: USB Type-C connector class
> >>
> >> This driver only implements the state machine. Lower level drivers
> >> are responsible for
> >> - Reporting VBUS status and activating VBUS
> >> - Setting CC lines and providing CC line status
> >> - Setting line polarity
> >> - Activating and deactivating VCONN
> >> - Setting the current limit
> >> - Activating and deactivating PD message transfers
> >> - Sending and receiving PD messages
> >>
> >> The driver provides both a functional API as well as callbacks for
> >> lower level drivers.
> >>
> >> Signed-off-by: Guenter Roeck 
> >> ---
> >
> > A specific question, if power sink wants to request a new power level
> > after SNK_READY, how to handle it with this tcpm?
> >
> 
> So far I have considered the required power level to be static, based on
> our curent implementations. That should be easy to change, though, with an
> additional API function, to be called from a low level driver.
> Do you have that requirement, and would such a function meet your needs ?
> 

So you are going to make port->tcpc->config to be dynamic to meet my need?

Li Jun
 
> Thanks,
> Guenter

RE: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

[Jun Li]

> -Original Message-
> From: Guenter Roeck [mailto:gro...@google.com]
> Sent: Monday, September 12, 2016 10:24 AM
> To: Jun Li <jun...@nxp.com>
> Cc: Guenter Roeck <gro...@chromium.org>; Felipe Balbi
> <felipe.ba...@linux.intel.com>; Chandra Sekhar Anagani
> <chandra.sekhar.anag...@intel.com>; Bruce Ashfield
> <bruce.ashfi...@windriver.com>; Bin Gao <bin@intel.com>; Pranav Tipnis
> <pranav.tip...@intel.com>; Heikki Krogerus
> <heikki.kroge...@linux.intel.com>; linux-kernel@vger.kernel.org; linux-
> u...@vger.kernel.org
> Subject: Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)
> 
> On Sun, Sep 11, 2016 at 7:16 PM, Jun Li <jun...@nxp.com> wrote:
> > Hi Guenter
> >
> >> -Original Message-----
> >> From: Guenter Roeck [mailto:gro...@google.com]
> >> Sent: Saturday, September 10, 2016 10:23 AM
> >> To: Jun Li <jun...@nxp.com>
> >> Cc: Guenter Roeck <gro...@chromium.org>; Felipe Balbi
> >> <felipe.ba...@linux.intel.com>; Chandra Sekhar Anagani
> >> <chandra.sekhar.anag...@intel.com>; Bruce Ashfield
> >> <bruce.ashfi...@windriver.com>; Bin Gao <bin@intel.com>; Pranav
> >> Tipnis <pranav.tip...@intel.com>; Heikki Krogerus
> >> <heikki.kroge...@linux.intel.com>; linux-kernel@vger.kernel.org;
> >> linux- u...@vger.kernel.org
> >> Subject: Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager
> >> (tcpm)
> >>
> >> On Fri, Sep 9, 2016 at 5:26 PM, Jun Li <jun...@nxp.com> wrote:
> >> > Hi Guenter,
> >> >
> >> >> -Original Message-
> >> >> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> >> >> ow...@vger.kernel.org] On Behalf Of Guenter Roeck
> >> >> Sent: Wednesday, August 24, 2016 5:11 AM
> >> >> To: Felipe Balbi <felipe.ba...@linux.intel.com>
> >> >> Cc: Chandra Sekhar Anagani <chandra.sekhar.anag...@intel.com>;
> >> >> Bruce Ashfield <bruce.ashfi...@windriver.com>; Bin Gao
> >> >> <bin@intel.com>; Pranav Tipnis <pranav.tip...@intel.com>;
> >> >> Heikki Krogerus <heikki.kroge...@linux.intel.com>;
> >> >> linux-kernel@vger.kernel.org;
> >> >> linux- u...@vger.kernel.org; Guenter Roeck <gro...@chromium.org>
> >> >> Subject: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager
> >> >> (tcpm)
> >> >>
> >> >> This driver implements the USB Type-C Power Delivery state machine
> >> >> for both source and sink ports. Alternate mode support is not
> >> >> fully implemented.
> >> >>
> >> >> The driver attaches to the USB Type-C class code implemented in
> >> >> the following patches.
> >> >>
> >> >>   usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C
> PHY
> >> >>   usb: USB Type-C connector class
> >> >>
> >> >> This driver only implements the state machine. Lower level drivers
> >> >> are responsible for
> >> >> - Reporting VBUS status and activating VBUS
> >> >> - Setting CC lines and providing CC line status
> >> >> - Setting line polarity
> >> >> - Activating and deactivating VCONN
> >> >> - Setting the current limit
> >> >> - Activating and deactivating PD message transfers
> >> >> - Sending and receiving PD messages
> >> >>
> >> >> The driver provides both a functional API as well as callbacks for
> >> >> lower level drivers.
> >> >>
> >> >> Signed-off-by: Guenter Roeck <gro...@chromium.org>
> >> >> ---
> >> >
> >> > A specific question, if power sink wants to request a new power
> >> > level after SNK_READY, how to handle it with this tcpm?
> >> >
> >>
> >> So far I have considered the required power level to be static, based
> >> on our curent implementations. That should be easy to change, though,
> >> with an additional API function, to be called from a low level driver.
> >> Do you have that requirement, and would such a function meet your
> needs ?
> >>
> >
> > So you are going to make port->tcpc->config to be dynamic to meet my
> need?
> >
> What would that help ? How would tcpm get informed that the power
> requirements changed without an API function telling it that power
> requirements changed ?

Of cos I agree an additional API is required, I am just wondering how
that API will be look like, as current request build is according to
port->tcpc->config.

Li Jun  
> 
> Guenter

RE: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

[Jun Li]

> -Original Message-
> From: Guenter Roeck [mailto:gro...@google.com]
> Sent: Monday, September 12, 2016 10:24 AM
> To: Jun Li 
> Cc: Guenter Roeck ; Felipe Balbi
> ; Chandra Sekhar Anagani
> ; Bruce Ashfield
> ; Bin Gao ; Pranav Tipnis
> ; Heikki Krogerus
> ; linux-kernel@vger.kernel.org; linux-
> u...@vger.kernel.org
> Subject: Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)
> 
> On Sun, Sep 11, 2016 at 7:16 PM, Jun Li  wrote:
> > Hi Guenter
> >
> >> -Original Message-
> >> From: Guenter Roeck [mailto:gro...@google.com]
> >> Sent: Saturday, September 10, 2016 10:23 AM
> >> To: Jun Li 
> >> Cc: Guenter Roeck ; Felipe Balbi
> >> ; Chandra Sekhar Anagani
> >> ; Bruce Ashfield
> >> ; Bin Gao ; Pranav
> >> Tipnis ; Heikki Krogerus
> >> ; linux-kernel@vger.kernel.org;
> >> linux- u...@vger.kernel.org
> >> Subject: Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager
> >> (tcpm)
> >>
> >> On Fri, Sep 9, 2016 at 5:26 PM, Jun Li  wrote:
> >> > Hi Guenter,
> >> >
> >> >> -Original Message-
> >> >> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> >> >> ow...@vger.kernel.org] On Behalf Of Guenter Roeck
> >> >> Sent: Wednesday, August 24, 2016 5:11 AM
> >> >> To: Felipe Balbi 
> >> >> Cc: Chandra Sekhar Anagani ;
> >> >> Bruce Ashfield ; Bin Gao
> >> >> ; Pranav Tipnis ;
> >> >> Heikki Krogerus ;
> >> >> linux-kernel@vger.kernel.org;
> >> >> linux- u...@vger.kernel.org; Guenter Roeck 
> >> >> Subject: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager
> >> >> (tcpm)
> >> >>
> >> >> This driver implements the USB Type-C Power Delivery state machine
> >> >> for both source and sink ports. Alternate mode support is not
> >> >> fully implemented.
> >> >>
> >> >> The driver attaches to the USB Type-C class code implemented in
> >> >> the following patches.
> >> >>
> >> >>   usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C
> PHY
> >> >>   usb: USB Type-C connector class
> >> >>
> >> >> This driver only implements the state machine. Lower level drivers
> >> >> are responsible for
> >> >> - Reporting VBUS status and activating VBUS
> >> >> - Setting CC lines and providing CC line status
> >> >> - Setting line polarity
> >> >> - Activating and deactivating VCONN
> >> >> - Setting the current limit
> >> >> - Activating and deactivating PD message transfers
> >> >> - Sending and receiving PD messages
> >> >>
> >> >> The driver provides both a functional API as well as callbacks for
> >> >> lower level drivers.
> >> >>
> >> >> Signed-off-by: Guenter Roeck 
> >> >> ---
> >> >
> >> > A specific question, if power sink wants to request a new power
> >> > level after SNK_READY, how to handle it with this tcpm?
> >> >
> >>
> >> So far I have considered the required power level to be static, based
> >> on our curent implementations. That should be easy to change, though,
> >> with an additional API function, to be called from a low level driver.
> >> Do you have that requirement, and would such a function meet your
> needs ?
> >>
> >
> > So you are going to make port->tcpc->config to be dynamic to meet my
> need?
> >
> What would that help ? How would tcpm get informed that the power
> requirements changed without an API function telling it that power
> requirements changed ?

Of cos I agree an additional API is required, I am just wondering how
that API will be look like, as current request build is according to
port->tcpc->config.

Li Jun  
> 
> Guenter

RE: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

[Jun Li]

Hi Guenter,

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Guenter Roeck
> Sent: Wednesday, August 24, 2016 5:11 AM
> To: Felipe Balbi 
> Cc: Chandra Sekhar Anagani ; Bruce
> Ashfield ; Bin Gao ;
> Pranav Tipnis ; Heikki Krogerus
> ; linux-kernel@vger.kernel.org; linux-
> u...@vger.kernel.org; Guenter Roeck 
> Subject: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)
> 
> This driver implements the USB Type-C Power Delivery state machine
> for both source and sink ports. Alternate mode support is not
> fully implemented.
> 
> The driver attaches to the USB Type-C class code implemented in
> the following patches.
> 
>   usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY
>   usb: USB Type-C connector class
> 
> This driver only implements the state machine. Lower level drivers are
> responsible for
> - Reporting VBUS status and activating VBUS
> - Setting CC lines and providing CC line status
> - Setting line polarity
> - Activating and deactivating VCONN
> - Setting the current limit
> - Activating and deactivating PD message transfers
> - Sending and receiving PD messages
> 
> The driver provides both a functional API as well as callbacks for
> lower level drivers.
> 
> Signed-off-by: Guenter Roeck 
> ---

A specific question, if power sink wants to request a new power level
after SNK_READY, how to handle it with this tcpm?

Thanks
Li Jun

RE: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

[Jun Li]

Hi Guenter,

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Guenter Roeck
> Sent: Wednesday, August 24, 2016 5:11 AM
> To: Felipe Balbi 
> Cc: Chandra Sekhar Anagani ; Bruce
> Ashfield ; Bin Gao ;
> Pranav Tipnis ; Heikki Krogerus
> ; linux-kernel@vger.kernel.org; linux-
> u...@vger.kernel.org; Guenter Roeck 
> Subject: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)
> 
> This driver implements the USB Type-C Power Delivery state machine
> for both source and sink ports. Alternate mode support is not
> fully implemented.
> 
> The driver attaches to the USB Type-C class code implemented in
> the following patches.
> 
>   usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY
>   usb: USB Type-C connector class
> 
> This driver only implements the state machine. Lower level drivers are
> responsible for
> - Reporting VBUS status and activating VBUS
> - Setting CC lines and providing CC line status
> - Setting line polarity
> - Activating and deactivating VCONN
> - Setting the current limit
> - Activating and deactivating PD message transfers
> - Sending and receiving PD messages
> 
> The driver provides both a functional API as well as callbacks for
> lower level drivers.
> 
> Signed-off-by: Guenter Roeck 
> ---

A specific question, if power sink wants to request a new power level
after SNK_READY, how to handle it with this tcpm?

Thanks
Li Jun

RE: [PATCH v5 5/6] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node

[Jun Li]

Hi, Peter

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Peter Chen
> Sent: Wednesday, August 10, 2016 11:12 AM
> To: Stephen Boyd 
> Cc: Peter Chen ; gre...@linuxfoundation.org;
> st...@rowland.harvard.edu; ulf.hans...@linaro.org; broo...@kernel.org;
> s...@kernel.org; robh...@kernel.org; shawn...@kernel.org;
> dbarysh...@gmail.com; dw...@infradead.org; k.kozlow...@samsung.com; linux-
> arm-ker...@lists.infradead.org; p.za...@pengutronix.de;
> devicet...@vger.kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
> linux-...@vger.kernel.org; a...@arndb.de; s.ha...@pengutronix.de;
> m...@maciej.szmigiero.name; troy.ki...@boundarydevices.com;
> feste...@gmail.com; os...@naiandei.net; linux...@vger.kernel.org;
> stillcompil...@gmail.com; linux-kernel@vger.kernel.org; m...@chromium.org;
> Peter Chen 
> Subject: Re: [PATCH v5 5/6] usb: chipidea: let chipidea core device
> of_node equal's glue layer device of_node
> 
> On Tue, Aug 09, 2016 at 05:15:36PM -0700, Stephen Boyd wrote:
> > Quoting Peter Chen (2016-08-08 01:52:10)
> > > From: Peter Chen 
> > >
> > > At device tree, we have no device node for chipidea core, the glue
> > > layer's node is the parent node for host and udc device. But in
> > > related driver, the parent device is chipidea core. So, in order to
> > > let the common driver get parent's node, we let the core's device
> > > node equals glue layer device node.
> > >
> > > Signed-off-by: Peter Chen 
> > > Tested-by: Maciej S. Szmigiero 
> > > Tested-by Joshua Clayton 
> > > ---
> > >  drivers/usb/chipidea/core.c | 11 +++
> > >  1 file changed, 11 insertions(+)
> > >
> > > diff --git a/drivers/usb/chipidea/core.c
> > > b/drivers/usb/chipidea/core.c index 69426e6..b189dc7 100644
> > > --- a/drivers/usb/chipidea/core.c
> > > +++ b/drivers/usb/chipidea/core.c
> > > @@ -954,6 +954,15 @@ static int ci_hdrc_probe(struct platform_device
> *pdev)
> > > dev_err(dev, "unable to init phy: %d\n", ret);
> > > return ret;
> > > }
> > > +   /*
> > > +* At device tree, we have no device node for chipidea core,
> > > +* the glue layer's node is the parent node for host and udc
> > > +* device. But in related driver, the parent device is
> chipidea
> > > +* core. So, in order to let the common driver get parent's
> node,
> > > +* we let the core's device node equals glue layer's node.
> > > +*/
> > > +   if (dev->parent && dev->parent->of_node)
> > > +   dev->of_node = dev->parent->of_node;
> >
> > Can this be done earlier? Perhaps after hw_device_init() in this probe
> > routine? That would allow me to remove the awkward parent searching in
> > my ULPI DT awareness patch.
> 
> The reason why I locate it there is to avoid "goto label" for error path
> during PHY's get and initialization operation.
> 
> Ok, to simplify your work, I will change it at next version.

As iommu need this to be done even more earlier, will you consider to
put it before adding the core's platform device?

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

RE: [PATCH v5 5/6] usb: chipidea: let chipidea core device of_node equal's glue layer device of_node

[Jun Li]

Hi, Peter

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Peter Chen
> Sent: Wednesday, August 10, 2016 11:12 AM
> To: Stephen Boyd 
> Cc: Peter Chen ; gre...@linuxfoundation.org;
> st...@rowland.harvard.edu; ulf.hans...@linaro.org; broo...@kernel.org;
> s...@kernel.org; robh...@kernel.org; shawn...@kernel.org;
> dbarysh...@gmail.com; dw...@infradead.org; k.kozlow...@samsung.com; linux-
> arm-ker...@lists.infradead.org; p.za...@pengutronix.de;
> devicet...@vger.kernel.org; pawel.m...@arm.com; mark.rutl...@arm.com;
> linux-...@vger.kernel.org; a...@arndb.de; s.ha...@pengutronix.de;
> m...@maciej.szmigiero.name; troy.ki...@boundarydevices.com;
> feste...@gmail.com; os...@naiandei.net; linux...@vger.kernel.org;
> stillcompil...@gmail.com; linux-kernel@vger.kernel.org; m...@chromium.org;
> Peter Chen 
> Subject: Re: [PATCH v5 5/6] usb: chipidea: let chipidea core device
> of_node equal's glue layer device of_node
> 
> On Tue, Aug 09, 2016 at 05:15:36PM -0700, Stephen Boyd wrote:
> > Quoting Peter Chen (2016-08-08 01:52:10)
> > > From: Peter Chen 
> > >
> > > At device tree, we have no device node for chipidea core, the glue
> > > layer's node is the parent node for host and udc device. But in
> > > related driver, the parent device is chipidea core. So, in order to
> > > let the common driver get parent's node, we let the core's device
> > > node equals glue layer device node.
> > >
> > > Signed-off-by: Peter Chen 
> > > Tested-by: Maciej S. Szmigiero 
> > > Tested-by Joshua Clayton 
> > > ---
> > >  drivers/usb/chipidea/core.c | 11 +++
> > >  1 file changed, 11 insertions(+)
> > >
> > > diff --git a/drivers/usb/chipidea/core.c
> > > b/drivers/usb/chipidea/core.c index 69426e6..b189dc7 100644
> > > --- a/drivers/usb/chipidea/core.c
> > > +++ b/drivers/usb/chipidea/core.c
> > > @@ -954,6 +954,15 @@ static int ci_hdrc_probe(struct platform_device
> *pdev)
> > > dev_err(dev, "unable to init phy: %d\n", ret);
> > > return ret;
> > > }
> > > +   /*
> > > +* At device tree, we have no device node for chipidea core,
> > > +* the glue layer's node is the parent node for host and udc
> > > +* device. But in related driver, the parent device is
> chipidea
> > > +* core. So, in order to let the common driver get parent's
> node,
> > > +* we let the core's device node equals glue layer's node.
> > > +*/
> > > +   if (dev->parent && dev->parent->of_node)
> > > +   dev->of_node = dev->parent->of_node;
> >
> > Can this be done earlier? Perhaps after hw_device_init() in this probe
> > routine? That would allow me to remove the awkward parent searching in
> > my ULPI DT awareness patch.
> 
> The reason why I locate it there is to avoid "goto label" for error path
> during PHY's get and initialization operation.
> 
> Ok, to simplify your work, I will change it at next version.

As iommu need this to be done even more earlier, will you consider to
put it before adding the core's platform device?

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

RE: [PATCH 08/21] usb: chipidea: Kick OTG state machine for AVVIS with vbus extcon

[Jun Li]

Hi Stephen,

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Peter Chen
> Sent: Thursday, June 30, 2016 9:27 AM
> To: Stephen Boyd 
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; linux-arm-...@vger.kernel.org; Andy Gross
> ; Bjorn Andersson ;
> Neil Armstrong ; Arnd Bergmann ;
> Felipe Balbi ; Peter Chen ; Greg
> Kroah-Hartman 
> Subject: Re: [PATCH 08/21] usb: chipidea: Kick OTG state machine for AVVIS
> with vbus extcon
> 
> On Wed, Jun 29, 2016 at 06:19:59PM -0700, Stephen Boyd wrote:
> > Quoting Peter Chen (2016-06-28 20:09:13)
> > > On Sun, Jun 26, 2016 at 12:28:25AM -0700, Stephen Boyd wrote:
> > > > Force the OTG state machine to go forward when we're using an
> > > > extcon for vbus detection. In this case, the controller may never
> > > > raise an interrupt for AVVIS, so we need to simulate the event by
> > > > toggling the appropriate OTG fsm bits and kicking the state
> > > > machine again.
> > > >
> > >
> > > Well, I think you may misunderstand the OTG FSM and dual-role.
> > > From my and Felipe's point, there are seldom users for USB FSM,
> > > there are only OTG FSM spec and related OTG certification.
> >
> > Probably yes.
> >
> > >
> > > The OTG FSM needs related SoC support, the vbus will be off at
> > > several states, and the SRP should be supported by SoC.
> > >
> > > By default, the dts needs below properties for disabling it if you
> > > choose otg fsm support at kernel configuration.
> > >
> > >  {
> > > vbus-supply = <_usb_otg1_vbus>;
> > > srp-disable;
> > > hnp-disable;
> > > adp-disable;
> > > status = "okay";
> > > };
> > >
> > > See Documentation/devicetree/bindings/usb/generic.txt.
> >
> > Does this mean we should be setting all those properties if we're
> > using an extcon for vbus and id?
> 
> It is not related to how we know vbus and id. If your controller is otg-
> capable, and you don't want to enable OTG FSM (just want dual-role), you
> should set them at dts since the zImage is multi-platforms, the
> CONFIG_USB_OTG and CONFIG_USB_OTG_FSM may be chosen.
> 
> > I have noticed that vbus is powered off after some time when no device
> > is connected and we're in A_HOST state because the timeout for a B
> > device connection happens.
> 
> I think it is not you want, but it is OTG compliance.

For simple, if you don't want OTG(i.e HNP) at all, just needs
dual role, you may disable CONFIG_USB_OTG and CONFIG_USB_OTG_FSM
in your menuconfig, then you don't need touch all those properties.

Li Jun

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

RE: [PATCH 08/21] usb: chipidea: Kick OTG state machine for AVVIS with vbus extcon

[Jun Li]

Hi Stephen,

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Peter Chen
> Sent: Thursday, June 30, 2016 9:27 AM
> To: Stephen Boyd 
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> linux-kernel@vger.kernel.org; linux-arm-...@vger.kernel.org; Andy Gross
> ; Bjorn Andersson ;
> Neil Armstrong ; Arnd Bergmann ;
> Felipe Balbi ; Peter Chen ; Greg
> Kroah-Hartman 
> Subject: Re: [PATCH 08/21] usb: chipidea: Kick OTG state machine for AVVIS
> with vbus extcon
> 
> On Wed, Jun 29, 2016 at 06:19:59PM -0700, Stephen Boyd wrote:
> > Quoting Peter Chen (2016-06-28 20:09:13)
> > > On Sun, Jun 26, 2016 at 12:28:25AM -0700, Stephen Boyd wrote:
> > > > Force the OTG state machine to go forward when we're using an
> > > > extcon for vbus detection. In this case, the controller may never
> > > > raise an interrupt for AVVIS, so we need to simulate the event by
> > > > toggling the appropriate OTG fsm bits and kicking the state
> > > > machine again.
> > > >
> > >
> > > Well, I think you may misunderstand the OTG FSM and dual-role.
> > > From my and Felipe's point, there are seldom users for USB FSM,
> > > there are only OTG FSM spec and related OTG certification.
> >
> > Probably yes.
> >
> > >
> > > The OTG FSM needs related SoC support, the vbus will be off at
> > > several states, and the SRP should be supported by SoC.
> > >
> > > By default, the dts needs below properties for disabling it if you
> > > choose otg fsm support at kernel configuration.
> > >
> > >  {
> > > vbus-supply = <_usb_otg1_vbus>;
> > > srp-disable;
> > > hnp-disable;
> > > adp-disable;
> > > status = "okay";
> > > };
> > >
> > > See Documentation/devicetree/bindings/usb/generic.txt.
> >
> > Does this mean we should be setting all those properties if we're
> > using an extcon for vbus and id?
> 
> It is not related to how we know vbus and id. If your controller is otg-
> capable, and you don't want to enable OTG FSM (just want dual-role), you
> should set them at dts since the zImage is multi-platforms, the
> CONFIG_USB_OTG and CONFIG_USB_OTG_FSM may be chosen.
> 
> > I have noticed that vbus is powered off after some time when no device
> > is connected and we're in A_HOST state because the timeout for a B
> > device connection happens.
> 
> I think it is not you want, but it is OTG compliance.

For simple, if you don't want OTG(i.e HNP) at all, just needs
dual role, you may disable CONFIG_USB_OTG and CONFIG_USB_OTG_FSM
in your menuconfig, then you don't need touch all those properties.

Li Jun

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

RE: [PATCH] usb: otg-fsm: Cancel HNP polling work when not used

[Jun Li]

Hi

> -Original Message-
> From: Peter Chen [mailto:hzpeterc...@gmail.com]
> Sent: Wednesday, June 29, 2016 5:44 PM
> To: Stephen Boyd <stephen.b...@linaro.org>
> Cc: Peter Chen <peter.c...@nxp.com>; Felipe Balbi <ba...@kernel.org>;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> u...@vger.kernel.org; Jun Li <jun...@nxp.com>; Greg Kroah-Hartman
> <gre...@linuxfoundation.org>
> Subject: Re: [PATCH] usb: otg-fsm: Cancel HNP polling work when not used
> 
> On Mon, Jun 27, 2016 at 06:18:27PM -0700, Stephen Boyd wrote:
> > We setup the HNP polling worker, but we never stop it. The OTG state
> > machine can go round and round and keep reinitializing the worker even
> > while it's actively running. That's bad, and debug objects catches it.
> > Fix this by canceling the work when we leave the A_HOST or B_HOST
> > states.
> >
> > [otg_set_state]  Set state: a_wait_bcon usb 2-1: USB disconnect,
> > device number 2 [otg_statemachine]  quit statemachine, changed = 1
> > [otg_set_state]  Set state: a_host 
> > [otg_statemachine]  quit statemachine, changed = 1 usb 2-1: new
> > low-speed USB device number 3 using ci_hdrc usb 2-1: New USB device
> > found, idVendor=03f0, idProduct=134a usb 2-1: New USB device strings:
> > Mfr=1, Product=2, SerialNumber=0 usb 2-1: Product: HP USB Optical
> > Mouse usb 2-1: Manufacturer: PixArt
> > input: PixArt HP USB Optical Mouse as
> > /devices/platform/soc/f9a55000.usb/ci_hdrc.0/usb2/2-1/2-1:1.0/0003:03F
> > 0:134A.0002/input/input1 hid-generic 0003:03F0:134A.0002: input: USB
> > HID v1.11 Mouse [PixArt HP USB Optical Mouse] on
> > usb-ci_hdrc.0-1/input0 [otg_set_state]  Set state: a_wait_bcon usb
> > 2-1: USB disconnect, device number 3 [otg_statemachine]  quit
> > statemachine, changed = 1 [otg_set_state]  Set state: a_host  > Polling started> [ cut here ]
> > WARNING: CPU: 2 PID: 95 at lib/debugobjects.c:263
> > debug_print_object+0x98/0xc0
> > ODEBUG: init active (active state 0) object type: timer_list hint:
> > delayed_work_timer_fn+0x0/0x2c Modules linked in: phy_qcom_usb_hsic
> > phy_qcom_usb_hs ci_hdrc_msm ci_hdrc
> > CPU: 2 PID: 95 Comm: kworker/u8:1 Not tainted
> > 4.7.0-rc1-00043-g1f22f3b65c44-dirty #442 Hardware name: Qualcomm
> > (Flattened Device Tree)
> > Workqueue: ci_otg ci_otg_work [ci_hdrc] []
> > (unwind_backtrace) from [] (show_stack+0x20/0x24)
> > [] (show_stack) from [] (dump_stack+0x7c/0x9c)
> > [] (dump_stack) from [] (__warn+0xe4/0x110)
> > [] (__warn) from [] (warn_slowpath_fmt+0x48/0x50)
> > [] (warn_slowpath_fmt) from []
> > (debug_print_object+0x98/0xc0) [] (debug_print_object) from
> > [] (__debug_object_init+0xcc/0x3bc) []
> > (__debug_object_init) from [] (debug_object_init+0x24/0x2c)
> > [] (debug_object_init) from []
> > (init_timer_key+0x24/0x120) [] (init_timer_key) from
> > [] (otg_start_hnp_polling+0x7c/0xbc) []
> > (otg_start_hnp_polling) from [] (otg_set_state+0x740/0xc20)
> > [] (otg_set_state) from []
> > (otg_statemachine+0x47c/0x4ac) [] (otg_statemachine) from
> > [] (ci_otg_fsm_work+0x48/0x1a0 [ci_hdrc]) []
> > (ci_otg_fsm_work [ci_hdrc]) from [] (ci_otg_work+0xd4/0x218
> > [ci_hdrc]) [] (ci_otg_work [ci_hdrc]) from []
> > (process_one_work+0x154/0x4b4) [] (process_one_work) from
> > [] (worker_thread+0x38/0x4d0) [] (worker_thread)
> > from [] (kthread+0xe8/0x104) [] (kthread) from
> > [] (ret_from_fork+0x14/0x3c)
> >
> > Cc: Li Jun <jun...@nxp.com>
> > Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> > Fixes: ae57e97a9521 ("usb: common: otg-fsm: add HNP polling support")
> > Signed-off-by: Stephen Boyd <stephen.b...@linaro.org>
> > ---
> >  drivers/usb/common/usb-otg-fsm.c | 14 ++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/usb/common/usb-otg-fsm.c
> > b/drivers/usb/common/usb-otg-fsm.c
> > index 9059b7dc185e..73eec8c12235 100644
> > --- a/drivers/usb/common/usb-otg-fsm.c
> > +++ b/drivers/usb/common/usb-otg-fsm.c
> > @@ -61,6 +61,18 @@ static int otg_set_protocol(struct otg_fsm *fsm, int
> protocol)
> > return 0;
> >  }
> >
> > +static void otg_stop_hnp_polling(struct otg_fsm *fsm) {
> > +   /*
> > +* The memory of host_req_flag should be allocated by
> > +* controller driver, otherwise, hnp polling is not started.
> > +*/
> > +   if (!fsm->host_req_flag)
> > +   return;
> > +
> > +   cancel_delayed_work_sync(>hnp_polling_work);
>

RE: [PATCH] usb: otg-fsm: Cancel HNP polling work when not used

[Jun Li]

Hi

> -Original Message-
> From: Peter Chen [mailto:hzpeterc...@gmail.com]
> Sent: Wednesday, June 29, 2016 5:44 PM
> To: Stephen Boyd 
> Cc: Peter Chen ; Felipe Balbi ;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> u...@vger.kernel.org; Jun Li ; Greg Kroah-Hartman
> 
> Subject: Re: [PATCH] usb: otg-fsm: Cancel HNP polling work when not used
> 
> On Mon, Jun 27, 2016 at 06:18:27PM -0700, Stephen Boyd wrote:
> > We setup the HNP polling worker, but we never stop it. The OTG state
> > machine can go round and round and keep reinitializing the worker even
> > while it's actively running. That's bad, and debug objects catches it.
> > Fix this by canceling the work when we leave the A_HOST or B_HOST
> > states.
> >
> > [otg_set_state]  Set state: a_wait_bcon usb 2-1: USB disconnect,
> > device number 2 [otg_statemachine]  quit statemachine, changed = 1
> > [otg_set_state]  Set state: a_host 
> > [otg_statemachine]  quit statemachine, changed = 1 usb 2-1: new
> > low-speed USB device number 3 using ci_hdrc usb 2-1: New USB device
> > found, idVendor=03f0, idProduct=134a usb 2-1: New USB device strings:
> > Mfr=1, Product=2, SerialNumber=0 usb 2-1: Product: HP USB Optical
> > Mouse usb 2-1: Manufacturer: PixArt
> > input: PixArt HP USB Optical Mouse as
> > /devices/platform/soc/f9a55000.usb/ci_hdrc.0/usb2/2-1/2-1:1.0/0003:03F
> > 0:134A.0002/input/input1 hid-generic 0003:03F0:134A.0002: input: USB
> > HID v1.11 Mouse [PixArt HP USB Optical Mouse] on
> > usb-ci_hdrc.0-1/input0 [otg_set_state]  Set state: a_wait_bcon usb
> > 2-1: USB disconnect, device number 3 [otg_statemachine]  quit
> > statemachine, changed = 1 [otg_set_state]  Set state: a_host  > Polling started> [ cut here ]
> > WARNING: CPU: 2 PID: 95 at lib/debugobjects.c:263
> > debug_print_object+0x98/0xc0
> > ODEBUG: init active (active state 0) object type: timer_list hint:
> > delayed_work_timer_fn+0x0/0x2c Modules linked in: phy_qcom_usb_hsic
> > phy_qcom_usb_hs ci_hdrc_msm ci_hdrc
> > CPU: 2 PID: 95 Comm: kworker/u8:1 Not tainted
> > 4.7.0-rc1-00043-g1f22f3b65c44-dirty #442 Hardware name: Qualcomm
> > (Flattened Device Tree)
> > Workqueue: ci_otg ci_otg_work [ci_hdrc] []
> > (unwind_backtrace) from [] (show_stack+0x20/0x24)
> > [] (show_stack) from [] (dump_stack+0x7c/0x9c)
> > [] (dump_stack) from [] (__warn+0xe4/0x110)
> > [] (__warn) from [] (warn_slowpath_fmt+0x48/0x50)
> > [] (warn_slowpath_fmt) from []
> > (debug_print_object+0x98/0xc0) [] (debug_print_object) from
> > [] (__debug_object_init+0xcc/0x3bc) []
> > (__debug_object_init) from [] (debug_object_init+0x24/0x2c)
> > [] (debug_object_init) from []
> > (init_timer_key+0x24/0x120) [] (init_timer_key) from
> > [] (otg_start_hnp_polling+0x7c/0xbc) []
> > (otg_start_hnp_polling) from [] (otg_set_state+0x740/0xc20)
> > [] (otg_set_state) from []
> > (otg_statemachine+0x47c/0x4ac) [] (otg_statemachine) from
> > [] (ci_otg_fsm_work+0x48/0x1a0 [ci_hdrc]) []
> > (ci_otg_fsm_work [ci_hdrc]) from [] (ci_otg_work+0xd4/0x218
> > [ci_hdrc]) [] (ci_otg_work [ci_hdrc]) from []
> > (process_one_work+0x154/0x4b4) [] (process_one_work) from
> > [] (worker_thread+0x38/0x4d0) [] (worker_thread)
> > from [] (kthread+0xe8/0x104) [] (kthread) from
> > [] (ret_from_fork+0x14/0x3c)
> >
> > Cc: Li Jun 
> > Cc: Greg Kroah-Hartman 
> > Fixes: ae57e97a9521 ("usb: common: otg-fsm: add HNP polling support")
> > Signed-off-by: Stephen Boyd 
> > ---
> >  drivers/usb/common/usb-otg-fsm.c | 14 ++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/drivers/usb/common/usb-otg-fsm.c
> > b/drivers/usb/common/usb-otg-fsm.c
> > index 9059b7dc185e..73eec8c12235 100644
> > --- a/drivers/usb/common/usb-otg-fsm.c
> > +++ b/drivers/usb/common/usb-otg-fsm.c
> > @@ -61,6 +61,18 @@ static int otg_set_protocol(struct otg_fsm *fsm, int
> protocol)
> > return 0;
> >  }
> >
> > +static void otg_stop_hnp_polling(struct otg_fsm *fsm) {
> > +   /*
> > +* The memory of host_req_flag should be allocated by
> > +* controller driver, otherwise, hnp polling is not started.
> > +*/
> > +   if (!fsm->host_req_flag)
> > +   return;
> > +
> > +   cancel_delayed_work_sync(>hnp_polling_work);
> > +}
> > +
> >  /* Called when leaving a state.  Do state clean up jobs here */
> > static void otg_leave_state(struct otg_fsm *fsm, enum usb_otg_state
> > old_state)  { @@ -84,6 +96,7 @

RE: [PATCH] usb: otg-fsm: Cancel HNP polling work when not used

[Jun Li]

Hi

> -Original Message-
> From: Stephen Boyd [mailto:stephen.b...@linaro.org]
> Sent: Tuesday, June 28, 2016 9:18 AM
> To: Peter Chen <peter.c...@nxp.com>; Felipe Balbi <ba...@kernel.org>
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> linux-...@vger.kernel.org; Jun Li <jun...@nxp.com>; Greg Kroah-Hartman
> <gre...@linuxfoundation.org>
> Subject: [PATCH] usb: otg-fsm: Cancel HNP polling work when not used
> 
> We setup the HNP polling worker, but we never stop it. The OTG state
> machine can go round and round and keep reinitializing the worker even
> while it's actively running. That's bad, and debug objects catches it. Fix
> this by canceling the work when we leave the A_HOST or B_HOST states.
> 

Normally we need not stop it because the scheduled delayed work will
be finished before next host entering, in your case there is another
host entering before the previous delayed work timeout, so we reinit
the active worker wrongly. Thanks for the required fix.

Acked-by: Li Jun <jun...@nxp.com>
 
> [otg_set_state]  Set state: a_wait_bcon
> usb 2-1: USB disconnect, device number 2 [otg_statemachine]  quit
> statemachine, changed = 1 [otg_set_state]  Set state: a_host  started> [otg_statemachine]  quit statemachine, changed = 1 usb 2-1: new
> low-speed USB device number 3 using ci_hdrc usb 2-1: New USB device found,
> idVendor=03f0, idProduct=134a usb 2-1: New USB device strings: Mfr=1,
> Product=2, SerialNumber=0 usb 2-1: Product: HP USB Optical Mouse usb 2-1:
> Manufacturer: PixArt
> input: PixArt HP USB Optical Mouse as
> /devices/platform/soc/f9a55000.usb/ci_hdrc.0/usb2/2-1/2-
> 1:1.0/0003:03F0:134A.0002/input/input1
> hid-generic 0003:03F0:134A.0002: input: USB HID v1.11 Mouse [PixArt HP USB
> Optical Mouse] on usb-ci_hdrc.0-1/input0 [otg_set_state]  Set state:
> a_wait_bcon usb 2-1: USB disconnect, device number 3 [otg_statemachine]
> quit statemachine, changed = 1 [otg_set_state]  Set state: a_host  Polling started> [ cut here ]
> WARNING: CPU: 2 PID: 95 at lib/debugobjects.c:263
> debug_print_object+0x98/0xc0
> ODEBUG: init active (active state 0) object type: timer_list hint:
> delayed_work_timer_fn+0x0/0x2c Modules linked in: phy_qcom_usb_hsic
> phy_qcom_usb_hs ci_hdrc_msm ci_hdrc
> CPU: 2 PID: 95 Comm: kworker/u8:1 Not tainted 4.7.0-rc1-00043-
> g1f22f3b65c44-dirty #442 Hardware name: Qualcomm (Flattened Device Tree)
> Workqueue: ci_otg ci_otg_work [ci_hdrc]
> [] (unwind_backtrace) from [] (show_stack+0x20/0x24)
> [] (show_stack) from [] (dump_stack+0x7c/0x9c)
> [] (dump_stack) from [] (__warn+0xe4/0x110)
> [] (__warn) from [] (warn_slowpath_fmt+0x48/0x50)
> [] (warn_slowpath_fmt) from []
> (debug_print_object+0x98/0xc0) [] (debug_print_object) from
> [] (__debug_object_init+0xcc/0x3bc) []
> (__debug_object_init) from [] (debug_object_init+0x24/0x2c)
> [] (debug_object_init) from []
> (init_timer_key+0x24/0x120) [] (init_timer_key) from []
> (otg_start_hnp_polling+0x7c/0xbc) [] (otg_start_hnp_polling)
> from [] (otg_set_state+0x740/0xc20) [] (otg_set_state)
> from [] (otg_statemachine+0x47c/0x4ac) []
> (otg_statemachine) from [] (ci_otg_fsm_work+0x48/0x1a0 [ci_hdrc])
> [] (ci_otg_fsm_work [ci_hdrc]) from []
> (ci_otg_work+0xd4/0x218 [ci_hdrc]) [] (ci_otg_work [ci_hdrc])
> from [] (process_one_work+0x154/0x4b4) []
> (process_one_work) from [] (worker_thread+0x38/0x4d0)
> [] (worker_thread) from [] (kthread+0xe8/0x104)
> [] (kthread) from [] (ret_from_fork+0x14/0x3c)
> 
> Cc: Li Jun <jun...@nxp.com>
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> Fixes: ae57e97a9521 ("usb: common: otg-fsm: add HNP polling support")
> Signed-off-by: Stephen Boyd <stephen.b...@linaro.org>
> ---
>  drivers/usb/common/usb-otg-fsm.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/usb/common/usb-otg-fsm.c b/drivers/usb/common/usb-
> otg-fsm.c
> index 9059b7dc185e..73eec8c12235 100644
> --- a/drivers/usb/common/usb-otg-fsm.c
> +++ b/drivers/usb/common/usb-otg-fsm.c
> @@ -61,6 +61,18 @@ static int otg_set_protocol(struct otg_fsm *fsm, int
> protocol)
>   return 0;
>  }
> 
> +static void otg_stop_hnp_polling(struct otg_fsm *fsm) {
> + /*
> +  * The memory of host_req_flag should be allocated by
> +  * controller driver, otherwise, hnp polling is not started.
> +  */
> + if (!fsm->host_req_flag)
> + return;
> +
> + cancel_delayed_work_sync(>hnp_polling_work);
> +}
> +
>  /* Called when leaving a state.  Do state clean up jobs here */  static
> void otg_leave_state(struct otg_fsm *fsm, enum usb_otg_state old_state)
> { @@ -84,6 +96,7 @@ static void otg_leave

RE: [PATCH] usb: otg-fsm: Cancel HNP polling work when not used

[Jun Li]

Hi

> -Original Message-
> From: Stephen Boyd [mailto:stephen.b...@linaro.org]
> Sent: Tuesday, June 28, 2016 9:18 AM
> To: Peter Chen ; Felipe Balbi 
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> linux-...@vger.kernel.org; Jun Li ; Greg Kroah-Hartman
> 
> Subject: [PATCH] usb: otg-fsm: Cancel HNP polling work when not used
> 
> We setup the HNP polling worker, but we never stop it. The OTG state
> machine can go round and round and keep reinitializing the worker even
> while it's actively running. That's bad, and debug objects catches it. Fix
> this by canceling the work when we leave the A_HOST or B_HOST states.
> 

Normally we need not stop it because the scheduled delayed work will
be finished before next host entering, in your case there is another
host entering before the previous delayed work timeout, so we reinit
the active worker wrongly. Thanks for the required fix.

Acked-by: Li Jun 
 
> [otg_set_state]  Set state: a_wait_bcon
> usb 2-1: USB disconnect, device number 2 [otg_statemachine]  quit
> statemachine, changed = 1 [otg_set_state]  Set state: a_host  started> [otg_statemachine]  quit statemachine, changed = 1 usb 2-1: new
> low-speed USB device number 3 using ci_hdrc usb 2-1: New USB device found,
> idVendor=03f0, idProduct=134a usb 2-1: New USB device strings: Mfr=1,
> Product=2, SerialNumber=0 usb 2-1: Product: HP USB Optical Mouse usb 2-1:
> Manufacturer: PixArt
> input: PixArt HP USB Optical Mouse as
> /devices/platform/soc/f9a55000.usb/ci_hdrc.0/usb2/2-1/2-
> 1:1.0/0003:03F0:134A.0002/input/input1
> hid-generic 0003:03F0:134A.0002: input: USB HID v1.11 Mouse [PixArt HP USB
> Optical Mouse] on usb-ci_hdrc.0-1/input0 [otg_set_state]  Set state:
> a_wait_bcon usb 2-1: USB disconnect, device number 3 [otg_statemachine]
> quit statemachine, changed = 1 [otg_set_state]  Set state: a_host  Polling started> [ cut here ]
> WARNING: CPU: 2 PID: 95 at lib/debugobjects.c:263
> debug_print_object+0x98/0xc0
> ODEBUG: init active (active state 0) object type: timer_list hint:
> delayed_work_timer_fn+0x0/0x2c Modules linked in: phy_qcom_usb_hsic
> phy_qcom_usb_hs ci_hdrc_msm ci_hdrc
> CPU: 2 PID: 95 Comm: kworker/u8:1 Not tainted 4.7.0-rc1-00043-
> g1f22f3b65c44-dirty #442 Hardware name: Qualcomm (Flattened Device Tree)
> Workqueue: ci_otg ci_otg_work [ci_hdrc]
> [] (unwind_backtrace) from [] (show_stack+0x20/0x24)
> [] (show_stack) from [] (dump_stack+0x7c/0x9c)
> [] (dump_stack) from [] (__warn+0xe4/0x110)
> [] (__warn) from [] (warn_slowpath_fmt+0x48/0x50)
> [] (warn_slowpath_fmt) from []
> (debug_print_object+0x98/0xc0) [] (debug_print_object) from
> [] (__debug_object_init+0xcc/0x3bc) []
> (__debug_object_init) from [] (debug_object_init+0x24/0x2c)
> [] (debug_object_init) from []
> (init_timer_key+0x24/0x120) [] (init_timer_key) from []
> (otg_start_hnp_polling+0x7c/0xbc) [] (otg_start_hnp_polling)
> from [] (otg_set_state+0x740/0xc20) [] (otg_set_state)
> from [] (otg_statemachine+0x47c/0x4ac) []
> (otg_statemachine) from [] (ci_otg_fsm_work+0x48/0x1a0 [ci_hdrc])
> [] (ci_otg_fsm_work [ci_hdrc]) from []
> (ci_otg_work+0xd4/0x218 [ci_hdrc]) [] (ci_otg_work [ci_hdrc])
> from [] (process_one_work+0x154/0x4b4) []
> (process_one_work) from [] (worker_thread+0x38/0x4d0)
> [] (worker_thread) from [] (kthread+0xe8/0x104)
> [] (kthread) from [] (ret_from_fork+0x14/0x3c)
> 
> Cc: Li Jun 
> Cc: Greg Kroah-Hartman 
> Fixes: ae57e97a9521 ("usb: common: otg-fsm: add HNP polling support")
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/common/usb-otg-fsm.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/usb/common/usb-otg-fsm.c b/drivers/usb/common/usb-
> otg-fsm.c
> index 9059b7dc185e..73eec8c12235 100644
> --- a/drivers/usb/common/usb-otg-fsm.c
> +++ b/drivers/usb/common/usb-otg-fsm.c
> @@ -61,6 +61,18 @@ static int otg_set_protocol(struct otg_fsm *fsm, int
> protocol)
>   return 0;
>  }
> 
> +static void otg_stop_hnp_polling(struct otg_fsm *fsm) {
> + /*
> +  * The memory of host_req_flag should be allocated by
> +  * controller driver, otherwise, hnp polling is not started.
> +  */
> + if (!fsm->host_req_flag)
> + return;
> +
> + cancel_delayed_work_sync(>hnp_polling_work);
> +}
> +
>  /* Called when leaving a state.  Do state clean up jobs here */  static
> void otg_leave_state(struct otg_fsm *fsm, enum usb_otg_state old_state)
> { @@ -84,6 +96,7 @@ static void otg_leave_state(struct otg_fsm *fsm, enum
> usb_otg_state old_state)
>   fsm->b_ase0_brst_tmout = 0;
>   break;
>   case OTG_STATE_B_HOST:
> + otg_st

RE: [PATCH 04/21] usb: chipidea: Only read/write OTGSC from one place

[Jun Li]

Hi

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Stephen Boyd
> Sent: Sunday, June 26, 2016 3:28 PM
> To: linux-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> linux-arm-...@vger.kernel.org; Andy Gross ; Bjorn
> Andersson ; Neil Armstrong
> ; Arnd Bergmann ; Felipe Balbi
> ; Peter Chen ; Greg Kroah-Hartman
> ; Ivan T. Ivanov 
> Subject: [PATCH 04/21] usb: chipidea: Only read/write OTGSC from one place
> 
> With the id and vbus detection done via extcon we need to make sure we
> poll the status of OTGSC properly by considering what the extcon is saying,
> and not just what the register is saying. Let's move this hw_wait_reg()
> function to the only place it's used and simplify it for polling the OTGSC
> register. Then we can make certain we only use the hw_read_otgsc() API to
> read OTGSC, which will make sure we properly handle extcon events.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Cc: "Ivan T. Ivanov" 
> Fixes: 3ecb3e09b042 ("usb: chipidea: Use extcon framework for VBUS and ID
> detect")
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/core.c | 32 
> drivers/usb/chipidea/otg.c  | 35 +++
>  2 files changed, 31 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 69426e644d17..01390e02ee53 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -516,38 +516,6 @@ int hw_device_reset(struct ci_hdrc *ci)
>   return 0;
>  }
> 
> -/**
> - * hw_wait_reg: wait the register value
> - *
> - * Sometimes, it needs to wait register value before going on.
> - * Eg, when switch to device mode, the vbus value should be lower
> - * than OTGSC_BSV before connects to host.
> - *
> - * @ci: the controller
> - * @reg: register index
> - * @mask: mast bit
> - * @value: the bit value to wait
> - * @timeout_ms: timeout in millisecond
> - *
> - * This function returns an error code if timeout
> - */
> -int hw_wait_reg(struct ci_hdrc *ci, enum ci_hw_regs reg, u32 mask,
> - u32 value, unsigned int timeout_ms)
> -{
> - unsigned long elapse = jiffies + msecs_to_jiffies(timeout_ms);
> -
> - while (hw_read(ci, reg, mask) != value) {
> - if (time_after(jiffies, elapse)) {
> - dev_err(ci->dev, "timeout waiting for %08x in %d\n",
> - mask, reg);
> - return -ETIMEDOUT;
> - }
> - msleep(20);
> - }
> -
> - return 0;
> -}
> -
>  static irqreturn_t ci_irq(int irq, void *data)  {
>   struct ci_hdrc *ci = data;
> diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c index
> 03b6743461d1..763a8332b009 100644
> --- a/drivers/usb/chipidea/otg.c
> +++ b/drivers/usb/chipidea/otg.c
> @@ -104,7 +104,32 @@ void ci_handle_vbus_change(struct ci_hdrc *ci)
>   usb_gadget_vbus_disconnect(>gadget);
>  }
> 
> -#define CI_VBUS_STABLE_TIMEOUT_MS 5000
> +/**
> + * Sometimes, it needs to wait register value before going on.
> + * Eg, when switch to device mode, the vbus value should be lower
> + * than OTGSC_BSV before connects to host.

This should be updated since this API is dedicated for BSV now.

> + *
> + * @ci: the controller
> + *
> + * This function returns an error code if timeout  */ static int
> +hw_wait_otgsc_bsv(struct ci_hdrc *ci) {
> + unsigned long elapse = jiffies + msecs_to_jiffies(5000);
> + u32 mask = OTGSC_BSV;
> +
> + while (!hw_read_otgsc(ci, mask)) {

Reverse logic, should be:
while (hw_read_otgsc(ci, mask)) {

Li Jun

> + if (time_after(jiffies, elapse)) {
> + dev_err(ci->dev, "timeout waiting for %08x in OTGSC\n",
> + mask);
> + return -ETIMEDOUT;
> + }
> + msleep(20);
> + }
> +
> + return 0;
> +}
> +
>  static void ci_handle_id_switch(struct ci_hdrc *ci)  {
>   enum ci_role role = ci_otg_role(ci);
> @@ -116,9 +141,11 @@ static void ci_handle_id_switch(struct ci_hdrc *ci)
>   ci_role_stop(ci);
> 
>   if (role == CI_ROLE_GADGET)
> - /* wait vbus lower than OTGSC_BSV */
> - hw_wait_reg(ci, OP_OTGSC, OTGSC_BSV, 0,
> - CI_VBUS_STABLE_TIMEOUT_MS);
> + /*
> +  * wait vbus lower than OTGSC_BSV before connecting
> +  * to host
> +  */
> + hw_wait_otgsc_bsv(ci);

RE: [PATCH 04/21] usb: chipidea: Only read/write OTGSC from one place

[Jun Li]

Hi

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Stephen Boyd
> Sent: Sunday, June 26, 2016 3:28 PM
> To: linux-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org;
> linux-arm-...@vger.kernel.org; Andy Gross ; Bjorn
> Andersson ; Neil Armstrong
> ; Arnd Bergmann ; Felipe Balbi
> ; Peter Chen ; Greg Kroah-Hartman
> ; Ivan T. Ivanov 
> Subject: [PATCH 04/21] usb: chipidea: Only read/write OTGSC from one place
> 
> With the id and vbus detection done via extcon we need to make sure we
> poll the status of OTGSC properly by considering what the extcon is saying,
> and not just what the register is saying. Let's move this hw_wait_reg()
> function to the only place it's used and simplify it for polling the OTGSC
> register. Then we can make certain we only use the hw_read_otgsc() API to
> read OTGSC, which will make sure we properly handle extcon events.
> 
> Cc: Peter Chen 
> Cc: Greg Kroah-Hartman 
> Cc: "Ivan T. Ivanov" 
> Fixes: 3ecb3e09b042 ("usb: chipidea: Use extcon framework for VBUS and ID
> detect")
> Signed-off-by: Stephen Boyd 
> ---
>  drivers/usb/chipidea/core.c | 32 
> drivers/usb/chipidea/otg.c  | 35 +++
>  2 files changed, 31 insertions(+), 36 deletions(-)
> 
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 69426e644d17..01390e02ee53 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -516,38 +516,6 @@ int hw_device_reset(struct ci_hdrc *ci)
>   return 0;
>  }
> 
> -/**
> - * hw_wait_reg: wait the register value
> - *
> - * Sometimes, it needs to wait register value before going on.
> - * Eg, when switch to device mode, the vbus value should be lower
> - * than OTGSC_BSV before connects to host.
> - *
> - * @ci: the controller
> - * @reg: register index
> - * @mask: mast bit
> - * @value: the bit value to wait
> - * @timeout_ms: timeout in millisecond
> - *
> - * This function returns an error code if timeout
> - */
> -int hw_wait_reg(struct ci_hdrc *ci, enum ci_hw_regs reg, u32 mask,
> - u32 value, unsigned int timeout_ms)
> -{
> - unsigned long elapse = jiffies + msecs_to_jiffies(timeout_ms);
> -
> - while (hw_read(ci, reg, mask) != value) {
> - if (time_after(jiffies, elapse)) {
> - dev_err(ci->dev, "timeout waiting for %08x in %d\n",
> - mask, reg);
> - return -ETIMEDOUT;
> - }
> - msleep(20);
> - }
> -
> - return 0;
> -}
> -
>  static irqreturn_t ci_irq(int irq, void *data)  {
>   struct ci_hdrc *ci = data;
> diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c index
> 03b6743461d1..763a8332b009 100644
> --- a/drivers/usb/chipidea/otg.c
> +++ b/drivers/usb/chipidea/otg.c
> @@ -104,7 +104,32 @@ void ci_handle_vbus_change(struct ci_hdrc *ci)
>   usb_gadget_vbus_disconnect(>gadget);
>  }
> 
> -#define CI_VBUS_STABLE_TIMEOUT_MS 5000
> +/**
> + * Sometimes, it needs to wait register value before going on.
> + * Eg, when switch to device mode, the vbus value should be lower
> + * than OTGSC_BSV before connects to host.

This should be updated since this API is dedicated for BSV now.

> + *
> + * @ci: the controller
> + *
> + * This function returns an error code if timeout  */ static int
> +hw_wait_otgsc_bsv(struct ci_hdrc *ci) {
> + unsigned long elapse = jiffies + msecs_to_jiffies(5000);
> + u32 mask = OTGSC_BSV;
> +
> + while (!hw_read_otgsc(ci, mask)) {

Reverse logic, should be:
while (hw_read_otgsc(ci, mask)) {

Li Jun

> + if (time_after(jiffies, elapse)) {
> + dev_err(ci->dev, "timeout waiting for %08x in OTGSC\n",
> + mask);
> + return -ETIMEDOUT;
> + }
> + msleep(20);
> + }
> +
> + return 0;
> +}
> +
>  static void ci_handle_id_switch(struct ci_hdrc *ci)  {
>   enum ci_role role = ci_otg_role(ci);
> @@ -116,9 +141,11 @@ static void ci_handle_id_switch(struct ci_hdrc *ci)
>   ci_role_stop(ci);
> 
>   if (role == CI_ROLE_GADGET)
> - /* wait vbus lower than OTGSC_BSV */
> - hw_wait_reg(ci, OP_OTGSC, OTGSC_BSV, 0,
> - CI_VBUS_STABLE_TIMEOUT_MS);
> + /*
> +  * wait vbus lower than OTGSC_BSV before connecting
> +  * to host
> +  */
> + hw_wait_otgsc_bsv(ci);
> 
>   ci_role_start(ci, role);
>   }
> --
> 2.9.0.rc2.8.ga28705d
> 
> --
> 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
> 

RE: [RESEND PATCH v11 1/4] gadget: Introduce the usb charger framework

[Jun Li]

Hi

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Baolin Wang
> Sent: Monday, June 13, 2016 4:47 PM
> To: ba...@kernel.org; gre...@linuxfoundation.org; s...@kernel.org;
> dbarysh...@gmail.com; dw...@infradead.org
> Cc: r...@kernel.org; m.szyprow...@samsung.com; ruslan.bilo...@gmail.com;
> peter.c...@freescale.com; st...@rowland.harvard.edu; r.bald...@samsung.com;
> yoshihiro.shimoda...@renesas.com; lee.jo...@linaro.org; broo...@kernel.org;
> ckee...@opensource.wolfsonmicro.com; patc...@opensource.wolfsonmicro.com;
> baolin.w...@linaro.org; linux...@vger.kernel.org; linux-
> u...@vger.kernel.org; device-mainlin...@lists.linuxfoundation.org; linux-
> ker...@vger.kernel.org
> Subject: [RESEND PATCH v11 1/4] gadget: Introduce the usb charger
> framework
> 
> This patch introduces the usb charger driver based on usb gadget that
> makes an enhancement to a power driver. It works well in practice but that
> requires a system with suitable hardware.
> 
> The basic conception of the usb charger is that, when one usb charger is
> added or removed by reporting from the usb gadget state change or the
> extcon device state change, the usb charger will report to power user to
> set the current limitation.
> 
> The usb charger will register notifiees on the usb gadget or the extcon
> device to get notified the usb charger state. It also supplies the
> notification mechanism to userspace When the usb charger state is changed.
> 
> Power user will register a notifiee on the usb charger to get notified by
> status changes from the usb charger. It will report to power user to set
> the current limitation when detecting the usb charger is added or removed
> from extcon device state or usb gadget state.
> 
> This patch doesn't yet integrate with the gadget code, so some functions
> which rely on the 'gadget' are not completed, that will be implemented in
> the following patches.
> 
> Signed-off-by: Baolin Wang 

Reviewed-by: Li Jun 
Tested-by: Li Jun 

> ---
>  drivers/usb/gadget/Kconfig   |7 +
>  drivers/usb/gadget/udc/Makefile  |1 +
>  drivers/usb/gadget/udc/charger.c |  770
> ++
>  include/linux/usb/charger.h  |  191 ++
>  include/uapi/linux/usb/charger.h |   31 ++
>  5 files changed, 1000 insertions(+)
>  create mode 100644 drivers/usb/gadget/udc/charger.c  create mode 100644
> include/linux/usb/charger.h  create mode 100644
> include/uapi/linux/usb/charger.h

RE: [RESEND PATCH v11 1/4] gadget: Introduce the usb charger framework

[Jun Li]

Hi

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Baolin Wang
> Sent: Monday, June 13, 2016 4:47 PM
> To: ba...@kernel.org; gre...@linuxfoundation.org; s...@kernel.org;
> dbarysh...@gmail.com; dw...@infradead.org
> Cc: r...@kernel.org; m.szyprow...@samsung.com; ruslan.bilo...@gmail.com;
> peter.c...@freescale.com; st...@rowland.harvard.edu; r.bald...@samsung.com;
> yoshihiro.shimoda...@renesas.com; lee.jo...@linaro.org; broo...@kernel.org;
> ckee...@opensource.wolfsonmicro.com; patc...@opensource.wolfsonmicro.com;
> baolin.w...@linaro.org; linux...@vger.kernel.org; linux-
> u...@vger.kernel.org; device-mainlin...@lists.linuxfoundation.org; linux-
> ker...@vger.kernel.org
> Subject: [RESEND PATCH v11 1/4] gadget: Introduce the usb charger
> framework
> 
> This patch introduces the usb charger driver based on usb gadget that
> makes an enhancement to a power driver. It works well in practice but that
> requires a system with suitable hardware.
> 
> The basic conception of the usb charger is that, when one usb charger is
> added or removed by reporting from the usb gadget state change or the
> extcon device state change, the usb charger will report to power user to
> set the current limitation.
> 
> The usb charger will register notifiees on the usb gadget or the extcon
> device to get notified the usb charger state. It also supplies the
> notification mechanism to userspace When the usb charger state is changed.
> 
> Power user will register a notifiee on the usb charger to get notified by
> status changes from the usb charger. It will report to power user to set
> the current limitation when detecting the usb charger is added or removed
> from extcon device state or usb gadget state.
> 
> This patch doesn't yet integrate with the gadget code, so some functions
> which rely on the 'gadget' are not completed, that will be implemented in
> the following patches.
> 
> Signed-off-by: Baolin Wang 

Reviewed-by: Li Jun 
Tested-by: Li Jun 

> ---
>  drivers/usb/gadget/Kconfig   |7 +
>  drivers/usb/gadget/udc/Makefile  |1 +
>  drivers/usb/gadget/udc/charger.c |  770
> ++
>  include/linux/usb/charger.h  |  191 ++
>  include/uapi/linux/usb/charger.h |   31 ++
>  5 files changed, 1000 insertions(+)
>  create mode 100644 drivers/usb/gadget/udc/charger.c  create mode 100644
> include/linux/usb/charger.h  create mode 100644
> include/uapi/linux/usb/charger.h

RE: [RESEND PATCH v11 3/4] gadget: Integrate with the usb gadget supporting for usb charger

[Jun Li]

Hi

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Baolin Wang
> Sent: Monday, June 13, 2016 4:47 PM
> To: ba...@kernel.org; gre...@linuxfoundation.org; s...@kernel.org;
> dbarysh...@gmail.com; dw...@infradead.org
> Cc: r...@kernel.org; m.szyprow...@samsung.com; ruslan.bilo...@gmail.com;
> peter.c...@freescale.com; st...@rowland.harvard.edu; r.bald...@samsung.com;
> yoshihiro.shimoda...@renesas.com; lee.jo...@linaro.org; broo...@kernel.org;
> ckee...@opensource.wolfsonmicro.com; patc...@opensource.wolfsonmicro.com;
> baolin.w...@linaro.org; linux...@vger.kernel.org; linux-
> u...@vger.kernel.org; device-mainlin...@lists.linuxfoundation.org; linux-
> ker...@vger.kernel.org
> Subject: [RESEND PATCH v11 3/4] gadget: Integrate with the usb gadget
> supporting for usb charger
> 
> When the usb gadget supporting for usb charger is ready, the usb charger
> can implement the usb_charger_plug_by_gadget() function and
> usb_charger_exit() function by getting 'struct usb_charger' from 'struct
> gadget'.
> 
> Signed-off-by: Baolin Wang 

Reviewed-by: Li Jun 
Tested-by: Li Jun 

> ---
>  drivers/usb/gadget/udc/charger.c |   39
> +-
>  1 file changed, 38 insertions(+), 1 deletion(-)

RE: [RESEND PATCH v11 3/4] gadget: Integrate with the usb gadget supporting for usb charger

[Jun Li]

Hi

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Baolin Wang
> Sent: Monday, June 13, 2016 4:47 PM
> To: ba...@kernel.org; gre...@linuxfoundation.org; s...@kernel.org;
> dbarysh...@gmail.com; dw...@infradead.org
> Cc: r...@kernel.org; m.szyprow...@samsung.com; ruslan.bilo...@gmail.com;
> peter.c...@freescale.com; st...@rowland.harvard.edu; r.bald...@samsung.com;
> yoshihiro.shimoda...@renesas.com; lee.jo...@linaro.org; broo...@kernel.org;
> ckee...@opensource.wolfsonmicro.com; patc...@opensource.wolfsonmicro.com;
> baolin.w...@linaro.org; linux...@vger.kernel.org; linux-
> u...@vger.kernel.org; device-mainlin...@lists.linuxfoundation.org; linux-
> ker...@vger.kernel.org
> Subject: [RESEND PATCH v11 3/4] gadget: Integrate with the usb gadget
> supporting for usb charger
> 
> When the usb gadget supporting for usb charger is ready, the usb charger
> can implement the usb_charger_plug_by_gadget() function and
> usb_charger_exit() function by getting 'struct usb_charger' from 'struct
> gadget'.
> 
> Signed-off-by: Baolin Wang 

Reviewed-by: Li Jun 
Tested-by: Li Jun 

> ---
>  drivers/usb/gadget/udc/charger.c |   39
> +-
>  1 file changed, 38 insertions(+), 1 deletion(-)

RE: [RESEND PATCH v11 2/4] gadget: Support for the usb charger framework

[Jun Li]

Hi

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Baolin Wang
> Sent: Monday, June 13, 2016 4:47 PM
> To: ba...@kernel.org; gre...@linuxfoundation.org; s...@kernel.org;
> dbarysh...@gmail.com; dw...@infradead.org
> Cc: r...@kernel.org; m.szyprow...@samsung.com; ruslan.bilo...@gmail.com;
> peter.c...@freescale.com; st...@rowland.harvard.edu; r.bald...@samsung.com;
> yoshihiro.shimoda...@renesas.com; lee.jo...@linaro.org; broo...@kernel.org;
> ckee...@opensource.wolfsonmicro.com; patc...@opensource.wolfsonmicro.com;
> baolin.w...@linaro.org; linux...@vger.kernel.org; linux-
> u...@vger.kernel.org; device-mainlin...@lists.linuxfoundation.org; linux-
> ker...@vger.kernel.org
> Subject: [RESEND PATCH v11 2/4] gadget: Support for the usb charger
> framework
> 
> For supporting the usb charger, it adds the usb_charger_init() and
> usb_charger_exit() functions for usb charger initialization and exit.
> 
> It will report to the usb charger when the gadget state is changed, then
> the usb charger can do the power things.
> 
> Signed-off-by: Baolin Wang 

Reviewed-by: Li Jun 
Tested-by: Li Jun 

> ---
>  drivers/usb/gadget/udc/udc-core.c |   11 +++
>  include/linux/usb/gadget.h|   11 +++
>  2 files changed, 22 insertions(+)

RE: [RESEND PATCH v11 2/4] gadget: Support for the usb charger framework

[Jun Li]

Hi

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Baolin Wang
> Sent: Monday, June 13, 2016 4:47 PM
> To: ba...@kernel.org; gre...@linuxfoundation.org; s...@kernel.org;
> dbarysh...@gmail.com; dw...@infradead.org
> Cc: r...@kernel.org; m.szyprow...@samsung.com; ruslan.bilo...@gmail.com;
> peter.c...@freescale.com; st...@rowland.harvard.edu; r.bald...@samsung.com;
> yoshihiro.shimoda...@renesas.com; lee.jo...@linaro.org; broo...@kernel.org;
> ckee...@opensource.wolfsonmicro.com; patc...@opensource.wolfsonmicro.com;
> baolin.w...@linaro.org; linux...@vger.kernel.org; linux-
> u...@vger.kernel.org; device-mainlin...@lists.linuxfoundation.org; linux-
> ker...@vger.kernel.org
> Subject: [RESEND PATCH v11 2/4] gadget: Support for the usb charger
> framework
> 
> For supporting the usb charger, it adds the usb_charger_init() and
> usb_charger_exit() functions for usb charger initialization and exit.
> 
> It will report to the usb charger when the gadget state is changed, then
> the usb charger can do the power things.
> 
> Signed-off-by: Baolin Wang 

Reviewed-by: Li Jun 
Tested-by: Li Jun 

> ---
>  drivers/usb/gadget/udc/udc-core.c |   11 +++
>  include/linux/usb/gadget.h|   11 +++
>  2 files changed, 22 insertions(+)

RE: [PATCH v10 09/14] usb: of: add an API to get OTG device from USB controller node

[Jun Li]

Hi

> diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
> index e3d0161..d7ec471 100644
> --- a/drivers/usb/common/common.c
> +++ b/drivers/usb/common/common.c
> @@ -238,6 +238,33 @@ int of_usb_update_otg_caps(struct device_node *np,  }
> EXPORT_SYMBOL_GPL(of_usb_update_otg_caps);
> 
> +#ifdef CONFIG_USB_OTG
> +/**
> + * of_usb_get_otg - get the OTG controller linked to the USB controller
> + * @np: Pointer to the device_node of the USB controller
> + * @otg_caps: Pointer to the target usb_otg_caps to be set

Remove otg_caps.

Li Jun

> + *
> + * Returns the OTG controller device or NULL on error.
> + */
> +struct device *of_usb_get_otg(struct device_node *np) {
> + struct device_node *otg_np;
> + struct platform_device *pdev;
> +
> + otg_np = of_parse_phandle(np, "otg-controller", 0);
> + if (!otg_np)
> + return NULL;
> +
> + pdev = of_find_device_by_node(otg_np);
> + of_node_put(otg_np);
> + if (!pdev)
> + return NULL;
> +
> + return >dev;
> +}
> +EXPORT_SYMBOL_GPL(of_usb_get_otg);
> +#endif
> +
>  #endif
> 
>  MODULE_LICENSE("GPL");
> diff --git a/include/linux/usb/of.h b/include/linux/usb/of.h index
> de3237f..499a4e8 100644
> --- a/include/linux/usb/of.h
> +++ b/include/linux/usb/of.h
> @@ -40,6 +40,15 @@ static inline struct device_node
> *usb_of_get_child_node  }  #endif
> 
> +#if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_USB_OTG) struct device
> +*of_usb_get_otg(struct device_node *np); #else static inline struct
> +device *of_usb_get_otg(struct device_node *np) {
> + return NULL;
> +}
> +#endif
> +
>  #if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_USB_SUPPORT)  enum
> usb_phy_interface of_usb_get_phy_mode(struct device_node *np);  #else
> --
> 2.7.4

RE: [PATCH v10 09/14] usb: of: add an API to get OTG device from USB controller node

[Jun Li]

Hi

> diff --git a/drivers/usb/common/common.c b/drivers/usb/common/common.c
> index e3d0161..d7ec471 100644
> --- a/drivers/usb/common/common.c
> +++ b/drivers/usb/common/common.c
> @@ -238,6 +238,33 @@ int of_usb_update_otg_caps(struct device_node *np,  }
> EXPORT_SYMBOL_GPL(of_usb_update_otg_caps);
> 
> +#ifdef CONFIG_USB_OTG
> +/**
> + * of_usb_get_otg - get the OTG controller linked to the USB controller
> + * @np: Pointer to the device_node of the USB controller
> + * @otg_caps: Pointer to the target usb_otg_caps to be set

Remove otg_caps.

Li Jun

> + *
> + * Returns the OTG controller device or NULL on error.
> + */
> +struct device *of_usb_get_otg(struct device_node *np) {
> + struct device_node *otg_np;
> + struct platform_device *pdev;
> +
> + otg_np = of_parse_phandle(np, "otg-controller", 0);
> + if (!otg_np)
> + return NULL;
> +
> + pdev = of_find_device_by_node(otg_np);
> + of_node_put(otg_np);
> + if (!pdev)
> + return NULL;
> +
> + return >dev;
> +}
> +EXPORT_SYMBOL_GPL(of_usb_get_otg);
> +#endif
> +
>  #endif
> 
>  MODULE_LICENSE("GPL");
> diff --git a/include/linux/usb/of.h b/include/linux/usb/of.h index
> de3237f..499a4e8 100644
> --- a/include/linux/usb/of.h
> +++ b/include/linux/usb/of.h
> @@ -40,6 +40,15 @@ static inline struct device_node
> *usb_of_get_child_node  }  #endif
> 
> +#if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_USB_OTG) struct device
> +*of_usb_get_otg(struct device_node *np); #else static inline struct
> +device *of_usb_get_otg(struct device_node *np) {
> + return NULL;
> +}
> +#endif
> +
>  #if IS_ENABLED(CONFIG_OF) && IS_ENABLED(CONFIG_USB_SUPPORT)  enum
> usb_phy_interface of_usb_get_phy_mode(struct device_node *np);  #else
> --
> 2.7.4