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 = &pdev->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&id=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 y

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.git&data=02%7C01%
> 7Cjun.li%40nxp.com%7Ce261827f14f6446b3e8308d83ab8c407%7C686ea1d3bc2b4c6fa92cd9
> 9c5c301635%7C0%7C0%7C637323912694699319&sdata=ioDexF9tIACz%2BlnZC%2BzZsiFz
> iOeeLembxqr9PwE%2Fpgg%3D&reserved=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(&ci->lock, flags);
>629if (current_role == USB_ROLE_DEVICE)
>630cable = &ci->platdata->vbus_extcon;
>631else if (current_role == USB_ROLE_HOST)
>632cable = &ci->platdata->id_extcon;
>633
>634if (cable) {
>635cable->changed = true;
>636cable->connected = false;
>637ci_irq(ci->irq, ci);
>  > 638spin_unlock_irqrestore(&ci->lock, flags);
>639if (ci->wq && role != USB_ROLE_NONE)
>640flush_workqueue(ci->wq);
>641spin_lock_irqsave(&ci->lock, flags);

Here we hold the lock again.

>642}
>643
>644cable = NULL;
>645
>646/* Start target role */
>647if (role == USB_ROLE_DEVICE)
>648cable = &ci->platdata->vbus_extcon;
>649else if (role == USB_ROLE_HOST)
>650cable = &ci->platdata->id_extcon;
>651
>652if (cable) {
>653cable->changed = true;
>654cable->connected = true;
>655ci_irq(ci->irq, ci);
>656}
>  > 657spin_unlock_irqrestore(&ci->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.org&data=02%7C01%7Cjun.li%40n
> xp.com%7Ce261827f14f6446b3e8308d83ab8c407%7C686ea1d3bc2b4c6fa92cd99c5c301635%7
> C0%7C0%7C637323912694709319&sdata=tAxmh6eq3yT3A89mY2RrGQxwdkUN4A9r708lFQJW
> gcI%3D&reserved=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)
> +   dev_err(qcom_usb->d

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, &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 =

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(&dwc_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(&pdev->dev);
> pm_runtime_disable(&pdev->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(&dwc->lock, flags);
> +   role = dwc->current_otg_role;
> +   spin_unlock_irqrestore(&dwc->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, &dwc3_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%2F619&data=02%7C01%7Cjun.li%40nxp.co
> m%7C2fd7c8c28d67434354be08d686cc6b55%7C686ea1d3bc2b4c6fa92cd99c5c
> 301635%7C0%7C0%7C636844609858846167&sdata=AWDD9WaO%2BXxM
> Izlli6GUNEq%2FqUpa5hSyLbBsjICdLIo%3D&reserved=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 = <&sw_consumer_node>;
> > };
> > };
> > };
> >
> > typec_node {
> > ...
> > port {
> > sw_consumer_node: endpoint {
> > remote-endpoint = <&sw_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%2F437&data=02%7C01%7Cjun.li%40nx
> p.com
> > %7C8c2d40d5e5d246da34ad08d6900e31cf%7C686ea1d3bc2b4c6fa92cd99c5
> c301635
> > %7C0%7C0%7C636854788040965224&sdata=db4gvXKc9InWiltsweetxXYr
> tPbtfX
> > jshPh%2FnvA24ig%3D&reserved=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 = <&sw_consumer_node>;
};
};
};

typec_node {
...
port {
sw_consumer_node: endpoint {
remote-endpoint = <&sw_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 
> 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(&client->dev, client->irq, NULL,
> >> >> + _tcpci_irq,
> >> >>   IRQF_ONESHOT |
> >> IRQF_TRIGGER_LOW,
> >> >> - dev_name(tcpci->dev),
> tcpci);
> >> >> + dev_name(&client->dev),
> >> >> + chip);
> >> >
> >> > - dev_name(&client->dev), chip);
> >> > + dev_name(&client->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 
> 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(&client->dev, client->irq, NULL,
> >> + _tcpci_irq,
> >>   IRQF_ONESHOT |
> IRQF_TRIGGER_LOW,
> >> - dev_name(tcpci->dev), tcpci);
> >> + dev_name(&client->dev), chip);
> >
> > - dev_name(&client->dev), chip);
> > + dev_name(&client->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(&client->dev, client->irq, NULL,
> + _tcpci_irq,
>   IRQF_ONESHOT | IRQF_TRIGGER_LOW,
> - dev_name(tcpci->dev), tcpci);
> + dev_name(&client->dev), chip);

- dev_name(&client->dev), chip);
+ dev_name(&client->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&id=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 ; 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
> > 

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,
 

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_req

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,
> bool enable)
>   struct tcpci *tcpci = tcpc_t

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

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 t

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

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 no

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

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 mac

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, &val, 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)
> 
> 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 
> 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 
> 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: [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.
> > >
> > > &usbotg1 {
> > > 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&SRP) 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 
> 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(&fsm->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)  { @@

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(&fsm->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:
> + 

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(&ci->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
> http://vger.kernel.org/majord

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 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 &pdev->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 2/7] usb: mux: add generic code for dual role port mux

[Jun Li]

Hi, Baolu

From: Lu Baolu [mailto:baolu...@linux.intel.com] 
Sent: Wednesday, June 08, 2016 1:11 PM
To: Jun Li ; Felipe Balbi ; Roger 
Quadros ; Peter Chen 
Cc: Mathias Nyman ; Greg Kroah-Hartman 
; Lee Jones ; Heikki Krogerus 
; Liam Girdwood ; Mark 
Brown ; linux-...@vger.kernel.org; 
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

Hi,

[I have to resend my reply. The previous reply was failed to deliver
to usb mailing list. Sorry for inconvenience.]
On 06/08/2016 11:04 AM, Jun Li wrote:
Whether controller drivers want to use it or not is upto the driver
> > maintainers but we should at least ensure that user space ABI if any,
> > is consistent across different implementations.
> 
> Role decisions should not be exposed to userspace unless as debug feature
> (using e.g. DebugFS). That should be done either by the HW or within the
> kernel.
> In many cases the role decision is made by usersapce, this also should be
> covered.
> This patchset also expose it to userspace but I think it isn't for debug:
> /sys/bus/platform/devices/.../portmux.N/state

> Please don't use this interface for host/gadget role switch, and the
> document doesn't tell you to do so as well. This is only designed to
> put the port mux device to a right direction. Host/gadget dual
> role switch includes other elements, like ID pin detection, type-c
> events, VBUS management and so on.

Confused, then what's the purpose of it? How to use it?
Below is all about it in document, it's seems telling me can do that,
but you say no:)

+What:  /sys/bus/platform/devices/.../portmux.N/name
+   /sys/bus/platform/devices/.../portmux.N/state
+Date:  April 2016
+Contact:   Lu Baolu 
+Description:
+   In some platforms, a single USB port is shared between a USB 
host
+   controller and a device controller. A USB mux driver is needed 
to
+   handle the port mux. Read-only attribute "name" shows the name 
of
+   the port mux device. "state" attribute shows and stores the mux
+   state.
+   For read:
+   'unknown'- the mux hasn't been set yet;
+   'peripheral' - mux has been switched to PERIPHERAL controller;
+   'host'   - mux has been switched to HOST controller.
+   For write:
+   'peripheral' - mux will be switched to PERIPHERAL controller;
+   'host'   - mux will be switched to HOST controller.

> Best regards,
> Lu Baolu

RE: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

[Jun Li]

Hi,
> -Original Message-
> From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com]
> Sent: Tuesday, June 07, 2016 11:05 PM
> To: Roger Quadros ; Lu Baolu ;
> Jun Li ; Peter Chen 
> Cc: Mathias Nyman ; Greg Kroah-Hartman
> ; Lee Jones ; Heikki
> Krogerus ; Liam Girdwood
> ; Mark Brown ; linux-
> u...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port
> mux
> 
> 
> Hi,
> 
> Roger Quadros  writes:
> >> I might be able to find some time to implement a proof of concept
> >> which would allow your platforms to get dual-role with code we
> >> already have, but I need DWC3's OTG support which, I'm assuming, you
> >> already have :-)
> >>
> >> If you wanna try something offline, just ping me ;-) I'll be happy to
> >> help.
> >
> > What you are proposing is a dwc3 only solution. With the otg/dual-role
> > series we are trying to be generic as much as possible.
> 
> Well, if there is a need for that, sure. Take MUSB for instance. It makes
> use of nothing of the sorts, because it doesn't have to.
> 
> > Whether controller drivers want to use it or not is upto the driver
> > maintainers but we should at least ensure that user space ABI if any,
> > is consistent across different implementations.
> 
> Role decisions should not be exposed to userspace unless as debug feature
> (using e.g. DebugFS). That should be done either by the HW or within the
> kernel.

In many cases the role decision is made by usersapce, this also should be
covered.
This patchset also expose it to userspace but I think it isn't for debug:
/sys/bus/platform/devices/.../portmux.N/state

Li Jun
> 
> If we're discussing userspace ABI here, there's something very wrong with
> OTG/DRD layer design.
> 
> >>> How are you switching the port mux between host and peripheral? Only
> >>> by sysfs or do you have a GPIO for ID pin as well?
> >>
> >> depends. Some SoCs have GPIO-controller muxes while some just have
> >> mux's select signals (one for ID, one for VBUS) mapped on xHCI's
> >> address space.
> >>
> >>> What happens to the gadget controller when the port is muxed to the
> >>> host controller?  Is it stopped or it continues to run?
> >>
> >> it continues running, but that's pretty irrelevant for Intel's
> >> dual-role
> >
> > Isn't that unnecessary waste of power? Or you have firmware assisted
> > low power mode?
> 
> that's an implementation detail which brings nothing to this discussion,
> right? :-)
> 
> We can, certainly, put the other side to D3.
> 
> >> setup. We have an actual physical (inside the die, though) mux which
> >> muxes USB signals to XHCI (not DWC3's XHCI) or to a peripheral-only
> >> DWC3.
> >>
> >
> > Probably irrelevant for Intel's dual-role but many platforms that
> > share the port can't have device controller running when port is in
> > host mode and vice versa.
> 
> but that doesn't mean we need an entire new layer added to the kernel
> ;-)
> 
> DWC3 already gives us all the information necessary to make a decision on
> which role we should assume. Just consider your options. Here's how things
> would look like without any OTG/DRD layer:
> 
> -> DWC3 OTG IRQ
>  -> readl(OSTS);
>   -> if (OSTS & BIT(4))
>-> dwc3_host_exit(); __dwc3_gadget_start();
>   -> else
>-> __dwc3_gadget_stop(); dwc3_host_init();
> 
> Can you draw something similar for your proposed OTG/DRD layer?
> 
> I remember there were at least two schedule_work(). IIRC it looked
> something like below:
> 
> -> DWC3 OTG IRQ
>  -> readl(OSTS);
>   -> if (OSTS & BIT(4))
>-> otg_set_mode(PERIPHERAL);
> -> schedule_work();
>  -> otg_ops->stop_host();
>   -> usb_del_hcd();
>  -> otg_ops->start_peripheral();
>   -> usb_gadget_add_udc();
>   -> else
>-> otg_set_mode(HOST);
> -> schedule_work();
>  -> otg_ops->stop_peripheral();
>   -> usb_gadget_del_udc();
>  -> otg_ops->start_host();
>   -> usb_add_hcd();
> 
> I'm probably missing some steps there.
> 
> > So there has to be a central point of control where the respective
> > controllers are started/stopped.
> 
> some implementations might need this, yes. DWC3 and MUSB don't seem to be
> this type of system.
> 
> > That is the other point we are trying to address with the common
> > otg/dual-role code.
> >
> > Even in the TI dwc3 implementation we use dwc3's XHCI so I guess we
> > need to stop the host controller for device mode, right?
> 
> yes, see above. We already have that code.
> 
> > If so then who will deal with start/stop of the controllers then?
> 
> dwc3 itself.
> 
> --
> balbi

RE: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

[Jun Li]

Hi Baolu

> -Original Message-
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Tuesday, June 07, 2016 2:27 PM
> To: Jun Li ; Roger Quadros ; Peter Chen
> 
> Cc: felipe.ba...@linux.intel.com; Mathias Nyman ;
> Greg Kroah-Hartman ; Lee Jones
> ; Heikki Krogerus ;
> Liam Girdwood ; Mark Brown ;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port
> mux
> 
> Hi Jun,
> 
> On 06/07/2016 11:03 AM, Jun Li wrote:
> > Hi Roger
> >
> >>
> >> For Mux devices implementing dual-role, the mux device driver _must_
> >> use OTG/dual-role core API so that a common ABI is presented to user
> >> space for OTG/dual-role.
> > That's the only point we have concern, do dual role switch through
> > OTG/dual-role core, not do it by itself.
> 
> That really depends on how do you define "dual role". Can you please
> provide an unambiguous definition of "dual role" used in OTG/dual-role
> framework?

Host and peripheral.

> 
> Best regards,
> Lu Baolu
> 
> >
> >> I haven't yet looked at the mux framework but if we take care of the
> >> above point then we are not introducing any redundancy.
> >>
> > Roger, actually this is my worry on OTG core: those dual role switch
> > users just tends to do it simply by itself(straightforward and easy),
> > not through the OTG core(some complicated in first look), this is just
> > an example for us to convince people to select a better
> > way:)
> >
> > Li Jun
> >

RE: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

[Jun Li]

Hi Roger

>  
> For Mux devices implementing dual-role, the mux device driver _must_ use
> OTG/dual-role core API so that a common ABI is presented to user space for
> OTG/dual-role.

That's the only point we have concern, do dual role switch through
OTG/dual-role core, not do it by itself.

> 
> I haven't yet looked at the mux framework but if we take care of the above
> point then we are not introducing any redundancy.
> 

Roger, actually this is my worry on OTG core: those dual role switch
users just tends to do it simply by itself(straightforward and easy),
not through the OTG core(some complicated in first look),
this is just an example for us to convince people to select a better
way:)

Li Jun

RE: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

[Jun Li]

> -Original Message-
> From: Lu Baolu [mailto:baolu...@linux.intel.com]
> Sent: Sunday, June 05, 2016 4:47 PM
> To: Jun Li ; Peter Chen 
> Cc: felipe.ba...@linux.intel.com; Mathias Nyman ;
> Greg Kroah-Hartman ; Lee Jones
> ; Heikki Krogerus ;
> Liam Girdwood ; Mark Brown ;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Roger Quadros
> 
> Subject: Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port
> mux
> 
> Hi,
> 
> On 06/05/2016 04:33 PM, Jun Li wrote:
> >> Port mux is part of dual role switch, but not the whole thing.
> >> >
> >> > Dual role switch includes at least below things:
> >> >  - ID or type-C event detection
> >> >  - port mux
> >> >  - VBUS management
> >> >  - start/stop host/device controllers
> >> >
> >> > An OTG/Dual-role framework can be used to keep all these things run
> >> > together with an internal state machine. But it's not duplicated
> >> > with a generic framework for port mux and the port mux drivers.
> >> >
> >>> > > Your
> >>> > > case is just like Renesas case, which uses two different drivers
> >>> > > between peripheral and host[1].
> >> >
> >> > In my case, the port mux devices are physical devices and they can
> >> > be controlled through GPIO pins or device registers. They are
> >> > independent of both peripheral and host controllers.
> >> >
> > I also think current OTG/Dual role framework can support your case, if
> > you find there is any limitation of it which can't meet your
> > requirement, we should improve it, Roger also provide an example of
> > dual role switch with
> > USB3 based on his OTG core.
> 
> Why do we need an OTG framework to support a device driver?

Currently there are many controller drivers which are dual role
capable, all has its specific approach/implementation, your case
is another one, actually there are common part we can share and
reuse, Roger is introducing a common framework which cooperates
into usb core and udc-core. With that, each OTG/dual role user
only need take care of its small specific part.
  
> Is it something like a bus or class driver?

It's not actually a driver, instead, it's more like a lib or
helper routines. You just need register your host and gadget
into OTG core, and define the ops routines if required, OTG state
machine will help you do the switch.

Li Jun
 
> 
> Best regards,
> Lu Baolu

RE: [PATCH v10 2/7] usb: mux: add generic code for dual role port mux

[Jun Li]

Hi

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Lu Baolu
> Sent: Sunday, June 05, 2016 2:56 PM
> To: Peter Chen 
> Cc: felipe.ba...@linux.intel.com; Mathias Nyman ;
> Greg Kroah-Hartman ; Lee Jones
> ; Heikki Krogerus ;
> Liam Girdwood ; Mark Brown ;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Roger Quadros
> 
> Subject: Re: [PATCH v10 2/7] usb: mux: add generic code for dual role port
> mux
> 
> Hi Peter,
> 
> On 06/04/2016 10:28 AM, Peter Chen wrote:
> > On Sat, Jun 04, 2016 at 12:06:06AM +0800, Lu Baolu wrote:
> >>> from my point,it is a dual-role switch driver too,
> >> No, it's not a dual-role switch driver, but a driver for USB port
> multiplexing.
> >>
> >> One example of port multiplexing can be found in several Intel SOC
> >> and PCH chips, inside of which, there are two independent USB
> >> controllers: host and device. They might share a single port and this
> >> port could be configured to route the line to one of these two
> >> controllers. This patch introduced a generic framework for port mux
> >> drivers. It aids the drivers to handle port mux by providing
> >> interfaces to 1) register/unregister a mux device; 2) lookup the mux
> device; and 3) switch the port.
> >>
> > For this case, I can't see it is different with dual-role switch.
> 
> Port mux is part of dual role switch, but not the whole thing.
> 
> Dual role switch includes at least below things:
>  - ID or type-C event detection
>  - port mux
>  - VBUS management
>  - start/stop host/device controllers
> 
> An OTG/Dual-role framework can be used to keep all these things run
> together with an internal state machine. But it's not duplicated with a
> generic framework for port mux and the port mux drivers.
> 
> > Your
> > case is just like Renesas case, which uses two different drivers
> > between peripheral and host[1].
> 
> In my case, the port mux devices are physical devices and they can be
> controlled through GPIO pins or device registers. They are independent of
> both peripheral and host controllers.
> 

I also think current OTG/Dual role framework can support your case, if you
find there is any limitation of it which can't meet your requirement, we
should improve it, Roger also provide an example of dual role switch with
USB3 based on his OTG core.

> 
> >> Port multiplexing isn't equal to USB dual role. There are other cases
> >> in today's systems. In several Intel PCH chips, there equips two USB
> >> host controllers: ehci and xhci. The xhci USB2 ports are multiplexed
> >> with ehci. This guarantees all USB ports work even running an old
> version of OS which lacks of USB3 support.
> >> In theory, we can create a driver for the port mux and switch the
> >> ports between xhci and ehci, but that's silly, isn't it? Why not
> >> always USB3?:-)
> >>
> >> Another case is xHCI debug capability. The xHCI host controller might
> >> equip a unit for system debugging (refer to 7.6 of xHCI spec). The
> >> debugging unit is independent of xhci host controller. But it shares
> >> its port with xhci. Software could switch the port between xhci and
> >> the debugging unit through the registers defined in xHCI spec.
> >>
> > Yes, above two are different with dual role switch. But in your code
> > and Kconfig, it seems this framework is dedicated for dual-role. Eg:
> >
> > +menuconfig USB_PORTMUX
> > +   bool "USB dual role port MUX support"
> > +   help
> > + Generic USB dual role port mux support.
> 
> Above two cases are examples for port multiplexing, but I don't think we
> need drivers for them. At this moment, this framework is only for dual
> role port mux devices.
> 
> >
> > I think a general dual role port mux is necessary, it can be used to
> > manage different dual-role switch method, eg
> 
> Yes, I agree.
> 
> > - ID pin
> > - External connector through GPIO
> > - SoC register
> > - sysfs
> > - type-C events
> 
> ID pin and type-C events are the *reasons* which trigger the port mux
> switch. Currently, on our platforms, gpio, registers and sysfs are methods
> to control the mux.

Those methods also can be mapped/added into OTG/dual role core framework.

> 
> >
> > But this code is better co-work with OTG/Dual-role framework, we'd
> > better have only interface that the user can know which role for the
> > current port.
> 
> OTG/Dual-role framework and portmux framework are not overlapped.

>From previous discussion, I still think this is a special dual role
switch:) which should be covered by general OTG/dual role core(this
core framework is target to support one port with both host and
device capable by any HW/IC implementations).

Li Jun

> The sysfs interface shouldn't be overlapped as well. Say, I have a port
> mux device and I have a driver for it. I am able to read the status of my
> port mux device through sysfs. This is not part of OTG/Dual-role as far as
> I can see.
> 
> Best regards,
> Lu Baolu
> --
> To

RE: [PATCH v8 08/14] usb: otg: add OTG/dual-role core

[Jun Li]

Hi Roger

> >>
> >> Here, we should be checking if user needs to disable any OTG
> >> features. So,
> >>
> >>if (dev->of_node)
> >>of_usb_update_otg_caps(dev->of_node, &otg->caps);
> >>
> >> Do you agree?
> >> This means we need to change otg->caps from 'struct usb_otg_caps
> *caps;'
> >> to 'struct usb_otg_caps caps;' so that we can modify the local copy
> >> instead of the one passed by the OTG controller.
> >
> > Why can't modify the one from OTG controller directly?
> >
> 
> There are 2 things.
> 1) OTG features supported by hardware. This is the controller's config-
> >otg_caps
> 2) OTG features needed by system designer. This can be a subset of (1).

Let's make things simple, we only need this subnet, which can be set
by controller driver in config->otg_caps before pass (its address)
to OTG core.

So controller driver should get the capability of HW(+SW) and user config
by whatever approach, then set its config->otg_caps.

Li Jun

RE: [PATCH v8 08/14] usb: otg: add OTG/dual-role core

[Jun Li]

> -Original Message-
> From: Peter Chen [mailto:hzpeterc...@gmail.com]
> Sent: Wednesday, May 25, 2016 10:44 AM
> To: Roger Quadros 
> Cc: peter.c...@freescale.com; ba...@kernel.org; t...@atomide.com;
> gre...@linuxfoundation.org; dan.j.willi...@intel.com;
> mathias.ny...@linux.intel.com; joao.pi...@synopsys.com;
> sergei.shtyl...@cogentembedded.com; jun...@freescale.com;
> grygorii.stras...@ti.com; yoshihiro.shimoda...@renesas.com;
> r...@kernel.org; nsek...@ti.com; b-...@ti.com; linux-...@vger.kernel.org;
> linux-o...@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org
> Subject: Re: [PATCH v8 08/14] usb: otg: add OTG/dual-role core
> 
> On Tue, May 24, 2016 at 12:45:46PM +0300, Roger Quadros wrote:
> > Hi Peter,
> >
> > I have one question here. Please see below.
> >
> > On 13/05/16 13:03, Roger Quadros wrote:
> > > It provides APIs for the following tasks
> > >
> > > - Registering an OTG/dual-role capable controller
> > > - Registering Host and Gadget controllers to OTG core
> > > - Providing inputs to and kicking the OTG state machine
> > >
> > > Provide a dual-role device (DRD) state machine.
> > > DRD mode is a reduced functionality OTG mode. In this mode we don't
> > > support SRP, HNP and dynamic role-swap.
> > >
> > > In DRD operation, the controller mode (Host or Peripheral) is
> > > decided based on the ID pin status. Once a cable plug (Type-A or
> > > Type-B) is attached the controller selects the state and doesn't
> > > change till the cable in unplugged and a different cable type is
> > > inserted.
> > >
> > > As we don't need most of the complex OTG states and OTG timers we
> > > implement a lean DRD state machine in usb-otg.c.
> > > The DRD state machine is only interested in 2 hardware inputs 'id'
> > > and 'b_sess_vld'.
> > >
> > > Signed-off-by: Roger Quadros 
> > > ---
> > >  drivers/usb/common/Makefile  |2 +-
> > >  drivers/usb/common/usb-otg.c | 1042
> ++
> > >  drivers/usb/core/Kconfig |4 +-
> > >  include/linux/usb/gadget.h   |2 +
> > >  include/linux/usb/hcd.h  |1 +
> > >  include/linux/usb/otg-fsm.h  |7 +
> > >  include/linux/usb/otg.h  |  154 ++-
> > >  7 files changed, 1206 insertions(+), 6 deletions(-)  create mode
> > > 100644 drivers/usb/common/usb-otg.c
> > >
> >
> > 
> >
> > > +
> > > +/**
> > > + * usb_otg_register() - Register the OTG/dual-role device to OTG
> > > +core
> > > + * @dev: OTG/dual-role controller device.
> > > + * @config: OTG configuration.
> > > + *
> > > + * Registers the OTG/dual-role controller device with the USB OTG
> core.
> > > + *
> > > + * Return: struct usb_otg * if success, ERR_PTR() if error.
> > > + */
> > > +struct usb_otg *usb_otg_register(struct device *dev,
> > > +  struct usb_otg_config *config) {
> > > + struct usb_otg *otg;
> > > + struct otg_wait_data *wait;
> > > + int ret = 0;
> > > +
> > > + if (!dev || !config || !config->fsm_ops)
> > > + return ERR_PTR(-EINVAL);
> > > +
> > > + /* already in list? */
> > > + mutex_lock(&otg_list_mutex);
> > > + if (usb_otg_get_data(dev)) {
> > > + dev_err(dev, "otg: %s: device already in otg list\n",
> > > + __func__);
> > > + ret = -EINVAL;
> > > + goto unlock;
> > > + }
> > > +
> > > + /* allocate and add to list */
> > > + otg = kzalloc(sizeof(*otg), GFP_KERNEL);
> > > + if (!otg) {
> > > + ret = -ENOMEM;
> > > + goto unlock;
> > > + }
> > > +
> > > + otg->dev = dev;
> > > + otg->caps = config->otg_caps;
> >
> > Here, we should be checking if user needs to disable any OTG features.
> > So,
> >
> > if (dev->of_node)
> > of_usb_update_otg_caps(dev->of_node, &otg->caps);
> >
> > Do you agree?
> > This means we need to change otg->caps from 'struct usb_otg_caps *caps;'
> > to 'struct usb_otg_caps caps;' so that we can modify the local copy
> > instead of the one passed by the OTG controller.
> 
> Why can't modify the one from OTG controller directly?

Yes, if user wants to disable any OTG features, this should have been
done in 'config->otg_caps', if not, 'config->otg_caps' from controller
driver is invalid and making no sense.

> 
> >
> > We can also move of_usb_update_otg_caps() to otg.h.
> >
> > We will also need to modify the udc-core code so that it sets
> > gadget->otg_caps to the modified otg_caps from the OTG core. This will
> > ensure that the right OTG descriptors are sent.
> >
> > So we will have to introduce an API.
> >
> > struct usb_otg_caps *usb_otg_get_otg_caps(struct device *otg_dev)
> >
> > And in udc-core.c,
> >
> > static int udc_bind_to_driver(struct usb_udc *udc, struct
> > usb_gadget_driver *driver) { ..
> > ret = driver->bind(udc->gadget, driver);
> > if (ret)
> > goto err1;
> >
> > /* If OTG, the otg core starts the UDC when needed */
> > if (udc->gadget->otg_dev) {
> > +   udc->gadget->is_otg = true;
> 
> g

RE: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core

[Jun Li]

Hi

> -Original Message-
> From: Roger Quadros [mailto:rog...@ti.com]
> Sent: Monday, May 23, 2016 6:12 PM
> To: Peter Chen 
> Cc: Jun Li ; peter.c...@freescale.com; ba...@kernel.org;
> t...@atomide.com; gre...@linuxfoundation.org; dan.j.willi...@intel.com;
> mathias.ny...@linux.intel.com; joao.pi...@synopsys.com;
> sergei.shtyl...@cogentembedded.com; jun...@freescale.com;
> grygorii.stras...@ti.com; yoshihiro.shimoda...@renesas.com;
> r...@kernel.org; nsek...@ti.com; b-...@ti.com; linux-...@vger.kernel.org;
> linux-o...@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org
> Subject: Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
> 
> On 23/05/16 06:21, Peter Chen wrote:
> > On Sat, May 21, 2016 at 10:29:40AM +0800, Peter Chen wrote:
> >> On Thu, May 19, 2016 at 10:32:44AM +0300, Roger Quadros wrote:
> >>> On 18/05/16 17:46, Jun Li wrote:
> >>>>
> >>>>
> >>>>>>>
> >>>>>>> I didn't want to have complex Kconfig so decided to have otg as
> >>>>>>> built-in only.
> >>>>>>> What do you want me to change in existing code? and why?
> >>>>>>
> >>>>>> Remove those stuff which only for pass diff driver config Like
> >>>>>> every controller driver need a duplicated
> >>>>>>
> >>>>>> static struct otg_hcd_ops ci_hcd_ops = {
> >>>>>> ...
> >>>>>> }
> >>>>>
> >>>>> This is an exception only. Every controller driver doesn't need to
> >>>>> implement hcd_ops. It is implemented in the hcd core.
> >>>>>
> >>>>>>
> >>>>>> And here is another example, for gadget connect, otg driver can
> >>>>>> directly call to usb_udc_vbus_handler() in drd state machine, but
> >>>>>> you create another interface:
> >>>>>>
> >>>>>> .connect_control = usb_gadget_connect_control,
> >>>>>>
> >>>>>> If the symbol is defined in one driver which is 'm', another
> >>>>>> driver reference it should be 'm' as well, then there is no this
> >>>>>> kind of problem as my understanding.
> >>>>>
> >>>>> That is fine as long as all are 'm'. but how do you solve the case
> >>>>> when Gadget is built in and host is 'm'? OTG has to be built-in
> >>>>> and you will need an hcd to gadget interface.
> >>>>
> >>>> Hcd to gadget interface? Or you want to say otg to host interface?
> >>>
> >>> Sorry, I meant to say host to otg interface.
> >>>
> >>>>
> >>>> I think hcd and gadget are independent each other, now
> >>>>
> >>>> Hcd --> otg; and gadget --> otg, (hcd and gadget use otg's symbol)
> >>>
> >>> It is actually a circular dependency for both.
> >>>  hcd <--> otg and gadget <--> otg
> >>>
> >>> hcd -> otg for usb_otg_register/unregister_hcd otg -> hcd for
> >>> usb_add/remove_hcd, usb_bus_start_enum, usb_control_msg,
> >>> usb_hub_find_child
> >>>
> >>> gadget -> otg for usb_otg_register/unregister_gadget
> >>> otg -> gadget for usb_gadget_start/stop, usb_udc_vbus_handler
> >>>
> >>> Now consider what will happen if I get rid of the otg_hcd and
> otg_gadget interfaces.
> >>> 'y' means built-in, 'm' means module.
> >>>
> >>> 1) hcd 'y', gadget 'y'
> >>> otg has to be 'y' for proper build.
> >>>
> >>> 2) hcd 'm', gadget 'm'
> >>> otg has to be 'm' for proper build.
> >>>
> >>> 3) hcd 'y', gadget 'm'
> >>> Build will fail always.
> >>> If otg is 'y', otg build will fail due to dependency on gadget.
> >>> If otg is 'm', hcd build will fail due to dependency on otg.
> >>>
> >>> 4) hcd 'm', gadget 'y'
> >>> Build will fail always.
> >>> If otg is 'y', otg build will fail due to dependency on hcd.
> >>> If otg is 'm', gadget build will fails due to dependency on otg.
> >>>
> >>> So I solve this problem 

RE: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core

[Jun Li]

> >>
> >> I didn't want to have complex Kconfig so decided to have otg as
> >> built-in only.
> >> What do you want me to change in existing code? and why?
> >
> > Remove those stuff which only for pass diff driver config Like every
> > controller driver need a duplicated
> >
> > static struct otg_hcd_ops ci_hcd_ops = {
> > ...
> > }
> 
> This is an exception only. Every controller driver doesn't need to
> implement hcd_ops. It is implemented in the hcd core.
> 
> >
> > And here is another example, for gadget connect, otg driver can
> > directly call to usb_udc_vbus_handler() in drd state machine, but you
> > create another interface:
> >
> > .connect_control = usb_gadget_connect_control,
> >
> > If the symbol is defined in one driver which is 'm', another driver
> > reference it should be 'm' as well, then there is no this kind of
> > problem as my understanding.
> 
> That is fine as long as all are 'm'. but how do you solve the case when
> Gadget is built in and host is 'm'? OTG has to be built-in and you will
> need an hcd to gadget interface.

Hcd to gadget interface? Or you want to say otg to host interface?

I think hcd and gadget are independent each other, now

Hcd --> otg; and gadget --> otg, (hcd and gadget use otg's symbol)

If you directly call to usb_udc_vbus_handler() in drd state machine

Then:

Hcd --> otg; and gadget <--> otg, (gadget and otg will refer to symbol of each 
other)

Li Jun

> 
> Do you have any ideas to solve that case?
> 
> cheers,
> -roger
> 
> >>
> >>>
> >
> >>return 0;
> >> @@ -660,9 +830,15 @@ static ssize_t
> >> usb_udc_softconn_store(struct
> >> device *dev,
> >>return -EOPNOTSUPP;
> >>}
> >>
> >> +  /* In OTG mode we don't support softconnect, but
> b_bus_req */
> >> +  if (udc->gadget->otg_dev) {
> >> +  dev_err(dev, "soft-connect not supported in OTG
> mode\n");
> >> +  return -EOPNOTSUPP;
> >> +  }
> >> +
> >
> > The soft-connect can be supported at dual-role mode currently,
> > we can use b_bus_req entry once it is implemented later.
> 
>  Soft-connect should be done via sysfs handling within the OTG
> core.
>  This can be added later. I don't want anything outside the OTG
>  core to handle soft-connect behaviour as it will be hard to
>  keep things in sync.
> 
>  I can update the comment to something like this.
> 
>  /* In OTG/dual-role mode, soft-connect should be handled by OTG
>  core */
> >>>
> >>> Ok, let's Felipe decide it.
> >>>
> 
> >
> >>if (sysfs_streq(buf, "connect")) {
> >>usb_gadget_udc_start(udc);
> >> -  usb_gadget_connect(udc->gadget);
> >> +  usb_udc_connect_control(udc);
> >
> > This line seems to be not related with this patch.
> >
>  Right. I'll remove it.
> 
>  cheers,
>  -roger
> >>>

RE: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core

[Jun Li]

Hi

> -Original Message-
> From: Roger Quadros [mailto:rog...@ti.com]
> Sent: Wednesday, May 18, 2016 8:43 PM
> To: Jun Li ; Peter Chen 
> Cc: peter.c...@freescale.com; ba...@kernel.org; t...@atomide.com;
> gre...@linuxfoundation.org; dan.j.willi...@intel.com;
> mathias.ny...@linux.intel.com; joao.pi...@synopsys.com;
> sergei.shtyl...@cogentembedded.com; jun...@freescale.com;
> grygorii.stras...@ti.com; yoshihiro.shimoda...@renesas.com;
> r...@kernel.org; nsek...@ti.com; b-...@ti.com; linux-...@vger.kernel.org;
> linux-o...@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org
> Subject: Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
> 
> On 17/05/16 11:28, Jun Li wrote:
> > Hi Roger,
> >
> >> -Original Message-
> >> From: Roger Quadros [mailto:rog...@ti.com]
> >> Sent: Tuesday, May 17, 2016 4:09 PM
> >> To: Jun Li ; Peter Chen 
> >> Cc: peter.c...@freescale.com; ba...@kernel.org; t...@atomide.com;
> >> gre...@linuxfoundation.org; dan.j.willi...@intel.com;
> >> mathias.ny...@linux.intel.com; joao.pi...@synopsys.com;
> >> sergei.shtyl...@cogentembedded.com; jun...@freescale.com;
> >> grygorii.stras...@ti.com; yoshihiro.shimoda...@renesas.com;
> >> r...@kernel.org; nsek...@ti.com; b-...@ti.com;
> >> linux-...@vger.kernel.org; linux-o...@vger.kernel.org;
> >> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org
> >> Subject: Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
> >>
> >> On 17/05/16 10:38, Jun Li wrote:
> >>> Hi
> >>>
> >>>> -Original Message-
> >>>> From: Roger Quadros [mailto:rog...@ti.com]
> >>>> Sent: Monday, May 16, 2016 5:52 PM
> >>>> To: Peter Chen 
> >>>> Cc: peter.c...@freescale.com; ba...@kernel.org; t...@atomide.com;
> >>>> gre...@linuxfoundation.org; dan.j.willi...@intel.com;
> >>>> mathias.ny...@linux.intel.com; joao.pi...@synopsys.com;
> >>>> sergei.shtyl...@cogentembedded.com; jun...@freescale.com;
> >>>> grygorii.stras...@ti.com; yoshihiro.shimoda...@renesas.com;
> >>>> r...@kernel.org; nsek...@ti.com; b-...@ti.com;
> >>>> linux-...@vger.kernel.org; linux-o...@vger.kernel.org;
> >>>> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org
> >>>> Subject: Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
> >>>>
> >>>> On 16/05/16 12:23, Peter Chen wrote:
> >>>>> On Mon, May 16, 2016 at 11:26:57AM +0300, Roger Quadros wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> On 16/05/16 10:02, Peter Chen wrote:
> >>>>>>> On Fri, May 13, 2016 at 01:03:27PM +0300, Roger Quadros wrote:
> >>>>>>>> +
> >>>>>>>> +static int usb_gadget_connect_control(struct usb_gadget
> >>>>>>>> +*gadget, bool connect) {
> >>>>>>>> +struct usb_udc *udc;
> >>>>>>>> +
> >>>>>>>> +mutex_lock(&udc_lock);
> >>>>>>>> +udc = usb_gadget_to_udc(gadget);
> >>>>>>>> +if (!udc) {
> >>>>>>>> +dev_err(gadget->dev.parent, "%s: gadget not
> >>>> registered.\n",
> >>>>>>>> +__func__);
> >>>>>>>> +mutex_unlock(&udc_lock);
> >>>>>>>> +return -EINVAL;
> >>>>>>>> +}
> >>>>>>>> +
> >>>>>>>> +if (connect) {
> >>>>>>>> +if (!gadget->connected)
> >>>>>>>> +usb_gadget_connect(udc->gadget);
> >>>>>>>> +} else {
> >>>>>>>> +if (gadget->connected) {
> >>>>>>>> +usb_gadget_disconnect(udc->gadget);
> >>>>>>>> +udc->driver->disconnect(udc->gadget);
> >>>>>>>> +}
> >>>>>>>> +}
> >>>>>>>> +
> >>>>>>>> +mutex_unlock(&udc_lock);
> >>>>>>>> +
> >>>>>>>> +return 0;
> >>>>>>>> +}
> >>>>>>>> +
> >>>>>>>
> 

RE: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core

[Jun Li]

Hi Roger,

> -Original Message-
> From: Roger Quadros [mailto:rog...@ti.com]
> Sent: Tuesday, May 17, 2016 4:09 PM
> To: Jun Li ; Peter Chen 
> Cc: peter.c...@freescale.com; ba...@kernel.org; t...@atomide.com;
> gre...@linuxfoundation.org; dan.j.willi...@intel.com;
> mathias.ny...@linux.intel.com; joao.pi...@synopsys.com;
> sergei.shtyl...@cogentembedded.com; jun...@freescale.com;
> grygorii.stras...@ti.com; yoshihiro.shimoda...@renesas.com;
> r...@kernel.org; nsek...@ti.com; b-...@ti.com; linux-...@vger.kernel.org;
> linux-o...@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org
> Subject: Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
> 
> On 17/05/16 10:38, Jun Li wrote:
> > Hi
> >
> >> -Original Message-
> >> From: Roger Quadros [mailto:rog...@ti.com]
> >> Sent: Monday, May 16, 2016 5:52 PM
> >> To: Peter Chen 
> >> Cc: peter.c...@freescale.com; ba...@kernel.org; t...@atomide.com;
> >> gre...@linuxfoundation.org; dan.j.willi...@intel.com;
> >> mathias.ny...@linux.intel.com; joao.pi...@synopsys.com;
> >> sergei.shtyl...@cogentembedded.com; jun...@freescale.com;
> >> grygorii.stras...@ti.com; yoshihiro.shimoda...@renesas.com;
> >> r...@kernel.org; nsek...@ti.com; b-...@ti.com;
> >> linux-...@vger.kernel.org; linux-o...@vger.kernel.org;
> >> linux-kernel@vger.kernel.org; devicet...@vger.kernel.org
> >> Subject: Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
> >>
> >> On 16/05/16 12:23, Peter Chen wrote:
> >>> On Mon, May 16, 2016 at 11:26:57AM +0300, Roger Quadros wrote:
> >>>> Hi,
> >>>>
> >>>> On 16/05/16 10:02, Peter Chen wrote:
> >>>>> On Fri, May 13, 2016 at 01:03:27PM +0300, Roger Quadros wrote:
> >>>>>> +
> >>>>>> +static int usb_gadget_connect_control(struct usb_gadget *gadget,
> >>>>>> +bool connect) {
> >>>>>> +  struct usb_udc *udc;
> >>>>>> +
> >>>>>> +  mutex_lock(&udc_lock);
> >>>>>> +  udc = usb_gadget_to_udc(gadget);
> >>>>>> +  if (!udc) {
> >>>>>> +  dev_err(gadget->dev.parent, "%s: gadget not
> >> registered.\n",
> >>>>>> +  __func__);
> >>>>>> +  mutex_unlock(&udc_lock);
> >>>>>> +  return -EINVAL;
> >>>>>> +  }
> >>>>>> +
> >>>>>> +  if (connect) {
> >>>>>> +  if (!gadget->connected)
> >>>>>> +  usb_gadget_connect(udc->gadget);
> >>>>>> +  } else {
> >>>>>> +  if (gadget->connected) {
> >>>>>> +  usb_gadget_disconnect(udc->gadget);
> >>>>>> +  udc->driver->disconnect(udc->gadget);
> >>>>>> +  }
> >>>>>> +  }
> >>>>>> +
> >>>>>> +  mutex_unlock(&udc_lock);
> >>>>>> +
> >>>>>> +  return 0;
> >>>>>> +}
> >>>>>> +
> >>>>>
> >>>>> Since this is called for vbus interrupt, why not using
> >>>>> usb_udc_vbus_handler directly, and call udc->driver->disconnect at
> >>>>> usb_gadget_stop.
> >>>>
> >>>> We can't assume that this is always called for vbus interrupt so I
> >>>> decided not to call usb_udc_vbus_handler.
> >>>>
> >>>> udc->vbus is really pointless for us. We keep vbus states in our
> >>>> state machine and leave udc->vbus as ture always.
> >>>>
> >>>> Why do you want to move udc->driver->disconnect() to stop?
> >>>> If USB controller disconnected from bus then the gadget driver must
> >>>> be notified about the disconnect immediately. The controller may or
> >>>> may not be stopped by the core.
> >>>>
> >>>
> >>> Then, would you give some comments when this API will be used?
> >>> I was assumed it is only used for drd state machine.
> >>
> >> drd_state machine didn't even need this API in the first place :).
> >> You guys wanted me to separate out start/stop and connect/dis

RE: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core

[Jun Li]

Hi

> -Original Message-
> From: Roger Quadros [mailto:rog...@ti.com]
> Sent: Monday, May 16, 2016 5:52 PM
> To: Peter Chen 
> Cc: peter.c...@freescale.com; ba...@kernel.org; t...@atomide.com;
> gre...@linuxfoundation.org; dan.j.willi...@intel.com;
> mathias.ny...@linux.intel.com; joao.pi...@synopsys.com;
> sergei.shtyl...@cogentembedded.com; jun...@freescale.com;
> grygorii.stras...@ti.com; yoshihiro.shimoda...@renesas.com;
> r...@kernel.org; nsek...@ti.com; b-...@ti.com; linux-...@vger.kernel.org;
> linux-o...@vger.kernel.org; linux-kernel@vger.kernel.org;
> devicet...@vger.kernel.org
> Subject: Re: [PATCH v8 13/14] usb: gadget: udc: adapt to OTG core
> 
> On 16/05/16 12:23, Peter Chen wrote:
> > On Mon, May 16, 2016 at 11:26:57AM +0300, Roger Quadros wrote:
> >> Hi,
> >>
> >> On 16/05/16 10:02, Peter Chen wrote:
> >>> On Fri, May 13, 2016 at 01:03:27PM +0300, Roger Quadros wrote:
>  +
>  +static int usb_gadget_connect_control(struct usb_gadget *gadget,
>  +bool connect) {
>  +struct usb_udc *udc;
>  +
>  +mutex_lock(&udc_lock);
>  +udc = usb_gadget_to_udc(gadget);
>  +if (!udc) {
>  +dev_err(gadget->dev.parent, "%s: gadget not
> registered.\n",
>  +__func__);
>  +mutex_unlock(&udc_lock);
>  +return -EINVAL;
>  +}
>  +
>  +if (connect) {
>  +if (!gadget->connected)
>  +usb_gadget_connect(udc->gadget);
>  +} else {
>  +if (gadget->connected) {
>  +usb_gadget_disconnect(udc->gadget);
>  +udc->driver->disconnect(udc->gadget);
>  +}
>  +}
>  +
>  +mutex_unlock(&udc_lock);
>  +
>  +return 0;
>  +}
>  +
> >>>
> >>> Since this is called for vbus interrupt, why not using
> >>> usb_udc_vbus_handler directly, and call udc->driver->disconnect at
> >>> usb_gadget_stop.
> >>
> >> We can't assume that this is always called for vbus interrupt so I
> >> decided not to call usb_udc_vbus_handler.
> >>
> >> udc->vbus is really pointless for us. We keep vbus states in our
> >> state machine and leave udc->vbus as ture always.
> >>
> >> Why do you want to move udc->driver->disconnect() to stop?
> >> If USB controller disconnected from bus then the gadget driver must
> >> be notified about the disconnect immediately. The controller may or
> >> may not be stopped by the core.
> >>
> >
> > Then, would you give some comments when this API will be used?
> > I was assumed it is only used for drd state machine.
> 
> drd_state machine didn't even need this API in the first place :).
> You guys wanted me to separate out start/stop and connect/disconnect for
> full OTG case.
> Won't full OTG state machine want to use this API? If not what would it
> use?

Instead create those new interfaces/symbol here and there just aim to
address build problems in diff configures, Could we only allow meaningful
combination of those 3 drivers configures?

Hcd=y, gadget=y, otg=y or
Hcd=m, gadget=m, otg=m

Li Jun

> 
> cheers,
> -roger
> 
> >
> >>>
>   return 0;
>  @@ -660,9 +830,15 @@ static ssize_t usb_udc_softconn_store(struct
> device *dev,
>   return -EOPNOTSUPP;
>   }
> 
>  +/* In OTG mode we don't support softconnect, but b_bus_req */
>  +if (udc->gadget->otg_dev) {
>  +dev_err(dev, "soft-connect not supported in OTG 
>  mode\n");
>  +return -EOPNOTSUPP;
>  +}
>  +
> >>>
> >>> The soft-connect can be supported at dual-role mode currently, we
> >>> can use b_bus_req entry once it is implemented later.
> >>
> >> Soft-connect should be done via sysfs handling within the OTG core.
> >> This can be added later. I don't want anything outside the OTG core
> >> to handle soft-connect behaviour as it will be hard to keep things in
> >> sync.
> >>
> >> I can update the comment to something like this.
> >>
> >> /* In OTG/dual-role mode, soft-connect should be handled by OTG core
> >> */
> >
> > Ok, let's Felipe decide it.
> >
> >>
> >>>
>   if (sysfs_streq(buf, "connect")) {
>   usb_gadget_udc_start(udc);
>  -usb_gadget_connect(udc->gadget);
>  +usb_udc_connect_control(udc);
> >>>
> >>> This line seems to be not related with this patch.
> >>>
> >> Right. I'll remove it.
> >>
> >> cheers,
> >> -roger
> >

RE: [PATCH v7 03/14] usb: hcd.h: Add OTG to HCD interface

[Jun Li]

Hi

> -Original Message-
> From: Roger Quadros [mailto:rog...@ti.com]
> Sent: Tuesday, May 10, 2016 3:35 PM
> To: Peter Chen 
> Cc: peter.c...@freescale.com; st...@rowland.harvard.edu; ba...@kernel.org;
> gre...@linuxfoundation.org; dan.j.willi...@intel.com; jun...@freescale.com;
> mathias.ny...@linux.intel.com; t...@atomide.com; joao.pi...@synopsys.com;
> abres...@chromium.org; yoshihiro.shimoda...@renesas.com; linux-
> u...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> o...@vger.kernel.org; devicet...@vger.kernel.org
> Subject: Re: [PATCH v7 03/14] usb: hcd.h: Add OTG to HCD interface
> 
> On 10/05/16 06:14, Peter Chen wrote:
> > On Mon, May 09, 2016 at 12:45:38PM +0300, Roger Quadros wrote:
> >> On 06/05/16 12:41, Peter Chen wrote:
> >>> On Mon, May 02, 2016 at 03:18:46PM +0300, Roger Quadros wrote:
>  The OTG core will use struct otg_hcd_ops to interface with the HCD
>  controller.
> 
>  The main purpose of this interface is to avoid directly calling HCD
>  APIs from the OTG core as they wouldn't be defined in the built-in
>  symbol table if CONFIG_USB is m.
> 
>  Signed-off-by: Roger Quadros 
>  Acked-by: Peter Chen 
> >>>
> >>> Roger, after thinking more, I still think current dependency between
> >>> OTG, HCD and gadget are too complicated. Since the OTG can't work if
> >>> it is built as module, I suggest letting OTG depends on HCD &&
> >>> USB_GADGET, and it is a boolean, in that case, we don't need to
> >>> export any HCD and gadget ops, things will be much simpler.
> >>> What's your opinion?
> >>
> >> How will it work if HCD and USB_GADGET are modules and OTG is built-in?
> >>
> >
> > The OTG will not be compiled at this situation, since it is boolean.
> > In fact, like I mentioned at above, OTG or USB function can't work if
> > it is built as module.
> 
> Isn't this a limitation?
> As per the current implementation dual role works fine even with both
> USB_GADGET and HCD as module.

My understand: only make sense for pass build, host can't work before
gadget modules loaded; gadget can't work before hcd loaded, nothing
can work before all drivers are loaded.

> 
> In the real world it is unlikely that GADGET and HCD will be built-in.

Why? User enable USB_OTG means both drivers should be enabled anyway.
Even in non-OTG case, both may be built-in for machine with 2 ports
(one port is host only, the other one is peripheral only).

A general question, 2 drivers depends on each other, allowable?

> 
> cheers,
> -roger
> 
> >
> > Peter
> >> cheers,
> >> -roger
> >>
> >>>
> >>> Peter
> >>>
>  ---
>   include/linux/usb/hcd.h | 24 
>   1 file changed, 24 insertions(+)
> 
>  diff --git a/include/linux/usb/hcd.h b/include/linux/usb/hcd.h
>  index b98f831..861ccaa 100644
>  --- a/include/linux/usb/hcd.h
>  +++ b/include/linux/usb/hcd.h
>  @@ -399,6 +399,30 @@ struct hc_driver {
> 
>   };
> 
>  +/**
>  + * struct otg_hcd_ops - Interface between OTG core and HCD
>  + *
>  + * Provided by the HCD core to allow the OTG core to interface
>  +with the HCD
>  + *
>  + * @add: function to add the HCD
>  + * @remove: function to remove the HCD
>  + * @usb_bus_start_enum: function to immediately start bus
>  +enumeration
>  + * @usb_control_msg: function to build and send of a control urb
>  + * @usb_hub_find_child: function to get pointer to the child
>  +device  */ struct otg_hcd_ops {
>  +int (*add)(struct usb_hcd *hcd,
>  +   unsigned int irqnum, unsigned long irqflags);
>  +void (*remove)(struct usb_hcd *hcd);
>  +int (*usb_bus_start_enum)(struct usb_bus *bus, unsigned int
> port_num);
>  +int (*usb_control_msg)(struct usb_device *dev, unsigned int
> pipe,
>  +   __u8 request, __u8 requesttype, __u16 
>  value,
>  +   __u16 index, void *data, __u16 size,
>  +   int timeout);
>  +struct usb_device * (*usb_hub_find_child)(struct usb_device
> *hdev,
>  +  int port1);
>  +};
>  +
>   static inline int hcd_giveback_urb_in_bh(struct usb_hcd *hcd)  {
>   return hcd->driver->flags & HCD_BH;
>  --
>  2.7.4
> 
>  --
>  To unsubscribe from this list: send the line "unsubscribe
>  linux-usb" in the body of a message to majord...@vger.kernel.org
>  More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>>
> >

RE: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core

[Jun Li]

Hi

> -Original Message-
> From: Roger Quadros [mailto:rog...@ti.com]
> Sent: Wednesday, May 04, 2016 2:37 PM
> To: Peter Chen 
> Cc: Jun Li ; st...@rowland.harvard.edu; ba...@kernel.org;
> gre...@linuxfoundation.org; peter.c...@freescale.com;
> dan.j.willi...@intel.com; jun...@freescale.com;
> mathias.ny...@linux.intel.com; t...@atomide.com; joao.pi...@synopsys.com;
> abres...@chromium.org; r.bald...@samsung.com; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-o...@vger.kernel.org
> Subject: Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core
> 
> Peter,
> 
> On 04/05/16 06:35, Peter Chen wrote:
> > On Tue, May 03, 2016 at 06:44:46PM +0300, Roger Quadros wrote:
> >> Hi,
> >>
> >> On 03/05/16 10:06, Jun Li wrote:
> >>> Hi
> >>>
> >>>>>>>>>>>  /**
> >>>>>>>>>>> + * usb_gadget_start - start the usb gadget controller and
> >>>>>>>>>>> +connect to bus
> >>>>>>>>>>> + * @gadget: the gadget device to start
> >>>>>>>>>>> + *
> >>>>>>>>>>> + * This is external API for use by OTG core.
> >>>>>>>>>>> + *
> >>>>>>>>>>> + * Start the usb device controller and connect to bus
> >>>>>>>>>>> +(enable
> >>>> pull).
> >>>>>>>>>>> + */
> >>>>>>>>>>> +static int usb_gadget_start(struct usb_gadget *gadget) {
> >>>>>>>>>>> + int ret;
> >>>>>>>>>>> + struct usb_udc *udc = NULL;
> >>>>>>>>>>> +
> >>>>>>>>>>> + dev_dbg(&gadget->dev, "%s\n", __func__);
> >>>>>>>>>>> + mutex_lock(&udc_lock);
> >>>>>>>>>>> + list_for_each_entry(udc, &udc_list, list)
> >>>>>>>>>>> + if (udc->gadget == gadget)
> >>>>>>>>>>> + goto found;
> >>>>>>>>>>> +
> >>>>>>>>>>> + dev_err(gadget->dev.parent, "%s: gadget not
> registered.\n",
> >>>>>>>>>>> + __func__);
> >>>>>>>>>>> + mutex_unlock(&udc_lock);
> >>>>>>>>>>> + return -EINVAL;
> >>>>>>>>>>> +
> >>>>>>>>>>> +found:
> >>>>>>>>>>> + ret = usb_gadget_udc_start(udc);
> >>>>>>>>>>> + if (ret)
> >>>>>>>>>>> + dev_err(&udc->dev, "USB Device Controller didn't
> >>>>>> start: %d\n",
> >>>>>>>>>>> + ret);
> >>>>>>>>>>> + else
> >>>>>>>>>>> + usb_udc_connect_control(udc);
> >>>>>>>>>>
> >>>>>>>>>> For drd, it's fine, but for real otg, gadget connect should
> >>>>>>>>>> be done by
> >>>>>>>>>> loc_conn() instead of gadget start.
> >>>>>>>>>
> >>>>>>>>> It is upto the OTG state machine to call gadget_start() when
> >>>>>>>>> it needs to connect to the bus (i.e. loc_conn()). I see no
> >>>>>>>>> point in calling gadget start before.
> >>>>>>>>>
> >>>>>>>>> Do you see any issue in doing so?
> >>>>>>>>
> >>>>>>>> This is what OTG state machine does:
> >>>>>>>> case OTG_STATE_B_PERIPHERAL:
> >>>>>>>>  otg_chrg_vbus(otg, 0);
> >>>>>>>>  otg_loc_sof(otg, 0);
> >>>>>>>>  otg_set_protocol(fsm, PROTO_GADGET);
> >>>>>>>>  otg_loc_conn(otg, 1);
> >>>>>>>>  break;
> >>>>>>
> >>>>>> On second thoughts, after seen the OTG state machine.
> >>>>>> otg_set_protocol(fsm, PROTO_GADGET); is always followed by
> >>>>>> otg_loc_conn(otg, 1); And whenever protocol changes to anything

RE: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core

[Jun Li]

Hi

> >>>  /**
> >>> + * usb_gadget_start - start the usb gadget controller and
> >>> +connect to bus
> >>> + * @gadget: the gadget device to start
> >>> + *
> >>> + * This is external API for use by OTG core.
> >>> + *
> >>> + * Start the usb device controller and connect to bus (enable
> pull).
> >>> + */
> >>> +static int usb_gadget_start(struct usb_gadget *gadget) {
> >>> + int ret;
> >>> + struct usb_udc *udc = NULL;
> >>> +
> >>> + dev_dbg(&gadget->dev, "%s\n", __func__);
> >>> + mutex_lock(&udc_lock);
> >>> + list_for_each_entry(udc, &udc_list, list)
> >>> + if (udc->gadget == gadget)
> >>> + goto found;
> >>> +
> >>> + dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
> >>> + __func__);
> >>> + mutex_unlock(&udc_lock);
> >>> + return -EINVAL;
> >>> +
> >>> +found:
> >>> + ret = usb_gadget_udc_start(udc);
> >>> + if (ret)
> >>> + dev_err(&udc->dev, "USB Device Controller didn't
> >> start: %d\n",
> >>> + ret);
> >>> + else
> >>> + usb_udc_connect_control(udc);
> >>
> >> For drd, it's fine, but for real otg, gadget connect should be
> >> done by
> >> loc_conn() instead of gadget start.
> >
> > It is upto the OTG state machine to call gadget_start() when it
> > needs to connect to the bus (i.e. loc_conn()). I see no point in
> > calling gadget start before.
> >
> > Do you see any issue in doing so?
> 
>  This is what OTG state machine does:
>  case OTG_STATE_B_PERIPHERAL:
>   otg_chrg_vbus(otg, 0);
>   otg_loc_sof(otg, 0);
>   otg_set_protocol(fsm, PROTO_GADGET);
>   otg_loc_conn(otg, 1);
>   break;
> >>
> >> On second thoughts, after seen the OTG state machine.
> >> otg_set_protocol(fsm, PROTO_GADGET); is always followed by
> >> otg_loc_conn(otg, 1); And whenever protocol changes to anything other
> >> the PROTO_GADGET, we use otg_loc_conn(otg, 0);
> >>
> >> So otg_loc_conn seems redundant. Can we just get rid of it?
> >>
> >> usb_gadget_start() implies that gadget controller starts up and
> >> enables pull.
> >> usb_gadget_stop() implies that gadget controller disables pull and
> stops.
> >>
> >>
> >> Can you please explain why just these 2 APIs are not sufficient for
> >> full OTG?
> >>
> >> Do we want anything to happen between gadget controller start/stop
> >> and pull on/off?
> >
> > "loc_conn" is a standard output parameter in OTG spec, it deserves a
> > separate api, yes, current implementation of OTG state machine code
> > seems allow you to combine the 2 things into one, but don't do that,
> > because they do not always happen together, e.g. for peripheral only B
> > device (also a part OTG spec: section 7.3), will be fixed in gadget
> > mode, but it will do gadget connect and disconnect in its diff states,
> > so, to make the framework common, let's keep them separated.
> 
> I'm sorry but I didn't understand your comment about "it will do gadget
> connect and disconnect in its diff states"

Gadget connect means loc_conn(1).

> 
> I am reading the OTG v2.0 specification and loc_conn is always true when
> b_peripheral or a_peripheral is true and false otherwise.

If you only talk about these 2 states, yes, loc_conn is ture.

> 
> loc_conn is just an internal state variable and it corresponds to our
> gadget_start/stop() state.

It's not an internal variable, there are OTG state machine
parameters tables(table 7-x) in OTG spec which have clear lists
which are "internal variable", which are "input", which are "output"...

Those APIs are driven directly from OTG spec, easily understood so
code reader can know what's those APIs for. For real OTG, I don't
see the benefit if get rid of it.

> 
> As per 7.4.2.3
> "loc_conn
> The "local connect" (loc_conn) variable is TRUE when the local device has
> signaled that it is connected to the bus. This variable is FALSE when the
> local device has signaled that it is disconnected from the bus"
> 
> Can you please point me in the specification if there is any place where
> loc_conn is false and b_peripheral/a_peripheral is true?
> 
> cheers,
> -roger

RE: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core

[Jun Li]

Hi

> -Original Message-
> From: Roger Quadros [mailto:rog...@ti.com]
> Sent: Thursday, April 28, 2016 5:55 PM
> To: Jun Li ; st...@rowland.harvard.edu; ba...@kernel.org;
> gre...@linuxfoundation.org; peter.c...@freescale.com
> Cc: dan.j.willi...@intel.com; jun...@freescale.com;
> mathias.ny...@linux.intel.com; t...@atomide.com; joao.pi...@synopsys.com;
> abres...@chromium.org; r.bald...@samsung.com; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-o...@vger.kernel.org
> Subject: Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core
> 
> Hi,
> 
> On 27/04/16 14:22, Roger Quadros wrote:
> > On 26/04/16 03:07, Jun Li wrote:
> >> Hi
> >>
> >>> -Original Message-
> >>> From: Roger Quadros [mailto:rog...@ti.com]
> >>> Sent: Monday, April 25, 2016 10:04 PM
> >>> To: Jun Li ; st...@rowland.harvard.edu;
> >>> ba...@kernel.org; gre...@linuxfoundation.org;
> >>> peter.c...@freescale.com
> >>> Cc: dan.j.willi...@intel.com; jun...@freescale.com;
> >>> mathias.ny...@linux.intel.com; t...@atomide.com;
> >>> joao.pi...@synopsys.com; abres...@chromium.org;
> >>> r.bald...@samsung.com; linux-...@vger.kernel.org;
> >>> linux-kernel@vger.kernel.org; linux-o...@vger.kernel.org
> >>> Subject: Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core
> >>>
> >>> Hi,
> >>>
> >>> On 21/04/16 09:38, Jun Li wrote:
> >>>> Hi,
> >>>>
> >>>> ...
> >>>>>
> >>>>>  /**
> >>>>> + * usb_gadget_start - start the usb gadget controller and connect
> >>>>> +to bus
> >>>>> + * @gadget: the gadget device to start
> >>>>> + *
> >>>>> + * This is external API for use by OTG core.
> >>>>> + *
> >>>>> + * Start the usb device controller and connect to bus (enable pull).
> >>>>> + */
> >>>>> +static int usb_gadget_start(struct usb_gadget *gadget) {
> >>>>> +   int ret;
> >>>>> +   struct usb_udc *udc = NULL;
> >>>>> +
> >>>>> +   dev_dbg(&gadget->dev, "%s\n", __func__);
> >>>>> +   mutex_lock(&udc_lock);
> >>>>> +   list_for_each_entry(udc, &udc_list, list)
> >>>>> +   if (udc->gadget == gadget)
> >>>>> +   goto found;
> >>>>> +
> >>>>> +   dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
> >>>>> +   __func__);
> >>>>> +   mutex_unlock(&udc_lock);
> >>>>> +   return -EINVAL;
> >>>>> +
> >>>>> +found:
> >>>>> +   ret = usb_gadget_udc_start(udc);
> >>>>> +   if (ret)
> >>>>> +   dev_err(&udc->dev, "USB Device Controller didn't
> start: %d\n",
> >>>>> +   ret);
> >>>>> +   else
> >>>>> +   usb_udc_connect_control(udc);
> >>>>
> >>>> For drd, it's fine, but for real otg, gadget connect should be done
> >>>> by
> >>>> loc_conn() instead of gadget start.
> >>>
> >>> It is upto the OTG state machine to call gadget_start() when it
> >>> needs to connect to the bus (i.e. loc_conn()). I see no point in
> >>> calling gadget start before.
> >>>
> >>> Do you see any issue in doing so?
> >>
> >> This is what OTG state machine does:
> >> case OTG_STATE_B_PERIPHERAL:
> >>  otg_chrg_vbus(otg, 0);
> >>  otg_loc_sof(otg, 0);
> >>  otg_set_protocol(fsm, PROTO_GADGET);
> >>  otg_loc_conn(otg, 1);
> >>  break;
> 
> On second thoughts, after seen the OTG state machine.
> otg_set_protocol(fsm, PROTO_GADGET); is always followed by
> otg_loc_conn(otg, 1); And whenever protocol changes to anything other the
> PROTO_GADGET, we use otg_loc_conn(otg, 0);
> 
> So otg_loc_conn seems redundant. Can we just get rid of it?
> 
> usb_gadget_start() implies that gadget controller starts up and enables
> pull.
> usb_gadget_stop() implies that gadget controller disables pull and stops.
> 
> 
> Can you please explain why just these 2 APIs are not sufficient for full
> OTG?
> 
> Do we want anything to happen bet

RE: [PATCH v6 08/12] usb: hcd: Adapt to OTG core

[Jun Li]

Hi,

> -Original Message-
> From: Jun Li [mailto:jun...@nxp.com]
> Sent: Wednesday, April 27, 2016 8:50 PM
> To: Roger Quadros ; st...@rowland.harvard.edu;
> ba...@kernel.org; gre...@linuxfoundation.org; peter.c...@freescale.com
> Cc: dan.j.willi...@intel.com; jun...@freescale.com;
> mathias.ny...@linux.intel.com; t...@atomide.com; joao.pi...@synopsys.com;
> abres...@chromium.org; r.bald...@samsung.com; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-o...@vger.kernel.org
> Subject: RE: [PATCH v6 08/12] usb: hcd: Adapt to OTG core
> 
> Hi
> > -Original Message-
> > From: Roger Quadros [mailto:rog...@ti.com]
> > Sent: Wednesday, April 27, 2016 7:12 PM
> > To: Jun Li ; st...@rowland.harvard.edu;
> > ba...@kernel.org; gre...@linuxfoundation.org; peter.c...@freescale.com
> > Cc: dan.j.willi...@intel.com; jun...@freescale.com;
> > mathias.ny...@linux.intel.com; t...@atomide.com;
> > joao.pi...@synopsys.com; abres...@chromium.org; r.bald...@samsung.com;
> > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-o...@vger.kernel.org
> > Subject: Re: [PATCH v6 08/12] usb: hcd: Adapt to OTG core
> >
> > On 27/04/16 14:00, Roger Quadros wrote:
> > > On 27/04/16 13:16, Jun Li wrote:
> > >> Hi
> > >>
> > >>>
> > >>> +
> > >>> +static struct otg_hcd_ops otg_hcd_intf = {
> > >>> +   .add = usb_add_hcd,
> > >>> +   .remove = usb_remove_hcd,
> > >>> +   .usb_bus_start_enum = usb_bus_start_enum,
> > >>
> > >> Build break if CONFIG_USB_OTG is not enabled:
> > >>
> > >> drivers/built-in.o:(.data+0x1db30): undefined reference to
> > `usb_bus_start_enum'
> > >> Makefile:948: recipe for target 'vmlinux' failed
> > >> make: *** [vmlinux] Error 1
> >
> > I couldn't get this error. Could you please send me your .config? Thanks.
> 
> imx_v6_v7_defconfig

My bad, no problem now.

Li Jun

> 
> >
> > cheers,
> > -roger
> > >
> > > Thanks. Will fix it.
> > >
> > > cheers,
> > > -roger
> > >
> > >>
> > >>> +   .usb_control_msg = usb_control_msg,
> > >>> +   .usb_hub_find_child = usb_hub_find_child, };
> > >>> +
> > >>
> > > --
> > > 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 v6 08/12] usb: hcd: Adapt to OTG core

[Jun Li]

Hi
> -Original Message-
> From: Roger Quadros [mailto:rog...@ti.com]
> Sent: Wednesday, April 27, 2016 7:12 PM
> To: Jun Li ; st...@rowland.harvard.edu; ba...@kernel.org;
> gre...@linuxfoundation.org; peter.c...@freescale.com
> Cc: dan.j.willi...@intel.com; jun...@freescale.com;
> mathias.ny...@linux.intel.com; t...@atomide.com; joao.pi...@synopsys.com;
> abres...@chromium.org; r.bald...@samsung.com; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-o...@vger.kernel.org
> Subject: Re: [PATCH v6 08/12] usb: hcd: Adapt to OTG core
> 
> On 27/04/16 14:00, Roger Quadros wrote:
> > On 27/04/16 13:16, Jun Li wrote:
> >> Hi
> >>
> >>>
> >>> +
> >>> +static struct otg_hcd_ops otg_hcd_intf = {
> >>> + .add = usb_add_hcd,
> >>> + .remove = usb_remove_hcd,
> >>> + .usb_bus_start_enum = usb_bus_start_enum,
> >>
> >> Build break if CONFIG_USB_OTG is not enabled:
> >>
> >> drivers/built-in.o:(.data+0x1db30): undefined reference to
> `usb_bus_start_enum'
> >> Makefile:948: recipe for target 'vmlinux' failed
> >> make: *** [vmlinux] Error 1
> 
> I couldn't get this error. Could you please send me your .config? Thanks.

imx_v6_v7_defconfig

> 
> cheers,
> -roger
> >
> > Thanks. Will fix it.
> >
> > cheers,
> > -roger
> >
> >>
> >>> + .usb_control_msg = usb_control_msg,
> >>> + .usb_hub_find_child = usb_hub_find_child, };
> >>> +
> >>
> > --
> > 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 v6 08/12] usb: hcd: Adapt to OTG core

[Jun Li]

Hi

> 
> +
> +static struct otg_hcd_ops otg_hcd_intf = {
> + .add = usb_add_hcd,
> + .remove = usb_remove_hcd,
> + .usb_bus_start_enum = usb_bus_start_enum,

Build break if CONFIG_USB_OTG is not enabled:

drivers/built-in.o:(.data+0x1db30): undefined reference to `usb_bus_start_enum'
Makefile:948: recipe for target 'vmlinux' failed
make: *** [vmlinux] Error 1

Li Jun
 
> + .usb_control_msg = usb_control_msg,
> + .usb_hub_find_child = usb_hub_find_child, };
> +

RE: [PATCH v6 07/12] usb: otg: add OTG/dual-role core

[Jun Li]

Hi

> -Original Message-
> From: Peter Chen [mailto:hzpeterc...@gmail.com]
> Sent: Tuesday, April 26, 2016 2:28 PM
> To: Jun Li 
> Cc: Roger Quadros ; st...@rowland.harvard.edu;
> ba...@kernel.org; gre...@linuxfoundation.org; peter.c...@freescale.com;
> dan.j.willi...@intel.com; jun...@freescale.com;
> mathias.ny...@linux.intel.com; t...@atomide.com; joao.pi...@synopsys.com;
> abres...@chromium.org; r.bald...@samsung.com; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-o...@vger.kernel.org
> Subject: Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core
> 
> On Tue, Apr 26, 2016 at 05:11:36AM +, Jun Li wrote:
> > Hi
> >
> > > -Original Message-
> > > From: Peter Chen [mailto:hzpeterc...@gmail.com]
> > > Sent: Tuesday, April 26, 2016 11:47 AM
> > > To: Jun Li 
> > > Cc: Roger Quadros ; st...@rowland.harvard.edu;
> > > ba...@kernel.org; gre...@linuxfoundation.org;
> > > peter.c...@freescale.com; dan.j.willi...@intel.com;
> > > jun...@freescale.com; mathias.ny...@linux.intel.com;
> > > t...@atomide.com; joao.pi...@synopsys.com; abres...@chromium.org;
> > > r.bald...@samsung.com; linux-...@vger.kernel.org;
> > > linux-kernel@vger.kernel.org; linux-o...@vger.kernel.org
> > > Subject: Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core
> > >
> > > On Tue, Apr 26, 2016 at 02:07:56AM +, Jun Li wrote:
> > > > > +struct usb_otg *usb_otg_register(struct device *dev,
> > > > > +  struct usb_otg_config *config) {
> > > > > + struct usb_otg *otg;
> > > > > + struct otg_wait_data *wait;
> > > > > + int ret = 0;
> > > > > +
> > > > > + if (!dev || !config || !config->fsm_ops)
> > > > > + return ERR_PTR(-EINVAL);
> > > > > +
> > > > > + /* already in list? */
> > > > > + mutex_lock(&otg_list_mutex);
> > > > > + if (usb_otg_get_data(dev)) {
> > > > > + dev_err(dev, "otg: %s: device already in otg list\n",
> > > > > + __func__);
> > > > > + ret = -EINVAL;
> > > > > + goto unlock;
> > > > > + }
> > > > > +
> > > > > + /* allocate and add to list */
> > > > > + otg = kzalloc(sizeof(*otg), GFP_KERNEL);
> > > > > + if (!otg) {
> > > > > + ret = -ENOMEM;
> > > > > + goto unlock;
> > > > > + }
> > > > > +
> > > > > + otg->dev = dev;
> > > > > + otg->caps = config->otg_caps;
> > > > > +
> > > > > + if ((otg->caps->hnp_support || otg->caps->srp_support ||
> > > > > +  otg->caps->adp_support) && !config->otg_work)
> > > > > + dev_info(dev, "otg: limiting to dual-role\n");
> > > >
> > > > dev_err, this should be an error.
> > >
> > > The condition may be wrong, but it is an information to show that
> > > current OTG is dual-role.
> >
> > This should not happen in any correct design, I even doubt if we
> > should try to continue by "downgrade" it to be duel role, currently
> > the only example user is dual role, so doing like this can't be tested
> > by real case, this downgrade is not so easy like we image, at least
> > for chipidea otg driver, simply replace a queue worker may not work,
> > as we have much more difference between the 2 configs.
> >
> 
> Would you show more why chipidea can't work just replace the work item,
> and see if anything we still can improve for this framework?

In real OTG, we need enable AVV irq, but for duel role, nobody care/handle,
there are much more resource required for OTG: timers, hnp polling,
otg test device handling... 

with current design, chipidea driver can support real OTG with its own
queue worker, or DRD with Roger's drd work item if config is correct.

But improve something to work on a *wrong* config will make it complicated
and does not make much sense IMO.

Li Jun
> 
> --
> Best Regards,
> Peter Chen

RE: [PATCH v6 07/12] usb: otg: add OTG/dual-role core

[Jun Li]

Hi

> -Original Message-
> From: Peter Chen [mailto:hzpeterc...@gmail.com]
> Sent: Tuesday, April 26, 2016 11:47 AM
> To: Jun Li 
> Cc: Roger Quadros ; st...@rowland.harvard.edu;
> ba...@kernel.org; gre...@linuxfoundation.org; peter.c...@freescale.com;
> dan.j.willi...@intel.com; jun...@freescale.com;
> mathias.ny...@linux.intel.com; t...@atomide.com; joao.pi...@synopsys.com;
> abres...@chromium.org; r.bald...@samsung.com; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-o...@vger.kernel.org
> Subject: Re: [PATCH v6 07/12] usb: otg: add OTG/dual-role core
> 
> On Tue, Apr 26, 2016 at 02:07:56AM +, Jun Li wrote:
> > > +struct usb_otg *usb_otg_register(struct device *dev,
> > > +  struct usb_otg_config *config) {
> > > + struct usb_otg *otg;
> > > + struct otg_wait_data *wait;
> > > + int ret = 0;
> > > +
> > > + if (!dev || !config || !config->fsm_ops)
> > > + return ERR_PTR(-EINVAL);
> > > +
> > > + /* already in list? */
> > > + mutex_lock(&otg_list_mutex);
> > > + if (usb_otg_get_data(dev)) {
> > > + dev_err(dev, "otg: %s: device already in otg list\n",
> > > + __func__);
> > > + ret = -EINVAL;
> > > + goto unlock;
> > > + }
> > > +
> > > + /* allocate and add to list */
> > > + otg = kzalloc(sizeof(*otg), GFP_KERNEL);
> > > + if (!otg) {
> > > + ret = -ENOMEM;
> > > + goto unlock;
> > > + }
> > > +
> > > + otg->dev = dev;
> > > + otg->caps = config->otg_caps;
> > > +
> > > + if ((otg->caps->hnp_support || otg->caps->srp_support ||
> > > +  otg->caps->adp_support) && !config->otg_work)
> > > + dev_info(dev, "otg: limiting to dual-role\n");
> >
> > dev_err, this should be an error.
> 
> The condition may be wrong, but it is an information to show that current
> OTG is dual-role.

This should not happen in any correct design, I even doubt if we
should try to continue by "downgrade" it to be duel role, currently
the only example user is dual role, so doing like this can't be
tested by real case, this downgrade is not so easy like we image,
at least for chipidea otg driver, simply replace a queue worker may
not work, as we have much more difference between the 2 configs.

Li Jun
 
> 
> Peter
> >
> > > +
> > > + if (config->otg_work)   /* custom otg_work ? */
> > > + INIT_WORK(&otg->work, config->otg_work);
> > > + else
> > > + INIT_WORK(&otg->work, usb_otg_work);
> > > +
> > > + otg->wq = create_singlethread_workqueue("usb_otg");
> > > + if (!otg->wq) {
> > > + dev_err(dev, "otg: %s: can't create workqueue\n",
> > > + __func__);
> > > + ret = -ENOMEM;
> > > + goto err_wq;
> > > + }
> > > +
> > > + /* set otg ops */
> > > + otg->fsm.ops = config->fsm_ops;
> > > +
> > > + mutex_init(&otg->fsm.lock);
> > > +
> > > + list_add_tail(&otg->list, &otg_list);
> > > + mutex_unlock(&otg_list_mutex);
> > > +
> > > + /* were we in wait list? */
> > > + mutex_lock(&wait_list_mutex);
> > > + wait = usb_otg_get_wait(dev);
> > > + mutex_unlock(&wait_list_mutex);
> > > + if (wait) {
> > > + /* register pending host/gadget and flush from list */
> > > + usb_otg_flush_wait(dev);
> > > + }
> > > +
> > > + return otg;
> > > +
> > > +err_wq:
> > > + kfree(otg);
> > > +unlock:
> > > + mutex_unlock(&otg_list_mutex);
> > > + return ERR_PTR(ret);
> > > +}
> > > +EXPORT_SYMBOL_GPL(usb_otg_register);
> > > +
> >
> > --
> > 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
> 
> --
> Best Regards,
> Peter Chen

RE: [PATCH v6 07/12] usb: otg: add OTG/dual-role core

[Jun Li]

Hi Roger

> -Original Message-
> From: Roger Quadros [mailto:rog...@ti.com]
> Sent: Tuesday, April 05, 2016 10:05 PM
> To: st...@rowland.harvard.edu; ba...@kernel.org;
> gre...@linuxfoundation.org; peter.c...@freescale.com
> Cc: dan.j.willi...@intel.com; jun...@freescale.com;
> mathias.ny...@linux.intel.com; t...@atomide.com; joao.pi...@synopsys.com;
> abres...@chromium.org; r.bald...@samsung.com; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-o...@vger.kernel.org; Roger Quadros
> 
> Subject: [PATCH v6 07/12] usb: otg: add OTG/dual-role core
> 
> It provides APIs for the following tasks
> 
> - Registering an OTG/dual-role capable controller
> - Registering Host and Gadget controllers to OTG core
> - Providing inputs to and kicking the OTG state machine
> 
> Provide a dual-role device (DRD) state machine.
> DRD mode is a reduced functionality OTG mode. In this mode we don't
> support SRP, HNP and dynamic role-swap.
> 
> In DRD operation, the controller mode (Host or Peripheral) is decided
> based on the ID pin status. Once a cable plug (Type-A or Type-B) is
> attached the controller selects the state and doesn't change till the
> cable in unplugged and a different cable type is inserted.
> 
> As we don't need most of the complex OTG states and OTG timers we
> implement a lean DRD state machine in usb-otg.c.
> The DRD state machine is only interested in 2 hardware inputs 'id' and
> 'b_sess_vld'.
> 
> Signed-off-by: Roger Quadros 
> ---

...

> +/**
> + * Register pending host/gadget and remove entry from wait list  */
> +static void usb_otg_flush_wait(struct device *otg_dev) {
> + struct otg_wait_data *wait;
> + struct otg_hcd *host;
> + struct otg_gcd *gadget;
> +
> + mutex_lock(&wait_list_mutex);
> +
> + wait = usb_otg_get_wait(otg_dev);
> + if (!wait)
> + goto done;
> +
> + dev_dbg(otg_dev, "otg: registering pending host/gadget\n");
> + gadget = &wait->gcd;
> + if (gadget)

If (gadget->gadget)

> + usb_otg_register_gadget(gadget->gadget, gadget->ops);
> +
> + host = &wait->primary_hcd;
> + if (host->hcd)
> + usb_otg_register_hcd(host->hcd, host->irqnum, host->irqflags,
> +  host->ops);
> +
> + host = &wait->shared_hcd;
> + if (host->hcd)
> + usb_otg_register_hcd(host->hcd, host->irqnum, host->irqflags,
> +  host->ops);
> +
> + list_del(&wait->list);
> + kfree(wait);
> +
> +done:
> + mutex_unlock(&wait_list_mutex);
> +}
> +
> +/**
> + * Check if the OTG device is in our OTG list and return
> + * usb_otg data, else NULL.
> + *
> + * otg_list_mutex must be held.
> + */
> +static struct usb_otg *usb_otg_get_data(struct device *otg_dev) {
> + struct usb_otg *otg;
> +
> + if (!otg_dev)
> + return NULL;
> +
> + list_for_each_entry(otg, &otg_list, list) {
> + if (otg->dev == otg_dev)
> + return otg;
> + }
> +
> + return NULL;
> +}

Could you export it to be a public API, we may need access usb_otg
in common host driver for handling of enumeration of otg test device.

...

> +/**
> + * Called when entering a DRD state.
> + * fsm->lock must be held.
> + */
> +static void drd_set_state(struct otg_fsm *fsm, enum usb_otg_state
> +new_state) {
> + struct usb_otg *otg = container_of(fsm, struct usb_otg, fsm);
> +
> + if (otg->state == new_state)
> + return;
> +
> + fsm->state_changed = 1;
> + dev_dbg(otg->dev, "otg: set state: %s\n",
> + usb_otg_state_string(new_state));
> + switch (new_state) {
> + case OTG_STATE_B_IDLE:
> + drd_set_protocol(fsm, PROTO_UNDEF);
> + otg_drv_vbus(otg, 0);
> + break;
> + case OTG_STATE_B_PERIPHERAL:
> + drd_set_protocol(fsm, PROTO_GADGET);
> + otg_drv_vbus(otg, 0);
> + break;
> + case OTG_STATE_A_HOST:
> + drd_set_protocol(fsm, PROTO_HOST);
> + otg_drv_vbus(otg, 1);
> + break;
> + case OTG_STATE_UNDEFINED:
> + case OTG_STATE_B_SRP_INIT:
> + case OTG_STATE_B_WAIT_ACON:
> + case OTG_STATE_B_HOST:
> + case OTG_STATE_A_IDLE:
> + case OTG_STATE_A_WAIT_VRISE:
> + case OTG_STATE_A_WAIT_BCON:
> + case OTG_STATE_A_SUSPEND:
> + case OTG_STATE_A_PERIPHERAL:
> + case OTG_STATE_A_WAIT_VFALL:
> + case OTG_STATE_A_VBUS_ERR:

Remove above unused states.

> + default:
> + dev_warn(otg->dev, "%s: otg: invalid state: %s\n",
> +  __func__, usb_otg_state_string(new_state));
> + break;
> + }
> +
> + otg->state = new_state;
> +}
> +
> +/**
> + * DRD state change judgement
> + *
> + * For DRD we're only interested in some of the OTG states
> + * i.e. OTG_STATE_B_IDLE: both peripheral and host are stopped
> + *   OTG_STATE_B_PERIPHERAL: peripheral active
> + *   OTG_STATE_A_HOST: host active
> 

RE: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core

[Jun Li]

Hi

> -Original Message-
> From: Roger Quadros [mailto:rog...@ti.com]
> Sent: Monday, April 25, 2016 10:04 PM
> To: Jun Li ; st...@rowland.harvard.edu; ba...@kernel.org;
> gre...@linuxfoundation.org; peter.c...@freescale.com
> Cc: dan.j.willi...@intel.com; jun...@freescale.com;
> mathias.ny...@linux.intel.com; t...@atomide.com; joao.pi...@synopsys.com;
> abres...@chromium.org; r.bald...@samsung.com; linux-...@vger.kernel.org;
> linux-kernel@vger.kernel.org; linux-o...@vger.kernel.org
> Subject: Re: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core
> 
> Hi,
> 
> On 21/04/16 09:38, Jun Li wrote:
> > Hi,
> >
> > ...
> >>
> >>  /**
> >> + * usb_gadget_start - start the usb gadget controller and connect to
> >> +bus
> >> + * @gadget: the gadget device to start
> >> + *
> >> + * This is external API for use by OTG core.
> >> + *
> >> + * Start the usb device controller and connect to bus (enable pull).
> >> + */
> >> +static int usb_gadget_start(struct usb_gadget *gadget) {
> >> +  int ret;
> >> +  struct usb_udc *udc = NULL;
> >> +
> >> +  dev_dbg(&gadget->dev, "%s\n", __func__);
> >> +  mutex_lock(&udc_lock);
> >> +  list_for_each_entry(udc, &udc_list, list)
> >> +  if (udc->gadget == gadget)
> >> +  goto found;
> >> +
> >> +  dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
> >> +  __func__);
> >> +  mutex_unlock(&udc_lock);
> >> +  return -EINVAL;
> >> +
> >> +found:
> >> +  ret = usb_gadget_udc_start(udc);
> >> +  if (ret)
> >> +  dev_err(&udc->dev, "USB Device Controller didn't start: %d\n",
> >> +  ret);
> >> +  else
> >> +  usb_udc_connect_control(udc);
> >
> > For drd, it's fine, but for real otg, gadget connect should be done by
> > loc_conn() instead of gadget start.
> 
> It is upto the OTG state machine to call gadget_start() when it needs to
> connect to the bus (i.e. loc_conn()). I see no point in calling gadget
> start before.
> 
> Do you see any issue in doing so?

This is what OTG state machine does:
case OTG_STATE_B_PERIPHERAL:
 otg_chrg_vbus(otg, 0);
 otg_loc_sof(otg, 0);
 otg_set_protocol(fsm, PROTO_GADGET);
 otg_loc_conn(otg, 1);
 break;

You intend to abstract something common in this api when start gadget,
which should be called by otg_set_protocol(fsm, PROTO_GADGET); and
drd_set_protocol(fsm, PROTO_GADGET); right?

So you may move usb_udc_connect_control(IMO usb_gadget_connect()
is better)out of usb_gadget_start(), then for drd:

case OTG_STATE_B_PERIPHERAL:
 drd_set_protocol(fsm, PROTO_GADGET);
 otg_drv_vbus(otg, 0);
 usb_gadget_connect();

Li Jun

> 
> cheers,
> -roger
> 
> >
> >> +
> >> +  mutex_unlock(&udc_lock);
> >> +
> >> +  return ret;
> >> +}
> >> +
> >> +/**
> >> + * usb_gadget_stop - disconnect from bus and stop the usb gadget
> >> + * @gadget: The gadget device we want to stop
> >> + *
> >> + * This is external API for use by OTG core.
> >> + *
> >> + * Disconnect from the bus (disable pull) and stop the
> >> + * gadget controller.
> >> + */
> >> +static int usb_gadget_stop(struct usb_gadget *gadget) {
> >> +  struct usb_udc *udc = NULL;
> >> +
> >> +  dev_dbg(&gadget->dev, "%s\n", __func__);
> >> +  mutex_lock(&udc_lock);
> >> +  list_for_each_entry(udc, &udc_list, list)
> >> +  if (udc->gadget == gadget)
> >> +  goto found;
> >> +
> >> +  dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
> >> +  __func__);
> >> +  mutex_unlock(&udc_lock);
> >> +  return -EINVAL;
> >> +
> >> +found:
> >> +  usb_gadget_disconnect(udc->gadget);
> >
> > Likewise, gadget disconnect also should be done by loc_conn() instead
> > of gadget stop.
> >
> >> +  udc->driver->disconnect(udc->gadget);
> >> +  usb_gadget_udc_stop(udc);
> >> +  mutex_unlock(&udc_lock);
> >> +
> >> +  return 0;
> >> +}
> >> +
> >
> > Li Jun
> >

RE: [PATCH v6 09/12] usb: gadget: udc: adapt to OTG core

[Jun Li]

Hi,

...
> 
>  /**
> + * usb_gadget_start - start the usb gadget controller and connect to
> +bus
> + * @gadget: the gadget device to start
> + *
> + * This is external API for use by OTG core.
> + *
> + * Start the usb device controller and connect to bus (enable pull).
> + */
> +static int usb_gadget_start(struct usb_gadget *gadget) {
> + int ret;
> + struct usb_udc *udc = NULL;
> +
> + dev_dbg(&gadget->dev, "%s\n", __func__);
> + mutex_lock(&udc_lock);
> + list_for_each_entry(udc, &udc_list, list)
> + if (udc->gadget == gadget)
> + goto found;
> +
> + dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
> + __func__);
> + mutex_unlock(&udc_lock);
> + return -EINVAL;
> +
> +found:
> + ret = usb_gadget_udc_start(udc);
> + if (ret)
> + dev_err(&udc->dev, "USB Device Controller didn't start: %d\n",
> + ret);
> + else
> + usb_udc_connect_control(udc);

For drd, it's fine, but for real otg, gadget connect should be done
by loc_conn() instead of gadget start.

> +
> + mutex_unlock(&udc_lock);
> +
> + return ret;
> +}
> +
> +/**
> + * usb_gadget_stop - disconnect from bus and stop the usb gadget
> + * @gadget: The gadget device we want to stop
> + *
> + * This is external API for use by OTG core.
> + *
> + * Disconnect from the bus (disable pull) and stop the
> + * gadget controller.
> + */
> +static int usb_gadget_stop(struct usb_gadget *gadget) {
> + struct usb_udc *udc = NULL;
> +
> + dev_dbg(&gadget->dev, "%s\n", __func__);
> + mutex_lock(&udc_lock);
> + list_for_each_entry(udc, &udc_list, list)
> + if (udc->gadget == gadget)
> + goto found;
> +
> + dev_err(gadget->dev.parent, "%s: gadget not registered.\n",
> + __func__);
> + mutex_unlock(&udc_lock);
> + return -EINVAL;
> +
> +found:
> + usb_gadget_disconnect(udc->gadget);

Likewise, gadget disconnect also should be done by loc_conn()
instead of gadget stop.

> + udc->driver->disconnect(udc->gadget);
> + usb_gadget_udc_stop(udc);
> + mutex_unlock(&udc_lock);
> +
> + return 0;
> +}
> +

Li Jun

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

[Jun Li]

Hi

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Monday, April 11, 2016 7:15 PM
> To: Jun Li 
> Cc: ba...@kernel.org; gre...@linuxfoundation.org; s...@kernel.org;
> dbarysh...@gmail.com; dw...@infradead.org; 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;
> linux...@vger.kernel.org; linux-...@vger.kernel.org; device-
> mainlin...@lists.linuxfoundation.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v10 1/4] gadget: Introduce the usb charger framework
> 
> Hi Jun,
> 
> Sorry for late reply.
> 
> >> >> >> >> +/*
> >> >> >> >> + * usb_charger_detect_type() - detect the charger type
> manually.
> >> >> >> >> + * @uchger - usb charger device
> >> >> >> >> + *
> >> >> >> >> + * Note: You should ensure you need to detect the charger
> >> >> >> >> +type manually on your
> >> >> >> >> + * platform.
> >> >> >> >> + * You should call it at the right gadget state to avoid
> >> >> >> >> +affecting gadget
> >> >> >> >> + * enumeration.
> >> >> >> >> + */
> >> >> >> >> +int usb_charger_detect_type(struct usb_charger *uchger) {
> >> >> >> >> + enum usb_charger_type type;
> >> >> >> >> +
> >> >> >> >> + if (WARN(!uchger->charger_detect,
> >> >> >> >> +  "charger detection method should not be NULL"))
> >> >> >> >> + return -EINVAL;
> >> >> >> >> +
> >> >> >> >> + type = uchger->charger_detect(uchger);
> >> >> >> >> +
> >> >> >> >> + mutex_lock(&uchger->lock);
> >> >> >> >> + uchger->type = type;
> >> >> >> >> + mutex_unlock(&uchger->lock);
> >> >> >> >> +
> >> >> >> >> + return 0;
> >> >> >> >> +}
> >> >> >> >> +EXPORT_SYMBOL_GPL(usb_charger_detect_type);
> >> >> >> >
> >> >> >> > I still recommend have a central place to call
> >> >> >> > usb_charger_detect_type() to cover real charger detection
> >> >> >> > instead of leaving this question open to diff users. This can
> >> >> >> > be done after vbus-on is detected and before do gadget
> >> >> >> > connect. I don't think this
> >> >> >> will make your framework complicated.
> >> >> >>
> >> >> >> This API is used for detecting the charger type manually
> >> >> >> (software charger detection), so if user's udc driver is needed
> >> >> >> to do this, then they can issue it at their right place to make
> it more flexible.
> >> >> >> But let us see other people's suggestion. Thanks.
> >> >> >
> >> >> > Ok, actually this API can be used for what ever charger
> >> >> > detection type, user can implement any method(manual detection,
> >> >> > directly read result from some HW...what ever) in
> >> >> > uchger->charger_detect(), target is
> >> >>
> >> >> But reading result from some HW dose not means *detect*, actually
> >> >> is
> >> *get*.
> >> >> We can not mix them together with the different semantics.
> >> >
> >> > It doesn’t matter here, you already define the _get_ API for just
> >> > read the charger type from the saved value(uchger->type), so we can
> >> > think the API to make uchger->type from UNKNOW to ONE KNOWN type is
> >> > *detect*, because we don't need 2 separate API one for *get* type
> >> > from HW and another one for *detect* from HW, only one API involve
> >> > HW access
> >> is enough.
> >>
> >> But another issue is some users may need to get the charger type from
> >> power supply by "power_supply_get_property()" function, we need to
> >> integrate with the power supply things in th

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

[Jun Li]

Hi

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Friday, April 08, 2016 7:51 PM
> To: Jun Li 
> Cc: ba...@kernel.org; gre...@linuxfoundation.org; s...@kernel.org;
> dbarysh...@gmail.com; dw...@infradead.org; 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;
> linux...@vger.kernel.org; linux-...@vger.kernel.org; device-
> mainlin...@lists.linuxfoundation.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v10 1/4] gadget: Introduce the usb charger framework
> 
> On 8 April 2016 at 19:27, Jun Li  wrote:
> >
> >
> >> -Original Message-
> >> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> >> Sent: Friday, April 08, 2016 7:00 PM
> >> To: Jun Li 
> >> Cc: ba...@kernel.org; gre...@linuxfoundation.org; s...@kernel.org;
> >> dbarysh...@gmail.com; dw...@infradead.org; 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;
> >> linux...@vger.kernel.org; linux-...@vger.kernel.org; device-
> >> mainlin...@lists.linuxfoundation.org; linux-kernel@vger.kernel.org
> >> Subject: Re: [PATCH v10 1/4] gadget: Introduce the usb charger
> >> framework
> >>
> >> Hi Jun,
> >>
> >> >> >> +/*
> >> >> >> + * usb_charger_detect_type() - detect the charger type manually.
> >> >> >> + * @uchger - usb charger device
> >> >> >> + *
> >> >> >> + * Note: You should ensure you need to detect the charger type
> >> >> >> +manually on your
> >> >> >> + * platform.
> >> >> >> + * You should call it at the right gadget state to avoid
> >> >> >> +affecting gadget
> >> >> >> + * enumeration.
> >> >> >> + */
> >> >> >> +int usb_charger_detect_type(struct usb_charger *uchger) {
> >> >> >> + enum usb_charger_type type;
> >> >> >> +
> >> >> >> + if (WARN(!uchger->charger_detect,
> >> >> >> +  "charger detection method should not be NULL"))
> >> >> >> + return -EINVAL;
> >> >> >> +
> >> >> >> + type = uchger->charger_detect(uchger);
> >> >> >> +
> >> >> >> + mutex_lock(&uchger->lock);
> >> >> >> + uchger->type = type;
> >> >> >> + mutex_unlock(&uchger->lock);
> >> >> >> +
> >> >> >> + return 0;
> >> >> >> +}
> >> >> >> +EXPORT_SYMBOL_GPL(usb_charger_detect_type);
> >> >> >
> >> >> > I still recommend have a central place to call
> >> >> > usb_charger_detect_type() to cover real charger detection
> >> >> > instead of leaving this question open to diff users. This can be
> >> >> > done after vbus-on is detected and before do gadget connect. I
> >> >> > don't think this
> >> >> will make your framework complicated.
> >> >>
> >> >> This API is used for detecting the charger type manually (software
> >> >> charger detection), so if user's udc driver is needed to do this,
> >> >> then they can issue it at their right place to make it more flexible.
> >> >> But let us see other people's suggestion. Thanks.
> >> >
> >> > Ok, actually this API can be used for what ever charger detection
> >> > type, user can implement any method(manual detection, directly read
> >> > result from some HW...what ever) in uchger->charger_detect(),
> >> > target is
> >>
> >> But reading result from some HW dose not means *detect*, actually is
> *get*.
> >> We can not mix them together with the different semantics.
> >
> > It doesn’t matter here, you already define the _get_ API for just read
> > the charger type from the saved value(uchger->type), so we can think
> > the API to make uchger->type from UNKNOW to ONE KNOWN type is
> > *detect*, because we don't need 2 separ

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

[Jun Li]

Hi

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Friday, April 08, 2016 5:56 PM
> To: Jun Li 
> Cc: ba...@kernel.org; gre...@linuxfoundation.org; s...@kernel.org;
> dbarysh...@gmail.com; dw...@infradead.org; 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;
> linux...@vger.kernel.org; linux-...@vger.kernel.org; device-
> mainlin...@lists.linuxfoundation.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v10 1/4] gadget: Introduce the usb charger framework
> 
> Hi Jun,
> 
> On 8 April 2016 at 16:04, Jun Li  wrote:
> > Hi, Baolin
> >
> >> +/*
> >> + * usb_charger_detect_type() - detect the charger type manually.
> >> + * @uchger - usb charger device
> >> + *
> >> + * Note: You should ensure you need to detect the charger type
> >> +manually on your
> >> + * platform.
> >> + * You should call it at the right gadget state to avoid affecting
> >> +gadget
> >> + * enumeration.
> >> + */
> >> +int usb_charger_detect_type(struct usb_charger *uchger) {
> >> + enum usb_charger_type type;
> >> +
> >> + if (WARN(!uchger->charger_detect,
> >> +  "charger detection method should not be NULL"))
> >> + return -EINVAL;
> >> +
> >> + type = uchger->charger_detect(uchger);
> >> +
> >> + mutex_lock(&uchger->lock);
> >> + uchger->type = type;
> >> + mutex_unlock(&uchger->lock);
> >> +
> >> + return 0;
> >> +}
> >> +EXPORT_SYMBOL_GPL(usb_charger_detect_type);
> >
> > I still recommend have a central place to call
> > usb_charger_detect_type() to cover real charger detection instead of
> > leaving this question open to diff users. This can be done after
> > vbus-on is detected and before do gadget connect. I don't think this
> will make your framework complicated.
> 
> This API is used for detecting the charger type manually (software charger
> detection), so if user's udc driver is needed to do this, then they can
> issue it at their right place to make it more flexible. But let us see
> other people's suggestion. Thanks.

Ok, actually this API can be used for what ever charger detection
type, user can implement any method(manual detection, directly read
result from some HW...what ever) in uchger->charger_detect(), target is
to have the charger type and set uchger->type, then you no need to add the 
comments/description to limit it usage. Also I do see there is possible
central place to do this.

> 
> >
> > Hi Felipe, what do you think of this?
> >
> > Li Jun
> >
> >> +
> >> +/*
> >> + * usb_charger_get_type_by_others() - Get the usb charger type by
> >> +the callback
> >> + * which is implemented by users.
> >> + * @uchger - the usb charger device.
> >> + *
> >> + * Note: This function is just used for getting the charger type,
> >> +not for
> >> + * detecting charger type which might affect the DP/DM line when
> >> +gadget is on
> >> + * enumeration state.
> >> + */
> >> +static enum usb_charger_type
> >> +usb_charger_get_type_by_others(struct usb_charger *uchger) {
> >> + if (uchger->type != UNKNOWN_TYPE)
> >> + return uchger->type;
> >> +
> >> + if (uchger->psy) {
> >> + union power_supply_propval val;
> >> +
> >> + power_supply_get_property(uchger->psy,
> >> +   POWER_SUPPLY_PROP_CHARGE_TYPE,
> >> +   &val);
> >> + switch (val.intval) {
> >> + case POWER_SUPPLY_TYPE_USB:
> >> + uchger->type = SDP_TYPE;
> >> + break;
> >> + case POWER_SUPPLY_TYPE_USB_DCP:
> >> + uchger->type = DCP_TYPE;
> >> + break;
> >> + case POWER_SUPPLY_TYPE_USB_CDP:
> >> + uchger->type = CDP_TYPE;
> >> + break;
> >> + case POWER_SUPPLY_TYPE_USB_ACA:
> >> + uchger->type = ACA_TYPE;
> >> + break;
> >> + default:
> >> + uchger->type = UNKNOWN_TYPE;
> >> + break;
> >> + }
> >> + } else if (uchger->get_charger_type) {
> >> + uchger->type = uchger->get_charger_type(uchger);
> >> + } else {
> >> + uchger->type = UNKNOWN_TYPE;
> >> + }
> >> +
> >> + return uchger->type;
> >> +}
> >> +
> 
> 
> 
> --
> Baolin.wang
> Best Regards

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

[Jun Li]

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Friday, April 08, 2016 7:00 PM
> To: Jun Li 
> Cc: ba...@kernel.org; gre...@linuxfoundation.org; s...@kernel.org;
> dbarysh...@gmail.com; dw...@infradead.org; 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;
> linux...@vger.kernel.org; linux-...@vger.kernel.org; device-
> mainlin...@lists.linuxfoundation.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v10 1/4] gadget: Introduce the usb charger framework
> 
> Hi Jun,
> 
> >> >> +/*
> >> >> + * usb_charger_detect_type() - detect the charger type manually.
> >> >> + * @uchger - usb charger device
> >> >> + *
> >> >> + * Note: You should ensure you need to detect the charger type
> >> >> +manually on your
> >> >> + * platform.
> >> >> + * You should call it at the right gadget state to avoid
> >> >> +affecting gadget
> >> >> + * enumeration.
> >> >> + */
> >> >> +int usb_charger_detect_type(struct usb_charger *uchger) {
> >> >> + enum usb_charger_type type;
> >> >> +
> >> >> + if (WARN(!uchger->charger_detect,
> >> >> +  "charger detection method should not be NULL"))
> >> >> + return -EINVAL;
> >> >> +
> >> >> + type = uchger->charger_detect(uchger);
> >> >> +
> >> >> + mutex_lock(&uchger->lock);
> >> >> + uchger->type = type;
> >> >> + mutex_unlock(&uchger->lock);
> >> >> +
> >> >> + return 0;
> >> >> +}
> >> >> +EXPORT_SYMBOL_GPL(usb_charger_detect_type);
> >> >
> >> > I still recommend have a central place to call
> >> > usb_charger_detect_type() to cover real charger detection instead
> >> > of leaving this question open to diff users. This can be done after
> >> > vbus-on is detected and before do gadget connect. I don't think
> >> > this
> >> will make your framework complicated.
> >>
> >> This API is used for detecting the charger type manually (software
> >> charger detection), so if user's udc driver is needed to do this,
> >> then they can issue it at their right place to make it more flexible.
> >> But let us see other people's suggestion. Thanks.
> >
> > Ok, actually this API can be used for what ever charger detection
> > type, user can implement any method(manual detection, directly read
> > result from some HW...what ever) in uchger->charger_detect(), target
> > is
> 
> But reading result from some HW dose not means *detect*, actually is *get*.
> We can not mix them together with the different semantics.

It doesn’t matter here, you already define the _get_ API for just read
the charger type from the saved value(uchger->type), so we can think
the API to make uchger->type from UNKNOW to ONE KNOWN type is *detect*,
because we don't need 2 separate API one for *get* type from HW and another
one for *detect* from HW, only one API involve HW access is enough.

- Detect: (write to and) read from HW to get the charger type,
  save to uchger->type;
- Get: read the charger type from uchger->type.
 
> 
> > to have the charger type and set uchger->type, then you no need to add
> > the comments/description to limit it usage. Also I do see there is
> possible central place to do this.
> >
> 
> --
> Baolin.wang
> Best Regards

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

[Jun Li]

Hi, Baolin

> -Original Message-
> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> ow...@vger.kernel.org] On Behalf Of Baolin Wang
> Sent: Thursday, April 07, 2016 7:49 PM
> To: ba...@kernel.org; gre...@linuxfoundation.org; s...@kernel.org;
> dbarysh...@gmail.com; dw...@infradead.org
> Cc: 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: [PATCH v10 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 
> ---
>  drivers/usb/gadget/Kconfig   |7 +
>  drivers/usb/gadget/udc/Makefile  |1 +
>  drivers/usb/gadget/udc/charger.c |  729
> ++
>  include/linux/usb/charger.h  |  173 +
>  include/uapi/linux/usb/charger.h |   31 ++
>  5 files changed, 941 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
> 

...

> +
> +/*
> + * usb_charger_detect_type() - detect the charger type manually.
> + * @uchger - usb charger device
> + *
> + * Note: You should ensure you need to detect the charger type manually
> +on your
> + * platform.
> + * You should call it at the right gadget state to avoid affecting
> +gadget
> + * enumeration.
> + */
> +int usb_charger_detect_type(struct usb_charger *uchger) {
> + enum usb_charger_type type;
> +
> + if (WARN(!uchger->charger_detect,
> +  "charger detection method should not be NULL"))
> + return -EINVAL;
> +
> + type = uchger->charger_detect(uchger);
> +
> + mutex_lock(&uchger->lock);
> + uchger->type = type;
> + mutex_unlock(&uchger->lock);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(usb_charger_detect_type);

I still recommend have a central place to call usb_charger_detect_type()
to cover real charger detection instead of leaving this question open to
diff users. This can be done after vbus-on is detected and before do gadget
connect. I don't think this will make your framework complicated.

Hi Felipe, what do you think of this?

Li Jun

> +
> +/*
> + * usb_charger_get_type_by_others() - Get the usb charger type by the
> +callback
> + * which is implemented by users.
> + * @uchger - the usb charger device.
> + *
> + * Note: This function is just used for getting the charger type, not
> +for
> + * detecting charger type which might affect the DP/DM line when gadget
> +is on
> + * enumeration state.
> + */
> +static enum usb_charger_type
> +usb_charger_get_type_by_others(struct usb_charger *uchger) {
> + if (uchger->type != UNKNOWN_TYPE)
> + return uchger->type;
> +
> + if (uchger->psy) {
> + union power_supply_propval val;
> +
> + power_supply_get_property(uchger->psy,
> +   POWER_SUPPLY_PROP_CHARGE_TYPE,
> +   &val);
> + switch (val.intval) {
> + case POWER_SUPPLY_TYPE_USB:
> + uchger->type = SDP_TYPE;
> + break;
> + case POWER_SUPPLY_TYPE_USB_DCP:
> + uchger->type = DCP_TYPE;
> + break;
> + case POWER_SUPPLY_TYPE_USB_CDP:
> + uchger->type = CDP_TYPE;
> + break;
> + case POWER_SUPPLY_TYPE_USB_ACA:
> + uchger->type = ACA_TYPE;
> + break;
> + default:
> + uchger->type = UNKNOWN_TYPE;
> +  

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

[Jun Li]

Hi

> -Original Message-
> From: Felipe Balbi [mailto:ba...@kernel.org]
> Sent: Wednesday, April 06, 2016 8:56 PM
> To: Jun Li ; Baolin Wang ; Peter
> Chen 
> Cc: Greg KH ; Sebastian Reichel
> ; Dmitry Eremin-Solenikov ; David
> Woodhouse ; Peter Chen ;
> Alan Stern ; r.bald...@samsung.com; Yoshihiro
> Shimoda ; Lee Jones
> ; Mark Brown ; Charles Keepax
> ; patc...@opensource.wolfsonmicro.com;
> Linux PM list ; USB ;
> device-mainlin...@lists.linuxfoundation.org; LKML  ker...@vger.kernel.org>
> Subject: RE: [PATCH v9 2/4] gadget: Support for the usb charger framework
> 
> 
> Hi,
> 
> Jun Li  writes:
> >> >> On 6 April 2016 at 15:19, Peter Chen  wrote:
> >> >> > On Fri, Apr 01, 2016 at 03:21:50PM +0800, Baolin Wang wrote:
> >> >> >>
> >> >> >> @@ -563,6 +564,8 @@ struct usb_gadget_ops {
> >> >> >>   struct usb_ep *(*match_ep)(struct usb_gadget *,
> >> >> >>   struct usb_endpoint_descriptor *,
> >> >> >>   struct usb_ss_ep_comp_descriptor *);
> >> >> >> + /* get the charger type */
> >> >> >> + enum usb_charger_type (*get_charger_type)(struct
> >> >> >> + usb_gadget *);
> >> >> >>  };
> >> >> >
> >> >> > Since we already have get_charger_type callback at usb_charger
> >> >> > structure, why we still need this API at usb_gadget_ops?
> >> >>
> >> >> In case some users want to get charger type at gadget level.
> >> >>
> >> > Why gadget needs to know charger type? I also don't catch the
> >> > intent of
> >>
> >> because some gadgets need to call usb_gadget_vbus_draw(), although
> >> for that they need power in mA rather.
> >
> > In below change of usb_gadget_vbus_draw(), already can get charger
> > type via usb_charger_get_type().
> >
> > static inline int usb_gadget_vbus_draw(struct usb_gadget *gadget,
> > unsigned mA)  {
> > +   enum usb_charger_type type;
> > +
> > +   if (gadget->charger) {
> > +   type = usb_charger_get_type(gadget->charger);
> > +   usb_charger_set_cur_limit_by_type(gadget->charger, type,
> mA);
> > +   }
> > +
> > if (!gadget->ops->vbus_draw)
> > return -EOPNOTSUPP;
> > return gadget->ops->vbus_draw(gadget, mA);
> >
> > Could you detail in what situation gadget->ops-> get_charger_type() is
> used?
> 
> isn't it right there in the code ? Isn't usb_gadget_vbus_draw() calling
> it ? What did I miss here ?

Well, that's true, so my real meaning is why gadget need get charger type
via another new api gadget->ops->get_charger_type().
 
> 
> >> > This api, as my understanding, gadget only need report gadget state
> >> changes.
> >> > All information required for usb charger is charger type and gadget
> >> state.
> >>
> >> you're making an assumption about how the HW is laid out which might
> >> not be true.
> >>
> >
> > What other information you refer to here? Or what I am not aware of?
> 
> what I'm trying to say is that you're assuming gadgets don't need to know
> anything other than charger type and gadget state (suspended, resume,
> enumerated, default state, addressed, etc), but that might not be true for
> all UDCs. You can't make that assumption that charger type and gadget
> state is enough. The real question is what do we need *now*, but still
> keep in mind that what we need *now* might be valid 2 years from now, so
> API needs to be a little flexible.

Get your point, flexible, I just thought create an api without any user
for existing case/spec, wouldn't it be better to let the real user add it
later when it's needed.

> 
> cheers
> 
> --
> balbi

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

[Jun Li]

> -Original Message-
> From: Felipe Balbi [mailto:ba...@kernel.org]
> Sent: Wednesday, April 06, 2016 8:22 PM
> To: Jun Li ; Baolin Wang ; Peter
> Chen 
> Cc: Greg KH ; Sebastian Reichel
> ; Dmitry Eremin-Solenikov ; David
> Woodhouse ; Peter Chen ;
> Alan Stern ; r.bald...@samsung.com; Yoshihiro
> Shimoda ; Lee Jones
> ; Mark Brown ; Charles Keepax
> ; patc...@opensource.wolfsonmicro.com;
> Linux PM list ; USB ;
> device-mainlin...@lists.linuxfoundation.org; LKML  ker...@vger.kernel.org>
> Subject: RE: [PATCH v9 2/4] gadget: Support for the usb charger framework
> 
> 
> Hi,
> 
> Jun Li  writes:
> >> -Original Message-
> >> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> >> ow...@vger.kernel.org] On Behalf Of Baolin Wang
> >> Sent: Wednesday, April 06, 2016 6:47 PM
> >> To: Peter Chen 
> >> Cc: Felipe Balbi ; Greg KH
> >> ; Sebastian Reichel ;
> >> Dmitry Eremin-Solenikov ; David Woodhouse
> >> ; Peter Chen ; Alan
> >> Stern ; r.bald...@samsung.com; Yoshihiro
> >> Shimoda ; Lee Jones
> >> ; Mark Brown ; Charles
> >> Keepax ;
> >> patc...@opensource.wolfsonmicro.com;
> >> Linux PM list ; USB
> >> ;
> >> device-mainlin...@lists.linuxfoundation.org; LKML  >> ker...@vger.kernel.org>
> >> Subject: Re: [PATCH v9 2/4] gadget: Support for the usb charger
> >> framework
> >>
> >> On 6 April 2016 at 15:19, Peter Chen  wrote:
> >> > On Fri, Apr 01, 2016 at 03:21:50PM +0800, Baolin Wang wrote:
> >> >>
> >> >> @@ -563,6 +564,8 @@ struct usb_gadget_ops {
> >> >>   struct usb_ep *(*match_ep)(struct usb_gadget *,
> >> >>   struct usb_endpoint_descriptor *,
> >> >>   struct usb_ss_ep_comp_descriptor *);
> >> >> + /* get the charger type */
> >> >> + enum usb_charger_type (*get_charger_type)(struct usb_gadget
> >> >> + *);
> >> >>  };
> >> >
> >> > Since we already have get_charger_type callback at usb_charger
> >> > structure, why we still need this API at usb_gadget_ops?
> >>
> >> In case some users want to get charger type at gadget level.
> >>
> > Why gadget needs to know charger type? I also don't catch the intent
> > of
> 
> because some gadgets need to call usb_gadget_vbus_draw(), although for
> that they need power in mA rather.

In below change of usb_gadget_vbus_draw(), already can get charger type
via usb_charger_get_type().

static inline int usb_gadget_vbus_draw(struct usb_gadget *gadget, unsigned mA)
 {
+   enum usb_charger_type type;
+
+   if (gadget->charger) {
+   type = usb_charger_get_type(gadget->charger);
+   usb_charger_set_cur_limit_by_type(gadget->charger, type, mA);
+   }
+
if (!gadget->ops->vbus_draw)
return -EOPNOTSUPP;
return gadget->ops->vbus_draw(gadget, mA);

Could you detail in what situation gadget->ops-> get_charger_type() is used?

> 
> > This api, as my understanding, gadget only need report gadget state
> changes.
> > All information required for usb charger is charger type and gadget
> state.
> 
> you're making an assumption about how the HW is laid out which might not
> be true.
> 

What other information you refer to here? Or what I am not aware of?

Thanks.
Li Jun  

> --
> balbi