Re: [PATCH] usb: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume

[Baolin Wang]

On 5 March 2018 at 19:14, Roger Quadros <rog...@ti.com> wrote:
> On 05/03/18 13:06, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Baolin Wang <baolin.w...@linaro.org> writes:
>>>>> Roger Quadros <rog...@ti.com> writes:
>>>>>>> Roger Quadros <rog...@ti.com> writes:
>>>>>>>> In the following test we get stuck by sleeping forever in 
>>>>>>>> _dwc3_set_mode()
>>>>>>>> after which dual-role switching doesn't work.
>>>>>>>>
>>>>>>>> On dra7-evm's dual-role port,
>>>>>>>> - Load g_zero gadget driver and enumerate to host
>>>>>>>> - suspend to mem
>>>>>>>> - disconnect USB cable to host and connect otg cable with Pen drive in 
>>>>>>>> it.
>>>>>>>> - resume system
>>>>>>>> - we sleep indefinitely in _dwc3_set_mode due to.
>>>>>>>>   dwc3_gadget_exit()->usb_del_gadget_udc()->udc_stop()->
>>>>>>>>dwc3_gadget_stop()->wait_event_lock_irq()
>>>>>>>>
>>>>>>>> Let's clear the DWC3_EP_END_TRANSFER_PENDING flag on all endpoints
>>>>>>>> so we don't wait in dwc3_gadget_stop().
>>>>>>>>
>>>>>>>> Signed-off-by: Roger Quadros <rog...@ti.com>
>>>>>>>> ---
>>>>>>>>  drivers/usb/dwc3/gadget.c | 14 ++
>>>>>>>>  1 file changed, 14 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>>>>>>>> index 2bda4eb..0a360da 100644
>>>>>>>> --- a/drivers/usb/dwc3/gadget.c
>>>>>>>> +++ b/drivers/usb/dwc3/gadget.c
>>>>>>>> @@ -3273,6 +3273,20 @@ int dwc3_gadget_init(struct dwc3 *dwc)
>>>>>>>>
>>>>>>>>  void dwc3_gadget_exit(struct dwc3 *dwc)
>>>>>>>>  {
>>>>>>>> +  int epnum;
>>>>>>>> +  unsigned long flags;
>>>>>>>> +
>>>>>>>> +  spin_lock_irqsave(>lock, flags);
>>>>>>>> +  for (epnum = 2; epnum < DWC3_ENDPOINTS_NUM; epnum++) {
>>>>>>>> +  struct dwc3_ep  *dep = dwc->eps[epnum];
>>>>>>>> +
>>>>>>>> +  if (!dep)
>>>>>>>> +  continue;
>>>>>>>> +
>>>>>>>> +  dep->flags &= ~DWC3_EP_END_TRANSFER_PENDING;
>>>>>>>> +  }
>>>>>>>> +  spin_unlock_irqrestore(>lock, flags);
>>>>>>>> +
>>>>>>>>usb_del_gadget_udc(>gadget);
>>>>>>>>dwc3_gadget_free_endpoints(dwc);
>>>>>>>
>>>>>>> free endpoints is a better place for this. It's already going to free
>>>>>>> the memory anyway. Might as well clear all flags to 0 there.
>>>>>>>
>>>>>>
>>>>>> But it won't solve the deadlock issue. Since dwc3_gadget_free_endpoints()
>>>>>> is called after usb_del_gadget_udc() and the deadlock happens when
>>>>>>
>>>>>> usb_del_gadget_udc()->udc_stop()->dwc3_gadget_stop()->wait_event_lock_irq()
>>>>>>
>>>>>> and DWC3_EP_END_TRANSFER_PENDING flag is set.
>>>>>
>>>>> indeed. Iterating twice over the entire endpoint list seems
>>>>> wasteful. Perhaps we just shouldn't wait when removing the UDC since
>>>>> that's essentially what this patch will do, right? If you clear the flag
>>>>> before calling ->udc_stop(), this means the loop in dwc3_gadget_stop()
>>>>> will do nothing. Might as well remove it.
>>>>>
>>>>
>>>> This means that we will never wait for DWC3_EP_END_TRANSFER_PENDING to 
>>>> clear
>>>> in dwc3_gadget_stop() like we used to. This is perfectly fine, right?
>>>>
>>>> It makes sense to me as dwc3_gadget_stop() calls __dwc3_gadget_stop() which
>>>> masks all interrupts and nobody will ever clear that flag if it was set.
>>>
>>> I don't think so. It can not mask the endpoint events, please check
>>> the events which will be masked in DEVTEN register. The reason why we
>>> should wait for DWC3_EP_END_TRANSFER_PENDING to clear is that,
>>> sometimes the DWC3_DEPEVT_EPCMDCMPLT event will be triggered later
>>> than 100us, but now we may have freed the gadget irq which will cause
>>> crash.
>>
>> We could mask command complete events as soon as ->udc_stop() is called,
>> right? Hmm, actually, __dwc3_gadget_stop() already clears DEVTEN
>> completely.
>
> But which bit in DEVTEN says Endpoint events are disabled?

When we set up the DWC3_DEPCMD_ENDTRANSFER command in
dwc3_stop_active_transfer(), we can do not set DWC3_DEPCMD_CMDIOC,
then there will no endpoint command complete interrupts I think.

cmd |= DWC3_DEPCMD_CMDIOC;

>
>>
>> /me goes check databook
>>
>> At least on revision 2.60a of the databook, bit 10 is reserved. I wonder
>> if that's the start of all the problems. Anybody has access to older and
>> newer databook revisions so we can cross-check?
>>
>
> I can access v2.40 and v3.10 books.
>
> bit 10 is reserved on both
>
> Differences in v2.4 vs v3.10 are:
>
> bit 8   reservedvs  L1SUSPEN
> bit 13  reservedvs  StopOnDisconnectEn
> bit 14  reservedvs  L1WKUPEVTEN
>
> --
> cheers,
> -roger
>
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. 
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki



-- 
Baolin.wang
Best Regards
--
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: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume

[Baolin Wang]

Hi Roger,

On 5 March 2018 at 17:45, Roger Quadros  wrote:
> Felipe,
>
> On 05/03/18 10:49, Felipe Balbi wrote:
>>
>> Hi,
>>
>> Roger Quadros  writes:
 Roger Quadros  writes:
> In the following test we get stuck by sleeping forever in _dwc3_set_mode()
> after which dual-role switching doesn't work.
>
> On dra7-evm's dual-role port,
> - Load g_zero gadget driver and enumerate to host
> - suspend to mem
> - disconnect USB cable to host and connect otg cable with Pen drive in it.
> - resume system
> - we sleep indefinitely in _dwc3_set_mode due to.
>   dwc3_gadget_exit()->usb_del_gadget_udc()->udc_stop()->
>dwc3_gadget_stop()->wait_event_lock_irq()
>
> Let's clear the DWC3_EP_END_TRANSFER_PENDING flag on all endpoints
> so we don't wait in dwc3_gadget_stop().
>
> Signed-off-by: Roger Quadros 
> ---
>  drivers/usb/dwc3/gadget.c | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 2bda4eb..0a360da 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -3273,6 +3273,20 @@ int dwc3_gadget_init(struct dwc3 *dwc)
>
>  void dwc3_gadget_exit(struct dwc3 *dwc)
>  {
> +  int epnum;
> +  unsigned long flags;
> +
> +  spin_lock_irqsave(>lock, flags);
> +  for (epnum = 2; epnum < DWC3_ENDPOINTS_NUM; epnum++) {
> +  struct dwc3_ep  *dep = dwc->eps[epnum];
> +
> +  if (!dep)
> +  continue;
> +
> +  dep->flags &= ~DWC3_EP_END_TRANSFER_PENDING;
> +  }
> +  spin_unlock_irqrestore(>lock, flags);
> +
>usb_del_gadget_udc(>gadget);
>dwc3_gadget_free_endpoints(dwc);

 free endpoints is a better place for this. It's already going to free
 the memory anyway. Might as well clear all flags to 0 there.

>>>
>>> But it won't solve the deadlock issue. Since dwc3_gadget_free_endpoints()
>>> is called after usb_del_gadget_udc() and the deadlock happens when
>>>
>>> usb_del_gadget_udc()->udc_stop()->dwc3_gadget_stop()->wait_event_lock_irq()
>>>
>>> and DWC3_EP_END_TRANSFER_PENDING flag is set.
>>
>> indeed. Iterating twice over the entire endpoint list seems
>> wasteful. Perhaps we just shouldn't wait when removing the UDC since
>> that's essentially what this patch will do, right? If you clear the flag
>> before calling ->udc_stop(), this means the loop in dwc3_gadget_stop()
>> will do nothing. Might as well remove it.
>>
>
> This means that we will never wait for DWC3_EP_END_TRANSFER_PENDING to clear
> in dwc3_gadget_stop() like we used to. This is perfectly fine, right?
>
> It makes sense to me as dwc3_gadget_stop() calls __dwc3_gadget_stop() which
> masks all interrupts and nobody will ever clear that flag if it was set.

I don't think so. It can not mask the endpoint events, please check
the events which will be masked in DEVTEN register. The reason why we
should wait for DWC3_EP_END_TRANSFER_PENDING to clear is that,
sometimes the DWC3_DEPEVT_EPCMDCMPLT event will be triggered later
than 100us, but now we may have freed the gadget irq which will cause
crash.

-- 
Baolin.wang
Best Regards
--
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: dwc3: Prevent indefinite sleep in _dwc3_set_mode during suspend/resume

[Baolin Wang]

Hi Roger,

On 27 February 2018 at 19:22, Roger Quadros  wrote:
> In the following test we get stuck by sleeping forever in _dwc3_set_mode()
> after which dual-role switching doesn't work.
>
> On dra7-evm's dual-role port,
> - Load g_zero gadget driver and enumerate to host
> - suspend to mem
> - disconnect USB cable to host and connect otg cable with Pen drive in it.
> - resume system
> - we sleep indefinitely in _dwc3_set_mode due to.
>   dwc3_gadget_exit()->usb_del_gadget_udc()->udc_stop()->
> dwc3_gadget_stop()->wait_event_lock_irq()
>
> Let's clear the DWC3_EP_END_TRANSFER_PENDING flag on all endpoints
> so we don't wait in dwc3_gadget_stop().

I am curious why the DWC3_DEPEVT_EPCMDCMPLT event was not triggered
any more when you executed the DWC3_DEPCMD_ENDTRANSFER command?

>
> Signed-off-by: Roger Quadros 
> ---
>  drivers/usb/dwc3/gadget.c | 14 ++
>  1 file changed, 14 insertions(+)
>
> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
> index 2bda4eb..0a360da 100644
> --- a/drivers/usb/dwc3/gadget.c
> +++ b/drivers/usb/dwc3/gadget.c
> @@ -3273,6 +3273,20 @@ int dwc3_gadget_init(struct dwc3 *dwc)
>
>  void dwc3_gadget_exit(struct dwc3 *dwc)
>  {
> +   int epnum;
> +   unsigned long flags;
> +
> +   spin_lock_irqsave(>lock, flags);
> +   for (epnum = 2; epnum < DWC3_ENDPOINTS_NUM; epnum++) {
> +   struct dwc3_ep  *dep = dwc->eps[epnum];
> +
> +   if (!dep)
> +   continue;
> +
> +   dep->flags &= ~DWC3_EP_END_TRANSFER_PENDING;
> +   }
> +   spin_unlock_irqrestore(>lock, flags);
> +
> usb_del_gadget_udc(>gadget);
> dwc3_gadget_free_endpoints(dwc);
> dma_free_coherent(dwc->sysdev, DWC3_BOUNCE_SIZE, dwc->bounce,
> --

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

[PATCH] usb: phy: Factor out the usb charger initialization

[Baolin Wang]

Factor out the guts of usb charger initialization into usb_charger_init()
function, to make the usb_add_extcon() only do the extcon related things.
Meanwhile we also should initialize the USB charger before registering
the extcon device, in case the extcon notification was issued earlier than
usb charger initialization.

Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
 drivers/usb/phy/phy.c |   14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index f97cb47..bceb2c9 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -323,6 +323,14 @@ static int devm_usb_phy_match(struct device *dev, void 
*res, void *match_data)
return *phy == match_data;
 }
 
+static void usb_charger_init(struct usb_phy *usb_phy)
+{
+   usb_phy->chg_type = UNKNOWN_TYPE;
+   usb_phy->chg_state = USB_CHARGER_DEFAULT;
+   usb_phy_set_default_current(usb_phy);
+   INIT_WORK(_phy->chg_work, usb_phy_notify_charger_work);
+}
+
 static int usb_add_extcon(struct usb_phy *x)
 {
int ret;
@@ -406,10 +414,6 @@ static int usb_add_extcon(struct usb_phy *x)
}
}
 
-   usb_phy_set_default_current(x);
-   INIT_WORK(>chg_work, usb_phy_notify_charger_work);
-   x->chg_type = UNKNOWN_TYPE;
-   x->chg_state = USB_CHARGER_DEFAULT;
if (x->type_nb.notifier_call)
__usb_phy_get_charger_type(x);
 
@@ -704,6 +708,7 @@ int usb_add_phy(struct usb_phy *x, enum usb_phy_type type)
return -EINVAL;
}
 
+   usb_charger_init(x);
ret = usb_add_extcon(x);
if (ret)
return ret;
@@ -749,6 +754,7 @@ int usb_add_phy_dev(struct usb_phy *x)
return -EINVAL;
}
 
+   usb_charger_init(x);
ret = usb_add_extcon(x);
if (ret)
return ret;
-- 
1.7.9.5

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

Re: [PATCH resend 2/2] usb: phy: mxs: add usb charger type detection

[Baolin Wang]

Hi,

On 4 September 2017 at 23:14, Li Jun <jun...@nxp.com> wrote:
> mxs phy has data pin contact and usb charger detector blocks which
> can be controlled by software to detect charger type for SDP, CDP and
> DCP.
>
> Signed-off-by: Li Jun <jun...@nxp.com>

For USB charger part:
Reviewed-by: Baolin Wang <baolin.w...@linaro.org>

-- 
Baolin.wang
Best Regards
--
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 resend 1/2] usb: chipidea: do charger detection in vbus session

[Baolin Wang]

On 4 September 2017 at 23:14, Li Jun <jun...@nxp.com> wrote:
> In case the usb phy has the capability to detect usb charger type,
> do it when vbus is on.
>
> Signed-off-by: Li Jun <jun...@nxp.com>
> ---
>  drivers/usb/chipidea/udc.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index d68b125..63d311e 100644
> --- a/drivers/usb/chipidea/udc.c
> +++ b/drivers/usb/chipidea/udc.c
> @@ -1529,6 +1529,10 @@ static int ci_udc_vbus_session(struct usb_gadget 
> *_gadget, int is_active)
> gadget_ready = 1;
> spin_unlock_irqrestore(>lock, flags);
>
> +   if (ci->usb_phy)
> +   usb_phy_set_charger_state(ci->usb_phy, is_active ?
> +   USB_CHARGER_PRESENT : USB_CHARGER_ABSENT);

For USB charger part:
Reviewed-by: Baolin Wang <baolin.w...@linaro.org>

> +
> if (gadget_ready) {
> if (is_active) {
> pm_runtime_get_sync(&_gadget->dev);
> --
> 2.7.4
>



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

[PATCH] usb: dwc3: of-simple: Add compatible for Spreadtrum SC9860 platform

[Baolin Wang]

Add compatible string to use this generic glue layer to support
Spreadtrum SC9860 platform's dwc3 controller.

Signed-off-by: Baolin Wang <baolin.w...@spreadtrum.com>
---
 drivers/usb/dwc3/dwc3-of-simple.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/dwc3/dwc3-of-simple.c 
b/drivers/usb/dwc3/dwc3-of-simple.c
index fe414e7..43a7d44 100644
--- a/drivers/usb/dwc3/dwc3-of-simple.c
+++ b/drivers/usb/dwc3/dwc3-of-simple.c
@@ -177,6 +177,7 @@ static int dwc3_of_simple_runtime_resume(struct device *dev)
{ .compatible = "rockchip,rk3399-dwc3" },
{ .compatible = "xlnx,zynqmp-dwc3" },
{ .compatible = "cavium,octeon-7130-usb-uctl" },
+   { .compatible = "sprd,sc9860-dwc3" },
{ /* Sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, of_dwc3_simple_match);
-- 
1.7.9.5

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

[PATCH] usb: phy: Avoid unchecked dereference warning

[Baolin Wang]

Move the USB phy NULL checking before issuing usb_phy_set_charger_current()
to avoid unchecked dereference warning.

Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
 include/linux/usb/phy.h |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index de881b1..8c69148 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -322,9 +322,12 @@ static inline void usb_phy_set_charger_state(struct 
usb_phy *usb_phy,
 static inline int
 usb_phy_set_power(struct usb_phy *x, unsigned mA)
 {
+   if (!x)
+   return 0;
+
usb_phy_set_charger_current(x, mA);
 
-   if (x && x->set_power)
+   if (x->set_power)
return x->set_power(x, mA);
return 0;
 }
-- 
1.7.9.5

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

Re: [bug report] usb: phy: Add USB charger support

[Baolin Wang]

Hi Felipe,

On 28 August 2017 at 15:58, Felipe Balbi <felipe.ba...@linux.intel.com> wrote:
>
> Hi,
>
> Baolin Wang <baolin.w...@linaro.org> writes:
>> Hi Dan,
>>
>> On 25 August 2017 at 20:20, Dan Carpenter <dan.carpen...@oracle.com> wrote:
>>> Hello Baolin Wang,
>>>
>>> This is a semi-automatic email about new static checker warnings.
>>>
>>> The patch a9081a008f84: "usb: phy: Add USB charger support" from Aug
>>> 15, 2017, leads to the following Smatch complaint:
>>>
>>> include/linux/usb/phy.h:327 usb_phy_set_power()
>>>  warn: variable dereferenced before check 'x' (see line 325)
>>>
>>> include/linux/usb/phy.h
>>>322  static inline int
>>>323  usb_phy_set_power(struct usb_phy *x, unsigned mA)
>>>324  {
>>>325  usb_phy_set_charger_current(x, mA);
>>> ^
>>> The patch adds an unchecked dereference.
>>>
>>>326
>>>327  if (x && x->set_power)
>>> ^
>>> The existing code checks for NULL.  But so far as I know non of the
>>> existing caller pass a NULL usb_phy and it doesn't really make sense
>>> to me to do that.  Perhaps just remove the NULL check?
>>
>> I agree. I also saw most drivers will check for NULL before issuing
>> usb_phy_set_power(). I will send one patch to fix this issue. Thanks.
>
> I want to keep NULL phy valid. It's best to remove the NULL check from
> calling sites.

OK. To keep consistent for all USB phy interfaces.

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

Re: [bug report] usb: phy: Add USB charger support

[Baolin Wang]

Hi Dan,

On 25 August 2017 at 20:20, Dan Carpenter <dan.carpen...@oracle.com> wrote:
> Hello Baolin Wang,
>
> This is a semi-automatic email about new static checker warnings.
>
> The patch a9081a008f84: "usb: phy: Add USB charger support" from Aug
> 15, 2017, leads to the following Smatch complaint:
>
> include/linux/usb/phy.h:327 usb_phy_set_power()
>  warn: variable dereferenced before check 'x' (see line 325)
>
> include/linux/usb/phy.h
>322  static inline int
>323  usb_phy_set_power(struct usb_phy *x, unsigned mA)
>324  {
>325  usb_phy_set_charger_current(x, mA);
> ^
> The patch adds an unchecked dereference.
>
>326
>327  if (x && x->set_power)
> ^
> The existing code checks for NULL.  But so far as I know non of the
> existing caller pass a NULL usb_phy and it doesn't really make sense
> to me to do that.  Perhaps just remove the NULL check?

I agree. I also saw most drivers will check for NULL before issuing
usb_phy_set_power(). I will send one patch to fix this issue. Thanks.

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

Re: [PATCH v4 0/3] Introduce USB charger support in USB phy

[Baolin Wang]

Hi Felipe,

On 15 August 2017 at 17:53, Felipe Balbi <ba...@kernel.org> wrote:
>
> Hi,
>
> Baolin Wang <baolin.w...@linaro.org> writes:
>>> 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 USB charger support in USB phy core
>>> for doing this in kernel.
>>>
>>> Now introduce one user with wm831x_power to support and test the usb 
>>> charger.
>>> In future we will also cnvert below power drivers:
>>> drivers/power/supply/axp288_charger.c
>>> drivers/power/supply/bq24190_charger.c
>>> drivers/power/supply/charger-manager.c
>>> drivers/power/supply/qcom_smbb.c
>>>
>>> Changes since v3:
>>>  - Bail out errors when failed to find usb phy for wm831x_power driver.
>>> Changes since v2:
>>>  - Add DT binding documentation for wm831x_power driver.
>>>  - Change 'usb-phy' as one optional property for wm831x_power driver.
>>> Changes since v1:
>>>  - Fix building errors.
>>
>> Do you have any comments about usb charger support in usb phy core? Thanks.
>
> No more comments from me

Thanks for your feedback. I've send out V5 patchset which just changes
phy phandle name from 'usb-phy' to 'phys' for patch 3 suggested by
Rob. Hope you can apply this version patchset into your branch if
there are no other comments.

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

[PATCH v5 2/3] usb: phy: Add USB charger support

[Baolin Wang]

This patch introduces the usb charger support based on usb phy that
makes an enhancement to a power driver. The basic conception of the
usb charger is that, when one usb charger is added or removed by
reporting from the extcon device state change, the usb charger will
report to power user to set the current limitation.

Power user can register a notifiee on the usb phy by issuing
usb_register_notifier() to get notified by charger status changes
or charger current changes.

we can notify what current to be drawn to power user according to
different charger type, and now we have 2 methods to get charger type.
One is get charger type from extcon subsystem, which also means the
charger state changes. Another is we can get the charger type from
USB controller detecting or PMIC detecting, and the charger state
changes should be told by issuing usb_phy_set_charger_state().

Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
 drivers/usb/phy/phy.c   |  272 +++
 include/linux/usb/phy.h |   49 +
 2 files changed, 321 insertions(+)

diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index 032f5af..2dc48bb 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -18,6 +18,18 @@
 
 #include 
 
+/* Default current range by charger type. */
+#define DEFAULT_SDP_CUR_MIN2
+#define DEFAULT_SDP_CUR_MAX500
+#define DEFAULT_SDP_CUR_MIN_SS 150
+#define DEFAULT_SDP_CUR_MAX_SS 900
+#define DEFAULT_DCP_CUR_MIN500
+#define DEFAULT_DCP_CUR_MAX5000
+#define DEFAULT_CDP_CUR_MIN1500
+#define DEFAULT_CDP_CUR_MAX5000
+#define DEFAULT_ACA_CUR_MIN1500
+#define DEFAULT_ACA_CUR_MAX5000
+
 static LIST_HEAD(phy_list);
 static LIST_HEAD(phy_bind_list);
 static DEFINE_SPINLOCK(phy_lock);
@@ -77,6 +89,221 @@ static struct usb_phy *__of_usb_find_phy(struct device_node 
*node)
return ERR_PTR(-EPROBE_DEFER);
 }
 
+static void usb_phy_set_default_current(struct usb_phy *usb_phy)
+{
+   usb_phy->chg_cur.sdp_min = DEFAULT_SDP_CUR_MIN;
+   usb_phy->chg_cur.sdp_max = DEFAULT_SDP_CUR_MAX;
+   usb_phy->chg_cur.dcp_min = DEFAULT_DCP_CUR_MIN;
+   usb_phy->chg_cur.dcp_max = DEFAULT_DCP_CUR_MAX;
+   usb_phy->chg_cur.cdp_min = DEFAULT_CDP_CUR_MIN;
+   usb_phy->chg_cur.cdp_max = DEFAULT_CDP_CUR_MAX;
+   usb_phy->chg_cur.aca_min = DEFAULT_ACA_CUR_MIN;
+   usb_phy->chg_cur.aca_max = DEFAULT_ACA_CUR_MAX;
+}
+
+/**
+ * usb_phy_notify_charger_work - notify the USB charger state
+ * @work - the charger work to notify the USB charger state
+ *
+ * This work can be issued when USB charger state has been changed or
+ * USB charger current has been changed, then we can notify the current
+ * what can be drawn to power user and the charger state to userspace.
+ *
+ * If we get the charger type from extcon subsystem, we can notify the
+ * charger state to power user automatically by usb_phy_get_charger_type()
+ * issuing from extcon subsystem.
+ *
+ * If we get the charger type from ->charger_detect() instead of extcon
+ * subsystem, the usb phy driver should issue usb_phy_set_charger_state()
+ * to set charger state when the charger state has been changed.
+ */
+static void usb_phy_notify_charger_work(struct work_struct *work)
+{
+   struct usb_phy *usb_phy = container_of(work, struct usb_phy, chg_work);
+   char uchger_state[50] = { 0 };
+   char *envp[] = { uchger_state, NULL };
+   unsigned int min, max;
+
+   switch (usb_phy->chg_state) {
+   case USB_CHARGER_PRESENT:
+   usb_phy_get_charger_current(usb_phy, , );
+
+   atomic_notifier_call_chain(_phy->notifier, max, usb_phy);
+   snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+"USB_CHARGER_STATE=%s", "USB_CHARGER_PRESENT");
+   break;
+   case USB_CHARGER_ABSENT:
+   usb_phy_set_default_current(usb_phy);
+
+   atomic_notifier_call_chain(_phy->notifier, 0, usb_phy);
+   snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+"USB_CHARGER_STATE=%s", "USB_CHARGER_ABSENT");
+   break;
+   default:
+   dev_warn(usb_phy->dev, "Unknown USB charger state: %d\n",
+usb_phy->chg_state);
+   return;
+   }
+
+   kobject_uevent_env(_phy->dev->kobj, KOBJ_CHANGE, envp);
+}
+
+static void __usb_phy_get_charger_type(struct usb_phy *usb_phy)
+{
+   if (extcon_get_state(usb_phy->edev, EXTCON_CHG_USB_SDP) > 0) {
+   usb_phy->chg_type = SDP_TYPE;
+   usb_phy->chg_state = USB_CHARGER_PRESENT;
+   } else if (extcon_get_state(usb_phy->edev, EXTCON_CHG_USB_CDP) > 0) {
+   usb_phy->chg_type = CDP_TYPE;
+   usb_phy->chg_state = USB_CHARGER_PRESENT;
+   } else if (extcon_get_

[PATCH v5 0/3] Introduce USB charger support in USB phy

[Baolin Wang]

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 USB charger support in USB phy core
for doing this in kernel.

Now introduce one user with wm831x_power to support and test the usb charger.
In future we will also cnvert below power drivers:
drivers/power/supply/axp288_charger.c
drivers/power/supply/bq24190_charger.c
drivers/power/supply/charger-manager.c
drivers/power/supply/qcom_smbb.c

Changes since v4:
 - Change the phandle name from 'usb-phy' to 'phys' for wm831x_power driver.
Changes since v3:
 - Bail out errors when failed to find usb phy for wm831x_power driver.
Changes since v2:
 - Add DT binding documentation for wm831x_power driver.
 - Change 'usb-phy' as one optional property for wm831x_power driver.
Changes since v1:
 - Fix building errors.

Baolin Wang (3):
  include: uapi: usb: Introduce USB charger type and state definition
  usb: phy: Add USB charger support
  power: wm831x_power: Support USB charger current limit management

 Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
 drivers/power/supply/wm831x_power.c  |   72 ++
 drivers/usb/phy/phy.c|  272 ++
 include/linux/usb/phy.h  |   49 
 include/uapi/linux/usb/charger.h |   31 +++
 5 files changed, 425 insertions(+)
 create mode 100644 include/uapi/linux/usb/charger.h

-- 
1.7.9.5

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

[PATCH v5 1/3] include: uapi: usb: Introduce USB charger type and state definition

[Baolin Wang]

Introducing USB charger type and state definition can help
to support USB charging which will be added in USB phy core.

Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
 include/uapi/linux/usb/charger.h |   31 +++
 1 file changed, 31 insertions(+)
 create mode 100644 include/uapi/linux/usb/charger.h

diff --git a/include/uapi/linux/usb/charger.h b/include/uapi/linux/usb/charger.h
new file mode 100644
index 000..5f72af3
--- /dev/null
+++ b/include/uapi/linux/usb/charger.h
@@ -0,0 +1,31 @@
+/*
+ * This file defines the USB charger type and state that are needed for
+ * USB device APIs.
+ */
+
+#ifndef _UAPI__LINUX_USB_CHARGER_H
+#define _UAPI__LINUX_USB_CHARGER_H
+
+/*
+ * USB charger type:
+ * SDP (Standard Downstream Port)
+ * DCP (Dedicated Charging Port)
+ * CDP (Charging Downstream Port)
+ * ACA (Accessory Charger Adapters)
+ */
+enum usb_charger_type {
+   UNKNOWN_TYPE,
+   SDP_TYPE,
+   DCP_TYPE,
+   CDP_TYPE,
+   ACA_TYPE,
+};
+
+/* USB charger state */
+enum usb_charger_state {
+   USB_CHARGER_DEFAULT,
+   USB_CHARGER_PRESENT,
+   USB_CHARGER_ABSENT,
+};
+
+#endif /* _UAPI__LINUX_USB_CHARGER_H */
-- 
1.7.9.5

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

[PATCH v5 3/3] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.

Signed-off-by: Mark Brown <broo...@kernel.org>
Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
Acked-by: Lee Jones <lee.jo...@linaro.org>
Acked-by: Charles Keepax <ckee...@opensource.wolfsonmicro.com>
Acked-by: Sebastian Reichel <sebastian.reic...@collabora.co.uk>
---
 Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
 drivers/power/supply/wm831x_power.c  |   72 ++
 2 files changed, 73 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/wm831x.txt 
b/Documentation/devicetree/bindings/mfd/wm831x.txt
index 9f8b743..5057094 100644
--- a/Documentation/devicetree/bindings/mfd/wm831x.txt
+++ b/Documentation/devicetree/bindings/mfd/wm831x.txt
@@ -31,6 +31,7 @@ Required properties:
 ../interrupt-controller/interrupts.txt
 
 Optional sub-nodes:
+  - phys : Contains a phandle to the USB PHY.
   - regulators : Contains sub-nodes for each of the regulators supplied by
 the device. The regulators are bound using their names listed below:
 
diff --git a/drivers/power/supply/wm831x_power.c 
b/drivers/power/supply/wm831x_power.c
index 7082301..927050d 100644
--- a/drivers/power/supply/wm831x_power.c
+++ b/drivers/power/supply/wm831x_power.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -31,6 +32,8 @@ struct wm831x_power {
char usb_name[20];
char battery_name[20];
bool have_battery;
+   struct usb_phy *usb_phy;
+   struct notifier_block usb_notify;
 };
 
 static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
@@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
POWER_SUPPLY_PROP_VOLTAGE_NOW,
 };
 
+/* In milliamps */
+static const unsigned int wm831x_usb_limits[] = {
+   0,
+   2,
+   100,
+   500,
+   900,
+   1500,
+   1800,
+   550,
+};
+
+static int wm831x_usb_limit_change(struct notifier_block *nb,
+  unsigned long limit, void *data)
+{
+   struct wm831x_power *wm831x_power = container_of(nb,
+struct wm831x_power,
+usb_notify);
+   unsigned int i, best;
+
+   /* Find the highest supported limit */
+   best = 0;
+   for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
+   if (limit >= wm831x_usb_limits[i] &&
+   wm831x_usb_limits[best] < wm831x_usb_limits[i])
+   best = i;
+   }
+
+   dev_dbg(wm831x_power->wm831x->dev,
+   "Limiting USB current to %umA", wm831x_usb_limits[best]);
+
+   wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
+   WM831X_USB_ILIM_MASK, best);
+
+   return 0;
+}
+
 /*
  * Battery properties
  */
@@ -607,6 +647,33 @@ static int wm831x_power_probe(struct platform_device *pdev)
}
}
 
+   power->usb_phy = devm_usb_get_phy_by_phandle(>dev, "phys", 0);
+   ret = PTR_ERR_OR_ZERO(power->usb_phy);
+
+   switch (ret) {
+   case 0:
+   power->usb_notify.notifier_call = wm831x_usb_limit_change;
+   ret = usb_register_notifier(power->usb_phy, >usb_notify);
+   if (ret) {
+   dev_err(>dev, "Failed to register notifier: %d\n",
+   ret);
+   goto err_bat_irq;
+   }
+   break;
+   case -EINVAL:
+   case -ENODEV:
+   /* ignore missing usb-phy, it's optional */
+   power->usb_phy = NULL;
+   ret = 0;
+   break;
+   default:
+   dev_err(>dev, "Failed to find USB phy: %d\n", ret);
+   /* fall-through */
+   case -EPROBE_DEFER:
+   goto err_bat_irq;
+   break;
+   }
+
return ret;
 
 err_bat_irq:
@@ -637,6 +704,11 @@ static int wm831x_power_remove(struct platform_device 
*pdev)
struct wm831x *wm831x = wm831x_power->wm831x;
int irq, i;
 
+   if (wm831x_power->usb_phy) {
+   usb_unregister_notifier(wm831x_power->usb_phy,
+   _power->usb_notify);
+   }
+
for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
irq = wm831x_irq(wm831x, 
 platform_get_irq_byname(pdev,

Re: [PATCH v4 0/3] Introduce USB charger support in USB phy

[Baolin Wang]

Hi Felipe,

On 27 July 2017 at 13:14, Baolin Wang <baolin.w...@linaro.org> 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 USB charger support in USB phy core
> for doing this in kernel.
>
> Now introduce one user with wm831x_power to support and test the usb charger.
> In future we will also cnvert below power drivers:
> drivers/power/supply/axp288_charger.c
> drivers/power/supply/bq24190_charger.c
> drivers/power/supply/charger-manager.c
> drivers/power/supply/qcom_smbb.c
>
> Changes since v3:
>  - Bail out errors when failed to find usb phy for wm831x_power driver.
> Changes since v2:
>  - Add DT binding documentation for wm831x_power driver.
>  - Change 'usb-phy' as one optional property for wm831x_power driver.
> Changes since v1:
>  - Fix building errors.

Do you have any comments about usb charger support in usb phy core? Thanks.

>
> Baolin Wang (3):
>   include: uapi: usb: Introduce USB charger type and state definition
>   usb: phy: Add USB charger support
>   power: wm831x_power: Support USB charger current limit management
>
>  Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
>  drivers/power/supply/wm831x_power.c  |   72 ++
>  drivers/usb/phy/phy.c|  272 
> ++
>  include/linux/usb/phy.h  |   49 
>  include/uapi/linux/usb/charger.h |   31 +++
>  5 files changed, 425 insertions(+)
>  create mode 100644 include/uapi/linux/usb/charger.h
>
> --
> 1.7.9.5
>



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

Re: [PATCH v4 3/3] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

On 4 August 2017 at 03:16, Rob Herring <r...@kernel.org> wrote:
> On Thu, Jul 27, 2017 at 01:14:38PM +0800, Baolin Wang wrote:
>> Integrate with the newly added USB charger interface to limit the current
>> we draw from the USB input based on the input device configuration
>> identified by the USB stack, allowing us to charge more quickly from high
>> current inputs without drawing more current than specified from others.
>>
>> Signed-off-by: Mark Brown <broo...@kernel.org>
>> Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
>> Acked-by: Lee Jones <lee.jo...@linaro.org>
>> Acked-by: Charles Keepax <ckee...@opensource.wolfsonmicro.com>
>> ---
>>  Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
>>  drivers/power/supply/wm831x_power.c  |   72 
>> ++
>>  2 files changed, 73 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/wm831x.txt 
>> b/Documentation/devicetree/bindings/mfd/wm831x.txt
>> index 9f8b743..4e3bc07 100644
>> --- a/Documentation/devicetree/bindings/mfd/wm831x.txt
>> +++ b/Documentation/devicetree/bindings/mfd/wm831x.txt
>> @@ -31,6 +31,7 @@ Required properties:
>>  ../interrupt-controller/interrupts.txt
>>
>>  Optional sub-nodes:
>> +  - usb-phy : Contains a phandle to the USB PHY.
>
> Use the phy binding ("phys") instead.

OK. Will fix in next version. Thanks.

>
>>- regulators : Contains sub-nodes for each of the regulators supplied by
>>  the device. The regulators are bound using their names listed below:
>>
>> diff --git a/drivers/power/supply/wm831x_power.c 
>> b/drivers/power/supply/wm831x_power.c
>> index 7082301..dff6473 100644
>> --- a/drivers/power/supply/wm831x_power.c
>> +++ b/drivers/power/supply/wm831x_power.c
>> @@ -13,6 +13,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>  #include 
>> @@ -31,6 +32,8 @@ struct wm831x_power {
>>   char usb_name[20];
>>   char battery_name[20];
>>   bool have_battery;
>> + struct usb_phy *usb_phy;
>> + struct notifier_block usb_notify;
>>  };
>>
>>  static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
>> @@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
>>   POWER_SUPPLY_PROP_VOLTAGE_NOW,
>>  };
>>
>> +/* In milliamps */
>> +static const unsigned int wm831x_usb_limits[] = {
>> + 0,
>> + 2,
>> + 100,
>> + 500,
>> + 900,
>> + 1500,
>> + 1800,
>> + 550,
>> +};
>> +
>> +static int wm831x_usb_limit_change(struct notifier_block *nb,
>> +unsigned long limit, void *data)
>> +{
>> + struct wm831x_power *wm831x_power = container_of(nb,
>> +  struct wm831x_power,
>> +  usb_notify);
>> + unsigned int i, best;
>> +
>> + /* Find the highest supported limit */
>> + best = 0;
>> + for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
>> + if (limit >= wm831x_usb_limits[i] &&
>> + wm831x_usb_limits[best] < wm831x_usb_limits[i])
>> + best = i;
>> + }
>> +
>> + dev_dbg(wm831x_power->wm831x->dev,
>> + "Limiting USB current to %umA", wm831x_usb_limits[best]);
>> +
>> + wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
>> + WM831X_USB_ILIM_MASK, best);
>> +
>> + return 0;
>> +}
>> +
>>  /*
>>   *   Battery properties
>>   */
>> @@ -607,6 +647,33 @@ static int wm831x_power_probe(struct platform_device 
>> *pdev)
>>   }
>>   }
>>
>> + power->usb_phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
>> + ret = PTR_ERR_OR_ZERO(power->usb_phy);
>> +
>> + switch (ret) {
>> + case 0:
>> + power->usb_notify.notifier_call = wm831x_usb_limit_change;
>> + ret = usb_register_notifier(power->usb_phy, 
>> >usb_notify);
>> + if (ret) {
>> + dev_err(>dev, "Failed to register notifier: 
>> %d\n",
>

[PATCH v4 1/3] include: uapi: usb: Introduce USB charger type and state definition

[Baolin Wang]

Introducing USB charger type and state definition can help
to support USB charging which will be added in USB phy core.

Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
 include/uapi/linux/usb/charger.h |   31 +++
 1 file changed, 31 insertions(+)
 create mode 100644 include/uapi/linux/usb/charger.h

diff --git a/include/uapi/linux/usb/charger.h b/include/uapi/linux/usb/charger.h
new file mode 100644
index 000..5f72af3
--- /dev/null
+++ b/include/uapi/linux/usb/charger.h
@@ -0,0 +1,31 @@
+/*
+ * This file defines the USB charger type and state that are needed for
+ * USB device APIs.
+ */
+
+#ifndef _UAPI__LINUX_USB_CHARGER_H
+#define _UAPI__LINUX_USB_CHARGER_H
+
+/*
+ * USB charger type:
+ * SDP (Standard Downstream Port)
+ * DCP (Dedicated Charging Port)
+ * CDP (Charging Downstream Port)
+ * ACA (Accessory Charger Adapters)
+ */
+enum usb_charger_type {
+   UNKNOWN_TYPE,
+   SDP_TYPE,
+   DCP_TYPE,
+   CDP_TYPE,
+   ACA_TYPE,
+};
+
+/* USB charger state */
+enum usb_charger_state {
+   USB_CHARGER_DEFAULT,
+   USB_CHARGER_PRESENT,
+   USB_CHARGER_ABSENT,
+};
+
+#endif /* _UAPI__LINUX_USB_CHARGER_H */
-- 
1.7.9.5

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

[PATCH v4 2/3] usb: phy: Add USB charger support

[Baolin Wang]

This patch introduces the usb charger support based on usb phy that
makes an enhancement to a power driver. The basic conception of the
usb charger is that, when one usb charger is added or removed by
reporting from the extcon device state change, the usb charger will
report to power user to set the current limitation.

Power user can register a notifiee on the usb phy by issuing
usb_register_notifier() to get notified by charger status changes
or charger current changes.

we can notify what current to be drawn to power user according to
different charger type, and now we have 2 methods to get charger type.
One is get charger type from extcon subsystem, which also means the
charger state changes. Another is we can get the charger type from
USB controller detecting or PMIC detecting, and the charger state
changes should be told by issuing usb_phy_set_charger_state().

Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
 drivers/usb/phy/phy.c   |  272 +++
 include/linux/usb/phy.h |   49 +
 2 files changed, 321 insertions(+)

diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index 032f5af..2dc48bb 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -18,6 +18,18 @@
 
 #include 
 
+/* Default current range by charger type. */
+#define DEFAULT_SDP_CUR_MIN2
+#define DEFAULT_SDP_CUR_MAX500
+#define DEFAULT_SDP_CUR_MIN_SS 150
+#define DEFAULT_SDP_CUR_MAX_SS 900
+#define DEFAULT_DCP_CUR_MIN500
+#define DEFAULT_DCP_CUR_MAX5000
+#define DEFAULT_CDP_CUR_MIN1500
+#define DEFAULT_CDP_CUR_MAX5000
+#define DEFAULT_ACA_CUR_MIN1500
+#define DEFAULT_ACA_CUR_MAX5000
+
 static LIST_HEAD(phy_list);
 static LIST_HEAD(phy_bind_list);
 static DEFINE_SPINLOCK(phy_lock);
@@ -77,6 +89,221 @@ static struct usb_phy *__of_usb_find_phy(struct device_node 
*node)
return ERR_PTR(-EPROBE_DEFER);
 }
 
+static void usb_phy_set_default_current(struct usb_phy *usb_phy)
+{
+   usb_phy->chg_cur.sdp_min = DEFAULT_SDP_CUR_MIN;
+   usb_phy->chg_cur.sdp_max = DEFAULT_SDP_CUR_MAX;
+   usb_phy->chg_cur.dcp_min = DEFAULT_DCP_CUR_MIN;
+   usb_phy->chg_cur.dcp_max = DEFAULT_DCP_CUR_MAX;
+   usb_phy->chg_cur.cdp_min = DEFAULT_CDP_CUR_MIN;
+   usb_phy->chg_cur.cdp_max = DEFAULT_CDP_CUR_MAX;
+   usb_phy->chg_cur.aca_min = DEFAULT_ACA_CUR_MIN;
+   usb_phy->chg_cur.aca_max = DEFAULT_ACA_CUR_MAX;
+}
+
+/**
+ * usb_phy_notify_charger_work - notify the USB charger state
+ * @work - the charger work to notify the USB charger state
+ *
+ * This work can be issued when USB charger state has been changed or
+ * USB charger current has been changed, then we can notify the current
+ * what can be drawn to power user and the charger state to userspace.
+ *
+ * If we get the charger type from extcon subsystem, we can notify the
+ * charger state to power user automatically by usb_phy_get_charger_type()
+ * issuing from extcon subsystem.
+ *
+ * If we get the charger type from ->charger_detect() instead of extcon
+ * subsystem, the usb phy driver should issue usb_phy_set_charger_state()
+ * to set charger state when the charger state has been changed.
+ */
+static void usb_phy_notify_charger_work(struct work_struct *work)
+{
+   struct usb_phy *usb_phy = container_of(work, struct usb_phy, chg_work);
+   char uchger_state[50] = { 0 };
+   char *envp[] = { uchger_state, NULL };
+   unsigned int min, max;
+
+   switch (usb_phy->chg_state) {
+   case USB_CHARGER_PRESENT:
+   usb_phy_get_charger_current(usb_phy, , );
+
+   atomic_notifier_call_chain(_phy->notifier, max, usb_phy);
+   snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+"USB_CHARGER_STATE=%s", "USB_CHARGER_PRESENT");
+   break;
+   case USB_CHARGER_ABSENT:
+   usb_phy_set_default_current(usb_phy);
+
+   atomic_notifier_call_chain(_phy->notifier, 0, usb_phy);
+   snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+"USB_CHARGER_STATE=%s", "USB_CHARGER_ABSENT");
+   break;
+   default:
+   dev_warn(usb_phy->dev, "Unknown USB charger state: %d\n",
+usb_phy->chg_state);
+   return;
+   }
+
+   kobject_uevent_env(_phy->dev->kobj, KOBJ_CHANGE, envp);
+}
+
+static void __usb_phy_get_charger_type(struct usb_phy *usb_phy)
+{
+   if (extcon_get_state(usb_phy->edev, EXTCON_CHG_USB_SDP) > 0) {
+   usb_phy->chg_type = SDP_TYPE;
+   usb_phy->chg_state = USB_CHARGER_PRESENT;
+   } else if (extcon_get_state(usb_phy->edev, EXTCON_CHG_USB_CDP) > 0) {
+   usb_phy->chg_type = CDP_TYPE;
+   usb_phy->chg_state = USB_CHARGER_PRESENT;
+   } else if (extcon_get_

[PATCH v4 3/3] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.

Signed-off-by: Mark Brown <broo...@kernel.org>
Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
Acked-by: Lee Jones <lee.jo...@linaro.org>
Acked-by: Charles Keepax <ckee...@opensource.wolfsonmicro.com>
---
 Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
 drivers/power/supply/wm831x_power.c  |   72 ++
 2 files changed, 73 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/wm831x.txt 
b/Documentation/devicetree/bindings/mfd/wm831x.txt
index 9f8b743..4e3bc07 100644
--- a/Documentation/devicetree/bindings/mfd/wm831x.txt
+++ b/Documentation/devicetree/bindings/mfd/wm831x.txt
@@ -31,6 +31,7 @@ Required properties:
 ../interrupt-controller/interrupts.txt
 
 Optional sub-nodes:
+  - usb-phy : Contains a phandle to the USB PHY.
   - regulators : Contains sub-nodes for each of the regulators supplied by
 the device. The regulators are bound using their names listed below:
 
diff --git a/drivers/power/supply/wm831x_power.c 
b/drivers/power/supply/wm831x_power.c
index 7082301..dff6473 100644
--- a/drivers/power/supply/wm831x_power.c
+++ b/drivers/power/supply/wm831x_power.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -31,6 +32,8 @@ struct wm831x_power {
char usb_name[20];
char battery_name[20];
bool have_battery;
+   struct usb_phy *usb_phy;
+   struct notifier_block usb_notify;
 };
 
 static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
@@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
POWER_SUPPLY_PROP_VOLTAGE_NOW,
 };
 
+/* In milliamps */
+static const unsigned int wm831x_usb_limits[] = {
+   0,
+   2,
+   100,
+   500,
+   900,
+   1500,
+   1800,
+   550,
+};
+
+static int wm831x_usb_limit_change(struct notifier_block *nb,
+  unsigned long limit, void *data)
+{
+   struct wm831x_power *wm831x_power = container_of(nb,
+struct wm831x_power,
+usb_notify);
+   unsigned int i, best;
+
+   /* Find the highest supported limit */
+   best = 0;
+   for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
+   if (limit >= wm831x_usb_limits[i] &&
+   wm831x_usb_limits[best] < wm831x_usb_limits[i])
+   best = i;
+   }
+
+   dev_dbg(wm831x_power->wm831x->dev,
+   "Limiting USB current to %umA", wm831x_usb_limits[best]);
+
+   wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
+   WM831X_USB_ILIM_MASK, best);
+
+   return 0;
+}
+
 /*
  * Battery properties
  */
@@ -607,6 +647,33 @@ static int wm831x_power_probe(struct platform_device *pdev)
}
}
 
+   power->usb_phy = devm_usb_get_phy_by_phandle(>dev, "usb-phy", 0);
+   ret = PTR_ERR_OR_ZERO(power->usb_phy);
+
+   switch (ret) {
+   case 0:
+   power->usb_notify.notifier_call = wm831x_usb_limit_change;
+   ret = usb_register_notifier(power->usb_phy, >usb_notify);
+   if (ret) {
+   dev_err(>dev, "Failed to register notifier: %d\n",
+   ret);
+   goto err_bat_irq;
+   }
+   break;
+   case -EINVAL:
+   case -ENODEV:
+   /* ignore missing usb-phy, it's optional */
+   power->usb_phy = NULL;
+   ret = 0;
+   break;
+   default:
+   dev_err(>dev, "Failed to find USB phy: %d\n", ret);
+   /* fall-through */
+   case -EPROBE_DEFER:
+   goto err_bat_irq;
+   break;
+   }
+
return ret;
 
 err_bat_irq:
@@ -637,6 +704,11 @@ static int wm831x_power_remove(struct platform_device 
*pdev)
struct wm831x *wm831x = wm831x_power->wm831x;
int irq, i;
 
+   if (wm831x_power->usb_phy) {
+   usb_unregister_notifier(wm831x_power->usb_phy,
+   _power->usb_notify);
+   }
+
for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
irq = wm831x_irq(wm831x, 
 platform_get_irq_byname(pdev,
-- 
1.7.9.5

--
To unsubscribe from this list: send the line &q

[PATCH v4 0/3] Introduce USB charger support in USB phy

[Baolin Wang]

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 USB charger support in USB phy core
for doing this in kernel.

Now introduce one user with wm831x_power to support and test the usb charger.
In future we will also cnvert below power drivers:
drivers/power/supply/axp288_charger.c
drivers/power/supply/bq24190_charger.c
drivers/power/supply/charger-manager.c
drivers/power/supply/qcom_smbb.c

Changes since v3:
 - Bail out errors when failed to find usb phy for wm831x_power driver.
Changes since v2:
 - Add DT binding documentation for wm831x_power driver.
 - Change 'usb-phy' as one optional property for wm831x_power driver.
Changes since v1:
 - Fix building errors.

Baolin Wang (3):
  include: uapi: usb: Introduce USB charger type and state definition
  usb: phy: Add USB charger support
  power: wm831x_power: Support USB charger current limit management

 Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
 drivers/power/supply/wm831x_power.c  |   72 ++
 drivers/usb/phy/phy.c|  272 ++
 include/linux/usb/phy.h  |   49 
 include/uapi/linux/usb/charger.h |   31 +++
 5 files changed, 425 insertions(+)
 create mode 100644 include/uapi/linux/usb/charger.h

-- 
1.7.9.5

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

Re: [PATCH v3 3/3] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

Hi,

On 26 July 2017 at 20:08, Sebastian Reichel
<sebastian.reic...@collabora.co.uk> wrote:
> Hi,
>
> On Wed, Jul 26, 2017 at 11:05:25AM +0800, Baolin Wang wrote:
>> On 25 July 2017 at 17:59, Sebastian Reichel
>> <sebastian.reic...@collabora.co.uk> wrote:
>> > On Tue, Jul 25, 2017 at 04:00:01PM +0800, Baolin Wang wrote:
>> >> Integrate with the newly added USB charger interface to limit the current
>> >> we draw from the USB input based on the input device configuration
>> >> identified by the USB stack, allowing us to charge more quickly from high
>> >> current inputs without drawing more current than specified from others.
>> >>
>> >> Signed-off-by: Mark Brown <broo...@kernel.org>
>> >> Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
>> >> ---
>> >>  Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
>> >>  drivers/power/supply/wm831x_power.c  |   58 
>> >> ++
>> >>  2 files changed, 59 insertions(+)
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/mfd/wm831x.txt 
>> >> b/Documentation/devicetree/bindings/mfd/wm831x.txt
>> >> index 9f8b743..4e3bc07 100644
>> >> --- a/Documentation/devicetree/bindings/mfd/wm831x.txt
>> >> +++ b/Documentation/devicetree/bindings/mfd/wm831x.txt
>> >> @@ -31,6 +31,7 @@ Required properties:
>> >>  ../interrupt-controller/interrupts.txt
>> >>
>> >>  Optional sub-nodes:
>> >> +  - usb-phy : Contains a phandle to the USB PHY.
>> >>- regulators : Contains sub-nodes for each of the regulators supplied 
>> >> by
>> >>  the device. The regulators are bound using their names listed below:
>> >>
>> >> diff --git a/drivers/power/supply/wm831x_power.c 
>> >> b/drivers/power/supply/wm831x_power.c
>> >> index 7082301..d3948ab 100644
>> >> --- a/drivers/power/supply/wm831x_power.c
>> >> +++ b/drivers/power/supply/wm831x_power.c
>> >> @@ -13,6 +13,7 @@
>> >>  #include 
>> >>  #include 
>> >>  #include 
>> >> +#include 
>> >>
>> >>  #include 
>> >>  #include 
>> >> @@ -31,6 +32,8 @@ struct wm831x_power {
>> >>   char usb_name[20];
>> >>   char battery_name[20];
>> >>   bool have_battery;
>> >> + struct usb_phy *usb_phy;
>> >> + struct notifier_block usb_notify;
>> >>  };
>> >>
>> >>  static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
>> >> @@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply 
>> >> *psy,
>> >>   POWER_SUPPLY_PROP_VOLTAGE_NOW,
>> >>  };
>> >>
>> >> +/* In milliamps */
>> >> +static const unsigned int wm831x_usb_limits[] = {
>> >> + 0,
>> >> + 2,
>> >> + 100,
>> >> + 500,
>> >> + 900,
>> >> + 1500,
>> >> + 1800,
>> >> + 550,
>> >> +};
>> >> +
>> >> +static int wm831x_usb_limit_change(struct notifier_block *nb,
>> >> +unsigned long limit, void *data)
>> >> +{
>> >> + struct wm831x_power *wm831x_power = container_of(nb,
>> >> +  struct 
>> >> wm831x_power,
>> >> +  usb_notify);
>> >> + unsigned int i, best;
>> >> +
>> >> + /* Find the highest supported limit */
>> >> + best = 0;
>> >> + for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
>> >> + if (limit >= wm831x_usb_limits[i] &&
>> >> + wm831x_usb_limits[best] < wm831x_usb_limits[i])
>> >> + best = i;
>> >> + }
>> >> +
>> >> + dev_dbg(wm831x_power->wm831x->dev,
>> >> + "Limiting USB current to %umA", wm831x_usb_limits[best]);
>> >> +
>> >> + wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
>> >> + WM831X_USB_ILIM_MASK, best);
>> >> +
>> >> + return 0;
>> >> +}
>> >> +
>> >>  /

Re: [PATCH v3 2/3] usb: phy: Add USB charger support

[Baolin Wang]

Hi Manu,

On 25 July 2017 at 19:19, Manu Gautam <mgau...@codeaurora.org> wrote:
> Hi,
>
>
> On 7/25/2017 1:30 PM, Baolin Wang wrote:
>> This patch introduces the usb charger support based on usb phy that
>> makes an enhancement to a power driver. The basic conception of the
>> usb charger is that, when one usb charger is added or removed by
>> reporting from the extcon device state change, the usb charger will
>> report to power user to set the current limitation.
>>
>> Power user can register a notifiee on the usb phy by issuing
>> usb_register_notifier() to get notified by charger status changes
>> or charger current changes.
>
> Why can't we use power_supply framework for this?
> Power user can register usb power_supply and USB PHY driver
> can update charging current using - power_supply_set_property().

No. We can get the current can be drawn from USB layer not from power
supply framework, moreover some USB controller can detect the charger
type and power supply framework can not. I think you missed lots of
previous discussion, maybe you can check below links to follow what we
have discussed before.
https://lists.gt.net/linux/kernel/2546730
https://patchwork.kernel.org/patch/9601973/


>> we can notify what current to be drawn to power user according to
>> different charger type, and now we have 2 methods to get charger type.
>> One is get charger type from extcon subsystem, which also means the
>> charger state changes. Another is we can get the charger type from
>> USB controller detecting or PMIC detecting, and the charger state
>> changes should be told by issuing usb_phy_set_charger_state().
>>
>> Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
>> ---
>>  drivers/usb/phy/phy.c   |  272 
>> +++
>>  include/linux/usb/phy.h |   49 +
>
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>



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

Re: [PATCH v3 3/3] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

Hi,

On 25 July 2017 at 17:59, Sebastian Reichel
<sebastian.reic...@collabora.co.uk> wrote:
> Hi,
>
> On Tue, Jul 25, 2017 at 04:00:01PM +0800, Baolin Wang wrote:
>> Integrate with the newly added USB charger interface to limit the current
>> we draw from the USB input based on the input device configuration
>> identified by the USB stack, allowing us to charge more quickly from high
>> current inputs without drawing more current than specified from others.
>>
>> Signed-off-by: Mark Brown <broo...@kernel.org>
>> Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
>> ---
>>  Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
>>  drivers/power/supply/wm831x_power.c  |   58 
>> ++
>>  2 files changed, 59 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/wm831x.txt 
>> b/Documentation/devicetree/bindings/mfd/wm831x.txt
>> index 9f8b743..4e3bc07 100644
>> --- a/Documentation/devicetree/bindings/mfd/wm831x.txt
>> +++ b/Documentation/devicetree/bindings/mfd/wm831x.txt
>> @@ -31,6 +31,7 @@ Required properties:
>>  ../interrupt-controller/interrupts.txt
>>
>>  Optional sub-nodes:
>> +  - usb-phy : Contains a phandle to the USB PHY.
>>- regulators : Contains sub-nodes for each of the regulators supplied by
>>  the device. The regulators are bound using their names listed below:
>>
>> diff --git a/drivers/power/supply/wm831x_power.c 
>> b/drivers/power/supply/wm831x_power.c
>> index 7082301..d3948ab 100644
>> --- a/drivers/power/supply/wm831x_power.c
>> +++ b/drivers/power/supply/wm831x_power.c
>> @@ -13,6 +13,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>  #include 
>> @@ -31,6 +32,8 @@ struct wm831x_power {
>>   char usb_name[20];
>>   char battery_name[20];
>>   bool have_battery;
>> + struct usb_phy *usb_phy;
>> + struct notifier_block usb_notify;
>>  };
>>
>>  static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
>> @@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
>>   POWER_SUPPLY_PROP_VOLTAGE_NOW,
>>  };
>>
>> +/* In milliamps */
>> +static const unsigned int wm831x_usb_limits[] = {
>> + 0,
>> + 2,
>> + 100,
>> + 500,
>> + 900,
>> + 1500,
>> + 1800,
>> + 550,
>> +};
>> +
>> +static int wm831x_usb_limit_change(struct notifier_block *nb,
>> +unsigned long limit, void *data)
>> +{
>> + struct wm831x_power *wm831x_power = container_of(nb,
>> +  struct wm831x_power,
>> +  usb_notify);
>> + unsigned int i, best;
>> +
>> + /* Find the highest supported limit */
>> + best = 0;
>> + for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
>> + if (limit >= wm831x_usb_limits[i] &&
>> + wm831x_usb_limits[best] < wm831x_usb_limits[i])
>> + best = i;
>> + }
>> +
>> + dev_dbg(wm831x_power->wm831x->dev,
>> + "Limiting USB current to %umA", wm831x_usb_limits[best]);
>> +
>> + wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
>> + WM831X_USB_ILIM_MASK, best);
>> +
>> + return 0;
>> +}
>> +
>>  /*
>>   *   Battery properties
>>   */
>> @@ -607,6 +647,19 @@ static int wm831x_power_probe(struct platform_device 
>> *pdev)
>>   }
>>   }
>>
>> + power->usb_phy = devm_usb_get_phy_by_phandle(>dev,
>> +  "usb-phy", 0);
>> + if (!IS_ERR(power->usb_phy)) {
>> + power->usb_notify.notifier_call = wm831x_usb_limit_change;
>> + ret = usb_register_notifier(power->usb_phy,
>> + >usb_notify);
>> + if (ret) {
>> + dev_err(>dev, "Failed to register notifier: 
>> %d\n",
>> + ret);
>> + goto err_bat_irq;
>> + }
>> + }
>
> No error handling for power->usb_phy? I

[PATCH v3 0/3] Introduce USB charger support in USB phy

[Baolin Wang]

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 USB charger support in USB phy core
for doing this in kernel.

Now introduce one user with wm831x_power to support and test the usb charger.
In future we will also cnvert below power drivers:
drivers/power/supply/axp288_charger.c
drivers/power/supply/bq24190_charger.c
drivers/power/supply/charger-manager.c
drivers/power/supply/qcom_smbb.c

Changes since v1:
 - Fix building errors.
Changes since v2:
 - Add DT binding documentation for wm831x_power driver.
 - Change 'usb-phy' as one optional property for wm831x_power driver.

Baolin Wang (3):
  include: uapi: usb: Introduce USB charger type and state definition
  usb: phy: Add USB charger support
  power: wm831x_power: Support USB charger current limit management

 Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
 drivers/power/supply/wm831x_power.c  |   58 +
 drivers/usb/phy/phy.c|  272 ++
 include/linux/usb/phy.h  |   49 
 include/uapi/linux/usb/charger.h |   31 +++
 5 files changed, 411 insertions(+)
 create mode 100644 include/uapi/linux/usb/charger.h

-- 
1.7.9.5

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

[PATCH v3 1/3] include: uapi: usb: Introduce USB charger type and state definition

[Baolin Wang]

Introducing USB charger type and state definition can help
to support USB charging which will be added in USB phy core.

Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
 include/uapi/linux/usb/charger.h |   31 +++
 1 file changed, 31 insertions(+)
 create mode 100644 include/uapi/linux/usb/charger.h

diff --git a/include/uapi/linux/usb/charger.h b/include/uapi/linux/usb/charger.h
new file mode 100644
index 000..5f72af3
--- /dev/null
+++ b/include/uapi/linux/usb/charger.h
@@ -0,0 +1,31 @@
+/*
+ * This file defines the USB charger type and state that are needed for
+ * USB device APIs.
+ */
+
+#ifndef _UAPI__LINUX_USB_CHARGER_H
+#define _UAPI__LINUX_USB_CHARGER_H
+
+/*
+ * USB charger type:
+ * SDP (Standard Downstream Port)
+ * DCP (Dedicated Charging Port)
+ * CDP (Charging Downstream Port)
+ * ACA (Accessory Charger Adapters)
+ */
+enum usb_charger_type {
+   UNKNOWN_TYPE,
+   SDP_TYPE,
+   DCP_TYPE,
+   CDP_TYPE,
+   ACA_TYPE,
+};
+
+/* USB charger state */
+enum usb_charger_state {
+   USB_CHARGER_DEFAULT,
+   USB_CHARGER_PRESENT,
+   USB_CHARGER_ABSENT,
+};
+
+#endif /* _UAPI__LINUX_USB_CHARGER_H */
-- 
1.7.9.5

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

[PATCH v3 3/3] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.

Signed-off-by: Mark Brown <broo...@kernel.org>
Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
 Documentation/devicetree/bindings/mfd/wm831x.txt |1 +
 drivers/power/supply/wm831x_power.c  |   58 ++
 2 files changed, 59 insertions(+)

diff --git a/Documentation/devicetree/bindings/mfd/wm831x.txt 
b/Documentation/devicetree/bindings/mfd/wm831x.txt
index 9f8b743..4e3bc07 100644
--- a/Documentation/devicetree/bindings/mfd/wm831x.txt
+++ b/Documentation/devicetree/bindings/mfd/wm831x.txt
@@ -31,6 +31,7 @@ Required properties:
 ../interrupt-controller/interrupts.txt
 
 Optional sub-nodes:
+  - usb-phy : Contains a phandle to the USB PHY.
   - regulators : Contains sub-nodes for each of the regulators supplied by
 the device. The regulators are bound using their names listed below:
 
diff --git a/drivers/power/supply/wm831x_power.c 
b/drivers/power/supply/wm831x_power.c
index 7082301..d3948ab 100644
--- a/drivers/power/supply/wm831x_power.c
+++ b/drivers/power/supply/wm831x_power.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -31,6 +32,8 @@ struct wm831x_power {
char usb_name[20];
char battery_name[20];
bool have_battery;
+   struct usb_phy *usb_phy;
+   struct notifier_block usb_notify;
 };
 
 static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
@@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
POWER_SUPPLY_PROP_VOLTAGE_NOW,
 };
 
+/* In milliamps */
+static const unsigned int wm831x_usb_limits[] = {
+   0,
+   2,
+   100,
+   500,
+   900,
+   1500,
+   1800,
+   550,
+};
+
+static int wm831x_usb_limit_change(struct notifier_block *nb,
+  unsigned long limit, void *data)
+{
+   struct wm831x_power *wm831x_power = container_of(nb,
+struct wm831x_power,
+usb_notify);
+   unsigned int i, best;
+
+   /* Find the highest supported limit */
+   best = 0;
+   for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
+   if (limit >= wm831x_usb_limits[i] &&
+   wm831x_usb_limits[best] < wm831x_usb_limits[i])
+   best = i;
+   }
+
+   dev_dbg(wm831x_power->wm831x->dev,
+   "Limiting USB current to %umA", wm831x_usb_limits[best]);
+
+   wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
+   WM831X_USB_ILIM_MASK, best);
+
+   return 0;
+}
+
 /*
  * Battery properties
  */
@@ -607,6 +647,19 @@ static int wm831x_power_probe(struct platform_device *pdev)
}
}
 
+   power->usb_phy = devm_usb_get_phy_by_phandle(>dev,
+"usb-phy", 0);
+   if (!IS_ERR(power->usb_phy)) {
+   power->usb_notify.notifier_call = wm831x_usb_limit_change;
+   ret = usb_register_notifier(power->usb_phy,
+   >usb_notify);
+   if (ret) {
+   dev_err(>dev, "Failed to register notifier: %d\n",
+   ret);
+   goto err_bat_irq;
+   }
+   }
+
return ret;
 
 err_bat_irq:
@@ -637,6 +690,11 @@ static int wm831x_power_remove(struct platform_device 
*pdev)
struct wm831x *wm831x = wm831x_power->wm831x;
int irq, i;
 
+   if (!IS_ERR(wm831x_power->usb_phy)) {
+   usb_unregister_notifier(wm831x_power->usb_phy,
+   _power->usb_notify);
+   }
+
for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
irq = wm831x_irq(wm831x, 
 platform_get_irq_byname(pdev,
-- 
1.7.9.5

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

[PATCH v3 2/3] usb: phy: Add USB charger support

[Baolin Wang]

This patch introduces the usb charger support based on usb phy that
makes an enhancement to a power driver. The basic conception of the
usb charger is that, when one usb charger is added or removed by
reporting from the extcon device state change, the usb charger will
report to power user to set the current limitation.

Power user can register a notifiee on the usb phy by issuing
usb_register_notifier() to get notified by charger status changes
or charger current changes.

we can notify what current to be drawn to power user according to
different charger type, and now we have 2 methods to get charger type.
One is get charger type from extcon subsystem, which also means the
charger state changes. Another is we can get the charger type from
USB controller detecting or PMIC detecting, and the charger state
changes should be told by issuing usb_phy_set_charger_state().

Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
 drivers/usb/phy/phy.c   |  272 +++
 include/linux/usb/phy.h |   49 +
 2 files changed, 321 insertions(+)

diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index 032f5af..2dc48bb 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -18,6 +18,18 @@
 
 #include 
 
+/* Default current range by charger type. */
+#define DEFAULT_SDP_CUR_MIN2
+#define DEFAULT_SDP_CUR_MAX500
+#define DEFAULT_SDP_CUR_MIN_SS 150
+#define DEFAULT_SDP_CUR_MAX_SS 900
+#define DEFAULT_DCP_CUR_MIN500
+#define DEFAULT_DCP_CUR_MAX5000
+#define DEFAULT_CDP_CUR_MIN1500
+#define DEFAULT_CDP_CUR_MAX5000
+#define DEFAULT_ACA_CUR_MIN1500
+#define DEFAULT_ACA_CUR_MAX5000
+
 static LIST_HEAD(phy_list);
 static LIST_HEAD(phy_bind_list);
 static DEFINE_SPINLOCK(phy_lock);
@@ -77,6 +89,221 @@ static struct usb_phy *__of_usb_find_phy(struct device_node 
*node)
return ERR_PTR(-EPROBE_DEFER);
 }
 
+static void usb_phy_set_default_current(struct usb_phy *usb_phy)
+{
+   usb_phy->chg_cur.sdp_min = DEFAULT_SDP_CUR_MIN;
+   usb_phy->chg_cur.sdp_max = DEFAULT_SDP_CUR_MAX;
+   usb_phy->chg_cur.dcp_min = DEFAULT_DCP_CUR_MIN;
+   usb_phy->chg_cur.dcp_max = DEFAULT_DCP_CUR_MAX;
+   usb_phy->chg_cur.cdp_min = DEFAULT_CDP_CUR_MIN;
+   usb_phy->chg_cur.cdp_max = DEFAULT_CDP_CUR_MAX;
+   usb_phy->chg_cur.aca_min = DEFAULT_ACA_CUR_MIN;
+   usb_phy->chg_cur.aca_max = DEFAULT_ACA_CUR_MAX;
+}
+
+/**
+ * usb_phy_notify_charger_work - notify the USB charger state
+ * @work - the charger work to notify the USB charger state
+ *
+ * This work can be issued when USB charger state has been changed or
+ * USB charger current has been changed, then we can notify the current
+ * what can be drawn to power user and the charger state to userspace.
+ *
+ * If we get the charger type from extcon subsystem, we can notify the
+ * charger state to power user automatically by usb_phy_get_charger_type()
+ * issuing from extcon subsystem.
+ *
+ * If we get the charger type from ->charger_detect() instead of extcon
+ * subsystem, the usb phy driver should issue usb_phy_set_charger_state()
+ * to set charger state when the charger state has been changed.
+ */
+static void usb_phy_notify_charger_work(struct work_struct *work)
+{
+   struct usb_phy *usb_phy = container_of(work, struct usb_phy, chg_work);
+   char uchger_state[50] = { 0 };
+   char *envp[] = { uchger_state, NULL };
+   unsigned int min, max;
+
+   switch (usb_phy->chg_state) {
+   case USB_CHARGER_PRESENT:
+   usb_phy_get_charger_current(usb_phy, , );
+
+   atomic_notifier_call_chain(_phy->notifier, max, usb_phy);
+   snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+"USB_CHARGER_STATE=%s", "USB_CHARGER_PRESENT");
+   break;
+   case USB_CHARGER_ABSENT:
+   usb_phy_set_default_current(usb_phy);
+
+   atomic_notifier_call_chain(_phy->notifier, 0, usb_phy);
+   snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+"USB_CHARGER_STATE=%s", "USB_CHARGER_ABSENT");
+   break;
+   default:
+   dev_warn(usb_phy->dev, "Unknown USB charger state: %d\n",
+usb_phy->chg_state);
+   return;
+   }
+
+   kobject_uevent_env(_phy->dev->kobj, KOBJ_CHANGE, envp);
+}
+
+static void __usb_phy_get_charger_type(struct usb_phy *usb_phy)
+{
+   if (extcon_get_state(usb_phy->edev, EXTCON_CHG_USB_SDP) > 0) {
+   usb_phy->chg_type = SDP_TYPE;
+   usb_phy->chg_state = USB_CHARGER_PRESENT;
+   } else if (extcon_get_state(usb_phy->edev, EXTCON_CHG_USB_CDP) > 0) {
+   usb_phy->chg_type = CDP_TYPE;
+   usb_phy->chg_state = USB_CHARGER_PRESENT;
+   } else if (extcon_get_

Re: [PATCH] usb: dwc3: Support the dwc3 host suspend/resume

[Baolin Wang]

Hi Manu,

On 24 July 2017 at 17:38, Manu Gautam <mgau...@codeaurora.org> wrote:
> Hi,
>
>
> On 7/24/2017 2:45 PM, Baolin Wang wrote:
>> Hi Manu,
>>
>> On 24 July 2017 at 16:42, Manu Gautam <mgau...@codeaurora.org> wrote:
>>> Hi Baolin,
>>>
>>>
>>> On 7/24/2017 11:26 AM, Baolin Wang wrote:
>>>
>>>>>>> Other than what I pushed in my patch -
>>>>>>> ("usb: dwc3: Don't reinitialize core during host bus-suspend/resume")
>>>>>>> Just performing pm_request_resume or handling same in dwc3 glue
>>>>>>> driver should be sufficient.
>>>>>> Yes.
>>>>>>
>>>>>>> Also, what is trigger for runtime_resume for your platform?
>>>>>> In our platform glue layer, we have extcon events to notify there are
>>>>>> devices connected, then gule layer will resume dwc3 device.
>>>>>>
>>>>> IMO you can just perform resume of >xhci->dev instead of resuming 
>>>>> dwc3.
>>>>> Since, dwc3 is parent of xhci that will trigger resume of dwc3 as well.
>>>> I am not sure this is good enough but it seems can solve some
>>>> problems, then we do not need resume/suspend host in dwc3 core.
>>> In that case can we proceed with this patch:
>>> [1] https://www.spinics.net/lists/linux-usb/msg158682.html
>>>
>>> For your platform you can pick this patch and resume dwc->xhci->dev resume
>>> from your glue driver.
>>> Do you have any other concerns?
>> The same concern I explained in your patch. If we power off the
>> controller when suspend, how can controller work well as host if we do
>> not issue dwc3_core_init()? Suppose below cases:
>> device attached: resume glue layer (power on dwc3 controller) --->
>> resume dwc3 device ---> resume xHCI device
> Just resume won't do. XHCI also needs to be reinitialized.
>
>> no device attached: suspend xHCI device ---> suspend dwc3 device --->
>> suspend glue layer (we can power off the dwc3 controller now)
>>
>> Though now there are no upstreamed glue drivers will power off dwc3
>> controller, should we consider this situation?
>>
>
> Can we discuss on that patch thread itself?
>
> How will this platform handle runtime PM with only external HUB
> connected? Will runtime suspend take place?
> Would connecting device to that HUB's port be detected?

No, it should not suspend xHCI now. Maybe need get xHCI device usage
counter for this case in case xHCI can suspend automatically if there
are no device connected.

>
> Since, there is no upstreamed glue driver currently doing, we can
> probably ignore that. Also, above sequnence wont work without xhci init.
>
> Also, for this particular case glue driver can take care of re-initializing of
> dwc3 core as well.

Glue layer can not re-initialize of dwc3 core now since
dwc3_core_init() is not exported. Let's see what Felipe's suggestion
on your patch thread.

-- 
Baolin.wang
Best Regards
--
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: dwc3: Support the dwc3 host suspend/resume

[Baolin Wang]

Hi Manu,

On 24 July 2017 at 16:42, Manu Gautam <mgau...@codeaurora.org> wrote:
> Hi Baolin,
>
>
> On 7/24/2017 11:26 AM, Baolin Wang wrote:
>
>>>>> Other than what I pushed in my patch -
>>>>> ("usb: dwc3: Don't reinitialize core during host bus-suspend/resume")
>>>>> Just performing pm_request_resume or handling same in dwc3 glue
>>>>> driver should be sufficient.
>>>> Yes.
>>>>
>>>>> Also, what is trigger for runtime_resume for your platform?
>>>> In our platform glue layer, we have extcon events to notify there are
>>>> devices connected, then gule layer will resume dwc3 device.
>>>>
>>> IMO you can just perform resume of >xhci->dev instead of resuming dwc3.
>>> Since, dwc3 is parent of xhci that will trigger resume of dwc3 as well.
>> I am not sure this is good enough but it seems can solve some
>> problems, then we do not need resume/suspend host in dwc3 core.
>
> In that case can we proceed with this patch:
> [1] https://www.spinics.net/lists/linux-usb/msg158682.html
>
> For your platform you can pick this patch and resume dwc->xhci->dev resume
> from your glue driver.
> Do you have any other concerns?

The same concern I explained in your patch. If we power off the
controller when suspend, how can controller work well as host if we do
not issue dwc3_core_init()? Suppose below cases:
device attached: resume glue layer (power on dwc3 controller) --->
resume dwc3 device ---> resume xHCI device
no device attached: suspend xHCI device ---> suspend dwc3 device --->
suspend glue layer (we can power off the dwc3 controller now)

Though now there are no upstreamed glue drivers will power off dwc3
controller, should we consider this situation?

-- 
Baolin.wang
Best Regards
--
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: dwc3: Support the dwc3 host suspend/resume

[Baolin Wang]

Hi,

On 21 July 2017 at 17:13, Manu Gautam <mgau...@codeaurora.org> wrote:
> Hi,
>
> On 7/21/2017 2:31 PM, Baolin Wang wrote:
>> On 21 July 2017 at 16:45, Manu Gautam <mgau...@codeaurora.org> wrote:
>>> Hi,
>>>
>>>
>>> On 7/21/2017 12:28 PM, Baolin Wang wrote:
>>>> For some mobile devices with strict power management, we also want to
>>>> suspend the host when the slave was detached for power saving. Thus
>>>> adding the host suspend/resume functions to support this requirement.
>>>
>>> USB/PM core already takes care of suspending root-HUB/XHCI when
>>> no device connected.
>> Correct, but what I mean is we can power off the dwc3 controller when
>> there are no device connected.
>>
>>>> We will issue the pm_suspend_ignore_children() for the dwc3 device,
>>>> since we will resume the child device (xHCI device) in runtime resume
>>>> callback (dwc3_host_resume()) of dwc3 device, now the dwc3 device's
>>>> runtime state is not RPM_ACTIVE, which will block to resume its
>>>> child device (xHCI device). Add ignore children flag can avoid this
>>>> situation.
>>> This defeats the basic purpose of runtime PM. Without ignore_children
>>> once USB bus is suspended, dwc3 gets suspended and then dwc3 glue device.
>>> Only requirement I see from the patch is to resume XHCI/root-hub on
>>> dwc3 resume. I am sure there must be other way to deal with that e.g.
>>> doing same from glue driver by using a wq or use pm_request_resume()
>> Ah, I will try pm_request_resume().
>>
>>>> Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
>>>> ---
>>>>  drivers/usb/dwc3/core.c |   26 +-
>>>>  drivers/usb/dwc3/core.h |7 +++
>>>>  drivers/usb/dwc3/host.c |   15 +++
>>>>  3 files changed, 47 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>>> index 326b302..2be7ddc 100644
>>>> --- a/drivers/usb/dwc3/core.c
>>>> +++ b/drivers/usb/dwc3/core.c
>>>> @@ -1193,6 +1193,7 @@ static int dwc3_probe(struct platform_device *pdev)
>>>>   pm_runtime_use_autosuspend(dev);
>>>>   pm_runtime_set_autosuspend_delay(dev, 
>>>> DWC3_DEFAULT_AUTOSUSPEND_DELAY);
>>>>   pm_runtime_enable(dev);
>>>> + pm_suspend_ignore_children(dev, true);
>>>>   ret = pm_runtime_get_sync(dev);
>>>>   if (ret < 0)
>>>>   goto err1;
>>>> @@ -1292,15 +1293,27 @@ static int dwc3_remove(struct platform_device 
>>>> *pdev)
>>>>  static int dwc3_suspend_common(struct dwc3 *dwc)
>>> What is the trigger for runtime suspend now that you have ignore_children 
>>> set.
>>>>  {
>>>>   unsigned long   flags;
>>>> + int ret;
>>>>
>>>>   switch (dwc->dr_mode) {
>>>>   case USB_DR_MODE_PERIPHERAL:
>>>> + spin_lock_irqsave(>lock, flags);
>>>> + dwc3_gadget_suspend(dwc);
>>>> + spin_unlock_irqrestore(>lock, flags);
>>>> + break;
>>>>   case USB_DR_MODE_OTG:
>>>> + ret = dwc3_host_suspend(dwc);
>>> With DRD/OTG, if current mode is device and dwc3->xhci won't be valid.
>> If current mode is device, then xHCI device is always in suspend state.
> dwc->xhci is allocated in dwc3_host_init. And dwc->xhci device is unregistred
> from dwc3_host_exit that is called from __dwc3_set_mode.

Yes, you are right. I think I need check the dwc->current_dr_role to
identify host or device mode.

>>
>>> You can refer to the patch that I pushed to address this.
>>>
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>>   spin_lock_irqsave(>lock, flags);
>>>>   dwc3_gadget_suspend(dwc);
>>>>   spin_unlock_irqrestore(>lock, flags);
>>>>   break;
>>>>   case USB_DR_MODE_HOST:
>>>> + ret = dwc3_host_suspend(dwc);
>>>> + if (ret)
>>>> + return ret;
>>>>   default:
>>>>   /* do nothing */
>>>>   break;
>>>> @@ -1322,12 +1335,23 @@ static int dwc3_resume_common(struct dwc3 *dwc)
>>>>
&g

Re: [PATCH] usb: dwc3: Support the dwc3 host suspend/resume

[Baolin Wang]

On 21 July 2017 at 16:45, Manu Gautam <mgau...@codeaurora.org> wrote:
> Hi,
>
>
> On 7/21/2017 12:28 PM, Baolin Wang wrote:
>> For some mobile devices with strict power management, we also want to
>> suspend the host when the slave was detached for power saving. Thus
>> adding the host suspend/resume functions to support this requirement.
>
>
> USB/PM core already takes care of suspending root-HUB/XHCI when
> no device connected.

Correct, but what I mean is we can power off the dwc3 controller when
there are no device connected.

>
>>
>> We will issue the pm_suspend_ignore_children() for the dwc3 device,
>> since we will resume the child device (xHCI device) in runtime resume
>> callback (dwc3_host_resume()) of dwc3 device, now the dwc3 device's
>> runtime state is not RPM_ACTIVE, which will block to resume its
>> child device (xHCI device). Add ignore children flag can avoid this
>> situation.
>
> This defeats the basic purpose of runtime PM. Without ignore_children
> once USB bus is suspended, dwc3 gets suspended and then dwc3 glue device.
> Only requirement I see from the patch is to resume XHCI/root-hub on
> dwc3 resume. I am sure there must be other way to deal with that e.g.
> doing same from glue driver by using a wq or use pm_request_resume()

Ah, I will try pm_request_resume().

>
>>
>> Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
>> ---
>>  drivers/usb/dwc3/core.c |   26 +-
>>  drivers/usb/dwc3/core.h |7 +++
>>  drivers/usb/dwc3/host.c |   15 +++
>>  3 files changed, 47 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 326b302..2be7ddc 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -1193,6 +1193,7 @@ static int dwc3_probe(struct platform_device *pdev)
>>   pm_runtime_use_autosuspend(dev);
>>   pm_runtime_set_autosuspend_delay(dev, DWC3_DEFAULT_AUTOSUSPEND_DELAY);
>>   pm_runtime_enable(dev);
>> + pm_suspend_ignore_children(dev, true);
>>   ret = pm_runtime_get_sync(dev);
>>   if (ret < 0)
>>   goto err1;
>> @@ -1292,15 +1293,27 @@ static int dwc3_remove(struct platform_device *pdev)
>>  static int dwc3_suspend_common(struct dwc3 *dwc)
>
> What is the trigger for runtime suspend now that you have ignore_children set.
>>  {
>>   unsigned long   flags;
>> + int ret;
>>
>>   switch (dwc->dr_mode) {
>>   case USB_DR_MODE_PERIPHERAL:
>> + spin_lock_irqsave(>lock, flags);
>> + dwc3_gadget_suspend(dwc);
>> + spin_unlock_irqrestore(>lock, flags);
>> + break;
>>   case USB_DR_MODE_OTG:
>> + ret = dwc3_host_suspend(dwc);
> With DRD/OTG, if current mode is device and dwc3->xhci won't be valid.

If current mode is device, then xHCI device is always in suspend state.

> You can refer to the patch that I pushed to address this.
>
>> + if (ret)
>> + return ret;
>> +
>>   spin_lock_irqsave(>lock, flags);
>>   dwc3_gadget_suspend(dwc);
>>   spin_unlock_irqrestore(>lock, flags);
>>   break;
>>   case USB_DR_MODE_HOST:
>> + ret = dwc3_host_suspend(dwc);
>> + if (ret)
>> + return ret;
>>   default:
>>   /* do nothing */
>>   break;
>> @@ -1322,12 +1335,23 @@ static int dwc3_resume_common(struct dwc3 *dwc)
>>
>>   switch (dwc->dr_mode) {
>>   case USB_DR_MODE_PERIPHERAL:
>> + spin_lock_irqsave(>lock, flags);
>> + dwc3_gadget_resume(dwc);
>> + spin_unlock_irqrestore(>lock, flags);
>> + break;
>>   case USB_DR_MODE_OTG:
>> + ret = dwc3_host_resume(dwc);
>> + if (ret)
>> + return ret;
>> +
>>   spin_lock_irqsave(>lock, flags);
>>   dwc3_gadget_resume(dwc);
>>   spin_unlock_irqrestore(>lock, flags);
>> - /* FALLTHROUGH */
>> + break;
>>   case USB_DR_MODE_HOST:
>> + ret = dwc3_host_resume(dwc);
>> + if (ret)
>> + return ret;
>>   default:
>>   /* do nothing */
>>   break;
>> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
>> index ea910ac..9

Re: [PATCH 1/2] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

[Baolin Wang]

Hi Manu,

On 21 July 2017 at 10:32, Baolin Wang <baolin.w...@linaro.org> wrote:
> Hi Manu,
>
> On 20 July 2017 at 19:12, Manu Gautam <mgau...@codeaurora.org> wrote:
>> Hi,
>>
>>
>> On 7/13/2017 1:13 PM, Baolin Wang wrote:
>>> Hi,
>>>
>>> On 13 July 2017 at 15:26, Manu Gautam <mgau...@codeaurora.org> wrote:
>>>>
>>>> On 7/13/2017 11:33 AM, Baolin Wang wrote:
>>>>> On 12 July 2017 at 16:58, Manu Gautam <mgau...@codeaurora.org> wrote:
>>>>>> On 7/12/2017 2:06 PM, Baolin Wang wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 12 July 2017 at 15:25, Manu Gautam <mgau...@codeaurora.org> wrote:
>>>>>>>> On 7/12/2017 12:19 PM, Baolin Wang wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 3 July 2017 at 19:25, Manu Gautam <mgau...@codeaurora.org> wrote:
>>>>>>>>>> Driver powers-off PHYs and reinitializes DWC3 core and gadget on
>>>>>>>>>> resume. While this works fine for gadget mode but in host
>>>>>>>>>> mode there is not re-initialization of host stack. Also, resetting
>>>>>>>>>> bus as part of bus_suspend/resume is not correct which could affect
>>>>>>>>>> (or disconnect) connected devices.
>>>>>>>>>> Fix this by not reinitializing core on suspend/resume in host mode
>>>>>>>>>> for HOST only and OTG/drd configurations.
>>>>>>>>> But for some mobile devices, they also need suspend/resume in host
>>>>>>>>> mode which will power off dwc3 controller in glue layer. If we remove
>>>>>>>>> dwc3_core_init() for host mode, I am afraid it can not work well in
>>>>>>>>> host mode after resuming dwc3.
>>>>>>>> Can you point me to a glue driver doing that?
>>>>>>> Yes, now there are no glue driver doing that, but for many vendor
>>>>>>> trees they will do that. (Our platform will power off dwc3 when
>>>>>>> suspending dwc3, but have not upstreamed yet)
>>>>>> Fine, but glue driver still need to take care of re-initialization on 
>>>>>> resume
>>>>>> with current design.
>>>>> Yes.
>>>>>
>>>>>>>> If dwc3 is powered off on suspend then Xhci level initialization also
>>>>>>>> needed
>>>>>>>> after
>>>>>>>> performing dwc3_core_init on resume which is currently not present. So
>>>>>>>> this
>>>>>>>> seems
>>>>>>>> to me broken anyway.
>>>>>>> Since we've add runtime PM for xhci-plat driver [1], which means we
>>>>>>> can runtime suspend/resume xhci device from dwc3 [2].
>>>>>>> [1] https://www.spinics.net/lists/linux-usb/msg156077.html
>>>>>>> [2] https://patchwork.kernel.org/patch/9471869/
>>>>>> Sure. We can discuss this patch once you re-submit.
>>>>>> One concern I have with the patch is marking ignore_children for dwc3 
>>>>>> and as
>>>>>> part of
>>>>>> dwc3 suspend/resume invoking
>>>>> Suppose we will suspend xhci device as dwc3's child, but now dwc3
>>>>> device is not suspend yet, which will block to suspend xhci device.
>>>>> Thus we should set ignore children flag to remove the parent
>>>>> dependency.
>>>> I may not have understood the issue. In any case children must be 
>>>> suspended first.
>>>> Example sequence is:
>>>> external hub/device (if any) suspend -> root hub  -> xhci -> dwc3 core -> 
>>>> dwc3 glue.
>>>> xhci device's runtime/pm suspend should happen before dwc3 gets suspended.
>>> Since the [2] patch will get/put xhci usage counter to avoid affecting
>>> other controller's runtime PM, then we need ignore child. But now
>>> xhci-plat driver has done this (by issuing pm_runtime_forbid()
>>> default), we can remove the get/put counter in dwc3, then we do not
>>> need ignore child flag any more.
>>>
>>>>>> runtime pm on xhci. Ideally pm core should handle it seamlessly i.e.
>>>>>> suspending dwc3
>>>>>> once xhci gets suspended and pm_st

[PATCH] usb: dwc3: Support the dwc3 host suspend/resume

[Baolin Wang]

For some mobile devices with strict power management, we also want to
suspend the host when the slave was detached for power saving. Thus
adding the host suspend/resume functions to support this requirement.

We will issue the pm_suspend_ignore_children() for the dwc3 device,
since we will resume the child device (xHCI device) in runtime resume
callback (dwc3_host_resume()) of dwc3 device, now the dwc3 device's
runtime state is not RPM_ACTIVE, which will block to resume its
child device (xHCI device). Add ignore children flag can avoid this
situation.

Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
 drivers/usb/dwc3/core.c |   26 +-
 drivers/usb/dwc3/core.h |7 +++
 drivers/usb/dwc3/host.c |   15 +++
 3 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 326b302..2be7ddc 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -1193,6 +1193,7 @@ static int dwc3_probe(struct platform_device *pdev)
pm_runtime_use_autosuspend(dev);
pm_runtime_set_autosuspend_delay(dev, DWC3_DEFAULT_AUTOSUSPEND_DELAY);
pm_runtime_enable(dev);
+   pm_suspend_ignore_children(dev, true);
ret = pm_runtime_get_sync(dev);
if (ret < 0)
goto err1;
@@ -1292,15 +1293,27 @@ static int dwc3_remove(struct platform_device *pdev)
 static int dwc3_suspend_common(struct dwc3 *dwc)
 {
unsigned long   flags;
+   int ret;
 
switch (dwc->dr_mode) {
case USB_DR_MODE_PERIPHERAL:
+   spin_lock_irqsave(>lock, flags);
+   dwc3_gadget_suspend(dwc);
+   spin_unlock_irqrestore(>lock, flags);
+   break;
case USB_DR_MODE_OTG:
+   ret = dwc3_host_suspend(dwc);
+   if (ret)
+   return ret;
+
spin_lock_irqsave(>lock, flags);
dwc3_gadget_suspend(dwc);
spin_unlock_irqrestore(>lock, flags);
break;
case USB_DR_MODE_HOST:
+   ret = dwc3_host_suspend(dwc);
+   if (ret)
+   return ret;
default:
/* do nothing */
break;
@@ -1322,12 +1335,23 @@ static int dwc3_resume_common(struct dwc3 *dwc)
 
switch (dwc->dr_mode) {
case USB_DR_MODE_PERIPHERAL:
+   spin_lock_irqsave(>lock, flags);
+   dwc3_gadget_resume(dwc);
+   spin_unlock_irqrestore(>lock, flags);
+   break;
case USB_DR_MODE_OTG:
+   ret = dwc3_host_resume(dwc);
+   if (ret)
+   return ret;
+
spin_lock_irqsave(>lock, flags);
dwc3_gadget_resume(dwc);
spin_unlock_irqrestore(>lock, flags);
-   /* FALLTHROUGH */
+   break;
case USB_DR_MODE_HOST:
+   ret = dwc3_host_resume(dwc);
+   if (ret)
+   return ret;
default:
/* do nothing */
break;
diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
index ea910ac..9b5a4eb 100644
--- a/drivers/usb/dwc3/core.h
+++ b/drivers/usb/dwc3/core.h
@@ -1193,11 +1193,18 @@ static inline bool dwc3_is_usb31(struct dwc3 *dwc)
 #if IS_ENABLED(CONFIG_USB_DWC3_HOST) || IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)
 int dwc3_host_init(struct dwc3 *dwc);
 void dwc3_host_exit(struct dwc3 *dwc);
+int dwc3_host_suspend(struct dwc3 *dwc);
+int dwc3_host_resume(struct dwc3 *dwc);
 #else
 static inline int dwc3_host_init(struct dwc3 *dwc)
 { return 0; }
 static inline void dwc3_host_exit(struct dwc3 *dwc)
 { }
+
+static inline int dwc3_host_suspend(struct dwc3 *dwc)
+{ return 0; }
+static inline int dwc3_host_resume(struct dwc3 *dwc)
+{ return 0; }
 #endif
 
 #if IS_ENABLED(CONFIG_USB_DWC3_GADGET) || IS_ENABLED(CONFIG_USB_DWC3_DUAL_ROLE)
diff --git a/drivers/usb/dwc3/host.c b/drivers/usb/dwc3/host.c
index 76f0b0d..3fa4414 100644
--- a/drivers/usb/dwc3/host.c
+++ b/drivers/usb/dwc3/host.c
@@ -16,6 +16,7 @@
  */
 
 #include 
+#include 
 
 #include "core.h"
 
@@ -151,3 +152,17 @@ void dwc3_host_exit(struct dwc3 *dwc)
  dev_name(dwc->dev));
platform_device_unregister(dwc->xhci);
 }
+
+int dwc3_host_suspend(struct dwc3 *dwc)
+{
+   struct device *xhci = >xhci->dev;
+
+   return pm_runtime_suspend(xhci);
+}
+
+int dwc3_host_resume(struct dwc3 *dwc)
+{
+   struct device *xhci = >xhci->dev;
+
+   return pm_runtime_resume(xhci);
+}
-- 
1.7.9.5

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

Re: [PATCH 1/2] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

[Baolin Wang]

Hi Manu,

On 20 July 2017 at 19:12, Manu Gautam <mgau...@codeaurora.org> wrote:
> Hi,
>
>
> On 7/13/2017 1:13 PM, Baolin Wang wrote:
>> Hi,
>>
>> On 13 July 2017 at 15:26, Manu Gautam <mgau...@codeaurora.org> wrote:
>>>
>>> On 7/13/2017 11:33 AM, Baolin Wang wrote:
>>>> On 12 July 2017 at 16:58, Manu Gautam <mgau...@codeaurora.org> wrote:
>>>>> On 7/12/2017 2:06 PM, Baolin Wang wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 12 July 2017 at 15:25, Manu Gautam <mgau...@codeaurora.org> wrote:
>>>>>>> On 7/12/2017 12:19 PM, Baolin Wang wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> On 3 July 2017 at 19:25, Manu Gautam <mgau...@codeaurora.org> wrote:
>>>>>>>>> Driver powers-off PHYs and reinitializes DWC3 core and gadget on
>>>>>>>>> resume. While this works fine for gadget mode but in host
>>>>>>>>> mode there is not re-initialization of host stack. Also, resetting
>>>>>>>>> bus as part of bus_suspend/resume is not correct which could affect
>>>>>>>>> (or disconnect) connected devices.
>>>>>>>>> Fix this by not reinitializing core on suspend/resume in host mode
>>>>>>>>> for HOST only and OTG/drd configurations.
>>>>>>>> But for some mobile devices, they also need suspend/resume in host
>>>>>>>> mode which will power off dwc3 controller in glue layer. If we remove
>>>>>>>> dwc3_core_init() for host mode, I am afraid it can not work well in
>>>>>>>> host mode after resuming dwc3.
>>>>>>> Can you point me to a glue driver doing that?
>>>>>> Yes, now there are no glue driver doing that, but for many vendor
>>>>>> trees they will do that. (Our platform will power off dwc3 when
>>>>>> suspending dwc3, but have not upstreamed yet)
>>>>> Fine, but glue driver still need to take care of re-initialization on 
>>>>> resume
>>>>> with current design.
>>>> Yes.
>>>>
>>>>>>> If dwc3 is powered off on suspend then Xhci level initialization also
>>>>>>> needed
>>>>>>> after
>>>>>>> performing dwc3_core_init on resume which is currently not present. So
>>>>>>> this
>>>>>>> seems
>>>>>>> to me broken anyway.
>>>>>> Since we've add runtime PM for xhci-plat driver [1], which means we
>>>>>> can runtime suspend/resume xhci device from dwc3 [2].
>>>>>> [1] https://www.spinics.net/lists/linux-usb/msg156077.html
>>>>>> [2] https://patchwork.kernel.org/patch/9471869/
>>>>> Sure. We can discuss this patch once you re-submit.
>>>>> One concern I have with the patch is marking ignore_children for dwc3 and 
>>>>> as
>>>>> part of
>>>>> dwc3 suspend/resume invoking
>>>> Suppose we will suspend xhci device as dwc3's child, but now dwc3
>>>> device is not suspend yet, which will block to suspend xhci device.
>>>> Thus we should set ignore children flag to remove the parent
>>>> dependency.
>>> I may not have understood the issue. In any case children must be suspended 
>>> first.
>>> Example sequence is:
>>> external hub/device (if any) suspend -> root hub  -> xhci -> dwc3 core -> 
>>> dwc3 glue.
>>> xhci device's runtime/pm suspend should happen before dwc3 gets suspended.
>> Since the [2] patch will get/put xhci usage counter to avoid affecting
>> other controller's runtime PM, then we need ignore child. But now
>> xhci-plat driver has done this (by issuing pm_runtime_forbid()
>> default), we can remove the get/put counter in dwc3, then we do not
>> need ignore child flag any more.
>>
>>>>> runtime pm on xhci. Ideally pm core should handle it seamlessly i.e.
>>>>> suspending dwc3
>>>>> once xhci gets suspended and pm_stay_awake/relax can be used to block
>>>>> pm_suspend
>>>>> until runtime suspend of glue driver happens.
>>>>>
>>>>>> But [2] has not applied yet now, I will try to upstream it again. Then
>>>>>> we can suspend xhci device--> suspend dwc3 host---> glue layer can
>>>>>> power off, and it is similar when resuming in host mode.
>>>>> Do you see any issues with this patch?
>>>>> I am able to get runtime suspend/resume happening fine with XHCI on my
>>>>> platform.
>>>>> It involves runtime suspend/resume of USB HUB and dwc3 glue driver without
>>>>> any other
>>>>> change.
>>>> Great, I will try this patch again.
>
> Baolin, just checking if you were able to test this?

Yes, I will test this and resubmit again next week.

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

Re: [PATCH v2 0/3] Introduce USB charger support in USB phy

[Baolin Wang]

Hi,

On 3 July 2017 at 14:07, Baolin Wang <baolin.w...@linaro.org> 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 USB charger support in USB phy core
> for doing this in kernel.
>
> Now introduce one user with wm831x_power to support and test the usb charger.
>
> Changes since v1:
>  - Fix building errors.
>
> Baolin Wang (3):
>   include: uapi: usb: Introduce USB charger type and state definition
>   usb: phy: Add USB charger support
>   power: wm831x_power: Support USB charger current limit management

Any suggestion for the USB charger support in USB phy core? Thanks.

>
>  drivers/power/supply/wm831x_power.c |   61 
>  drivers/usb/phy/phy.c   |  265 
> +++
>  include/linux/usb/phy.h |   49 +++
>  include/uapi/linux/usb/charger.h|   31 
>  4 files changed, 406 insertions(+)
>  create mode 100644 include/uapi/linux/usb/charger.h
>
> --
> 1.7.9.5
>



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

Re: [PATCH 1/2] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

[Baolin Wang]

Hi,

On 13 July 2017 at 15:26, Manu Gautam <mgau...@codeaurora.org> wrote:
>
>
> On 7/13/2017 11:33 AM, Baolin Wang wrote:
>> On 12 July 2017 at 16:58, Manu Gautam <mgau...@codeaurora.org> wrote:
>>>
>>> On 7/12/2017 2:06 PM, Baolin Wang wrote:
>>>> Hi,
>>>>
>>>> On 12 July 2017 at 15:25, Manu Gautam <mgau...@codeaurora.org> wrote:
>>>>>
>>>>> On 7/12/2017 12:19 PM, Baolin Wang wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 3 July 2017 at 19:25, Manu Gautam <mgau...@codeaurora.org> wrote:
>>>>>>> Driver powers-off PHYs and reinitializes DWC3 core and gadget on
>>>>>>> resume. While this works fine for gadget mode but in host
>>>>>>> mode there is not re-initialization of host stack. Also, resetting
>>>>>>> bus as part of bus_suspend/resume is not correct which could affect
>>>>>>> (or disconnect) connected devices.
>>>>>>> Fix this by not reinitializing core on suspend/resume in host mode
>>>>>>> for HOST only and OTG/drd configurations.
>>>>>> But for some mobile devices, they also need suspend/resume in host
>>>>>> mode which will power off dwc3 controller in glue layer. If we remove
>>>>>> dwc3_core_init() for host mode, I am afraid it can not work well in
>>>>>> host mode after resuming dwc3.
>>>>> Can you point me to a glue driver doing that?
>>>> Yes, now there are no glue driver doing that, but for many vendor
>>>> trees they will do that. (Our platform will power off dwc3 when
>>>> suspending dwc3, but have not upstreamed yet)
>>>
>>> Fine, but glue driver still need to take care of re-initialization on resume
>>> with current design.
>> Yes.
>>
>>>>> If dwc3 is powered off on suspend then Xhci level initialization also
>>>>> needed
>>>>> after
>>>>> performing dwc3_core_init on resume which is currently not present. So
>>>>> this
>>>>> seems
>>>>> to me broken anyway.
>>>> Since we've add runtime PM for xhci-plat driver [1], which means we
>>>> can runtime suspend/resume xhci device from dwc3 [2].
>>>> [1] https://www.spinics.net/lists/linux-usb/msg156077.html
>>>> [2] https://patchwork.kernel.org/patch/9471869/
>>>
>>> Sure. We can discuss this patch once you re-submit.
>>> One concern I have with the patch is marking ignore_children for dwc3 and as
>>> part of
>>> dwc3 suspend/resume invoking
>> Suppose we will suspend xhci device as dwc3's child, but now dwc3
>> device is not suspend yet, which will block to suspend xhci device.
>> Thus we should set ignore children flag to remove the parent
>> dependency.
>
> I may not have understood the issue. In any case children must be suspended 
> first.
> Example sequence is:
> external hub/device (if any) suspend -> root hub  -> xhci -> dwc3 core -> 
> dwc3 glue.
> xhci device's runtime/pm suspend should happen before dwc3 gets suspended.

Since the [2] patch will get/put xhci usage counter to avoid affecting
other controller's runtime PM, then we need ignore child. But now
xhci-plat driver has done this (by issuing pm_runtime_forbid()
default), we can remove the get/put counter in dwc3, then we do not
need ignore child flag any more.

>>> runtime pm on xhci. Ideally pm core should handle it seamlessly i.e.
>>> suspending dwc3
>>> once xhci gets suspended and pm_stay_awake/relax can be used to block
>>> pm_suspend
>>> until runtime suspend of glue driver happens.
>>>
>>>> But [2] has not applied yet now, I will try to upstream it again. Then
>>>> we can suspend xhci device--> suspend dwc3 host---> glue layer can
>>>> power off, and it is similar when resuming in host mode.
>>>
>>> Do you see any issues with this patch?
>>> I am able to get runtime suspend/resume happening fine with XHCI on my
>>> platform.
>>> It involves runtime suspend/resume of USB HUB and dwc3 glue driver without
>>> any other
>>> change.
>> Great, I will try this patch again.
>>
>



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

Re: [PATCH 1/2] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

[Baolin Wang]

On 12 July 2017 at 16:58, Manu Gautam <mgau...@codeaurora.org> wrote:
>
>
> On 7/12/2017 2:06 PM, Baolin Wang wrote:
>>
>> Hi,
>>
>> On 12 July 2017 at 15:25, Manu Gautam <mgau...@codeaurora.org> wrote:
>>>
>>>
>>> On 7/12/2017 12:19 PM, Baolin Wang wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 3 July 2017 at 19:25, Manu Gautam <mgau...@codeaurora.org> wrote:
>>>>>
>>>>> Driver powers-off PHYs and reinitializes DWC3 core and gadget on
>>>>> resume. While this works fine for gadget mode but in host
>>>>> mode there is not re-initialization of host stack. Also, resetting
>>>>> bus as part of bus_suspend/resume is not correct which could affect
>>>>> (or disconnect) connected devices.
>>>>> Fix this by not reinitializing core on suspend/resume in host mode
>>>>> for HOST only and OTG/drd configurations.
>>>>
>>>> But for some mobile devices, they also need suspend/resume in host
>>>> mode which will power off dwc3 controller in glue layer. If we remove
>>>> dwc3_core_init() for host mode, I am afraid it can not work well in
>>>> host mode after resuming dwc3.
>>>
>>> Can you point me to a glue driver doing that?
>>
>> Yes, now there are no glue driver doing that, but for many vendor
>> trees they will do that. (Our platform will power off dwc3 when
>> suspending dwc3, but have not upstreamed yet)
>
>
> Fine, but glue driver still need to take care of re-initialization on resume
> with current design.

Yes.

>
>>> If dwc3 is powered off on suspend then Xhci level initialization also
>>> needed
>>> after
>>> performing dwc3_core_init on resume which is currently not present. So
>>> this
>>> seems
>>> to me broken anyway.
>>
>> Since we've add runtime PM for xhci-plat driver [1], which means we
>> can runtime suspend/resume xhci device from dwc3 [2].
>> [1] https://www.spinics.net/lists/linux-usb/msg156077.html
>> [2] https://patchwork.kernel.org/patch/9471869/
>
>
> Sure. We can discuss this patch once you re-submit.
> One concern I have with the patch is marking ignore_children for dwc3 and as
> part of
> dwc3 suspend/resume invoking

Suppose we will suspend xhci device as dwc3's child, but now dwc3
device is not suspend yet, which will block to suspend xhci device.
Thus we should set ignore children flag to remove the parent
dependency.

> runtime pm on xhci. Ideally pm core should handle it seamlessly i.e.
> suspending dwc3
> once xhci gets suspended and pm_stay_awake/relax can be used to block
> pm_suspend
> until runtime suspend of glue driver happens.
>
>>
>> But [2] has not applied yet now, I will try to upstream it again. Then
>> we can suspend xhci device--> suspend dwc3 host---> glue layer can
>> power off, and it is similar when resuming in host mode.
>
>
> Do you see any issues with this patch?
> I am able to get runtime suspend/resume happening fine with XHCI on my
> platform.
> It involves runtime suspend/resume of USB HUB and dwc3 glue driver without
> any other
> change.

Great, I will try this patch again.

-- 
Baolin.wang
Best Regards
--
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: dwc3: Fix the USB 3.0 hub detection bug after warm boot

[Baolin Wang]

Hi,

On 13 July 2017 at 07:20, gustavo panizzo <g...@zumbi.com.ar> wrote:
> Hello Wang
>
> thanks for your response
>
>
> On Wed, Jul 12, 2017 at 02:08:04PM +0800, Baolin Wang wrote:
>>
>> Hi,
>>
>> On 12 July 2017 at 11:52, gustavo panizzo <g...@zumbi.com.ar> wrote:
>>>
>>> The dwc3 could not release resources when the module is built-in
>>> because this module does not have shutdown method. This causes the USB
>>> 3.0 hub is not able to detect after warm boot.
>>>
>>> Original patch by Brian Kim, updated and submitted upstream by gustavo
>>> panizzo.
>>>
>>> Also see https://bugs.debian.org/843448
>>>
>>> Signed-off-by: Brian Kim <brian@hardkernel.com>
>>> Signed-off-by: gustavo panizzo <g...@zumbi.com.ar>
>>> ---
>>>  drivers/usb/dwc3/core.c | 33 +
>>>  1 file changed, 33 insertions(+)
>>>
>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>> index 326b302fc440..f92dfe213d89 100644
>>> --- a/drivers/usb/dwc3/core.c
>>> +++ b/drivers/usb/dwc3/core.c
>>> @@ -1259,6 +1259,38 @@ static int dwc3_probe(struct platform_device
>>> *pdev)
>>> return ret;
>>>  }
>>>
>>> +static void dwc3_shutdown(struct platform_device *pdev)
>>> +{
>>> +   struct dwc3 *dwc = platform_get_drvdata(pdev);
>>> +   struct resource *res = platform_get_resource(pdev,
>>> IORESOURCE_MEM, 0);
>>> +
>>> +   pm_runtime_get_sync(>dev);
>>> +   /*
>>> +* restore res->start back to its original value so that, in case
>>> the
>>> +* probe is deferred, we don't end up getting error in request
>>> the
>>> +* memory region the next time probe is called.
>>> +*/
>>> +   res->start -= DWC3_GLOBALS_REGS_START;
>>> +
>>> +   dwc3_debugfs_exit(dwc);
>>> +   dwc3_core_exit_mode(dwc);
>>> +   dwc3_event_buffers_cleanup(dwc);
>
>
> What about dwc3_event_buffers_cleanup? should I remove it from
> dwc3_shutdown()?
> It is already in dwc3_core_exit()

I think so. We should avoid duplicate code.

>>> +   dwc3_free_event_buffers(dwc);
>>> +
>>> +   usb_phy_set_suspend(dwc->usb2_phy, 1);
>>> +   usb_phy_set_suspend(dwc->usb3_phy, 1);
>>> +
>>> +   phy_power_off(dwc->usb2_generic_phy);
>>> +   phy_power_off(dwc->usb3_generic_phy);
>>
>>
>> We've done these in dwc3_core_exit().
>>
>>> +
>>> +   dwc3_core_exit(dwc);
>>> +   dwc3_ulpi_exit(dwc);
>>> +
>>> +   pm_runtime_put_sync(>dev);
>>> +   pm_runtime_allow(>dev);
>>> +   pm_runtime_disable(>dev);
>>> +}
>>> +
>>>  static int dwc3_remove(struct platform_device *pdev)
>>>  {
>>> struct dwc3 *dwc = platform_get_drvdata(pdev);
>>> @@ -1488,6 +1520,7 @@ MODULE_DEVICE_TABLE(acpi, dwc3_acpi_match);
>>>  static struct platform_driver dwc3_driver = {
>>> .probe  = dwc3_probe,
>>> .remove = dwc3_remove,
>>> +   .shutdown   = dwc3_shutdown,
>>> .driver = {
>>> .name   = "dwc3",
>>> .of_match_table = of_match_ptr(of_dwc3_match),
>>> --
>>> 2.11.0
>>>
>>> --
>>> 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
>>
>>
>>
>>
>> --
>> Baolin.wang
>> Best Regards
>
>
> --
> IRC: gfa
> GPG: 0X44BB1BA79F6C6333
>



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

Re: [PATCH 1/2] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

[Baolin Wang]

Hi,

On 12 July 2017 at 15:25, Manu Gautam <mgau...@codeaurora.org> wrote:
>
>
> On 7/12/2017 12:19 PM, Baolin Wang wrote:
>>
>> Hi,
>>
>> On 3 July 2017 at 19:25, Manu Gautam <mgau...@codeaurora.org> wrote:
>>>
>>> Driver powers-off PHYs and reinitializes DWC3 core and gadget on
>>> resume. While this works fine for gadget mode but in host
>>> mode there is not re-initialization of host stack. Also, resetting
>>> bus as part of bus_suspend/resume is not correct which could affect
>>> (or disconnect) connected devices.
>>> Fix this by not reinitializing core on suspend/resume in host mode
>>> for HOST only and OTG/drd configurations.
>>
>> But for some mobile devices, they also need suspend/resume in host
>> mode which will power off dwc3 controller in glue layer. If we remove
>> dwc3_core_init() for host mode, I am afraid it can not work well in
>> host mode after resuming dwc3.
>
> Can you point me to a glue driver doing that?

Yes, now there are no glue driver doing that, but for many vendor
trees they will do that. (Our platform will power off dwc3 when
suspending dwc3, but have not upstreamed yet)

> If dwc3 is powered off on suspend then Xhci level initialization also needed
> after
> performing dwc3_core_init on resume which is currently not present. So this
> seems
> to me broken anyway.

Since we've add runtime PM for xhci-plat driver [1], which means we
can runtime suspend/resume xhci device from dwc3 [2].
[1] https://www.spinics.net/lists/linux-usb/msg156077.html
[2] https://patchwork.kernel.org/patch/9471869/

But [2] has not applied yet now, I will try to upstream it again. Then
we can suspend xhci device--> suspend dwc3 host---> glue layer can
power off, and it is similar when resuming in host mode.

> Also, powering off dwc3 on suspend by default from dwc3 core may not be
> correct
> and better left to glue drivers as some platforms might not want to
> reinitialize host
> after suspend/resume. This can be achieved by exposing dwc3_core_init and
> dwc3_core_init_mode to glue drivers.
>
>>> Signed-off-by: Manu Gautam <mgau...@codeaurora.org>
>>>
>>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>>> index c22c37d..fc556a4 100644
>>> --- a/drivers/usb/dwc3/core.c
>>> +++ b/drivers/usb/dwc3/core.c
>>> @@ -924,6 +924,7 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
>>>
>>>  switch (dwc->dr_mode) {
>>>  case USB_DR_MODE_PERIPHERAL:
>>> +   dwc->current_dr_role = DWC3_GCTL_PRTCAP_DEVICE;
>>>  dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_DEVICE);
>>>  ret = dwc3_gadget_init(dwc);
>>>  if (ret) {
>>> @@ -933,6 +934,7 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
>>>  }
>>>  break;
>>>  case USB_DR_MODE_HOST:
>>> +   dwc->current_dr_role = DWC3_GCTL_PRTCAP_HOST;
>>>  dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST);
>>>  ret = dwc3_host_init(dwc);
>>>  if (ret) {
>>> @@ -1280,21 +1282,19 @@ static int dwc3_suspend_common(struct dwc3 *dwc)
>>>   {
>>>  unsigned long   flags;
>>>
>>> -   switch (dwc->dr_mode) {
>>> -   case USB_DR_MODE_PERIPHERAL:
>>> -   case USB_DR_MODE_OTG:
>>> +   switch (dwc->current_dr_role) {
>>> +   case DWC3_GCTL_PRTCAP_DEVICE:
>>>  spin_lock_irqsave(>lock, flags);
>>>  dwc3_gadget_suspend(dwc);
>>>  spin_unlock_irqrestore(>lock, flags);
>>> +   dwc3_core_exit(dwc);
>>>  break;
>>> -   case USB_DR_MODE_HOST:
>>> +   case DWC3_GCTL_PRTCAP_HOST:
>>>  default:
>>>  /* do nothing */
>>>  break;
>>>  }
>>>
>>> -   dwc3_core_exit(dwc);
>>> -
>>>  return 0;
>>>   }
>>>
>>> @@ -1303,18 +1303,17 @@ static int dwc3_resume_common(struct dwc3 *dwc)
>>>  unsigned long   flags;
>>>  int ret;
>>>
>>> -   ret = dwc3_core_init(dwc);
>>> -   if (ret)
>>> -   return ret;
>>> +   switch (dwc->current_dr_role) {
>>> +   case DWC3_GCTL_PRTCAP_DEVICE:
>>> +   ret = dwc3_core_init(dwc);
>>> +   if (ret)
>

Re: [PATCH 1/2] usb: dwc3: Don't reinitialize core during host bus-suspend/resume

[Baolin Wang]

Hi,

On 3 July 2017 at 19:25, Manu Gautam  wrote:
> Driver powers-off PHYs and reinitializes DWC3 core and gadget on
> resume. While this works fine for gadget mode but in host
> mode there is not re-initialization of host stack. Also, resetting
> bus as part of bus_suspend/resume is not correct which could affect
> (or disconnect) connected devices.
> Fix this by not reinitializing core on suspend/resume in host mode
> for HOST only and OTG/drd configurations.

But for some mobile devices, they also need suspend/resume in host
mode which will power off dwc3 controller in glue layer. If we remove
dwc3_core_init() for host mode, I am afraid it can not work well in
host mode after resuming dwc3.

>
> Signed-off-by: Manu Gautam 
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index c22c37d..fc556a4 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -924,6 +924,7 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
>
> switch (dwc->dr_mode) {
> case USB_DR_MODE_PERIPHERAL:
> +   dwc->current_dr_role = DWC3_GCTL_PRTCAP_DEVICE;
> dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_DEVICE);
> ret = dwc3_gadget_init(dwc);
> if (ret) {
> @@ -933,6 +934,7 @@ static int dwc3_core_init_mode(struct dwc3 *dwc)
> }
> break;
> case USB_DR_MODE_HOST:
> +   dwc->current_dr_role = DWC3_GCTL_PRTCAP_HOST;
> dwc3_set_prtcap(dwc, DWC3_GCTL_PRTCAP_HOST);
> ret = dwc3_host_init(dwc);
> if (ret) {
> @@ -1280,21 +1282,19 @@ static int dwc3_suspend_common(struct dwc3 *dwc)
>  {
> unsigned long   flags;
>
> -   switch (dwc->dr_mode) {
> -   case USB_DR_MODE_PERIPHERAL:
> -   case USB_DR_MODE_OTG:
> +   switch (dwc->current_dr_role) {
> +   case DWC3_GCTL_PRTCAP_DEVICE:
> spin_lock_irqsave(>lock, flags);
> dwc3_gadget_suspend(dwc);
> spin_unlock_irqrestore(>lock, flags);
> +   dwc3_core_exit(dwc);
> break;
> -   case USB_DR_MODE_HOST:
> +   case DWC3_GCTL_PRTCAP_HOST:
> default:
> /* do nothing */
> break;
> }
>
> -   dwc3_core_exit(dwc);
> -
> return 0;
>  }
>
> @@ -1303,18 +1303,17 @@ static int dwc3_resume_common(struct dwc3 *dwc)
> unsigned long   flags;
> int ret;
>
> -   ret = dwc3_core_init(dwc);
> -   if (ret)
> -   return ret;
> +   switch (dwc->current_dr_role) {
> +   case DWC3_GCTL_PRTCAP_DEVICE:
> +   ret = dwc3_core_init(dwc);
> +   if (ret)
> +   return ret;
>
> -   switch (dwc->dr_mode) {
> -   case USB_DR_MODE_PERIPHERAL:
> -   case USB_DR_MODE_OTG:
> spin_lock_irqsave(>lock, flags);
> dwc3_gadget_resume(dwc);
> spin_unlock_irqrestore(>lock, flags);
> -   /* FALLTHROUGH */
> -   case USB_DR_MODE_HOST:
> +   break;
> +   case DWC3_GCTL_PRTCAP_HOST:
> default:
> /* do nothing */
> break;
> @@ -1325,7 +1324,7 @@ static int dwc3_resume_common(struct dwc3 *dwc)
>
>  static int dwc3_runtime_checks(struct dwc3 *dwc)
>  {
> -   switch (dwc->dr_mode) {
> +   switch (dwc->current_dr_role) {
> case USB_DR_MODE_PERIPHERAL:
> case USB_DR_MODE_OTG:
> if (dwc->connected)
> @@ -1368,12 +1367,11 @@ static int dwc3_runtime_resume(struct device *dev)
> if (ret)
> return ret;
>
> -   switch (dwc->dr_mode) {
> -   case USB_DR_MODE_PERIPHERAL:
> -   case USB_DR_MODE_OTG:
> +   switch (dwc->current_dr_role) {
> +   case DWC3_GCTL_PRTCAP_DEVICE:
> dwc3_gadget_process_pending_events(dwc);
> break;
> -   case USB_DR_MODE_HOST:
> +   case DWC3_GCTL_PRTCAP_HOST:
> default:
> /* do nothing */
> break;
> @@ -1389,13 +1387,12 @@ static int dwc3_runtime_idle(struct device *dev)
>  {
> struct dwc3 *dwc = dev_get_drvdata(dev);
>
> -   switch (dwc->dr_mode) {
> -   case USB_DR_MODE_PERIPHERAL:
> -   case USB_DR_MODE_OTG:
> +   switch (dwc->current_dr_role) {
> +   case DWC3_GCTL_PRTCAP_DEVICE:
> if (dwc3_runtime_checks(dwc))
> return -EBUSY;
> break;
> -   case USB_DR_MODE_HOST:
> +   case DWC3_GCTL_PRTCAP_HOST:
> default:
> /* do nothing */
> break;
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,\na 
> Linux Foundation Collaborative Project
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> 

Re: [PATCH] usb: dwc3: Fix the USB 3.0 hub detection bug after warm boot

[Baolin Wang]

Hi,

On 12 July 2017 at 11:52, gustavo panizzo  wrote:
> The dwc3 could not release resources when the module is built-in
> because this module does not have shutdown method. This causes the USB
> 3.0 hub is not able to detect after warm boot.
>
> Original patch by Brian Kim, updated and submitted upstream by gustavo
> panizzo.
>
> Also see https://bugs.debian.org/843448
>
> Signed-off-by: Brian Kim 
> Signed-off-by: gustavo panizzo 
> ---
>  drivers/usb/dwc3/core.c | 33 +
>  1 file changed, 33 insertions(+)
>
> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
> index 326b302fc440..f92dfe213d89 100644
> --- a/drivers/usb/dwc3/core.c
> +++ b/drivers/usb/dwc3/core.c
> @@ -1259,6 +1259,38 @@ static int dwc3_probe(struct platform_device *pdev)
> return ret;
>  }
>
> +static void dwc3_shutdown(struct platform_device *pdev)
> +{
> +   struct dwc3 *dwc = platform_get_drvdata(pdev);
> +   struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +
> +   pm_runtime_get_sync(>dev);
> +   /*
> +* restore res->start back to its original value so that, in case the
> +* probe is deferred, we don't end up getting error in request the
> +* memory region the next time probe is called.
> +*/
> +   res->start -= DWC3_GLOBALS_REGS_START;
> +
> +   dwc3_debugfs_exit(dwc);
> +   dwc3_core_exit_mode(dwc);
> +   dwc3_event_buffers_cleanup(dwc);
> +   dwc3_free_event_buffers(dwc);
> +
> +   usb_phy_set_suspend(dwc->usb2_phy, 1);
> +   usb_phy_set_suspend(dwc->usb3_phy, 1);
> +
> +   phy_power_off(dwc->usb2_generic_phy);
> +   phy_power_off(dwc->usb3_generic_phy);

We've done these in dwc3_core_exit().

> +
> +   dwc3_core_exit(dwc);
> +   dwc3_ulpi_exit(dwc);
> +
> +   pm_runtime_put_sync(>dev);
> +   pm_runtime_allow(>dev);
> +   pm_runtime_disable(>dev);
> +}
> +
>  static int dwc3_remove(struct platform_device *pdev)
>  {
> struct dwc3 *dwc = platform_get_drvdata(pdev);
> @@ -1488,6 +1520,7 @@ MODULE_DEVICE_TABLE(acpi, dwc3_acpi_match);
>  static struct platform_driver dwc3_driver = {
> .probe  = dwc3_probe,
> .remove = dwc3_remove,
> +   .shutdown   = dwc3_shutdown,
> .driver = {
> .name   = "dwc3",
> .of_match_table = of_match_ptr(of_dwc3_match),
> --
> 2.11.0
>
> --
> 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



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

Re: [PATCH v2 3/3] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

Hi,

On 3 July 2017 at 16:53, Charles Keepax <ckee...@opensource.cirrus.com> wrote:
> On Mon, Jul 03, 2017 at 02:07:15PM +0800, Baolin Wang wrote:
>> Integrate with the newly added USB charger interface to limit the current
>> we draw from the USB input based on the input device configuration
>> identified by the USB stack, allowing us to charge more quickly from high
>> current inputs without drawing more current than specified from others.
>>
>> Signed-off-by: Mark Brown <broo...@kernel.org>
>> Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
>> ---
> 
>>  /*
>>   *   Battery properties
>>   */
>> @@ -607,6 +647,22 @@ static int wm831x_power_probe(struct platform_device 
>> *pdev)
>>   }
>>   }
>>
>> + power->usb_phy = devm_usb_get_phy_by_phandle(>dev,
>> +  "usb-phy", 0);
>> + if (IS_ERR(power->usb_phy)) {
>> + ret = PTR_ERR(power->usb_phy);
>> + dev_err(>dev, "Failed to find USB phy: %d\n", ret);
>> + goto err_bat_irq;
>> + }
>> +
>
> We should probably update the binding documentation for this as
> well: mfd/wm831x.txt

Yes, I will update the binding documentation.

>
> Also I am not sure this needs to be implemented now, but what is
> the plan regarding pdata systems? Generally the driver supports
> both and it would be nice to know there is a way forward for that
> even if we don't implement it yet.

OK, I'll modify this in next version. Thanks.

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

Re: [PATCH v2 3/3] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

Hi,

On 3 July 2017 at 23:50, Sebastian Reichel
<sebastian.reic...@collabora.co.uk> wrote:
> Hi,
>
> On Mon, Jul 03, 2017 at 02:07:15PM +0800, Baolin Wang wrote:
>> Integrate with the newly added USB charger interface to limit the current
>> we draw from the USB input based on the input device configuration
>> identified by the USB stack, allowing us to charge more quickly from high
>> current inputs without drawing more current than specified from others.
>>
>> Signed-off-by: Mark Brown <broo...@kernel.org>
>> Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
>
> Missing DT binding documentation, otherwise fine with me.
> Would be nice to convert existing drivers:
>
> $ git grep -l extcon -- drivers/power/supply
> drivers/power/supply/axp288_charger.c
> drivers/power/supply/bq24190_charger.c
> drivers/power/supply/charger-manager.c
> drivers/power/supply/qcom_smbb.c

I'll create new patches with adding the DT binding documentation if
there are no objections for USB phy modification, moreover I will help
to convert these drivers you listed. Thanks.

>
> -- Sebastian
>
>> ---
>>  drivers/power/supply/wm831x_power.c |   61 
>> +++
>>  1 file changed, 61 insertions(+)
>>
>> diff --git a/drivers/power/supply/wm831x_power.c 
>> b/drivers/power/supply/wm831x_power.c
>> index 7082301..3e3480708 100644
>> --- a/drivers/power/supply/wm831x_power.c
>> +++ b/drivers/power/supply/wm831x_power.c
>> @@ -13,6 +13,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>
>>  #include 
>>  #include 
>> @@ -31,6 +32,8 @@ struct wm831x_power {
>>   char usb_name[20];
>>   char battery_name[20];
>>   bool have_battery;
>> + struct usb_phy *usb_phy;
>> + struct notifier_block usb_notify;
>>  };
>>
>>  static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
>> @@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
>>   POWER_SUPPLY_PROP_VOLTAGE_NOW,
>>  };
>>
>> +/* In milliamps */
>> +static const unsigned int wm831x_usb_limits[] = {
>> + 0,
>> + 2,
>> + 100,
>> + 500,
>> + 900,
>> + 1500,
>> + 1800,
>> + 550,
>> +};
>> +
>> +static int wm831x_usb_limit_change(struct notifier_block *nb,
>> +unsigned long limit, void *data)
>> +{
>> + struct wm831x_power *wm831x_power = container_of(nb,
>> +  struct wm831x_power,
>> +  usb_notify);
>> + unsigned int i, best;
>> +
>> + /* Find the highest supported limit */
>> + best = 0;
>> + for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
>> + if (limit >= wm831x_usb_limits[i] &&
>> + wm831x_usb_limits[best] < wm831x_usb_limits[i])
>> + best = i;
>> + }
>> +
>> + dev_dbg(wm831x_power->wm831x->dev,
>> + "Limiting USB current to %umA", wm831x_usb_limits[best]);
>> +
>> + wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
>> + WM831X_USB_ILIM_MASK, best);
>> +
>> + return 0;
>> +}
>> +
>>  /*
>>   *   Battery properties
>>   */
>> @@ -607,6 +647,22 @@ static int wm831x_power_probe(struct platform_device 
>> *pdev)
>>   }
>>   }
>>
>> + power->usb_phy = devm_usb_get_phy_by_phandle(>dev,
>> +  "usb-phy", 0);
>> + if (IS_ERR(power->usb_phy)) {
>> + ret = PTR_ERR(power->usb_phy);
>> + dev_err(>dev, "Failed to find USB phy: %d\n", ret);
>> + goto err_bat_irq;
>> + }
>> +
>> + power->usb_notify.notifier_call = wm831x_usb_limit_change;
>> + ret = usb_register_notifier(power->usb_phy,
>> + >usb_notify);
>> + if (ret) {
>> + dev_err(>dev, "Failed to register notifier: %d\n", ret);
>> + goto err_bat_irq;
>> + }
>> +
>>   return ret;
>>
>>  err_bat_irq:
>> @@ -637,6 +693,11 @@ static int wm831x_power_remove(struct platform_device 
>> *pdev)
>>   struct wm831x *wm831x = wm831x_power->wm831x;
>>   int irq, i;
>>
>> + if (wm831x_power->usb_phy) {
>> + usb_unregister_notifier(wm831x_power->usb_phy,
>> + _power->usb_notify);
>> + }
>> +
>>   for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
>>   irq = wm831x_irq(wm831x,
>>platform_get_irq_byname(pdev,
>> --
>> 1.7.9.5
>>



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

[PATCH v2 2/3] usb: phy: Add USB charger support

[Baolin Wang]

This patch introduces the usb charger support based on usb phy that
makes an enhancement to a power driver. The basic conception of the
usb charger is that, when one usb charger is added or removed by
reporting from the extcon device state change, the usb charger will
report to power user to set the current limitation.

Power user can register a notifiee on the usb phy by issuing
usb_register_notifier() to get notified by charger status changes
or charger current changes.

we can notify what current to be drawn to power user according to
different charger type, and now we have 2 methods to get charger type.
One is get charger type from extcon subsystem, which also means the
charger state changes. Another is we can get the charger type from
USB controller detecting or PMIC detecting, and the charger state
changes should be told by issuing usb_phy_set_charger_state().

Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
 drivers/usb/phy/phy.c   |  265 +++
 include/linux/usb/phy.h |   49 +
 2 files changed, 314 insertions(+)

diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index 032f5af..db72802 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -18,6 +18,18 @@
 
 #include 
 
+/* Default current range by charger type. */
+#define DEFAULT_SDP_CUR_MIN2
+#define DEFAULT_SDP_CUR_MAX500
+#define DEFAULT_SDP_CUR_MIN_SS 150
+#define DEFAULT_SDP_CUR_MAX_SS 900
+#define DEFAULT_DCP_CUR_MIN500
+#define DEFAULT_DCP_CUR_MAX5000
+#define DEFAULT_CDP_CUR_MIN1500
+#define DEFAULT_CDP_CUR_MAX5000
+#define DEFAULT_ACA_CUR_MIN1500
+#define DEFAULT_ACA_CUR_MAX5000
+
 static LIST_HEAD(phy_list);
 static LIST_HEAD(phy_bind_list);
 static DEFINE_SPINLOCK(phy_lock);
@@ -77,6 +89,216 @@ static struct usb_phy *__of_usb_find_phy(struct device_node 
*node)
return ERR_PTR(-EPROBE_DEFER);
 }
 
+static void usb_phy_set_default_current(struct usb_phy *usb_phy)
+{
+   usb_phy->chg_cur.sdp_min = DEFAULT_SDP_CUR_MIN;
+   usb_phy->chg_cur.sdp_max = DEFAULT_SDP_CUR_MAX;
+   usb_phy->chg_cur.dcp_min = DEFAULT_DCP_CUR_MIN;
+   usb_phy->chg_cur.dcp_max = DEFAULT_DCP_CUR_MAX;
+   usb_phy->chg_cur.cdp_min = DEFAULT_CDP_CUR_MIN;
+   usb_phy->chg_cur.cdp_max = DEFAULT_CDP_CUR_MAX;
+   usb_phy->chg_cur.aca_min = DEFAULT_ACA_CUR_MIN;
+   usb_phy->chg_cur.aca_max = DEFAULT_ACA_CUR_MAX;
+}
+
+/**
+ * usb_phy_notify_charger_work - notify the USB charger state
+ * @work - the charger work to notify the USB charger state
+ *
+ * This work can be issued when USB charger state has been changed or
+ * USB charger current has been changed, then we can notify the current
+ * what can be drawn to power user and the charger state to userspace.
+ *
+ * If we get the charger type from extcon subsystem, we can notify the
+ * charger state to power user automatically by usb_phy_get_charger_type()
+ * issuing from extcon subsystem.
+ *
+ * If we get the charger type from ->charger_detect() instead of extcon
+ * subsystem, the usb phy driver should issue usb_phy_set_charger_state()
+ * to set charger state when the charger state has been changed.
+ */
+static void usb_phy_notify_charger_work(struct work_struct *work)
+{
+   struct usb_phy *usb_phy = container_of(work, struct usb_phy, chg_work);
+   char uchger_state[50] = { 0 };
+   char *envp[] = { uchger_state, NULL };
+   unsigned int min, max;
+
+   switch (usb_phy->chg_state) {
+   case USB_CHARGER_PRESENT:
+   usb_phy_get_charger_current(usb_phy, , );
+
+   atomic_notifier_call_chain(_phy->notifier, max, usb_phy);
+   snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+"USB_CHARGER_STATE=%s", "USB_CHARGER_PRESENT");
+   break;
+   case USB_CHARGER_ABSENT:
+   usb_phy_set_default_current(usb_phy);
+
+   atomic_notifier_call_chain(_phy->notifier, 0, usb_phy);
+   snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+"USB_CHARGER_STATE=%s", "USB_CHARGER_ABSENT");
+   break;
+   default:
+   dev_warn(usb_phy->dev, "Unknown USB charger state: %d\n",
+usb_phy->chg_state);
+   return;
+   }
+
+   kobject_uevent_env(_phy->dev->kobj, KOBJ_CHANGE, envp);
+}
+
+/**
+ * usb_phy_get_charger_type - get charger type from extcon subsystem
+ * @nb -the notifier block to determine charger type
+ * @state - the cable state
+ * @data - private data
+ *
+ * Determin the charger type from extcon subsystem which also means the
+ * charger state has been chaned, then we should notify this event.
+ */
+static int usb_phy_get_charger_type(struct notifier_block *nb,
+   unsigned long state, void *data)
+{
+   struct us

[PATCH v2 3/3] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.

Signed-off-by: Mark Brown <broo...@kernel.org>
Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
 drivers/power/supply/wm831x_power.c |   61 +++
 1 file changed, 61 insertions(+)

diff --git a/drivers/power/supply/wm831x_power.c 
b/drivers/power/supply/wm831x_power.c
index 7082301..3e3480708 100644
--- a/drivers/power/supply/wm831x_power.c
+++ b/drivers/power/supply/wm831x_power.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -31,6 +32,8 @@ struct wm831x_power {
char usb_name[20];
char battery_name[20];
bool have_battery;
+   struct usb_phy *usb_phy;
+   struct notifier_block usb_notify;
 };
 
 static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
@@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
POWER_SUPPLY_PROP_VOLTAGE_NOW,
 };
 
+/* In milliamps */
+static const unsigned int wm831x_usb_limits[] = {
+   0,
+   2,
+   100,
+   500,
+   900,
+   1500,
+   1800,
+   550,
+};
+
+static int wm831x_usb_limit_change(struct notifier_block *nb,
+  unsigned long limit, void *data)
+{
+   struct wm831x_power *wm831x_power = container_of(nb,
+struct wm831x_power,
+usb_notify);
+   unsigned int i, best;
+
+   /* Find the highest supported limit */
+   best = 0;
+   for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
+   if (limit >= wm831x_usb_limits[i] &&
+   wm831x_usb_limits[best] < wm831x_usb_limits[i])
+   best = i;
+   }
+
+   dev_dbg(wm831x_power->wm831x->dev,
+   "Limiting USB current to %umA", wm831x_usb_limits[best]);
+
+   wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
+   WM831X_USB_ILIM_MASK, best);
+
+   return 0;
+}
+
 /*
  * Battery properties
  */
@@ -607,6 +647,22 @@ static int wm831x_power_probe(struct platform_device *pdev)
}
}
 
+   power->usb_phy = devm_usb_get_phy_by_phandle(>dev,
+"usb-phy", 0);
+   if (IS_ERR(power->usb_phy)) {
+   ret = PTR_ERR(power->usb_phy);
+   dev_err(>dev, "Failed to find USB phy: %d\n", ret);
+   goto err_bat_irq;
+   }
+
+   power->usb_notify.notifier_call = wm831x_usb_limit_change;
+   ret = usb_register_notifier(power->usb_phy,
+   >usb_notify);
+   if (ret) {
+   dev_err(>dev, "Failed to register notifier: %d\n", ret);
+   goto err_bat_irq;
+   }
+
return ret;
 
 err_bat_irq:
@@ -637,6 +693,11 @@ static int wm831x_power_remove(struct platform_device 
*pdev)
struct wm831x *wm831x = wm831x_power->wm831x;
int irq, i;
 
+   if (wm831x_power->usb_phy) {
+   usb_unregister_notifier(wm831x_power->usb_phy,
+   _power->usb_notify);
+   }
+
for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
irq = wm831x_irq(wm831x, 
 platform_get_irq_byname(pdev,
-- 
1.7.9.5

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

[PATCH v2 1/3] include: uapi: usb: Introduce USB charger type and state definition

[Baolin Wang]

Introducing USB charger type and state definition can help
to support USB charging which will be added in USB phy core.

Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
 include/uapi/linux/usb/charger.h |   31 +++
 1 file changed, 31 insertions(+)
 create mode 100644 include/uapi/linux/usb/charger.h

diff --git a/include/uapi/linux/usb/charger.h b/include/uapi/linux/usb/charger.h
new file mode 100644
index 000..5f72af3
--- /dev/null
+++ b/include/uapi/linux/usb/charger.h
@@ -0,0 +1,31 @@
+/*
+ * This file defines the USB charger type and state that are needed for
+ * USB device APIs.
+ */
+
+#ifndef _UAPI__LINUX_USB_CHARGER_H
+#define _UAPI__LINUX_USB_CHARGER_H
+
+/*
+ * USB charger type:
+ * SDP (Standard Downstream Port)
+ * DCP (Dedicated Charging Port)
+ * CDP (Charging Downstream Port)
+ * ACA (Accessory Charger Adapters)
+ */
+enum usb_charger_type {
+   UNKNOWN_TYPE,
+   SDP_TYPE,
+   DCP_TYPE,
+   CDP_TYPE,
+   ACA_TYPE,
+};
+
+/* USB charger state */
+enum usb_charger_state {
+   USB_CHARGER_DEFAULT,
+   USB_CHARGER_PRESENT,
+   USB_CHARGER_ABSENT,
+};
+
+#endif /* _UAPI__LINUX_USB_CHARGER_H */
-- 
1.7.9.5

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

[PATCH v2 0/3] Introduce USB charger support in USB phy

[Baolin Wang]

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 USB charger support in USB phy core
for doing this in kernel.

Now introduce one user with wm831x_power to support and test the usb charger.

Changes since v1:
 - Fix building errors.

Baolin Wang (3):
  include: uapi: usb: Introduce USB charger type and state definition
  usb: phy: Add USB charger support
  power: wm831x_power: Support USB charger current limit management

 drivers/power/supply/wm831x_power.c |   61 
 drivers/usb/phy/phy.c   |  265 +++
 include/linux/usb/phy.h |   49 +++
 include/uapi/linux/usb/charger.h|   31 
 4 files changed, 406 insertions(+)
 create mode 100644 include/uapi/linux/usb/charger.h

-- 
1.7.9.5

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

Re: Crash in gs_write_room() in kernel 4.4, and your gs_start_tx() patch

[Baolin Wang]

On 29 June 2017 at 07:01, Stephen Warren  wrote:
>
>
> Baolin,
>
> I have a question about the following commit:
>
> 511a36d2f357 "usb: gadget: Add the gserial port checking in gs_start_tx()"
>
>> When usb gadget is set gadget serial function, it will be crash in below
>> situation.
>>
>> It will clean the 'port->port_usb' pointer in gserial_disconnect()
>> function
>> when usb link is inactive, but it will release lock for disabling the
>> endpoints
>> in this function. Druing the lock release period, it maybe complete one
>> request
>> to issue gs_write_complete()--->gs_start_tx() function, but the
>> 'port->port_usb'
>> pointer had been set NULL, thus it will be crash in gs_start_tx()
>> function.
>>
>> This patch adds the 'port->port_usb' pointer checking in gs_start_tx()
>> function
>> to avoid this situation.
>
>
> (also archived at)
> https://www.spinics.net/lists/linux-usb/msg143313.html
> https://patchwork.kernel.org/patch/9207037/
>
> In kernel 4.4, I'm seeing a rare NULL pointer dereference in
> gs_write_room(). I believe this happens pretty early during system boot,
> likely soon after the gadget configuration has been created, or soon after
> the host PC enumerates the device running the gadget serial driver. Full
> stack trace below, or soon after resume from system suspend. I wonder if you
> think this might be the same issue you fixed? Also, your fix was only
> applied to function gs_start_tx(). Do you think the same issue might also
> apply to other functions in the same driver, and hence we might need to add
> the same check to other functions like gs_start_tx() or similar?
>
> I will try applying your patch to see if it fixes my issue. However, the
> issue is very hard to reproduce, so it will be difficult to tell if the
> solution works:-(

I have not seen this problem on my platform, so I am not sure if it is
the same issue. In gs_write_room(), the 'port->port_usb' has been
checked, maybe the 'port' pointer was set to NULL? I think you can
check this or check if this issue was fixed on latest kernel?

>
>> [  132.757406] Unable to handle kernel NULL pointer dereference at virtual
>> address 0170
>
> ...
>>
>> [  132.757428] CPU: 5 PID: 53 Comm: kworker/u12:1 Not tainted 4.4.38-tegra
>> #1
>
> ...
>>
>> [  132.757439] Workqueue: events_unbound flush_to_ldisc
>
> ...
>>
>> [  132.757447] PC is at _raw_spin_lock_irqsave+0x20/0x54
>> [  132.757452] LR is at gs_write_room+0x1c/0x7c
>
> ...
>>
>> [  132.757481] Process kworker/u12:1 (pid: 53, stack limit =
>> 0xffc1eb6a8020)
>> [  132.757482] Call trace:
>> [  132.757484] [] _raw_spin_lock_irqsave+0x20/0x54
>> [  132.757487] [] tty_write_room+0x1c/0x2c
>> [  132.757489] [] __process_echoes+0x24/0x25c
>> [  132.757491] [] n_tty_receive_buf_common+0x1ec/0xa24
>> [  132.757493] [] n_tty_receive_buf2+0x10/0x18
>> [  132.757495] [] flush_to_ldisc+0xe4/0x154
>> [  132.757499] [] process_one_work+0x154/0x434
>> [  132.757501] [] worker_thread+0x134/0x40c
>> [  132.757503] [] kthread+0xe0/0xf4
>> [  132.757506] [] ret_from_fork+0x10/0x40
>
>
> Thanks for any insight at all!



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

Re: [PATCH 2/3] usb: phy: Add USB charger support

[Baolin Wang]

Hi,

On 28 June 2017 at 10:44, kbuild test robot <l...@intel.com> wrote:
> Hi Baolin,
>
> [auto build test ERROR on balbi-usb/next]
> [also build test ERROR on next-20170627]
> [cannot apply to v4.12-rc7]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Baolin-Wang/include-uapi-usb-Introduce-USB-charger-type-and-state-definition/20170628-093530
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
> config: i386-randconfig-x076-06262345 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
>drivers/power/supply/rt9455_charger.o: In function 
> `usb_phy_set_charger_current':
>>> rt9455_charger.c:(.text+0x1660): multiple definition of 
>>> `usb_phy_set_charger_current'
>drivers/power/supply/pda_power.o:pda_power.c:(.text+0xad0): first defined 
> here
>drivers/power/supply/rt9455_charger.o: In function 
> `usb_phy_get_charger_current':
>>> rt9455_charger.c:(.text+0x1670): multiple definition of 
>>> `usb_phy_get_charger_current'
>drivers/power/supply/pda_power.o:pda_power.c:(.text+0xae0): first defined 
> here
>drivers/power/supply/rt9455_charger.o: In function 
> `usb_phy_set_charger_state':
>>> rt9455_charger.c:(.text+0x1680): multiple definition of 
>>> `usb_phy_set_charger_state'
>drivers/power/supply/pda_power.o:pda_power.c:(.text+0xaf0): first defined 
> here

Sorry for missing "static inline" for these exported functions, will
fix in next version.

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

[PATCH 3/3] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.

Signed-off-by: Mark Brown <broo...@kernel.org>
Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
 drivers/power/supply/wm831x_power.c |   61 +++
 1 file changed, 61 insertions(+)

diff --git a/drivers/power/supply/wm831x_power.c 
b/drivers/power/supply/wm831x_power.c
index 7082301..3e3480708 100644
--- a/drivers/power/supply/wm831x_power.c
+++ b/drivers/power/supply/wm831x_power.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -31,6 +32,8 @@ struct wm831x_power {
char usb_name[20];
char battery_name[20];
bool have_battery;
+   struct usb_phy *usb_phy;
+   struct notifier_block usb_notify;
 };
 
 static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
@@ -125,6 +128,43 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
POWER_SUPPLY_PROP_VOLTAGE_NOW,
 };
 
+/* In milliamps */
+static const unsigned int wm831x_usb_limits[] = {
+   0,
+   2,
+   100,
+   500,
+   900,
+   1500,
+   1800,
+   550,
+};
+
+static int wm831x_usb_limit_change(struct notifier_block *nb,
+  unsigned long limit, void *data)
+{
+   struct wm831x_power *wm831x_power = container_of(nb,
+struct wm831x_power,
+usb_notify);
+   unsigned int i, best;
+
+   /* Find the highest supported limit */
+   best = 0;
+   for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
+   if (limit >= wm831x_usb_limits[i] &&
+   wm831x_usb_limits[best] < wm831x_usb_limits[i])
+   best = i;
+   }
+
+   dev_dbg(wm831x_power->wm831x->dev,
+   "Limiting USB current to %umA", wm831x_usb_limits[best]);
+
+   wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
+   WM831X_USB_ILIM_MASK, best);
+
+   return 0;
+}
+
 /*
  * Battery properties
  */
@@ -607,6 +647,22 @@ static int wm831x_power_probe(struct platform_device *pdev)
}
}
 
+   power->usb_phy = devm_usb_get_phy_by_phandle(>dev,
+"usb-phy", 0);
+   if (IS_ERR(power->usb_phy)) {
+   ret = PTR_ERR(power->usb_phy);
+   dev_err(>dev, "Failed to find USB phy: %d\n", ret);
+   goto err_bat_irq;
+   }
+
+   power->usb_notify.notifier_call = wm831x_usb_limit_change;
+   ret = usb_register_notifier(power->usb_phy,
+   >usb_notify);
+   if (ret) {
+   dev_err(>dev, "Failed to register notifier: %d\n", ret);
+   goto err_bat_irq;
+   }
+
return ret;
 
 err_bat_irq:
@@ -637,6 +693,11 @@ static int wm831x_power_remove(struct platform_device 
*pdev)
struct wm831x *wm831x = wm831x_power->wm831x;
int irq, i;
 
+   if (wm831x_power->usb_phy) {
+   usb_unregister_notifier(wm831x_power->usb_phy,
+   _power->usb_notify);
+   }
+
for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
irq = wm831x_irq(wm831x, 
 platform_get_irq_byname(pdev,
-- 
1.7.9.5

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

[PATCH 2/3] usb: phy: Add USB charger support

[Baolin Wang]

This patch introduces the usb charger support based on usb phy that
makes an enhancement to a power driver. The basic conception of the
usb charger is that, when one usb charger is added or removed by
reporting from the extcon device state change, the usb charger will
report to power user to set the current limitation.

Power user can register a notifiee on the usb phy by issuing
usb_register_notifier() to get notified by charger status changes
or charger current changes.

we can notify what current to be drawn to power user according to
different charger type, and now we have 2 methods to get charger type.
One is get charger type from extcon subsystem, which also means the
charger state changes. Another is we can get the charger type from
USB controller detecting or PMIC detecting, and the charger state
changes should be told by issuing usb_phy_set_charger_state().

Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
 drivers/usb/phy/phy.c   |  265 +++
 include/linux/usb/phy.h |   48 +
 2 files changed, 313 insertions(+)

diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index 032f5af..db72802 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -18,6 +18,18 @@
 
 #include 
 
+/* Default current range by charger type. */
+#define DEFAULT_SDP_CUR_MIN2
+#define DEFAULT_SDP_CUR_MAX500
+#define DEFAULT_SDP_CUR_MIN_SS 150
+#define DEFAULT_SDP_CUR_MAX_SS 900
+#define DEFAULT_DCP_CUR_MIN500
+#define DEFAULT_DCP_CUR_MAX5000
+#define DEFAULT_CDP_CUR_MIN1500
+#define DEFAULT_CDP_CUR_MAX5000
+#define DEFAULT_ACA_CUR_MIN1500
+#define DEFAULT_ACA_CUR_MAX5000
+
 static LIST_HEAD(phy_list);
 static LIST_HEAD(phy_bind_list);
 static DEFINE_SPINLOCK(phy_lock);
@@ -77,6 +89,216 @@ static struct usb_phy *__of_usb_find_phy(struct device_node 
*node)
return ERR_PTR(-EPROBE_DEFER);
 }
 
+static void usb_phy_set_default_current(struct usb_phy *usb_phy)
+{
+   usb_phy->chg_cur.sdp_min = DEFAULT_SDP_CUR_MIN;
+   usb_phy->chg_cur.sdp_max = DEFAULT_SDP_CUR_MAX;
+   usb_phy->chg_cur.dcp_min = DEFAULT_DCP_CUR_MIN;
+   usb_phy->chg_cur.dcp_max = DEFAULT_DCP_CUR_MAX;
+   usb_phy->chg_cur.cdp_min = DEFAULT_CDP_CUR_MIN;
+   usb_phy->chg_cur.cdp_max = DEFAULT_CDP_CUR_MAX;
+   usb_phy->chg_cur.aca_min = DEFAULT_ACA_CUR_MIN;
+   usb_phy->chg_cur.aca_max = DEFAULT_ACA_CUR_MAX;
+}
+
+/**
+ * usb_phy_notify_charger_work - notify the USB charger state
+ * @work - the charger work to notify the USB charger state
+ *
+ * This work can be issued when USB charger state has been changed or
+ * USB charger current has been changed, then we can notify the current
+ * what can be drawn to power user and the charger state to userspace.
+ *
+ * If we get the charger type from extcon subsystem, we can notify the
+ * charger state to power user automatically by usb_phy_get_charger_type()
+ * issuing from extcon subsystem.
+ *
+ * If we get the charger type from ->charger_detect() instead of extcon
+ * subsystem, the usb phy driver should issue usb_phy_set_charger_state()
+ * to set charger state when the charger state has been changed.
+ */
+static void usb_phy_notify_charger_work(struct work_struct *work)
+{
+   struct usb_phy *usb_phy = container_of(work, struct usb_phy, chg_work);
+   char uchger_state[50] = { 0 };
+   char *envp[] = { uchger_state, NULL };
+   unsigned int min, max;
+
+   switch (usb_phy->chg_state) {
+   case USB_CHARGER_PRESENT:
+   usb_phy_get_charger_current(usb_phy, , );
+
+   atomic_notifier_call_chain(_phy->notifier, max, usb_phy);
+   snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+"USB_CHARGER_STATE=%s", "USB_CHARGER_PRESENT");
+   break;
+   case USB_CHARGER_ABSENT:
+   usb_phy_set_default_current(usb_phy);
+
+   atomic_notifier_call_chain(_phy->notifier, 0, usb_phy);
+   snprintf(uchger_state, ARRAY_SIZE(uchger_state),
+"USB_CHARGER_STATE=%s", "USB_CHARGER_ABSENT");
+   break;
+   default:
+   dev_warn(usb_phy->dev, "Unknown USB charger state: %d\n",
+usb_phy->chg_state);
+   return;
+   }
+
+   kobject_uevent_env(_phy->dev->kobj, KOBJ_CHANGE, envp);
+}
+
+/**
+ * usb_phy_get_charger_type - get charger type from extcon subsystem
+ * @nb -the notifier block to determine charger type
+ * @state - the cable state
+ * @data - private data
+ *
+ * Determin the charger type from extcon subsystem which also means the
+ * charger state has been chaned, then we should notify this event.
+ */
+static int usb_phy_get_charger_type(struct notifier_block *nb,
+   unsigned long state, void *data)
+{
+   struct us

[PATCH 1/3] include: uapi: usb: Introduce USB charger type and state definition

[Baolin Wang]

Introducing USB charger type and state definition can help
to support USB charging which will be added in USB phy core.

Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
 include/uapi/linux/usb/charger.h |   31 +++
 1 file changed, 31 insertions(+)
 create mode 100644 include/uapi/linux/usb/charger.h

diff --git a/include/uapi/linux/usb/charger.h b/include/uapi/linux/usb/charger.h
new file mode 100644
index 000..5f72af3
--- /dev/null
+++ b/include/uapi/linux/usb/charger.h
@@ -0,0 +1,31 @@
+/*
+ * This file defines the USB charger type and state that are needed for
+ * USB device APIs.
+ */
+
+#ifndef _UAPI__LINUX_USB_CHARGER_H
+#define _UAPI__LINUX_USB_CHARGER_H
+
+/*
+ * USB charger type:
+ * SDP (Standard Downstream Port)
+ * DCP (Dedicated Charging Port)
+ * CDP (Charging Downstream Port)
+ * ACA (Accessory Charger Adapters)
+ */
+enum usb_charger_type {
+   UNKNOWN_TYPE,
+   SDP_TYPE,
+   DCP_TYPE,
+   CDP_TYPE,
+   ACA_TYPE,
+};
+
+/* USB charger state */
+enum usb_charger_state {
+   USB_CHARGER_DEFAULT,
+   USB_CHARGER_PRESENT,
+   USB_CHARGER_ABSENT,
+};
+
+#endif /* _UAPI__LINUX_USB_CHARGER_H */
-- 
1.7.9.5

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

[PATCH v3 1/3] usb: phy: Introduce one extcon device into usb phy

[Baolin Wang]

Usually usb phy need register one extcon device to get the connection
notifications. It will remove some duplicate code if the extcon device
is registered using common code instead of each phy driver having its
own related extcon APIs. So we add one pointer of extcon device into
usb phy structure, and some other helper functions to register extcon.

Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
 drivers/usb/phy/Kconfig |6 ++---
 drivers/usb/phy/phy.c   |   57 +++
 include/linux/usb/phy.h |7 ++
 3 files changed, 67 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 61cef75..c9c61a8 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -4,6 +4,7 @@
 menu "USB Physical Layer drivers"
 
 config USB_PHY
+   select EXTCON
def_bool n
 
 #
@@ -116,7 +117,7 @@ config OMAP_OTG
 
 config TAHVO_USB
tristate "Tahvo USB transceiver driver"
-   depends on MFD_RETU && EXTCON
+   depends on MFD_RETU
depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, this can't be 
'y'
select USB_PHY
help
@@ -148,7 +149,6 @@ config USB_MSM_OTG
depends on (USB || USB_GADGET) && (ARCH_QCOM || COMPILE_TEST)
depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, this can't be 
'y'
depends on RESET_CONTROLLER
-   depends on EXTCON
select USB_PHY
help
  Enable this to support the USB OTG transceiver on Qualcomm chips. It
@@ -162,7 +162,7 @@ config USB_MSM_OTG
 config USB_QCOM_8X16_PHY
tristate "Qualcomm APQ8016/MSM8916 on-chip USB PHY controller support"
depends on ARCH_QCOM || COMPILE_TEST
-   depends on RESET_CONTROLLER && EXTCON
+   depends on RESET_CONTROLLER
select USB_PHY
select USB_ULPI_VIEWPORT
help
diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index 98f75d2..032f5af 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -100,6 +100,54 @@ static int devm_usb_phy_match(struct device *dev, void 
*res, void *match_data)
return *phy == match_data;
 }
 
+static int usb_add_extcon(struct usb_phy *x)
+{
+   int ret;
+
+   if (of_property_read_bool(x->dev->of_node, "extcon")) {
+   x->edev = extcon_get_edev_by_phandle(x->dev, 0);
+   if (IS_ERR(x->edev))
+   return PTR_ERR(x->edev);
+
+   x->id_edev = extcon_get_edev_by_phandle(x->dev, 1);
+   if (IS_ERR(x->id_edev)) {
+   x->id_edev = NULL;
+   dev_info(x->dev, "No separate ID extcon device\n");
+   }
+
+   if (x->vbus_nb.notifier_call) {
+   ret = devm_extcon_register_notifier(x->dev, x->edev,
+   EXTCON_USB,
+   >vbus_nb);
+   if (ret < 0) {
+   dev_err(x->dev,
+   "register VBUS notifier failed\n");
+   return ret;
+   }
+   }
+
+   if (x->id_nb.notifier_call) {
+   struct extcon_dev *id_ext;
+
+   if (x->id_edev)
+   id_ext = x->id_edev;
+   else
+   id_ext = x->edev;
+
+   ret = devm_extcon_register_notifier(x->dev, id_ext,
+   EXTCON_USB_HOST,
+   >id_nb);
+   if (ret < 0) {
+   dev_err(x->dev,
+   "register ID notifier failed\n");
+   return ret;
+   }
+   }
+   }
+
+   return 0;
+}
+
 /**
  * devm_usb_get_phy - find the USB PHY
  * @dev - device that requests this phy
@@ -388,6 +436,10 @@ int usb_add_phy(struct usb_phy *x, enum usb_phy_type type)
return -EINVAL;
}
 
+   ret = usb_add_extcon(x);
+   if (ret)
+   return ret;
+
ATOMIC_INIT_NOTIFIER_HEAD(>notifier);
 
spin_lock_irqsave(_lock, flags);
@@ -422,12 +474,17 @@ int usb_add_phy_dev(struct usb_phy *x)
 {
struct usb_phy_bind *phy_bind;
unsigned long flags;
+   int ret;
 
if (!x->dev) {
dev_err(x->dev, "no device provided for PHY\n");
return -EINVAL;
}
 
+   ret = usb_add_extcon(x);
+   if (ret)
+   return ret;
+
ATOMIC_INIT_NOTIFIER_HEAD(>notifier);
 

[PATCH v3 3/3] usb: phy: phy-msm-usb: Remove redundant extcon register/unregister

[Baolin Wang]

Since usb phy core has added common code to register or unregister
extcon device, then phy-msm-usb driver does not need its own
code to register/unregister extcon device, then remove them.

Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
 drivers/usb/phy/phy-msm-usb.c |   85 +
 1 file changed, 18 insertions(+), 67 deletions(-)

diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
index 93d9aaa..8fb86a5 100644
--- a/drivers/usb/phy/phy-msm-usb.c
+++ b/drivers/usb/phy/phy-msm-usb.c
@@ -146,17 +146,6 @@ struct msm_otg_platform_data {
 };
 
 /**
- * struct msm_usb_cable - structure for exteternal connector cable
- *   state tracking
- * @nb: hold event notification callback
- * @conn: used for notification registration
- */
-struct msm_usb_cable {
-   struct notifier_block   nb;
-   struct extcon_dev   *extcon;
-};
-
-/**
  * struct msm_otg: OTG driver data. Shared by HCD and DCD.
  * @otg: USB OTG Transceiver structure.
  * @pdata: otg device platform data.
@@ -215,9 +204,6 @@ struct msm_otg {
 
bool manual_pullup;
 
-   struct msm_usb_cable vbus;
-   struct msm_usb_cable id;
-
struct gpio_desc *switch_gpio;
struct notifier_block reboot;
 };
@@ -1612,8 +1598,8 @@ static void msm_otg_debugfs_cleanup(void)
 static int msm_otg_vbus_notifier(struct notifier_block *nb, unsigned long 
event,
void *ptr)
 {
-   struct msm_usb_cable *vbus = container_of(nb, struct msm_usb_cable, nb);
-   struct msm_otg *motg = container_of(vbus, struct msm_otg, vbus);
+   struct usb_phy *usb_phy = container_of(nb, struct usb_phy, vbus_nb);
+   struct msm_otg *motg = container_of(usb_phy, struct msm_otg, phy);
 
if (event)
set_bit(B_SESS_VLD, >inputs);
@@ -1636,8 +1622,8 @@ static int msm_otg_vbus_notifier(struct notifier_block 
*nb, unsigned long event,
 static int msm_otg_id_notifier(struct notifier_block *nb, unsigned long event,
void *ptr)
 {
-   struct msm_usb_cable *id = container_of(nb, struct msm_usb_cable, nb);
-   struct msm_otg *motg = container_of(id, struct msm_otg, id);
+   struct usb_phy *usb_phy = container_of(nb, struct usb_phy, id_nb);
+   struct msm_otg *motg = container_of(usb_phy, struct msm_otg, phy);
 
if (event)
clear_bit(ID, >inputs);
@@ -1652,7 +1638,6 @@ static int msm_otg_id_notifier(struct notifier_block *nb, 
unsigned long event,
 static int msm_otg_read_dt(struct platform_device *pdev, struct msm_otg *motg)
 {
struct msm_otg_platform_data *pdata;
-   struct extcon_dev *ext_id, *ext_vbus;
struct device_node *node = pdev->dev.of_node;
struct property *prop;
int len, ret, words;
@@ -1708,54 +1693,6 @@ static int msm_otg_read_dt(struct platform_device *pdev, 
struct msm_otg *motg)
if (IS_ERR(motg->switch_gpio))
return PTR_ERR(motg->switch_gpio);
 
-   ext_id = ERR_PTR(-ENODEV);
-   ext_vbus = ERR_PTR(-ENODEV);
-   if (of_property_read_bool(node, "extcon")) {
-
-   /* Each one of them is not mandatory */
-   ext_vbus = extcon_get_edev_by_phandle(>dev, 0);
-   if (IS_ERR(ext_vbus) && PTR_ERR(ext_vbus) != -ENODEV)
-   return PTR_ERR(ext_vbus);
-
-   ext_id = extcon_get_edev_by_phandle(>dev, 1);
-   if (IS_ERR(ext_id) && PTR_ERR(ext_id) != -ENODEV)
-   return PTR_ERR(ext_id);
-   }
-
-   if (!IS_ERR(ext_vbus)) {
-   motg->vbus.extcon = ext_vbus;
-   motg->vbus.nb.notifier_call = msm_otg_vbus_notifier;
-   ret = devm_extcon_register_notifier(>dev, ext_vbus,
-   EXTCON_USB, >vbus.nb);
-   if (ret < 0) {
-   dev_err(>dev, "register VBUS notifier failed\n");
-   return ret;
-   }
-
-   ret = extcon_get_state(ext_vbus, EXTCON_USB);
-   if (ret)
-   set_bit(B_SESS_VLD, >inputs);
-   else
-   clear_bit(B_SESS_VLD, >inputs);
-   }
-
-   if (!IS_ERR(ext_id)) {
-   motg->id.extcon = ext_id;
-   motg->id.nb.notifier_call = msm_otg_id_notifier;
-   ret = devm_extcon_register_notifier(>dev, ext_id,
-   EXTCON_USB_HOST, >id.nb);
-   if (ret < 0) {
-   dev_err(>dev, "register ID notifier failed\n");
-   return ret;
-   }
-
-   ret = extcon_get_state(ext_id, EXTCON_USB_HOST);
-   if (ret)
-   clear_bit(ID, >inputs);
-   else
-

[PATCH v3 2/3] usb: phy: phy-qcom-8x16-usb: Remove redundant extcon register/unregister

[Baolin Wang]

Since usb phy core has added common code to register or unregister
extcon device, then phy-qcom-8x16-usb driver does not need its own
code to register/unregister extcon device, then remove them.

Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
 drivers/usb/phy/phy-qcom-8x16-usb.c |   20 +---
 1 file changed, 5 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/phy/phy-qcom-8x16-usb.c 
b/drivers/usb/phy/phy-qcom-8x16-usb.c
index fdf6863..b6a83a5 100644
--- a/drivers/usb/phy/phy-qcom-8x16-usb.c
+++ b/drivers/usb/phy/phy-qcom-8x16-usb.c
@@ -69,9 +69,6 @@ struct phy_8x16 {
 
struct reset_control*phy_reset;
 
-   struct extcon_dev   *vbus_edev;
-   struct notifier_block   vbus_notify;
-
struct gpio_desc*switch_gpio;
struct notifier_block   reboot_notify;
 };
@@ -131,7 +128,8 @@ static int phy_8x16_vbus_off(struct phy_8x16 *qphy)
 static int phy_8x16_vbus_notify(struct notifier_block *nb, unsigned long event,
void *ptr)
 {
-   struct phy_8x16 *qphy = container_of(nb, struct phy_8x16, vbus_notify);
+   struct usb_phy *usb_phy = container_of(nb, struct usb_phy, vbus_nb);
+   struct phy_8x16 *qphy = container_of(usb_phy, struct phy_8x16, phy);
 
if (event)
phy_8x16_vbus_on(qphy);
@@ -187,7 +185,7 @@ static int phy_8x16_init(struct usb_phy *phy)
val = ULPI_PWR_OTG_COMP_DISABLE;
usb_phy_io_write(phy, val, ULPI_SET(ULPI_PWR_CLK_MNG_REG));
 
-   state = extcon_get_state(qphy->vbus_edev, EXTCON_USB);
+   state = extcon_get_state(qphy->phy.edev, EXTCON_USB);
if (state)
phy_8x16_vbus_on(qphy);
else
@@ -289,15 +287,13 @@ static int phy_8x16_probe(struct platform_device *pdev)
phy->io_priv= qphy->regs + HSPHY_ULPI_VIEWPORT;
phy->io_ops = _viewport_access_ops;
phy->type   = USB_PHY_TYPE_USB2;
+   phy->vbus_nb.notifier_call = phy_8x16_vbus_notify;
+   phy->id_nb.notifier_call = NULL;
 
ret = phy_8x16_read_devicetree(qphy);
if (ret < 0)
return ret;
 
-   qphy->vbus_edev = extcon_get_edev_by_phandle(phy->dev, 0);
-   if (IS_ERR(qphy->vbus_edev))
-   return PTR_ERR(qphy->vbus_edev);
-
ret = clk_set_rate(qphy->core_clk, INT_MAX);
if (ret < 0)
dev_dbg(phy->dev, "Can't boost core clock\n");
@@ -315,12 +311,6 @@ static int phy_8x16_probe(struct platform_device *pdev)
if (WARN_ON(ret))
goto off_clks;
 
-   qphy->vbus_notify.notifier_call = phy_8x16_vbus_notify;
-   ret = devm_extcon_register_notifier(>dev, qphy->vbus_edev,
-   EXTCON_USB, >vbus_notify);
-   if (ret < 0)
-   goto off_power;
-
ret = usb_add_phy_dev(>phy);
if (ret)
goto off_power;
-- 
1.7.9.5

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

[PATCH v3 0/3] Introduce one extcon device into usb phy

[Baolin Wang]

This patchset introduces one pointer of extcon device into usb phy
structure, and some other helper functions to register extcon instead
of each phy driver having its own related extcon APIs.

Changes since v2:
 - Support separate extcon device.
 - Convert the phy-msm-usb driver.

Changes since v1:
 - Fix build errors with random config.

Baolin Wang (3):
  usb: phy: Introduce one extcon device into usb phy
  usb: phy: phy-qcom-8x16-usb: Remove redundant extcon
register/unregister
  usb: phy: phy-msm-usb: Remove redundant extcon register/unregister

 drivers/usb/phy/Kconfig |6 +--
 drivers/usb/phy/phy-msm-usb.c   |   85 ---
 drivers/usb/phy/phy-qcom-8x16-usb.c |   20 +++--
 drivers/usb/phy/phy.c   |   57 +++
 include/linux/usb/phy.h |7 +++
 5 files changed, 90 insertions(+), 85 deletions(-)

-- 
1.7.9.5

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

Re: [PATCH] usb: gadget: gserial: check if console kthread exists

[Baolin Wang]

Hi Mirea,

On 29 April 2017 at 17:58, Mirea, Bogdan-Stefan
<bogdan-stefan_mi...@mentor.com> wrote:
> Hi Baolin,
>
> On April 29, 2017 at 5:14, Baolin Wang <baolin.w...@linaro.org> wrote:
>> Hi,
>>
>> On 28 April 2017 at 21:26, Bogdan Mirea <bogdan-stefan_mi...@mentor.com> 
>> wrote:
>> > In the current implementation we get a Kernel Oops when calling rmmod
>> > for g_serial driver. This happens because the function that creates
>> > the kthread (gs_console_setup) which should be called at driver
>> > probing is never called for ttyGS* resulting in a null
>> > info->console_thread pointer.
>> >
>> > Noticed this behaviour on Renesas Rcar-H3 Salvator-X (R8A7795).
>> >
>> > Signed-off-by: Bogdan Mirea <bogdan-stefan_mi...@mentor.com>
>> > ---
>> >  drivers/usb/gadget/function/u_serial.c | 3 ++-
>> >  1 file changed, 2 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/usb/gadget/function/u_serial.c
>> > b/drivers/usb/gadget/function/u_serial.c
>> > index e0cd1e4..7283ff5 100644
>> > --- a/drivers/usb/gadget/function/u_serial.c
>> > +++ b/drivers/usb/gadget/function/u_serial.c
>> > @@ -1256,7 +1256,8 @@ static void gserial_console_exit(void)
>> > struct gscons_info *info = _info;
>> >
>> > unregister_console(_cons);
>> > -   kthread_stop(info->console_thread);
>> > +   if (info->console_thread && !IS_ERR(info->console_thread))
>> > +   kthread_stop(info->console_thread);
>> > gs_buf_free(>con_buf);
>> >  }
>>
>> Which kernel version did you test on? Since this issue had been fixed by 
>> below patch:
>> https://www.spinics.net/lists/linux-usb/msg149581.html (usb: gadget:
>> serial: fix possible Oops caused by calling kthread_stop(NULL))
>>
>> --
>> Baolin.wang
>> Best Regards
>
> Thank you for your input!
> I am using Kernel v4.9 and in this Kernel version the patch[1] is not
> present, I'm sorry for not checking v4.10.
> But this patch[1] only covers the case of a NULL pointer and doesn't
> include the case of a bad pointer value that should also be checked
> with IS_ERR(info->console_thread).
>
> This check is needed since the gserial setup callback function
> (gs_console_setup()) is only freeing the info->con_buf in the case of
> kthread_create failure which will result in bad info->console_thread
> pointer so this will also fail on rmmod if the bad pointer value is not
> checked in the gserial_console_exit() function before calling
> kthread_stop().
>
> I think cherry-picking the patch[1] and create a new one that is also
> checking this bad pointer value case is the best approach.

Agreed.

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

Re: [PATCH] usb: gadget: gserial: check if console kthread exists

[Baolin Wang]

Hi,

On 28 April 2017 at 21:26, Bogdan Mirea  wrote:
> In the current implementation we get a Kernel Oops when calling rmmod
> for g_serial driver. This happens because the function that creates the
> kthread (gs_console_setup) which should be called at driver probing is
> never called for ttyGS* resulting in a null info->console_thread
> pointer.
>
> Noticed this behaviour on Renesas Rcar-H3 Salvator-X (R8A7795).
>
> Signed-off-by: Bogdan Mirea 
> ---
>  drivers/usb/gadget/function/u_serial.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/gadget/function/u_serial.c 
> b/drivers/usb/gadget/function/u_serial.c
> index e0cd1e4..7283ff5 100644
> --- a/drivers/usb/gadget/function/u_serial.c
> +++ b/drivers/usb/gadget/function/u_serial.c
> @@ -1256,7 +1256,8 @@ static void gserial_console_exit(void)
> struct gscons_info *info = _info;
>
> unregister_console(_cons);
> -   kthread_stop(info->console_thread);
> +   if (info->console_thread && !IS_ERR(info->console_thread))
> +   kthread_stop(info->console_thread);
> gs_buf_free(>con_buf);
>  }

Which kernel version did you test on? Since this issue had been fixed
by below patch:
https://www.spinics.net/lists/linux-usb/msg149581.html (usb: gadget:
serial: fix possible Oops caused by calling kthread_stop(NULL))

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

[PATCH v2] usb: host: plat: Enable xHCI plat runtime PM

[Baolin Wang]

Enable the xHCI plat runtime PM for parent device to suspend/resume
xHCI. Also call pm_runtime_forbid() in probe() function to force users
to explicitly enable runtime pm using power/control in sysfs, in case
some parent devices didn't implement runtime PM callbacks.

Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
Changes since v1:
 - Rebase on Mathias's next branch.
---
 drivers/usb/host/xhci-plat.c | 53 ++--
 1 file changed, 46 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 62e71b8..e19b257 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -197,10 +197,16 @@ static int xhci_plat_probe(struct platform_device *pdev)
return ret;
}
 
+   pm_runtime_set_active(>dev);
+   pm_runtime_enable(>dev);
+   pm_runtime_get_noresume(>dev);
+
hcd = __usb_create_hcd(driver, sysdev, >dev,
   dev_name(>dev), NULL);
-   if (!hcd)
-   return -ENOMEM;
+   if (!hcd) {
+   ret = -ENOMEM;
+   goto disable_runtime;
+   }
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
hcd->regs = devm_ioremap_resource(>dev, res);
@@ -278,6 +284,13 @@ static int xhci_plat_probe(struct platform_device *pdev)
goto dealloc_usb2_hcd;
 
device_enable_async_suspend(>dev);
+   pm_runtime_put_noidle(>dev);
+
+   /*
+* Prevent runtime pm from being on as default, users should enable
+* runtime pm using power/control in sysfs.
+*/
+   pm_runtime_forbid(>dev);
 
return 0;
 
@@ -298,6 +311,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
 put_hcd:
usb_put_hcd(hcd);
 
+disable_runtime:
+   pm_runtime_put_noidle(>dev);
+   pm_runtime_disable(>dev);
+
return ret;
 }
 
@@ -318,6 +335,9 @@ static int xhci_plat_remove(struct platform_device *dev)
if (!IS_ERR(clk))
clk_disable_unprepare(clk);
usb_put_hcd(hcd);
+   
+   pm_runtime_set_suspended(>dev);
+   pm_runtime_disable(>dev);
 
return 0;
 }
@@ -346,14 +366,33 @@ static int xhci_plat_resume(struct device *dev)
 
return xhci_resume(xhci, 0);
 }
+#endif /* CONFIG_PM_SLEEP */
+
+#ifdef CONFIG_PM
+static int xhci_plat_runtime_suspend(struct device *dev)
+{
+   struct usb_hcd  *hcd = dev_get_drvdata(dev);
+   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+
+   return xhci_suspend(xhci, device_may_wakeup(dev));
+}
+
+static int xhci_plat_runtime_resume(struct device *dev)
+{
+   struct usb_hcd  *hcd = dev_get_drvdata(dev);
+   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+
+   return xhci_resume(xhci, 0);
+}
+#endif /* CONFIG_PM */
 
 static const struct dev_pm_ops xhci_plat_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(xhci_plat_suspend, xhci_plat_resume)
+
+   SET_RUNTIME_PM_OPS(xhci_plat_runtime_suspend,
+  xhci_plat_runtime_resume,
+  NULL)
 };
-#define DEV_PM_OPS (_plat_pm_ops)
-#else
-#define DEV_PM_OPS NULL
-#endif /* CONFIG_PM */
 
 static const struct acpi_device_id usb_xhci_acpi_match[] = {
/* XHCI-compliant USB Controller */
@@ -368,7 +407,7 @@ static int xhci_plat_resume(struct device *dev)
.shutdown   = usb_hcd_platform_shutdown,
.driver = {
.name = "xhci-hcd",
-   .pm = DEV_PM_OPS,
+   .pm = _plat_pm_ops,
.of_match_table = of_match_ptr(usb_xhci_of_match),
.acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),
},
-- 
1.9.1

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

Re: [PATCH] usb: host: plat: Enable xHCI plat runtime PM

[Baolin Wang]

Hi Mathias,

On 10 April 2017 at 18:09, Mathias Nyman <mathias.ny...@linux.intel.com> wrote:
> On 10.04.2017 10:57, Baolin Wang wrote:
>>
>> Hi Mathias,
>>
>> On 30 March 2017 at 11:26, Baolin Wang <baolin.w...@linaro.org> wrote:
>>>
>>> Enable the xHCI plat runtime PM for parent device to suspend/resume
>>> xHCI. Also call pm_runtime_forbid() in probe() function to force users
>>> to explicitly enable runtime pm using power/control in sysfs, in case
>>> some parent devices didn't implement runtime PM callbacks.
>>>
>>> Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
>>> ---
>>
>> Any comments?
>
>
> Patch looks good, but it didn't apply cleanly on top of the series going to
> usb next last Friday.
> I wanted those to go forward so this got postponed.
>
> Can you rebase this on latest usb-next?

Sure. I will resend it. Thanks.

-- 
Baolin.wang
Best Regards
--
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: host: plat: Enable xHCI plat runtime PM

[Baolin Wang]

Hi Mathias,

On 30 March 2017 at 11:26, Baolin Wang <baolin.w...@linaro.org> wrote:
> Enable the xHCI plat runtime PM for parent device to suspend/resume
> xHCI. Also call pm_runtime_forbid() in probe() function to force users
> to explicitly enable runtime pm using power/control in sysfs, in case
> some parent devices didn't implement runtime PM callbacks.
>
> Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
> ---
>  drivers/usb/host/xhci-plat.c |   54 
> --
>  1 file changed, 47 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index bd02a6c..2036c24 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -179,9 +179,15 @@ static int xhci_plat_probe(struct platform_device *pdev)
> return ret;
> }
>
> +   pm_runtime_set_active(>dev);
> +   pm_runtime_enable(>dev);
> +   pm_runtime_get_noresume(>dev);
> +
> hcd = usb_create_hcd(driver, >dev, dev_name(>dev));
> -   if (!hcd)
> -   return -ENOMEM;
> +   if (!hcd) {
> +   ret = -ENOMEM;
> +   goto disable_runtime;
> +   }
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> hcd->regs = devm_ioremap_resource(>dev, res);
> @@ -258,6 +264,14 @@ static int xhci_plat_probe(struct platform_device *pdev)
> if (ret)
> goto dealloc_usb2_hcd;
>
> +   pm_runtime_put_noidle(>dev);
> +
> +   /*
> +* Prevent runtime pm from being on as default, users should enable
> +* runtime pm using power/control in sysfs.
> +*/
> +   pm_runtime_forbid(>dev);
> +
> return 0;
>
>
> @@ -277,6 +291,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
>  put_hcd:
> usb_put_hcd(hcd);
>
> +disable_runtime:
> +   pm_runtime_put_noidle(>dev);
> +   pm_runtime_disable(>dev);
> +
> return ret;
>  }
>
> @@ -298,6 +316,9 @@ static int xhci_plat_remove(struct platform_device *dev)
> clk_disable_unprepare(clk);
> usb_put_hcd(hcd);
>
> +   pm_runtime_set_suspended(>dev);
> +   pm_runtime_disable(>dev);
> +
> return 0;
>  }
>
> @@ -325,14 +346,33 @@ static int xhci_plat_resume(struct device *dev)
>
> return xhci_resume(xhci, 0);
>  }
> +#endif /* CONFIG_PM_SLEEP */
> +
> +#ifdef CONFIG_PM
> +static int xhci_plat_runtime_suspend(struct device *dev)
> +{
> +   struct usb_hcd  *hcd = dev_get_drvdata(dev);
> +   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> +
> +   return xhci_suspend(xhci, device_may_wakeup(dev));
> +}
> +
> +static int xhci_plat_runtime_resume(struct device *dev)
> +{
> +   struct usb_hcd  *hcd = dev_get_drvdata(dev);
> +   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
> +
> +   return xhci_resume(xhci, 0);
> +}
> +#endif /* CONFIG_PM */
>
>  static const struct dev_pm_ops xhci_plat_pm_ops = {
> SET_SYSTEM_SLEEP_PM_OPS(xhci_plat_suspend, xhci_plat_resume)
> +
> +   SET_RUNTIME_PM_OPS(xhci_plat_runtime_suspend,
> +  xhci_plat_runtime_resume,
> +  NULL)
>  };
> -#define DEV_PM_OPS (_plat_pm_ops)
> -#else
> -#define DEV_PM_OPS NULL
> -#endif /* CONFIG_PM */
>
>  static const struct acpi_device_id usb_xhci_acpi_match[] = {
> /* XHCI-compliant USB Controller */
> @@ -346,7 +386,7 @@ static int xhci_plat_resume(struct device *dev)
> .remove = xhci_plat_remove,
> .driver = {
> .name = "xhci-hcd",
> -   .pm = DEV_PM_OPS,
> +   .pm = _plat_pm_ops,
> .of_match_table = of_match_ptr(usb_xhci_of_match),
> .acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),
> },

Any comments?

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

[PATCH] usb: host: plat: Enable xHCI plat runtime PM

[Baolin Wang]

Enable the xHCI plat runtime PM for parent device to suspend/resume
xHCI. Also call pm_runtime_forbid() in probe() function to force users
to explicitly enable runtime pm using power/control in sysfs, in case
some parent devices didn't implement runtime PM callbacks.

Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
 drivers/usb/host/xhci-plat.c |   54 --
 1 file changed, 47 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index bd02a6c..2036c24 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -179,9 +179,15 @@ static int xhci_plat_probe(struct platform_device *pdev)
return ret;
}
 
+   pm_runtime_set_active(>dev);
+   pm_runtime_enable(>dev);
+   pm_runtime_get_noresume(>dev);
+
hcd = usb_create_hcd(driver, >dev, dev_name(>dev));
-   if (!hcd)
-   return -ENOMEM;
+   if (!hcd) {
+   ret = -ENOMEM;
+   goto disable_runtime;
+   }
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
hcd->regs = devm_ioremap_resource(>dev, res);
@@ -258,6 +264,14 @@ static int xhci_plat_probe(struct platform_device *pdev)
if (ret)
goto dealloc_usb2_hcd;
 
+   pm_runtime_put_noidle(>dev);
+
+   /*
+* Prevent runtime pm from being on as default, users should enable
+* runtime pm using power/control in sysfs.
+*/
+   pm_runtime_forbid(>dev);
+
return 0;
 
 
@@ -277,6 +291,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
 put_hcd:
usb_put_hcd(hcd);
 
+disable_runtime:
+   pm_runtime_put_noidle(>dev);
+   pm_runtime_disable(>dev);
+
return ret;
 }
 
@@ -298,6 +316,9 @@ static int xhci_plat_remove(struct platform_device *dev)
clk_disable_unprepare(clk);
usb_put_hcd(hcd);
 
+   pm_runtime_set_suspended(>dev);
+   pm_runtime_disable(>dev);
+
return 0;
 }
 
@@ -325,14 +346,33 @@ static int xhci_plat_resume(struct device *dev)
 
return xhci_resume(xhci, 0);
 }
+#endif /* CONFIG_PM_SLEEP */
+
+#ifdef CONFIG_PM
+static int xhci_plat_runtime_suspend(struct device *dev)
+{
+   struct usb_hcd  *hcd = dev_get_drvdata(dev);
+   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+
+   return xhci_suspend(xhci, device_may_wakeup(dev));
+}
+
+static int xhci_plat_runtime_resume(struct device *dev)
+{
+   struct usb_hcd  *hcd = dev_get_drvdata(dev);
+   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
+
+   return xhci_resume(xhci, 0);
+}
+#endif /* CONFIG_PM */
 
 static const struct dev_pm_ops xhci_plat_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(xhci_plat_suspend, xhci_plat_resume)
+
+   SET_RUNTIME_PM_OPS(xhci_plat_runtime_suspend,
+  xhci_plat_runtime_resume,
+  NULL)
 };
-#define DEV_PM_OPS (_plat_pm_ops)
-#else
-#define DEV_PM_OPS NULL
-#endif /* CONFIG_PM */
 
 static const struct acpi_device_id usb_xhci_acpi_match[] = {
/* XHCI-compliant USB Controller */
@@ -346,7 +386,7 @@ static int xhci_plat_resume(struct device *dev)
.remove = xhci_plat_remove,
.driver = {
.name = "xhci-hcd",
-   .pm = DEV_PM_OPS,
+   .pm = _plat_pm_ops,
.of_match_table = of_match_ptr(usb_xhci_of_match),
.acpi_match_table = ACPI_PTR(usb_xhci_acpi_match),
},
-- 
1.7.9.5

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

Re: [PATCH v2 2/2] usb: phy: phy-qcom-8x16-usb: Remove redundant extcon register/unregister

[Baolin Wang]

Hi,

On 28 March 2017 at 21:42, Felipe Balbi <ba...@kernel.org> wrote:
>
> Hi,
>
> Baolin Wang <baolin.w...@linaro.org> writes:
>> Since usb phy core has added common code to register or unregister
>> extcon device, then phy-qcom-8x16-usb driver does not need its own
>> code to register/unregister extcon device, then remove them.
>>
>> Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
>
> so previous patch helped *ONE* single user? Was it really beneficial if
> it's all for a single user? Which duplicated code did it remove?

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.
phy-omap-otg.c did not add one usb phy, so I did not convert it.
phy-msm-usb.c had 2 separate extcon devices, but my last patch did not
support separate extcon devices which need to modify again. Moreover
in future usb phy drivers do not need to implement extcon things in
their own drivers.

-- 
Baolin.wang
Best Regards
--
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 v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

Hi,

On 29 March 2017 at 07:04, NeilBrown <ne...@suse.com> wrote:
> On Tue, Mar 07 2017, Baolin Wang wrote:
>
>> On 3 March 2017 at 10:23, NeilBrown <ne...@suse.com> wrote:
>>
>>>
>>> I understand your reluctance to change drivers that you cannot test.
>>> An alternative it do change all the
>>>   atomic_notifier_call_chain(.*notifier,
>>> calls that don't pass a pointer to vbus_draw to pass NULL, and to
>>> declare the passing of NULL to be deprecated (so hopefully people won't
>>> use it in new code).
>>> Then any notification callback that expects a current can just ignore
>>> calls where the pointer is NULL.
>>
>> I am afraid if it is enough to send out vbus draw information from USB
>> phy driver, for example you will miss super speed (900mA), which need
>> get the speed information from gadget driver.
>
> When the gadget driver determines that 900mA is available, it calls
> usb_phy_set_power() which calls the ->set_power() method on the usb_phy.
> The usb_phy the uses the notifier to inform all interested parties
> that 900mA is available.

That is one possible way. Now we only set vbus draw by
usb_gadget_vbus_draw() after setting config and suspend/resume usb
device. Maybe we can add one condition in usb_gadget_vbus_draw() like:

if (mA >= 500 && gadet->speed >= SUPER_SPEED)
 mA = 900;

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

Re: [PATCH v2 1/2] usb: phy: Introduce one extcon device into usb phy

[Baolin Wang]

Hi,

On 29 March 2017 at 06:56, NeilBrown <ne...@suse.com> wrote:
> On Thu, Mar 23 2017, Baolin Wang wrote:
>
>> Usually usb phy need register one extcon device to get the connection
>> notifications. It will remove some duplicate code if the extcon device
>> is registered using common code instead of each phy driver having its
>> own related extcon APIs. So we add one pointer of extcon device into
>> usb phy structure, and some other helper functions to register extcon.
>>
>> Suggested-by: NeilBrown <ne...@suse.com>
>> Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
>> ---
>> Changes since v1:
>>  - Fix build errors with random config.
>> ---
>>  drivers/usb/phy/Kconfig |6 +++---
>>  drivers/usb/phy/phy.c   |   44 
>>  include/linux/usb/phy.h |6 ++
>>  3 files changed, 53 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
>> index 61cef75..c9c61a8 100644
>> --- a/drivers/usb/phy/Kconfig
>> +++ b/drivers/usb/phy/Kconfig
>> @@ -4,6 +4,7 @@
>>  menu "USB Physical Layer drivers"
>>
>>  config USB_PHY
>> + select EXTCON
>>   def_bool n
>>
>>  #
>> @@ -116,7 +117,7 @@ config OMAP_OTG
>>
>>  config TAHVO_USB
>>   tristate "Tahvo USB transceiver driver"
>> - depends on MFD_RETU && EXTCON
>> + depends on MFD_RETU
>>   depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, this can't be 
>> 'y'
>>   select USB_PHY
>>   help
>> @@ -148,7 +149,6 @@ config USB_MSM_OTG
>>   depends on (USB || USB_GADGET) && (ARCH_QCOM || COMPILE_TEST)
>>   depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, this can't be 
>> 'y'
>>   depends on RESET_CONTROLLER
>> - depends on EXTCON
>>   select USB_PHY
>>   help
>> Enable this to support the USB OTG transceiver on Qualcomm chips. It
>> @@ -162,7 +162,7 @@ config USB_MSM_OTG
>>  config USB_QCOM_8X16_PHY
>>   tristate "Qualcomm APQ8016/MSM8916 on-chip USB PHY controller support"
>>   depends on ARCH_QCOM || COMPILE_TEST
>> - depends on RESET_CONTROLLER && EXTCON
>> + depends on RESET_CONTROLLER
>>   select USB_PHY
>>   select USB_ULPI_VIEWPORT
>>   help
>> diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
>> index 98f75d2..baa8b18 100644
>> --- a/drivers/usb/phy/phy.c
>> +++ b/drivers/usb/phy/phy.c
>> @@ -100,6 +100,41 @@ static int devm_usb_phy_match(struct device *dev, void 
>> *res, void *match_data)
>>   return *phy == match_data;
>>  }
>>
>> +static int usb_add_extcon(struct usb_phy *x)
>> +{
>> + int ret;
>> +
>> + if (of_property_read_bool(x->dev->of_node, "extcon")) {
>> + x->edev = extcon_get_edev_by_phandle(x->dev, 0);
>
> This is not what I meant to suggest.
> This provides an extcon only for some phy devices.  I meant that every
> single usb_phy should always have an extcon.
> So phy.c should probably call extcon_dev_allocate() and
> extcon_dev_register() - or similar.

That means every usb phy acts as one extcon device, but I think usb
phy device is not one extcon device, ID/VBUS GPIOs are really extcon
devices, which means usb phy extcon device is duplicate, right?

>
> The driver then calls extcon_set_state() or similar on this extcon
> device in whatever way might be appropriate.
> For a phy driver like phy-qcom-8x16-usb it might just pass on
> events from some separate extcon device.
>
> For the (hypothetical?) device that Felipe suggests with separate
> ID and VBUS extcons, it would pass on events from multiple different
> extcons.  i.e. it would act like a multiplexer.
>
> Other drivers would do things from interrupt handlers, based on values
> read from registers.
>
> The important point is that each usb_phy doesn't get a pointer to some
> separate extcon.  Rather it has an extcon that it completely owns.  The
> name of the extcon is the same of the phy.  The extcon should be seen as
> a part of the phy, not a separate thing which provides service to the
> phy.
>
> Thanks,
> NeilBrown



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

Re: [PATCH v2 1/2] usb: phy: Introduce one extcon device into usb phy

[Baolin Wang]

Hi,

On 28 March 2017 at 21:40, Felipe Balbi <ba...@kernel.org> wrote:
>
> Hi,
>
> Baolin Wang <baolin.w...@linaro.org> writes:
>> Usually usb phy need register one extcon device to get the connection
>> notifications. It will remove some duplicate code if the extcon device
>> is registered using common code instead of each phy driver having its
>> own related extcon APIs. So we add one pointer of extcon device into
>> usb phy structure, and some other helper functions to register extcon.
>>
>> Suggested-by: NeilBrown <ne...@suse.com>
>> Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
>
> will this work with devices which have ID and VBUS from separate EXTCON
> devices?

Ah, It can not work for separate EXTCON devices, now I realized some
devices have separate EXTCON devices. Thanks for pointing this.

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

[PATCH] usb: phy: Remove unused config

[Baolin Wang]

Since the old common Samsung USB PHY code has been removed by commit ea2fdf8423
("usb: phy: samsung: remove old common USB PHY code"), thus remove the unused
config.

Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
 drivers/usb/phy/Kconfig  |7 ---
 drivers/usb/phy/Makefile |1 -
 2 files changed, 8 deletions(-)

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index c9c61a8..aff702c 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -75,13 +75,6 @@ config AM335X_PHY_USB
  This driver provides PHY support for that phy which part for the
  AM335x SoC.
 
-config SAMSUNG_USBPHY
-   tristate
-   help
- Enable this to support Samsung USB phy helper driver for Samsung SoCs.
- This driver provides common interface to interact, for Samsung USB 
2.0 PHY
- driver and later for Samsung USB 3.0 PHY driver.
-
 config TWL6030_USB
tristate "TWL6030 USB Transceiver Driver"
depends on TWL4030_CORE && OMAP_USB2 && USB_MUSB_OMAP2PLUS
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index b433e5d..e7c9ca8 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -14,7 +14,6 @@ obj-$(CONFIG_TAHVO_USB)   += phy-tahvo.o
 obj-$(CONFIG_AM335X_CONTROL_USB)   += phy-am335x-control.o
 obj-$(CONFIG_AM335X_PHY_USB)   += phy-am335x.o
 obj-$(CONFIG_OMAP_OTG) += phy-omap-otg.o
-obj-$(CONFIG_SAMSUNG_USBPHY)   += phy-samsung-usb.o
 obj-$(CONFIG_TWL6030_USB)  += phy-twl6030-usb.o
 obj-$(CONFIG_USB_EHCI_TEGRA)   += phy-tegra-usb.o
 obj-$(CONFIG_USB_GPIO_VBUS)+= phy-gpio-vbus-usb.o
-- 
1.7.9.5

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

[PATCH v2 1/2] usb: phy: Introduce one extcon device into usb phy

[Baolin Wang]

Usually usb phy need register one extcon device to get the connection
notifications. It will remove some duplicate code if the extcon device
is registered using common code instead of each phy driver having its
own related extcon APIs. So we add one pointer of extcon device into
usb phy structure, and some other helper functions to register extcon.

Suggested-by: NeilBrown <ne...@suse.com>
Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
Changes since v1:
 - Fix build errors with random config.
---
 drivers/usb/phy/Kconfig |6 +++---
 drivers/usb/phy/phy.c   |   44 
 include/linux/usb/phy.h |6 ++
 3 files changed, 53 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 61cef75..c9c61a8 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -4,6 +4,7 @@
 menu "USB Physical Layer drivers"
 
 config USB_PHY
+   select EXTCON
def_bool n
 
 #
@@ -116,7 +117,7 @@ config OMAP_OTG
 
 config TAHVO_USB
tristate "Tahvo USB transceiver driver"
-   depends on MFD_RETU && EXTCON
+   depends on MFD_RETU
depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, this can't be 
'y'
select USB_PHY
help
@@ -148,7 +149,6 @@ config USB_MSM_OTG
depends on (USB || USB_GADGET) && (ARCH_QCOM || COMPILE_TEST)
depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, this can't be 
'y'
depends on RESET_CONTROLLER
-   depends on EXTCON
select USB_PHY
help
  Enable this to support the USB OTG transceiver on Qualcomm chips. It
@@ -162,7 +162,7 @@ config USB_MSM_OTG
 config USB_QCOM_8X16_PHY
tristate "Qualcomm APQ8016/MSM8916 on-chip USB PHY controller support"
depends on ARCH_QCOM || COMPILE_TEST
-   depends on RESET_CONTROLLER && EXTCON
+   depends on RESET_CONTROLLER
select USB_PHY
select USB_ULPI_VIEWPORT
help
diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index 98f75d2..baa8b18 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -100,6 +100,41 @@ static int devm_usb_phy_match(struct device *dev, void 
*res, void *match_data)
return *phy == match_data;
 }
 
+static int usb_add_extcon(struct usb_phy *x)
+{
+   int ret;
+
+   if (of_property_read_bool(x->dev->of_node, "extcon")) {
+   x->edev = extcon_get_edev_by_phandle(x->dev, 0);
+   if (IS_ERR(x->edev))
+   return PTR_ERR(x->edev);
+
+   if (x->vbus_nb.notifier_call) {
+   ret = devm_extcon_register_notifier(x->dev, x->edev,
+   EXTCON_USB,
+   >vbus_nb);
+   if (ret < 0) {
+   dev_err(x->dev,
+   "register VBUS notifier failed\n");
+   return ret;
+   }
+   }
+
+   if (x->id_nb.notifier_call) {
+   ret = devm_extcon_register_notifier(x->dev, x->edev,
+   EXTCON_USB_HOST,
+   >id_nb);
+   if (ret < 0) {
+   dev_err(x->dev,
+   "register ID notifier failed\n");
+   return ret;
+   }
+   }
+   }
+
+   return 0;
+}
+
 /**
  * devm_usb_get_phy - find the USB PHY
  * @dev - device that requests this phy
@@ -388,6 +423,10 @@ int usb_add_phy(struct usb_phy *x, enum usb_phy_type type)
return -EINVAL;
}
 
+   ret = usb_add_extcon(x);
+   if (ret)
+   return ret;
+
ATOMIC_INIT_NOTIFIER_HEAD(>notifier);
 
spin_lock_irqsave(_lock, flags);
@@ -422,12 +461,17 @@ int usb_add_phy_dev(struct usb_phy *x)
 {
struct usb_phy_bind *phy_bind;
unsigned long flags;
+   int ret;
 
if (!x->dev) {
dev_err(x->dev, "no device provided for PHY\n");
return -EINVAL;
}
 
+   ret = usb_add_extcon(x);
+   if (ret)
+   return ret;
+
ATOMIC_INIT_NOTIFIER_HEAD(>notifier);
 
spin_lock_irqsave(_lock, flags);
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 31a8068..1b5269e 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -9,6 +9,7 @@
 #ifndef __LINUX_USB_PHY_H
 #define __LINUX_USB_PHY_H
 
+#include 
 #include 
 #include 
 
@@ -85,6 +86,11 @@ struct usb_phy {
struct usb_phy_io_ops   *io_ops;
void __iomem

[PATCH v2 2/2] usb: phy: phy-qcom-8x16-usb: Remove redundant extcon register/unregister

[Baolin Wang]

Since usb phy core has added common code to register or unregister
extcon device, then phy-qcom-8x16-usb driver does not need its own
code to register/unregister extcon device, then remove them.

Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
Changes since v1:
 - No updates.
---
 drivers/usb/phy/phy-qcom-8x16-usb.c |   20 +---
 1 file changed, 5 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/phy/phy-qcom-8x16-usb.c 
b/drivers/usb/phy/phy-qcom-8x16-usb.c
index fdf6863..b6a83a5 100644
--- a/drivers/usb/phy/phy-qcom-8x16-usb.c
+++ b/drivers/usb/phy/phy-qcom-8x16-usb.c
@@ -69,9 +69,6 @@ struct phy_8x16 {
 
struct reset_control*phy_reset;
 
-   struct extcon_dev   *vbus_edev;
-   struct notifier_block   vbus_notify;
-
struct gpio_desc*switch_gpio;
struct notifier_block   reboot_notify;
 };
@@ -131,7 +128,8 @@ static int phy_8x16_vbus_off(struct phy_8x16 *qphy)
 static int phy_8x16_vbus_notify(struct notifier_block *nb, unsigned long event,
void *ptr)
 {
-   struct phy_8x16 *qphy = container_of(nb, struct phy_8x16, vbus_notify);
+   struct usb_phy *usb_phy = container_of(nb, struct usb_phy, vbus_nb);
+   struct phy_8x16 *qphy = container_of(usb_phy, struct phy_8x16, phy);
 
if (event)
phy_8x16_vbus_on(qphy);
@@ -187,7 +185,7 @@ static int phy_8x16_init(struct usb_phy *phy)
val = ULPI_PWR_OTG_COMP_DISABLE;
usb_phy_io_write(phy, val, ULPI_SET(ULPI_PWR_CLK_MNG_REG));
 
-   state = extcon_get_state(qphy->vbus_edev, EXTCON_USB);
+   state = extcon_get_state(qphy->phy.edev, EXTCON_USB);
if (state)
phy_8x16_vbus_on(qphy);
else
@@ -289,15 +287,13 @@ static int phy_8x16_probe(struct platform_device *pdev)
phy->io_priv= qphy->regs + HSPHY_ULPI_VIEWPORT;
phy->io_ops = _viewport_access_ops;
phy->type   = USB_PHY_TYPE_USB2;
+   phy->vbus_nb.notifier_call = phy_8x16_vbus_notify;
+   phy->id_nb.notifier_call = NULL;
 
ret = phy_8x16_read_devicetree(qphy);
if (ret < 0)
return ret;
 
-   qphy->vbus_edev = extcon_get_edev_by_phandle(phy->dev, 0);
-   if (IS_ERR(qphy->vbus_edev))
-   return PTR_ERR(qphy->vbus_edev);
-
ret = clk_set_rate(qphy->core_clk, INT_MAX);
if (ret < 0)
dev_dbg(phy->dev, "Can't boost core clock\n");
@@ -315,12 +311,6 @@ static int phy_8x16_probe(struct platform_device *pdev)
if (WARN_ON(ret))
goto off_clks;
 
-   qphy->vbus_notify.notifier_call = phy_8x16_vbus_notify;
-   ret = devm_extcon_register_notifier(>dev, qphy->vbus_edev,
-   EXTCON_USB, >vbus_notify);
-   if (ret < 0)
-   goto off_power;
-
ret = usb_add_phy_dev(>phy);
if (ret)
goto off_power;
-- 
1.7.9.5

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

Re: [PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM

[Baolin Wang]

Hi,

On 22 March 2017 at 20:43, Mathias Nyman <mathias.ny...@linux.intel.com> wrote:
> On 22.03.2017 12:40, Baolin Wang wrote:
>>
>> Hi,
>>
>> On 22 March 2017 at 17:00, Felipe Balbi <ba...@kernel.org> wrote:
>>>
>>>
>>> Hi,
>>>
>>> Baolin Wang <baolin.w...@linaro.org> writes:
>>>>>>>>
>>>>>>>> I don't yet understand why we can't just keep runtime pm disabled as
>>>>>>>> a
>>>>>>>> default for xhci platform devices.
>>>>>>>> It could be enabled by whatever creates the platform device by
>>>>>>>> setting some
>>>>>>>> device property
>>>>>>>> (or equivalent), which would be checked in xhci_plat_probe() before
>>>>>>>> enabling
>>>>>>>> runtime pm. It
>>>>>>>> could then optionally be set in sysfs via power/control entry.
>>>>>>>
>>>>>>>
>>>>>>> I think runtime pm is not one hardware property, is it suitable if we
>>>>>>> introduce one device property to enable/disable runtime pm?
>>>>>
>>>>>
>>>>> we already this functionality exposed on sysfs.
>>>>
>>>>
>>>>  From my understanding, Mathias suggested me to add one device property
>>>> (name like "usb-host-runtimePM") by platform_device_add_properties()
>>>> to enable/disable runtime PM when creating platform device, like
>>>> usb3_lpm_capable:
>>>>
>
> It was more of generic pondering how to automatically enable runtime PM for
> platforms
> that know their xhci can runtime suspend/resume. But all this can be skipped
> for now and just
> force users to manually enable xhci platform runtime pm in sysfs for now.
>
> For me, and for xhci point of view only, patch 1/2 is quite ok.
> Only some minor adjustments like calling runtime_get in the beginning of
> probe, and runtime_put
> at the end end after both hcd's are added.
>
> Probe could additionally call pm_runtime_forbid() to prevent runtime pm frpm
> being on as
> default, (increases usage count, modifies runtime_auto)
>
> This would force the user to explicitly enable runtime pm usin power/control
> in sysfs.

Fair enough.

>
> In my opinion that patch could be a separate one, and how dwc3 deals with it
> can be a separate
> topic.

OK.

>
>>>
>>> yeah, that's silly. We already have means for doing that:
>>>
>>>  my_probe()
>>>  {
>>>  [...]
>>>
>>>  pm_runtime_enable(dev);
>>>  pm_runtime_forbid(dev);
>>
>>
>> That's same with getting the usage counter.
>>
>>>
>>>  [...]
>>>
>>>  return 0;
>>>  }
>>>
>>>>>> Secondly, we only can resume the xhci platform device by getting the
>>>>>> xhci usage counter from gadget driver, since the cable plug in/out
>>>>>> events only can be notified to glue layer of gadget driver(like dwc3
>>>>>> glue layer). That means if we want to suspend xhci platform device, we
>>>>>
>>>>>
>>>>> this is a problem with the glue layer, IMO. It should be something like
>>>>> so:
>>>>>
>>>>> static irqreturn_t dwc3_foobar_wakeup(int irq, void *_glue)
>>>>> {
>>>>>  struct dwc3_foobar_glue *glue = _glue;
>>>>>  u32 reg;
>>>>>
>>>>>  reg = real(glue->base, OFFSET);
>>>>>  if (reg & CONNECT)
>>>>>  pm_runtime_resume(>dwc3);
>>>>>
>>>>>  return IRQ_HANDLED;
>>>>> }
>>>>>
>>>>> then dwc3's ->runtime_resume() should check if the event is supposed to
>>>>> be handled by host or peripheral by checking which mode it was before
>>>>> suspend and making the assumption that we don't change modes while
>>>>> suspended. Something like:
>>>>>
>>>>> static int dwc3_runtime_resume(struct device *dev)
>>>>> {
>>>>>  struct dwc3 *dwc = dev_get_drvdata(dev);
>>>>>
>>>>>  [...]
>>>>>
>>>>>  if (dwc->is_host)
>>>>

Re: [PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM

[Baolin Wang]

Hi,

On 22 March 2017 at 17:00, Felipe Balbi <ba...@kernel.org> wrote:
>
> Hi,
>
> Baolin Wang <baolin.w...@linaro.org> writes:
>>>>>> I don't yet understand why we can't just keep runtime pm disabled as a
>>>>>> default for xhci platform devices.
>>>>>> It could be enabled by whatever creates the platform device by setting 
>>>>>> some
>>>>>> device property
>>>>>> (or equivalent), which would be checked in xhci_plat_probe() before 
>>>>>> enabling
>>>>>> runtime pm. It
>>>>>> could then optionally be set in sysfs via power/control entry.
>>>>>
>>>>> I think runtime pm is not one hardware property, is it suitable if we
>>>>> introduce one device property to enable/disable runtime pm?
>>>>
>>>> As I said, runtime pm is not one hardware property, I think it is not
>>>> suitable if we introduce one device property to enable/disable runtime
>>>> pm.
>>>
>>> we already this functionality exposed on sysfs.
>>
>> From my understanding, Mathias suggested me to add one device property
>> (name like "usb-host-runtimePM") by platform_device_add_properties()
>> to enable/disable runtime PM when creating platform device, like
>> usb3_lpm_capable:
>>
>> if (dwc->usb3_lpm_capable)
>>   props[prop_idx++].name = "usb3-lpm-capable";
>>
>> ret = platform_device_add_properties(xhci, props);
>> if (ret) {
>>   dev_err(dwc->dev, "failed to add properties to xHCI\n");
>>   goto err1;
>> }
>>
>> What I think It is not suitable to introduce one device property like
>> above to enable/disable runtime PM, it is not one hardware attribute.
>
> yeah, that's silly. We already have means for doing that:
>
> my_probe()
> {
> [...]
>
> pm_runtime_enable(dev);
> pm_runtime_forbid(dev);

That's same with getting the usage counter.

>
> [...]
>
> return 0;
> }
>
>>>> Secondly, we only can resume the xhci platform device by getting the
>>>> xhci usage counter from gadget driver, since the cable plug in/out
>>>> events only can be notified to glue layer of gadget driver(like dwc3
>>>> glue layer). That means if we want to suspend xhci platform device, we
>>>
>>> this is a problem with the glue layer, IMO. It should be something like
>>> so:
>>>
>>> static irqreturn_t dwc3_foobar_wakeup(int irq, void *_glue)
>>> {
>>> struct dwc3_foobar_glue *glue = _glue;
>>> u32 reg;
>>>
>>> reg = real(glue->base, OFFSET);
>>> if (reg & CONNECT)
>>> pm_runtime_resume(>dwc3);
>>>
>>> return IRQ_HANDLED;
>>> }
>>>
>>> then dwc3's ->runtime_resume() should check if the event is supposed to
>>> be handled by host or peripheral by checking which mode it was before
>>> suspend and making the assumption that we don't change modes while
>>> suspended. Something like:
>>>
>>> static int dwc3_runtime_resume(struct device *dev)
>>> {
>>> struct dwc3 *dwc = dev_get_drvdata(dev);
>>>
>>> [...]
>>>
>>> if (dwc->is_host)
>>> pm_runtime_resume(dwc->xhci.dev);
>>>
>>> [...]
>>>
>>> return 0;
>>> }
>>
>> Yeah, if we don't need to get xhci usage counter in xhci_plat_probe()
>> to avoid affecting other controller's runtime PM, we can do like this
>> and do not need to get/put counter.
>
> why do you need to get xhci's usage counter in xhci_plat_probe() ?
>
> And why would one xhci affect the other? They are different struct
> device instances and, thus, have different pm usage counter. How would
> one xhci's pm_runtime affect another?

What I mean is if another USB controller's driver did not implement
runtime pm callbacks but system enables CONFIG_PM, that will make xhci
device auto-suspended when after probing xhci-plat if we did not get
xhci device usage counter, but gadget driver can not resume xhci
without implementing runtime PM callbacks.

If we want to implement xhci-plat runtime resume/suspend without
getting usage counter, we should assume every driver using xhci-plat
should implement their runtime PM callbacks. Is this right?

>
> PM runtime is not per driver, it's per device.

Correct.

-- 
Baolin.wang
Best Regards
--
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: [kbuild-all] [PATCH 1/2] usb: phy: Introduce one extcon device into usb phy

[Baolin Wang]

Hi,

On 22 March 2017 at 14:32, Ye Xiaolong <xiaolong...@intel.com> wrote:
> On 03/20, Baolin Wang wrote:
>>Hi,
>>
>>
>>On 19 March 2017 at 19:42, kbuild test robot <l...@intel.com> wrote:
>>> Hi Baolin,
>>>
>>> [auto build test ERROR on balbi-usb/next]
>>> [also build test ERROR on v4.11-rc2 next-20170310]
>>> [if your patch is applied to the wrong git tree, please drop us a note to 
>>> help improve the system]
>>>
>>> url:
>>> https://github.com/0day-ci/linux/commits/Baolin-Wang/usb-phy-Introduce-one-extcon-device-into-usb-phy/20170319-175509
>>> base:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
>>> config: i386-randconfig-i1-201712 (attached as .config)
>>> compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
>>> reproduce:
>>> # save the attached .config to linux build tree
>>> make ARCH=i386
>>>
>>> All errors (new ones prefixed by >>):
>>>
>>>drivers/built-in.o: In function `usb_add_extcon':
>>>>> phy.c:(.text+0x231580): undefined reference to 
>>>>> `extcon_get_edev_by_phandle'
>>>>> phy.c:(.text+0x2315d0): undefined reference to 
>>>>> `devm_extcon_register_notifier'
>>>phy.c:(.text+0x231629): undefined reference to 
>>> `devm_extcon_register_notifier'
>>
>>I am not sure how the errors were happened, since we will always
>>select EXTCON if we have selected USB_PHY, moreover we have included
>
> Hmm, this was a random config test and CONFIG_EXTCON was set as 'm', maybe you
> need to specify the dependency between CONFIG_USB_PHY and CONFIG_EXTCON ?

OK, I see. Thanks.

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

Re: [PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM

[Baolin Wang]

Hi,

On 21 March 2017 at 16:07, Felipe Balbi <ba...@kernel.org> wrote:
>
> Hi,
>
> Baolin Wang <baolin.w...@linaro.org> writes:
>>>> I don't yet understand why we can't just keep runtime pm disabled as a
>>>> default for xhci platform devices.
>>>> It could be enabled by whatever creates the platform device by setting some
>>>> device property
>>>> (or equivalent), which would be checked in xhci_plat_probe() before 
>>>> enabling
>>>> runtime pm. It
>>>> could then optionally be set in sysfs via power/control entry.
>>>
>>> I think runtime pm is not one hardware property, is it suitable if we
>>> introduce one device property to enable/disable runtime pm?
>>
>> As I said, runtime pm is not one hardware property, I think it is not
>> suitable if we introduce one device property to enable/disable runtime
>> pm.
>
> we already this functionality exposed on sysfs.

>From my understanding, Mathias suggested me to add one device property
(name like "usb-host-runtimePM") by platform_device_add_properties()
to enable/disable runtime PM when creating platform device, like
usb3_lpm_capable:

if (dwc->usb3_lpm_capable)
  props[prop_idx++].name = "usb3-lpm-capable";

ret = platform_device_add_properties(xhci, props);
if (ret) {
  dev_err(dwc->dev, "failed to add properties to xHCI\n");
  goto err1;
}

What I think It is not suitable to introduce one device property like
above to enable/disable runtime PM, it is not one hardware attribute.

>
>> Secondly, we only can resume the xhci platform device by getting the
>> xhci usage counter from gadget driver, since the cable plug in/out
>> events only can be notified to glue layer of gadget driver(like dwc3
>> glue layer). That means if we want to suspend xhci platform device, we
>
> this is a problem with the glue layer, IMO. It should be something like
> so:
>
> static irqreturn_t dwc3_foobar_wakeup(int irq, void *_glue)
> {
> struct dwc3_foobar_glue *glue = _glue;
> u32 reg;
>
> reg = real(glue->base, OFFSET);
> if (reg & CONNECT)
> pm_runtime_resume(>dwc3);
>
> return IRQ_HANDLED;
> }
>
> then dwc3's ->runtime_resume() should check if the event is supposed to
> be handled by host or peripheral by checking which mode it was before
> suspend and making the assumption that we don't change modes while
> suspended. Something like:
>
> static int dwc3_runtime_resume(struct device *dev)
> {
> struct dwc3 *dwc = dev_get_drvdata(dev);
>
> [...]
>
> if (dwc->is_host)
> pm_runtime_resume(dwc->xhci.dev);
>
> [...]
>
> return 0;
> }

Yeah, if we don't need to get xhci usage counter in xhci_plat_probe()
to avoid affecting other controller's runtime PM, we can do like this
and do not need to get/put counter.

>> must put xhci usage counter (so we can not keep their parent-child
>> relationship intact). That is why we need
>> pm_suspend_ignore_children(dev, true).
>
> you really shouldn't need that and it's still unclear why you think you
> do.
>
> --
> balbi



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

Re: [PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM

[Baolin Wang]

Hi Mathias,

On 21 February 2017 at 10:09, Baolin Wang <baolin.w...@linaro.org> wrote:
>>>>>> Do you have any comments about this patch? Thanks.
>>>>>>
>>>>>>>drivers/usb/host/xhci-plat.c |   41
>>>>>>> -
>>>>>>>1 file changed, 36 insertions(+), 5 deletions(-)
>>>>>>>
>>>>>>> diff --git a/drivers/usb/host/xhci-plat.c
>>>>>>> b/drivers/usb/host/xhci-plat.c
>>>>>>> index ed56bf9..5805c6a 100644
>>>>>>> --- a/drivers/usb/host/xhci-plat.c
>>>>>>> +++ b/drivers/usb/host/xhci-plat.c
>>>>>>> @@ -246,6 +246,10 @@ static int xhci_plat_probe(struct platform_device
>>>>>>> *pdev)
>>>>>>>   if (ret)
>>>>>>>   goto dealloc_usb2_hcd;
>>>>>>>
>>>>>>> +   pm_runtime_get_noresume(>dev);
>>>>>>> +   pm_runtime_set_active(>dev);
>>>>>>> +   pm_runtime_enable(>dev);
>>>>>>> +
>>>>>>>   return 0;
>>>>>>>
>>>>>>>
>>>>>
>>>>> To me this looks like we are not really enabling runtime pm for xhci, we
>>>>> increment the
>>>>> usage count in probe, and keep it until remove is called.
>>>>>
>>>>> This would normally prevent parent dwc3 from runtime suspending, but I
>>>>> see
>>>>> that in patch 2/2 adds
>>>>> pm_suspend_ignore_children(dev, true) to dwc3, and, that dwc3 actually
>>>>> controls xhci runtime
>>>>> pm by calling pm_runtime_get/put for xhci in its own dwc3
>>>>> runtime_suspend/resume callbacks.
>>>>>
>>>>> Looks a bit upside down to me, what's the reason for this?
>>>>>
>>>>> what prevents calling pm_runtime_put_* before leaving probe in xhci and
>>>>> let
>>>>> pm code handle
>>>>> the runtime suspend and parent/child relationships?
>>>>
>>>>
>>>> When dwc3 controller is working on host mode, which will create and
>>>> add the USB hcd for host side. Then if we want to suspend dwc3
>>>> controller as host mode, the USB device (bus) of host side will
>>>> runtime suspend automatically if there are no slave attached (by
>>>>
>>>> usb_runtime_suspend()--->usb_suspend_both()--->usb_suspend_interface()--->usb_suspend_device()--->generic_suspend()--->hcd_bus_suspend()--->xhci_bus_suspend()),
>>>> but we should not suspend xHCI device (issuing xhci_suspend()) now,
>>>> since some other  controllers did not implement the runtime PM to
>>>> control xHCI device's runtime state, which will cause other
>>>> controllers can not resume xHCI device (issuing xhci_resume()) if the
>>>> xHCI device suspend automatically by its child device. Thus we should
>>>> get the runtime count for xHCI device in xhci_plat_probe() in case
>>>> xHCI device will also suspend automatically by its child device.
>>>> According to that, for xHCI device's parent: dwc3 device, we should
>>>> put the xHCI device's runtime count to suspend xHCI device manually.
>>>>
>>>
>>> Any more comments?
>>>
>>
>> I think I at least partially understand your point. You don't want to enable
>> runtime suspend for all xhci platform devices by default, but only for the
>> ones
>> that are part of dwc3.
>>
>> The implementation you suggest is that xhci platform driver always increase
>> the xhci platform
>> device usage counter during probe with pm_runtime_get_noresume(), and never
>> decrement it,
>> preventing xhci platform devices from runtime suspending by themselves.
>>
>> You then control xhci runtime suspend from dwc3 driver runtime suspend,
>> allowing
>> xhci platfrom controller to runtime suspend only when dwc3 runtime suspends
>> by decrementing xhci
>> platform device usage in dwc3 runtime suspend callback.
>> As xhci is a child of dwc3 in this case,  dwc3 would never runtime suspend
>> as long as xhci is running, so
>> dwc3 needed to be detached from xhci by setting dwc3 to ignore its children
>> to get it to work.
>
> Yes, that's my point.
>
>>
>> I don't yet understand why we can't just keep runtime pm di

Re: [PATCH 1/2] usb: phy: Introduce one extcon device into usb phy

[Baolin Wang]

Hi,


On 19 March 2017 at 19:42, kbuild test robot <l...@intel.com> wrote:
> Hi Baolin,
>
> [auto build test ERROR on balbi-usb/next]
> [also build test ERROR on v4.11-rc2 next-20170310]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Baolin-Wang/usb-phy-Introduce-one-extcon-device-into-usb-phy/20170319-175509
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git next
> config: i386-randconfig-i1-201712 (attached as .config)
> compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
>drivers/built-in.o: In function `usb_add_extcon':
>>> phy.c:(.text+0x231580): undefined reference to `extcon_get_edev_by_phandle'
>>> phy.c:(.text+0x2315d0): undefined reference to 
>>> `devm_extcon_register_notifier'
>phy.c:(.text+0x231629): undefined reference to 
> `devm_extcon_register_notifier'

I am not sure how the errors were happened, since we will always
select EXTCON if we have selected USB_PHY, moreover we have included
the "linux/extcon.h" in phy.h file.

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

[PATCH 2/2] usb: phy: phy-qcom-8x16-usb: Remove redundant extcon register/unregister

[Baolin Wang]

Since usb phy core has added common code to register or unregister
extcon device, then phy-qcom-8x16-usb driver does not need its own
code to register/unregister extcon device, then remove them.

Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
 drivers/usb/phy/phy-qcom-8x16-usb.c |   20 +---
 1 file changed, 5 insertions(+), 15 deletions(-)

diff --git a/drivers/usb/phy/phy-qcom-8x16-usb.c 
b/drivers/usb/phy/phy-qcom-8x16-usb.c
index fdf6863..b6a83a5 100644
--- a/drivers/usb/phy/phy-qcom-8x16-usb.c
+++ b/drivers/usb/phy/phy-qcom-8x16-usb.c
@@ -69,9 +69,6 @@ struct phy_8x16 {
 
struct reset_control*phy_reset;
 
-   struct extcon_dev   *vbus_edev;
-   struct notifier_block   vbus_notify;
-
struct gpio_desc*switch_gpio;
struct notifier_block   reboot_notify;
 };
@@ -131,7 +128,8 @@ static int phy_8x16_vbus_off(struct phy_8x16 *qphy)
 static int phy_8x16_vbus_notify(struct notifier_block *nb, unsigned long event,
void *ptr)
 {
-   struct phy_8x16 *qphy = container_of(nb, struct phy_8x16, vbus_notify);
+   struct usb_phy *usb_phy = container_of(nb, struct usb_phy, vbus_nb);
+   struct phy_8x16 *qphy = container_of(usb_phy, struct phy_8x16, phy);
 
if (event)
phy_8x16_vbus_on(qphy);
@@ -187,7 +185,7 @@ static int phy_8x16_init(struct usb_phy *phy)
val = ULPI_PWR_OTG_COMP_DISABLE;
usb_phy_io_write(phy, val, ULPI_SET(ULPI_PWR_CLK_MNG_REG));
 
-   state = extcon_get_state(qphy->vbus_edev, EXTCON_USB);
+   state = extcon_get_state(qphy->phy.edev, EXTCON_USB);
if (state)
phy_8x16_vbus_on(qphy);
else
@@ -289,15 +287,13 @@ static int phy_8x16_probe(struct platform_device *pdev)
phy->io_priv= qphy->regs + HSPHY_ULPI_VIEWPORT;
phy->io_ops = _viewport_access_ops;
phy->type   = USB_PHY_TYPE_USB2;
+   phy->vbus_nb.notifier_call = phy_8x16_vbus_notify;
+   phy->id_nb.notifier_call = NULL;
 
ret = phy_8x16_read_devicetree(qphy);
if (ret < 0)
return ret;
 
-   qphy->vbus_edev = extcon_get_edev_by_phandle(phy->dev, 0);
-   if (IS_ERR(qphy->vbus_edev))
-   return PTR_ERR(qphy->vbus_edev);
-
ret = clk_set_rate(qphy->core_clk, INT_MAX);
if (ret < 0)
dev_dbg(phy->dev, "Can't boost core clock\n");
@@ -315,12 +311,6 @@ static int phy_8x16_probe(struct platform_device *pdev)
if (WARN_ON(ret))
goto off_clks;
 
-   qphy->vbus_notify.notifier_call = phy_8x16_vbus_notify;
-   ret = devm_extcon_register_notifier(>dev, qphy->vbus_edev,
-   EXTCON_USB, >vbus_notify);
-   if (ret < 0)
-   goto off_power;
-
ret = usb_add_phy_dev(>phy);
if (ret)
goto off_power;
-- 
1.7.9.5

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

[PATCH 1/2] usb: phy: Introduce one extcon device into usb phy

[Baolin Wang]

Usually usb phy need register one extcon device to get the connection
notifications. It will remove some duplicate code if the extcon device
is registered using common code instead of each phy driver having its
own related extcon APIs. So we add one pointer of extcon device into
usb phy structure, and some other helper functions to register extcon.

Suggested-by: NeilBrown <ne...@suse.com>
Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
---
 drivers/usb/phy/Kconfig |   17 ++---
 drivers/usb/phy/phy.c   |   44 
 include/linux/usb/phy.h |6 ++
 3 files changed, 64 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index 61cef75..39fd6e7 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -13,6 +13,7 @@ config AB8500_USB
tristate "AB8500 USB Transceiver Driver"
depends on AB8500_CORE
select USB_PHY
+   select EXTCON
help
  Enable this to support the USB OTG transceiver in AB8500 chip.
  This transceiver supports high and full speed devices plus,
@@ -23,6 +24,7 @@ config FSL_USB2_OTG
depends on USB_EHCI_FSL && USB_FSL_USB2 && USB_OTG_FSM && PM
depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, this can't be 
'y'
select USB_PHY
+   select EXTCON
help
  Enable this to support Freescale USB OTG transceiver.
 
@@ -32,6 +34,7 @@ config ISP1301_OMAP
depends on USB
depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, this can't be 
'y'
select USB_PHY
+   select EXTCON
help
  If you say yes here you get support for the Philips ISP1301
  USB-On-The-Go transceiver working with the OMAP OTG controller.
@@ -55,6 +58,7 @@ config NOP_USB_XCEIV
tristate "NOP USB Transceiver Driver"
depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, NOP can't be 
built-in
select USB_PHY
+   select EXTCON
help
  This driver is to be used by all the usb transceiver which are either
  built-in with usb ip or which are autonomous and doesn't require any
@@ -70,6 +74,7 @@ config AM335X_PHY_USB
select USB_PHY
select AM335X_CONTROL_USB
select USB_COMMON
+   select EXTCON
help
  This driver provides PHY support for that phy which part for the
  AM335x SoC.
@@ -98,6 +103,7 @@ config USB_GPIO_VBUS
depends on GPIOLIB || COMPILE_TEST
depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, this can't be 
'y'
select USB_PHY
+   select EXTCON
help
  Provides simple GPIO VBUS sensing for controllers with an
  internal transceiver via the usb_phy interface, and
@@ -116,9 +122,10 @@ config OMAP_OTG
 
 config TAHVO_USB
tristate "Tahvo USB transceiver driver"
-   depends on MFD_RETU && EXTCON
+   depends on MFD_RETU
depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, this can't be 
'y'
select USB_PHY
+   select EXTCON
help
  Enable this to support USB transceiver on Tahvo. This is used
  at least on Nokia 770.
@@ -135,6 +142,7 @@ config USB_ISP1301
depends on USB || USB_GADGET
depends on I2C
select USB_PHY
+   select EXTCON
help
  Say Y here to add support for the NXP ISP1301 USB transceiver driver.
  This chip is typically used as USB transceiver for USB host, gadget
@@ -148,8 +156,8 @@ config USB_MSM_OTG
depends on (USB || USB_GADGET) && (ARCH_QCOM || COMPILE_TEST)
depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, this can't be 
'y'
depends on RESET_CONTROLLER
-   depends on EXTCON
select USB_PHY
+   select EXTCON
help
  Enable this to support the USB OTG transceiver on Qualcomm chips. It
  handles PHY initialization, clock management, and workarounds
@@ -162,9 +170,10 @@ config USB_MSM_OTG
 config USB_QCOM_8X16_PHY
tristate "Qualcomm APQ8016/MSM8916 on-chip USB PHY controller support"
depends on ARCH_QCOM || COMPILE_TEST
-   depends on RESET_CONTROLLER && EXTCON
+   depends on RESET_CONTROLLER
select USB_PHY
select USB_ULPI_VIEWPORT
+   select EXTCON
help
  Enable this to support the USB transceiver on Qualcomm 8x16 chipsets.
  It handles PHY initialization, clock management, power management,
@@ -178,6 +187,7 @@ config USB_MV_OTG
depends on USB_EHCI_MV && USB_MV_UDC && PM && USB_OTG
depends on USB_GADGET || !USB_GADGET # if USB_GADGET=m, this can't be 
'y'
select USB_PHY
+   select EXTCON
help
  Say Y here if you want to build Marvell USB OTG transciever
  driver in kernel (including PXA and MMP se

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

[Baolin Wang]

Hi,

On 14 March 2017 at 17:57, Lee Jones <lee.jo...@linaro.org> wrote:
> On Mon, 20 Feb 2017, Baolin Wang wrote:
>
> [...]
>
>>  drivers/power/supply/wm831x_power.c |   63 +++
>>  drivers/usb/gadget/Kconfig  |8 +
>>  drivers/usb/gadget/udc/Makefile |1 +
>>  drivers/usb/gadget/udc/charger.c|  865 
>> +++
>>  drivers/usb/gadget/udc/core.c   |   19 +-
>>  include/linux/usb/charger.h |  176 +++
>>  include/linux/usb/gadget.h  |3 +
>>  include/uapi/linux/usb/charger.h|   31 ++
>>  8 files changed, 1165 insertions(+), 1 deletion(-)
>>  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
>
> Why have you sent this set to me?

Since you have one ack on patch 4, I think I need CC you. But If you
are not interested in this patchset, I will not CC you next time.
Sorry.

[PATCH v19 4/4] power: wm831x_power: Support USB charger current limit
management

Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.

Signed-off-by: Mark Brown <broo...@kernel.org>
Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
Acked-by: Lee Jones <lee.jo...@linaro.org>
Acked-by: Charles Keepax <ckee...@opensource.wolfsonmicro.com>
Acked-by: Peter Chen <peter.c...@freescale.com>
Acked-by: Sebastian Reichel <s...@kernel.org>
...

-- 
Baolin.wang
Best Regards
--
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 v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

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

That's right, I am creating patches for adding extcon_dev in
phy/usb_phy. Thanks.

-- 
Baolin.wang
Best Regards
--
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 v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

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

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

[Baolin Wang]

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

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

[Baolin Wang]

On 10 March 2017 at 14:30, Jun Li  wrote:
>> >> >
>> >> > Will generic phy need add extcon as well?
>> >>
>> >> Yes, will add a 'struct extcon_dev*' in 'struct usb_phy', which will
>> >> be common code.
>> >>
>> >
>> > I mean the common code need add 'struct extcon_dev' into both 'struct
>> > phy' and 'struct usb_phy', right? as some/new usb phy use that generic phy
>> driver.
>>
>> Ah, you remind me. Seems we need also add one 'struct extcon_dev' into
>> 'struct phy'.
>>
>> >> >
>> >> >> >
>> >> >> >> Secondly, I also agreed with Peter's comments: Not only USB PHY
>> >> >> >> to register an extcon, but also for the drivers which can
>> >> >> >> detect USB charger type, it may be USB controller driver, USB
>> >> >> >> type-c driver, pmic driver, and these drivers may not have an
>> >> >> >> extcon device since the internal part can finish the vbus detect.
>> >> >> >
>> >> >> > Whichever part can detect vbus, the driver for that part must be
>> >> >> > able to find the extcon and trigger a notification.
>> >> >> > Maybe one part can detect VBUS, another can measure the
>> >> >> > resistance on ID and a third can work through the state machine
>> >> >> > to determine if D+ and D- are shorted together.
>> >> >> > Somehow these three need to work together to determine what is
>> >> >> plugged
>> >> >> > in to the external connection port.  Somewhere there much an
>> 'extcon'
>> >> >> > device which represents that port and which the three devices
>> >> >> > can find and can interact with.
>> >> >> > I think it makes sense for the usb_phy to be the connection point.
>> >> >> > Each of the devices can get to the phy, and the phy can get to
>> >> >> > the
>> >> extcon.
>> >> >> > It doesn't matter very much if the usb phy driver creates the
>> >> >> > extcon, or if something else creates the extcon and the phy
>> >> >> > driver performs a lookup to find it (e.g. based on devicetree info).
>> >> >> >
>> >> >> > The point is that there is obviously an external physical
>> >> >> > connection, and so there should be an 'extcon' device that
>> represents it.
>> >> >>
>> >> >> Peter & Jun, is it OK for you every phy has one extcon device to
>> >> >> receive VBUS notification, especially for detecting the charger
>> >> >> type by
>> >> software?
>> >> >>
>> >> >
>> >> > My understanding is phy/usb_phy as the connection point, will send
>> >> > the notification to PMIC driver which actually control the charge
>> >> > current, also this will be done in your common framework, right?
>> >>
>> >> Not in USB charger framework. If we are all agree every usb_phy can
>> >> register one extcon device, can get correct charger type and send out
>> >> correct vbus_draw information, then we don't need USB charger
>> >> framework as Neil suggested. So this will be okay for your case
>> >> (especially for detecting the charger type by software) ?
>> >
>> > In my case, charger detection is done by controller driver and I need
>> > do charger type detection internally, and only pass the current draw
>> > info via phy which will send out, this seems ok for me, but I think it
>> > will be good if you or someone can show us an example user based on the
>> design Neil suggested.
>> > Will you work out that common code if this USB charger framework is not
>> needed?
>>
>> I will add  a 'struct extcon_dev*' in 'struct usb_phy' and struct phy“. 
>> Others
>> are already ready if everyone has no complain about current design, except
>
> Only adding extcon_dev into usb_phy/phy  and all others are ready?
> My understanding you will also do:
> - We need find a central place to send the notification(phy common part).

That will include these implementation when adding extcon_dev.

> - If the extcon_dev is directly added in usb_phy/phy, PMIC needs some API to 
> findup it.

PMIC can find extcon device by phandle.

>
>> my one concern. (I am afraid if it is enough to send out vbus draw
>> information from USB phy driver, for example you will miss super speed
>> (900mA), which need get the speed information from gadget driver.)
>>
>
> Can we handle this in USB(so has super speed information) and just send out
> 900mA directly?

>From Neil's suggestion, we only have one place to send out current
information from usb phy, so I have this concern and doubt if we still
need the USB charger framework.

-- 
Baolin.wang
Best Regards
--
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 v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[Baolin Wang]

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

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

[Baolin Wang]

Hi,

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

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

[Baolin Wang]

On 3 March 2017 at 10:23, NeilBrown <ne...@suse.com> wrote:
> On Mon, Feb 20 2017, Baolin Wang wrote:
>
>> Currently the Linux kernel does not provide any standard integration of this
>> feature that integrates the USB subsystem with the system power regulation
>> provided by PMICs meaning that either vendors must add this in their kernels
>> or USB gadget devices based on Linux (such as mobile phones) may not behave
>> as they should. Thus provide a standard framework for doing this in kernel.
>>
>> Now introduce one user with wm831x_power to support and test the usb charger.
>> Another user introduced to support charger detection by Jun Li:
>> https://www.spinics.net/lists/linux-usb/msg139425.html
>> Moreover there may be other potential users will use it in future.
>>
>> 1. Before v19 patchset we've fixed below issues in extcon subsystem and usb
>> phy driver, now all were merged. (Thanks for Neil's suggestion)
>> (1) Have fixed the inconsistencies with USB connector types in extcon 
>> subsystem
>> by following links:
>> https://lkml.org/lkml/2016/12/21/13
>> https://lkml.org/lkml/2016/12/21/15
>> https://lkml.org/lkml/2016/12/21/79
>> https://lkml.org/lkml/2017/1/3/13
>>
>> (2) Instead of using 'set_power' callback in phy drivers, we will introduce
>> USB charger to set PMIC current drawn from USB configuration, moreover some
>> 'set_power' callbacks did not implement anything to set PMIC current, thus
>> remove them by following links:
>> https://lkml.org/lkml/2017/1/18/436
>> https://lkml.org/lkml/2017/1/18/439
>> https://lkml.org/lkml/2017/1/18/438
>> Now only two phy drivers (phy-isp1301-omap.c and phy-gpio-vbus-usb.c) still
>> used 'set_power' callback to set current, we can remove them in future. (I
>> have no platform with enabling these two phy drivers, so I can not test them
>> if I converted 'set_power' callback to USB charger.)
>>
>> 2. Some issues pointed by Neil Brown were sill kept in this v19 patchset, and
>> I expalined each issue and may be need discuss again:
>> (1) Change all usb phys to register an extcon and to send appropriate 
>> notifications.
>> Firstly, now only 3 USB phy drivers (phy-qcom-8x16-usb.c, phy-omap-otg.c and
>> phy-msm-usb.c) had registered an extcon, mostly did not. I can not change all
>> usb phys to register an extcon, since there are no extcon device to register
>> for these different phy drivers.
>
> You don't have to change every driver.  You just need to make it easy
> and obvious how to change drivers in a consistent coherent way.
> For a start you would add a 'struct extcon_dev' to 'struct usb_phy', and
> possibly add or extend some 'static inline's in linux/usb/phy.h to send
> notification on that extcon (if it is non-NULL).
> e.g. usb_phy_vbus_on() could send an extcon notification.
>
> Then any phy driver which adds support for setting phy->extcon_dev
> appropriately, immediately gets the relevant notifications sent.

OK. We can make these extcon related code into phy common part.

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

>
>>
>> (2) Change the notifier of usb_phy to be used consistently.
>> Now only 3 phy driver

Re: [PATCH] usb: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase

[Baolin Wang]

Hi,

On 28 February 2017 at 06:11, Alan Stern <st...@rowland.harvard.edu> wrote:
> On Tue, 21 Feb 2017, Baolin Wang wrote:
>
>> On 17 February 2017 at 16:04, Felipe Balbi <ba...@kernel.org> wrote:
>> >
>> > Hi,
>> >
>> > Baolin Wang <baolin.w...@linaro.org> writes:
>> >>>> (One possible approach would be to have the setup routine return
>> >>>> different values for explicit and implicit status stages -- for
>> >>>> example, return 1 if it wants to submit an explicit status request.
>> >>>> That wouldn't be very different from the current
>> >>>> USB_GADGET_DELAYED_STATUS approach.)
>> >>>
>> >>> not really, no. The idea was for composite.c and/or functions to support
>> >>> both methods (temporarily) and use "gadget->wants_explicit_stages" to
>> >>> explicitly queue DATA and STATUS. That would mean that f_mass_storage
>> >>> wouldn't have to return DELAYED_STATUS if
>> >>> (gadget->wants_explicit_stages).
>> >>>
>> >>> After all UDCs are converted over and set wants_explicit_stages (which
>> >>> should all be done in a single series), then we get rid of the flag and
>> >>> the older method of DELAYED_STATUS.
>> >>
>> >> (Sorry for late reply due to my holiday)
>> >> I also met the problem pointed by Alan, from my test, I still want to
>> >> need one return value to indicate if it wants to submit an explicit
>> >> status request. Think about the Control-IN with a data stage, we can
>> >> not get the STATUS phase request from usb_ep_queue() call, and we need
>> >
>> > why not? wLength tells you that this is a 3-stage transfer. Gadget
>> > driver should be able to figure out that it needs to usb_ep_queue()
>> > another request for status stage.
>>
>> I tried again, but still can not work. Suppose the no-data control:
>> (1) SET_ADDRESS request: function driver will not queue one request
>> for status phase by usb_ep_queue() call.
>
> Function drivers do not handle Set-Address requests at all.  The UDC
> driver handles these requests without telling the gadget driver about
> them.

Correct. What I mean is it will not queue one request for status phase
by usb_ep_queue() call, UDC driver will do that.

>
>> (2) SET_CONFIGURATION request: function driver will queue one 0-length
>> request for status phase by usb_ep_queue() call, especially for
>> mass_storage driver, it will queue one request  for status phase
>> later.
>>
>> So I am not sure how the Gadget driver can figure out that it needs to
>> usb_ep_queue() another request for status stage when handling the
>> no-data control?
>
> Gadget drivers already queue status-stage requests for no-data
> control-OUT requests.  The difficulty comes when you want to handle an
> IN request or an OUT request with a data stage.
>

I try to explain that explicitly, In dwc3 driver, we can handle the
STATUS phase request in 2 places: (1) in usb_ep_queue(), (2) in
dwc3_ep0_xfernotready()
For no-data control-OUT requests:
(1) SET_ADDRESS request: no request queued for status phase by
usb_ep_queue(), dwc3 driver need handle the STATUS phase request when
one not-ready-event comes in dwc3_ep0_xfernotready() function.
(2) SET_CONFIGURATION request: function driver will queue one 0-length
request for status phase by usb_ep_queue(), but we can handle this
request in usb_ep_queue() or dwc3_ep0_xfernotready(). When the
function driver queued one 0-length request for status phase before
the not-ready-event comes, we need handle this request in
dwc3_ep0_xfernotready() when the not-ready-event comes. When  the
function driver queued one 0-length request for status phase after the
not-ready-event comes, we can handle this request in usb_ep_queue().
So in dwc3_ep0_xfernotready(), we need to check if the request for
status phase has been queued into pending request list, but if the
pending request list is NULL, which means the function driver have not
queued one 0-length request until now (then we can handle it in
usb_ep_queue()), or situation (1) (no request queued for status
phase), then I can not identify this 2 situations to determine where I
can handle the status request. Hope I make it clear.

Your concern about an IN request or an OUT request with a data stage,
I agree with Felipe and we can identify. Thanks.
-- 
Baolin.wang
Best Regards
--
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: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase

[Baolin Wang]

On 17 February 2017 at 16:04, Felipe Balbi <ba...@kernel.org> wrote:
>
> Hi,
>
> Baolin Wang <baolin.w...@linaro.org> writes:
>>>> (One possible approach would be to have the setup routine return
>>>> different values for explicit and implicit status stages -- for
>>>> example, return 1 if it wants to submit an explicit status request.
>>>> That wouldn't be very different from the current
>>>> USB_GADGET_DELAYED_STATUS approach.)
>>>
>>> not really, no. The idea was for composite.c and/or functions to support
>>> both methods (temporarily) and use "gadget->wants_explicit_stages" to
>>> explicitly queue DATA and STATUS. That would mean that f_mass_storage
>>> wouldn't have to return DELAYED_STATUS if
>>> (gadget->wants_explicit_stages).
>>>
>>> After all UDCs are converted over and set wants_explicit_stages (which
>>> should all be done in a single series), then we get rid of the flag and
>>> the older method of DELAYED_STATUS.
>>
>> (Sorry for late reply due to my holiday)
>> I also met the problem pointed by Alan, from my test, I still want to
>> need one return value to indicate if it wants to submit an explicit
>> status request. Think about the Control-IN with a data stage, we can
>> not get the STATUS phase request from usb_ep_queue() call, and we need
>
> why not? wLength tells you that this is a 3-stage transfer. Gadget
> driver should be able to figure out that it needs to usb_ep_queue()
> another request for status stage.

I tried again, but still can not work. Suppose the no-data control:
(1) SET_ADDRESS request: function driver will not queue one request
for status phase by usb_ep_queue() call.
(2) SET_CONFIGURATION request: function driver will queue one 0-length
request for status phase by usb_ep_queue() call, especially for
mass_storage driver, it will queue one request  for status phase
later.

So I am not sure how the Gadget driver can figure out that it needs to
usb_ep_queue() another request for status stage when handling the
no-data control?

>> to handle this STATUS phase request in dwc3_ep0_xfernotready(). But
>> Control-OUT will get one 0-length IN request for the status stage from
>> usb_ep_queue(), so we need one return value from setup routine to
>
> no we don't :-)
>
>> distinguish these in dwc3_ep0_xfernotready(), or we can not handle
>> status request correctly. Maybe I missed something else.
>>>
>>>> On the other hand, I am very doubtful about requiring explicit setup
>>>> requests.
>>>
>>> right, me too ;-)
>>
>> So do you suggest me continue to try to do this? Thanks.
>
> explicit setup? no
> explicit status? yes
>
> If you don't wanna do it, it's fine :-) I'll just add to my TODO
> list. It just depends on how much other tasks you have on your end ;-)
>
> --
> balbi



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

Re: [PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM

[Baolin Wang]

On 20 February 2017 at 23:10, Mathias Nyman
<mathias.ny...@linux.intel.com> wrote:
> On 20.02.2017 04:47, Baolin Wang wrote:
>>
>> Hi Mathias,
>>
>> On 6 February 2017 at 13:26, Baolin Wang <baolin.w...@linaro.org> wrote:
>>>
>>> Hi Mathias,
>>>
>>> On 31 January 2017 at 21:14, Mathias Nyman
>>> <mathias.ny...@linux.intel.com> wrote:
>>>>
>>>> On 16.01.2017 12:56, Baolin Wang wrote:
>>>>>
>>>>>
>>>>> Hi Mathias,
>>>>
>>>>
>>>>
>>>> Hi
>>>>
>>>> Sorry about the long review delay
>>>> CC Alan in case my pm assumptions need to be corrected
>>>>
>>>>
>>>>>
>>>>> On 13 December 2016 at 15:49, Baolin Wang <baolin.w...@linaro.org>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> Enable the xhci plat runtime PM for parent device to suspend/resume
>>>>>> xhci.
>>>>>> Also call pm_runtime_get_noresume() in probe() function in case the
>>>>>> parent
>>>>>> device doesn't call suspend/resume callback by runtime PM now.
>>>>>>
>>>>>> Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
>>>>>> ---
>>>>>> Changes since v4:
>>>>>>- No updates.
>>>>>>
>>>>>> Changes since v3:
>>>>>>- Fix kbuild error.
>>>>>>
>>>>>> Changes since v2:
>>>>>>- Add pm_runtime_get_noresume() in probe() function.
>>>>>>- Add pm_runtime_set_suspended()/pm_runtime_put_noidle() in
>>>>>> remove()
>>>>>> function.
>>>>>>
>>>>>> Changes since v1:
>>>>>>- No updates.
>>>>>> ---
>>>>>
>>>>>
>>>>>
>>>>> Do you have any comments about this patch? Thanks.
>>>>>
>>>>>>drivers/usb/host/xhci-plat.c |   41
>>>>>> -
>>>>>>1 file changed, 36 insertions(+), 5 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/usb/host/xhci-plat.c
>>>>>> b/drivers/usb/host/xhci-plat.c
>>>>>> index ed56bf9..5805c6a 100644
>>>>>> --- a/drivers/usb/host/xhci-plat.c
>>>>>> +++ b/drivers/usb/host/xhci-plat.c
>>>>>> @@ -246,6 +246,10 @@ static int xhci_plat_probe(struct platform_device
>>>>>> *pdev)
>>>>>>   if (ret)
>>>>>>   goto dealloc_usb2_hcd;
>>>>>>
>>>>>> +   pm_runtime_get_noresume(>dev);
>>>>>> +   pm_runtime_set_active(>dev);
>>>>>> +   pm_runtime_enable(>dev);
>>>>>> +
>>>>>>   return 0;
>>>>>>
>>>>>>
>>>>
>>>> To me this looks like we are not really enabling runtime pm for xhci, we
>>>> increment the
>>>> usage count in probe, and keep it until remove is called.
>>>>
>>>> This would normally prevent parent dwc3 from runtime suspending, but I
>>>> see
>>>> that in patch 2/2 adds
>>>> pm_suspend_ignore_children(dev, true) to dwc3, and, that dwc3 actually
>>>> controls xhci runtime
>>>> pm by calling pm_runtime_get/put for xhci in its own dwc3
>>>> runtime_suspend/resume callbacks.
>>>>
>>>> Looks a bit upside down to me, what's the reason for this?
>>>>
>>>> what prevents calling pm_runtime_put_* before leaving probe in xhci and
>>>> let
>>>> pm code handle
>>>> the runtime suspend and parent/child relationships?
>>>
>>>
>>> When dwc3 controller is working on host mode, which will create and
>>> add the USB hcd for host side. Then if we want to suspend dwc3
>>> controller as host mode, the USB device (bus) of host side will
>>> runtime suspend automatically if there are no slave attached (by
>>>
>>> usb_runtime_suspend()--->usb_suspend_both()--->usb_suspend_interface()--->usb_suspend_device()--->generic_suspend()--->hcd_bus_suspend()--->xhci_bus_suspend()),
>>> but we should not suspend xHCI device (issuing xhci_suspend()) now,
>>> since som

Re: [PATCH v19 2/4] usb: gadget: Support for the usb charger framework

[Baolin Wang]

On 20 February 2017 at 18:08, kbuild test robot <l...@intel.com> wrote:
> Hi Baolin,
>
> [auto build test ERROR on v4.9-rc8]
> [cannot apply to balbi-usb/next usb/usb-testing battery/master next-20170220]
> [if your patch is applied to the wrong git tree, please drop us a note to 
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Baolin-Wang/Introduce-usb-charger-framework-to-deal-with-the-usb-gadget-power-negotation/20170220-173051
> config: i386-randconfig-x015-201708 (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
>In file included from drivers/usb/gadget/udc/core.c:28:0:
>include/linux/usb/charger.h: In function 'usb_charger_get_state':
>>> include/linux/usb/charger.h:151:9: error: 'USB_CHARGER_REMOVE' undeclared 
>>> (first use in this function)
>  return USB_CHARGER_REMOVE;

Ah, missed fixing the state name without enable USB charger. Will fix
in next version.

> ^~
>include/linux/usb/charger.h:151:9: note: each undeclared identifier is 
> reported only once for each function it appears in
>
> vim +/USB_CHARGER_REMOVE +151 include/linux/usb/charger.h
>
> 28929615 Baolin Wang 2017-02-20  145return UNKNOWN_TYPE;
> 28929615 Baolin Wang 2017-02-20  146  }
> 28929615 Baolin Wang 2017-02-20  147
> 28929615 Baolin Wang 2017-02-20  148  static inline enum usb_charger_state
> 28929615 Baolin Wang 2017-02-20  149  usb_charger_get_state(struct 
> usb_charger *uchger)
> 28929615 Baolin Wang 2017-02-20  150  {
> 28929615 Baolin Wang 2017-02-20 @151    return USB_CHARGER_REMOVE;
> 28929615 Baolin Wang 2017-02-20  152  }
> 28929615 Baolin Wang 2017-02-20  153
> 28929615 Baolin Wang 2017-02-20  154  static inline int 
> usb_charger_detect_type(struct usb_charger *uchger)
>
> :: The code at line 151 was first introduced by commit
> :: 289296154f05985dedc08273f04d5b738450b3c7 usb: gadget: Introduce the 
> usb charger framework
>
> :: TO: Baolin Wang <baolin.w...@linaro.org>
> :: CC: 0day robot <fengguang...@intel.com>
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation



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

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

[Baolin Wang]

ce v14:
 - Add kernel documentation for struct usb_cahrger.
 - Remove some redundant WARN() functions.

Changes since v13:
 - Remove the charger checking in usb_gadget_vbus_draw() function.
 - Rename some functions in charger.c file.
 - Rebase on git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git 
tags/usb-for-v4.8

Changes since v12:
 - Remove the class and device things.
 - Link usb charger to udc-core.ko.
 - Create one "charger" subdirectory which holds all charger-related attributes.

Changes since v11:
 - Reviewed and tested by Li Jun.

Changes since v10:
 - Introduce usb_charger_get_state() function to check charger state.
 - Remove the mutex lock in usb_charger_set_cur_limit_by_type() function
 in case will be issued in atomic context.

Baolin Wang (4):
  usb: gadget: Introduce the usb charger framework
  usb: gadget: Support for the usb charger framework
  usb: gadget: Integrate with the usb gadget supporting for usb charger
  power: wm831x_power: Support USB charger current limit management

 drivers/power/supply/wm831x_power.c |   63 +++
 drivers/usb/gadget/Kconfig  |8 +
 drivers/usb/gadget/udc/Makefile |1 +
 drivers/usb/gadget/udc/charger.c|  865 +++
 drivers/usb/gadget/udc/core.c   |   19 +-
 include/linux/usb/charger.h |  176 +++
 include/linux/usb/gadget.h  |3 +
 include/uapi/linux/usb/charger.h|   31 ++
 8 files changed, 1165 insertions(+), 1 deletion(-)
 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

-- 
1.7.9.5

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

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

[Baolin Wang]

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 <baolin.w...@linaro.org>
Reviewed-by: Li Jun <jun...@nxp.com>
Tested-by: Li Jun <jun...@nxp.com>
---
 drivers/usb/gadget/udc/core.c |   19 ++-
 include/linux/usb/gadget.h|3 +++
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c
index 9483489..90df022 100644
--- a/drivers/usb/gadget/udc/core.c
+++ b/drivers/usb/gadget/udc/core.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -576,12 +577,17 @@ int usb_gadget_vbus_connect(struct usb_gadget *gadget)
  * reporting how much power the device may consume.  For example, this
  * could affect how quickly batteries are recharged.
  *
+ * It will also notify the USB charger how much power the device may
+ * consume if there is a USB charger linking with the gadget.
+ *
  * Returns zero on success, else negative errno.
  */
 int usb_gadget_vbus_draw(struct usb_gadget *gadget, unsigned mA)
 {
int ret = 0;
 
+   usb_charger_set_cur_limit_by_gadget(gadget, mA);
+
if (!gadget->ops->vbus_draw) {
ret = -EOPNOTSUPP;
goto out;
@@ -963,6 +969,9 @@ static void usb_gadget_state_work(struct work_struct *work)
struct usb_gadget *gadget = work_to_gadget(work);
struct usb_udc *udc = gadget->udc;
 
+   /* when the gadget state is changed, then report to USB charger */
+   usb_charger_plug_by_gadget(gadget, gadget->state);
+
if (udc)
sysfs_notify(>dev.kobj, NULL, "state");
 }
@@ -1132,6 +1141,10 @@ int usb_add_gadget_udc_release(struct device *parent, 
struct usb_gadget *gadget,
if (ret)
goto err4;
 
+   ret = usb_charger_init(gadget);
+   if (ret)
+   goto err5;
+
usb_gadget_set_state(gadget, USB_STATE_NOTATTACHED);
udc->vbus = true;
 
@@ -1143,7 +1156,7 @@ int usb_add_gadget_udc_release(struct device *parent, 
struct usb_gadget *gadget,
if (ret != -EPROBE_DEFER)
list_del(>pending);
if (ret)
-   goto err5;
+   goto err6;
break;
}
}
@@ -1152,6 +1165,9 @@ int usb_add_gadget_udc_release(struct device *parent, 
struct usb_gadget *gadget,
 
return 0;
 
+err6:
+   usb_charger_exit(gadget);
+
 err5:
device_del(>dev);
 
@@ -1263,6 +1279,7 @@ void usb_del_gadget_udc(struct usb_gadget *gadget)
kobject_uevent(>dev.kobj, KOBJ_REMOVE);
flush_work(>work);
device_unregister(>dev);
+   usb_charger_exit(gadget);
device_unregister(>dev);
 }
 EXPORT_SYMBOL_GPL(usb_del_gadget_udc);
diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
index e4516e9..b4d7be2 100644
--- a/include/linux/usb/gadget.h
+++ b/include/linux/usb/gadget.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define UDC_TRACE_STR_MAX  512
 
@@ -328,6 +329,7 @@ struct usb_gadget_ops {
  * @in_epnum: last used in ep number
  * @mA: last set mA value
  * @otg_caps: OTG capabilities of this gadget.
+ * @charger: Negotiate the power with the usb charger.
  * @sg_supported: true if we can handle scatter-gather
  * @is_otg: True if the USB device port uses a Mini-AB jack, so that the
  * gadget driver must provide a USB OTG descriptor.
@@ -387,6 +389,7 @@ struct usb_gadget {
unsignedin_epnum;
unsignedmA;
struct usb_otg_caps *otg_caps;
+   struct usb_charger  *charger;
 
unsignedsg_supported:1;
unsignedis_otg:1;
-- 
1.7.9.5

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

[PATCH v19 4/4] power: wm831x_power: Support USB charger current limit management

[Baolin Wang]

Integrate with the newly added USB charger interface to limit the current
we draw from the USB input based on the input device configuration
identified by the USB stack, allowing us to charge more quickly from high
current inputs without drawing more current than specified from others.

Signed-off-by: Mark Brown <broo...@kernel.org>
Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
Acked-by: Lee Jones <lee.jo...@linaro.org>
Acked-by: Charles Keepax <ckee...@opensource.wolfsonmicro.com>
Acked-by: Peter Chen <peter.c...@freescale.com>
Acked-by: Sebastian Reichel <s...@kernel.org>
---
 drivers/power/supply/wm831x_power.c |   63 +++
 1 file changed, 63 insertions(+)

diff --git a/drivers/power/supply/wm831x_power.c 
b/drivers/power/supply/wm831x_power.c
index 7082301..b5f1652 100644
--- a/drivers/power/supply/wm831x_power.c
+++ b/drivers/power/supply/wm831x_power.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -31,6 +32,8 @@ struct wm831x_power {
char usb_name[20];
char battery_name[20];
bool have_battery;
+   struct usb_charger *usb_charger;
+   struct notifier_block usb_notify;
 };
 
 static int wm831x_power_check_online(struct wm831x *wm831x, int supply,
@@ -125,6 +128,42 @@ static int wm831x_usb_get_prop(struct power_supply *psy,
POWER_SUPPLY_PROP_VOLTAGE_NOW,
 };
 
+/* In milliamps */
+static const unsigned int wm831x_usb_limits[] = {
+   0,
+   2,
+   100,
+   500,
+   900,
+   1500,
+   1800,
+   550,
+};
+
+static int wm831x_usb_limit_change(struct notifier_block *nb,
+  unsigned long limit, void *data)
+{
+   struct wm831x_power *wm831x_power = container_of(nb,
+struct wm831x_power,
+usb_notify);
+
+   /* Find the highest supported limit */
+   best = 0;
+   for (i = 0; i < ARRAY_SIZE(wm831x_usb_limits); i++) {
+   if (limit >= wm831x_usb_limits[i] &&
+   wm831x_usb_limits[best] < wm831x_usb_limits[i])
+   best = i;
+   }
+
+   dev_dbg(wm831x_power->wm831x->dev,
+   "Limiting USB current to %umA", wm831x_usb_limits[best]);
+
+   wm831x_set_bits(wm831x_power->wm831x, WM831X_POWER_STATE,
+   WM831X_USB_ILIM_MASK, best);
+
+   return 0;
+}
+
 /*
  * Battery properties
  */
@@ -607,8 +646,26 @@ static int wm831x_power_probe(struct platform_device *pdev)
}
}
 
+   power->usb_charger = usb_charger_get_instance();
+   if (IS_ERR(power->usb_charger)) {
+   ret = PTR_ERR(power->usb_charger);
+   dev_err(>dev, "Failed to find USB gadget: %d\n", ret);
+   goto err_bat_irq;
+   }
+
+   power->usb_notify.notifier_call = wm831x_usb_limit_change;
+
+   ret = usb_charger_register_notify(power->usb_charger,
+ >usb_notify);
+   if (ret != 0) {
+   dev_err(>dev, "Failed to register notifier: %d\n", ret);
+   goto err_usb_charger;
+   }
+
return ret;
 
+err_usb_charger:
+   /* put_device on charger */
 err_bat_irq:
--i;
for (; i >= 0; i--) {
@@ -637,6 +694,12 @@ static int wm831x_power_remove(struct platform_device 
*pdev)
struct wm831x *wm831x = wm831x_power->wm831x;
int irq, i;
 
+   if (wm831x_power->usb_charger) {
+   usb_charger_unregister_notify(wm831x_power->usb_charger,
+ _power->usb_notify);
+   /* Free charger */
+   }
+
for (i = 0; i < ARRAY_SIZE(wm831x_bat_irqs); i++) {
irq = wm831x_irq(wm831x, 
 platform_get_irq_byname(pdev,
-- 
1.7.9.5

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

[PATCH v19 3/4] usb: gadget: Integrate with the usb gadget supporting for usb charger

[Baolin Wang]

When the usb gadget supporting for usb charger is ready, the usb charger
can implement the usb_charger_plug_by_gadget() function, usb_charger_exit()
function and dev_to_uchger() function by getting 'struct usb_charger' from
'struct gadget'.

Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
Reviewed-by: Li Jun <jun...@nxp.com>
Tested-by: Li Jun <jun...@nxp.com>
---
 drivers/usb/gadget/udc/charger.c |   97 +-
 1 file changed, 96 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/udc/charger.c b/drivers/usb/gadget/udc/charger.c
index 6d62f54..19eb044 100644
--- a/drivers/usb/gadget/udc/charger.c
+++ b/drivers/usb/gadget/udc/charger.c
@@ -38,7 +38,9 @@
 
 static struct usb_charger *dev_to_uchger(struct device *dev)
 {
-   return NULL;
+   struct usb_gadget *gadget = container_of(dev, struct usb_gadget, dev);
+
+   return gadget->charger;
 }
 
 /*
@@ -398,6 +400,18 @@ static int __usb_charger_set_cur_limit_by_type(struct 
usb_charger *uchger,
 int usb_charger_set_cur_limit_by_gadget(struct usb_gadget *gadget,
unsigned int cur_limit)
 {
+   struct usb_charger *uchger = gadget->charger;
+   int ret;
+
+   if (!uchger)
+   return -EINVAL;
+
+   ret = __usb_charger_set_cur_limit_by_type(uchger, uchger->type,
+ cur_limit);
+   if (ret)
+   return ret;
+
+   schedule_work(>work);
return 0;
 }
 EXPORT_SYMBOL_GPL(usb_charger_set_cur_limit_by_gadget);
@@ -622,11 +636,66 @@ static int usb_charger_plug_by_extcon(struct 
notifier_block *nb,
 int usb_charger_plug_by_gadget(struct usb_gadget *gadget,
   unsigned long state)
 {
+   struct usb_charger *uchger = gadget->charger;
+   enum usb_charger_state uchger_state;
+
+   if (WARN(!uchger, "charger can not be NULL"))
+   return -EINVAL;
+
+   /*
+* Report event to power to setting the current limitation
+* for this usb charger when one usb charger state is changed
+* with detecting by usb gadget state.
+*/
+   if (uchger->old_gadget_state != state) {
+   uchger->old_gadget_state = state;
+
+   if (state >= USB_STATE_ATTACHED) {
+   uchger_state = USB_CHARGER_PRESENT;
+   } else if (state == USB_STATE_NOTATTACHED) {
+   mutex_lock(>lock);
+
+   /*
+* Need check the charger type to make sure the usb
+* cable is removed, in case it just changes the usb
+* function with configfs.
+*/
+   if (uchger->type != UNKNOWN_TYPE) {
+   mutex_unlock(>lock);
+   return 0;
+   }
+
+   mutex_unlock(>lock);
+   uchger_state = USB_CHARGER_ABSENT;
+   } else {
+   uchger_state = USB_CHARGER_DEFAULT;
+   }
+
+   usb_charger_notify_state(uchger, uchger_state);
+   }
+
return 0;
 }
 EXPORT_SYMBOL_GPL(usb_charger_plug_by_gadget);
 
 /*
+ * usb_charger_unregister() - Unregister a usb charger.
+ * @uchger - the usb charger to be unregistered.
+ */
+static int usb_charger_unregister(struct usb_charger *uchger)
+{
+   ida_simple_remove(_charger_ida, uchger->id);
+   sysfs_remove_groups(>gadget->dev.kobj, usb_charger_groups);
+   uchger->id = -1;
+
+   mutex_lock(_lock);
+   list_del(>list);
+   mutex_unlock(_lock);
+
+   return 0;
+}
+
+/*
  * usb_charger_register() - Register a new usb charger.
  * @uchger - the new usb charger instance.
  */
@@ -725,6 +794,7 @@ int usb_charger_init(struct usb_gadget *ugadget)
}
 
uchger->gadget = ugadget;
+   ugadget->charger = uchger;
uchger->old_gadget_state = USB_STATE_NOTATTACHED;
 
/* Register a new usb charger */
@@ -762,6 +832,31 @@ int usb_charger_init(struct usb_gadget *ugadget)
 
 int usb_charger_exit(struct usb_gadget *ugadget)
 {
+   struct usb_charger *uchger = ugadget->charger;
+
+   if (!uchger)
+   return -EINVAL;
+
+   usb_charger_unregister(uchger);
+   ugadget->charger = NULL;
+
+   extcon_unregister_notifier(uchger->extcon_dev,
+  EXTCON_USB,
+  >extcon_nb.nb);
+   extcon_unregister_notifier(uchger->extcon_dev,
+  EXTCON_CHG_USB_SDP,
+  >extcon_type_nb.nb);
+   extcon_unregister_notifier(uchger->extcon_dev,
+  EXTCON_CHG_USB_CDP,
+  >extcon_type_nb.n

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

[Baolin Wang]

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 <baolin.w...@linaro.org>
Reviewed-by: Li Jun <jun...@nxp.com>
Tested-by: Li Jun <jun...@nxp.com>
---
 drivers/usb/gadget/Kconfig   |8 +
 drivers/usb/gadget/udc/Makefile  |1 +
 drivers/usb/gadget/udc/charger.c |  770 ++
 include/linux/usb/charger.h  |  176 +
 include/uapi/linux/usb/charger.h |   31 ++
 5 files changed, 986 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

diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
index 8ad2032..60d2f29 100644
--- a/drivers/usb/gadget/Kconfig
+++ b/drivers/usb/gadget/Kconfig
@@ -134,6 +134,14 @@ config U_SERIAL_CONSOLE
help
   It supports the serial gadget can be used as a console.
 
+config USB_CHARGER
+   bool "USB charger support"
+   select EXTCON
+   help
+ The usb charger driver based on the usb gadget that makes an
+ enhancement to a power driver which can set the current limitation
+ when the usb charger is added or removed.
+
 source "drivers/usb/gadget/udc/Kconfig"
 
 #
diff --git a/drivers/usb/gadget/udc/Makefile b/drivers/usb/gadget/udc/Makefile
index 98e74ed..ede2351 100644
--- a/drivers/usb/gadget/udc/Makefile
+++ b/drivers/usb/gadget/udc/Makefile
@@ -2,6 +2,7 @@
 CFLAGS_trace.o := -I$(src)
 
 udc-core-y := core.o trace.o
+udc-core-$(CONFIG_USB_CHARGER) += charger.o
 
 #
 # USB peripheral controller drivers
diff --git a/drivers/usb/gadget/udc/charger.c b/drivers/usb/gadget/udc/charger.c
new file mode 100644
index 000..6d62f54
--- /dev/null
+++ b/drivers/usb/gadget/udc/charger.c
@@ -0,0 +1,770 @@
+/*
+ * charger.c -- USB charger driver
+ *
+ * Copyright (C) 2016 Linaro Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Default current range by charger type. */
+#define DEFAULT_SDP_CUR_MIN2
+#define DEFAULT_SDP_CUR_MAX500
+#define DEFAULT_SDP_CUR_MIN_SS 150
+#define DEFAULT_SDP_CUR_MAX_SS 900
+#define DEFAULT_DCP_CUR_MIN500
+#define DEFAULT_DCP_CUR_MAX5000
+#define DEFAULT_CDP_CUR_MIN1500
+#define DEFAULT_CDP_CUR_MAX5000
+#define DEFAULT_ACA_CUR_MIN1500
+#define DEFAULT_ACA_CUR_MAX5000
+
+static DEFINE_IDA(usb_charger_ida);
+static LIST_HEAD(charger_list);
+static DEFINE_MUTEX(charger_lock);
+
+static struct usb_charger *dev_to_uchger(struct device *dev)
+{
+   return NULL;
+}
+
+/*
+ * charger_current_show() - Show the charger current.
+ */
+static ssize_t charger_current_show(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+   unsigned int min, max;
+
+   usb_charger_get_current(uchger, , );
+   return sprintf(buf, "%u-%u\n", min, max);
+}
+static DEVICE_ATTR_RO(charger_current);
+
+/*
+ * charger_type_show() - Show the charger type.
+ *
+ * It can be SDP/DCP/CDP/ACA type, else for unknown type.
+ */
+static ssize_t charger_type_show(struct device *dev,
+struct device_attribute *attr,
+char *buf)
+{
+   struct usb_charger *uchger = dev_to_uchger(dev);
+   enum usb_charger_type type = usb_charger_get_type(uchger);
+   int cnt;
+
+   switch (type) {
+   case SDP_TYPE:
+   cnt = sprintf(buf, "%s\n", "SDP");
+   break;
+ 

Re: [PATCH RESEND v7 1/1] usb: xhci: plat: Enable async suspend/resume

[Baolin Wang]

On 10 February 2017 at 22:56, Robert Foss <robert.f...@collabora.com> wrote:
> From: Andrew Bresticker <abres...@chromium.org>
>
> USB host controllers can take a significant amount of time to suspend
> and resume, adding several hundred miliseconds to the kernel resume
> time. Since the XHCI controller has no outside dependencies (other than
> clocks, which are suspended late/resumed early), allow it to suspend and
> resume asynchronously.
>
> Signed-off-by: Andrew Bresticker <abres...@chromium.org>
> Tested-by: Andrew Bresticker <abres...@chromium.org>
> Tested-by: Robert Foss <robert.f...@collabora.com>
> Signed-off-by: Robert Foss <robert.f...@collabora.com>
> ---
>  drivers/usb/host/xhci-plat.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 3cf8e120c620..4d6741a0d8f8 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -257,6 +257,7 @@ static int xhci_plat_probe(struct platform_device *pdev)
>
> pm_runtime_set_active(>dev);
> pm_runtime_enable(>dev);
> +   device_enable_async_suspend(>dev);
>
> return 0;
>
> --
> 2.11.0.453.g787f75f05
>

Reviewed-by: Baolin Wang <baolin.w...@linaro.org>

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

Re: [PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM

[Baolin Wang]

Hi Mathias,

On 6 February 2017 at 13:26, Baolin Wang <baolin.w...@linaro.org> wrote:
> Hi Mathias,
>
> On 31 January 2017 at 21:14, Mathias Nyman
> <mathias.ny...@linux.intel.com> wrote:
>> On 16.01.2017 12:56, Baolin Wang wrote:
>>>
>>> Hi Mathias,
>>
>>
>> Hi
>>
>> Sorry about the long review delay
>> CC Alan in case my pm assumptions need to be corrected
>>
>>
>>>
>>> On 13 December 2016 at 15:49, Baolin Wang <baolin.w...@linaro.org> wrote:
>>>>
>>>> Enable the xhci plat runtime PM for parent device to suspend/resume xhci.
>>>> Also call pm_runtime_get_noresume() in probe() function in case the
>>>> parent
>>>> device doesn't call suspend/resume callback by runtime PM now.
>>>>
>>>> Signed-off-by: Baolin Wang <baolin.w...@linaro.org>
>>>> ---
>>>> Changes since v4:
>>>>   - No updates.
>>>>
>>>> Changes since v3:
>>>>   - Fix kbuild error.
>>>>
>>>> Changes since v2:
>>>>   - Add pm_runtime_get_noresume() in probe() function.
>>>>   - Add pm_runtime_set_suspended()/pm_runtime_put_noidle() in remove()
>>>> function.
>>>>
>>>> Changes since v1:
>>>>   - No updates.
>>>> ---
>>>
>>>
>>> Do you have any comments about this patch? Thanks.
>>>
>>>>   drivers/usb/host/xhci-plat.c |   41
>>>> -
>>>>   1 file changed, 36 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
>>>> index ed56bf9..5805c6a 100644
>>>> --- a/drivers/usb/host/xhci-plat.c
>>>> +++ b/drivers/usb/host/xhci-plat.c
>>>> @@ -246,6 +246,10 @@ static int xhci_plat_probe(struct platform_device
>>>> *pdev)
>>>>  if (ret)
>>>>  goto dealloc_usb2_hcd;
>>>>
>>>> +   pm_runtime_get_noresume(>dev);
>>>> +   pm_runtime_set_active(>dev);
>>>> +   pm_runtime_enable(>dev);
>>>> +
>>>>  return 0;
>>>>
>>>>
>>
>> To me this looks like we are not really enabling runtime pm for xhci, we
>> increment the
>> usage count in probe, and keep it until remove is called.
>>
>> This would normally prevent parent dwc3 from runtime suspending, but I see
>> that in patch 2/2 adds
>> pm_suspend_ignore_children(dev, true) to dwc3, and, that dwc3 actually
>> controls xhci runtime
>> pm by calling pm_runtime_get/put for xhci in its own dwc3
>> runtime_suspend/resume callbacks.
>>
>> Looks a bit upside down to me, what's the reason for this?
>>
>> what prevents calling pm_runtime_put_* before leaving probe in xhci and let
>> pm code handle
>> the runtime suspend and parent/child relationships?
>
> When dwc3 controller is working on host mode, which will create and
> add the USB hcd for host side. Then if we want to suspend dwc3
> controller as host mode, the USB device (bus) of host side will
> runtime suspend automatically if there are no slave attached (by
> usb_runtime_suspend()--->usb_suspend_both()--->usb_suspend_interface()--->usb_suspend_device()--->generic_suspend()--->hcd_bus_suspend()--->xhci_bus_suspend()),
> but we should not suspend xHCI device (issuing xhci_suspend()) now,
> since some other  controllers did not implement the runtime PM to
> control xHCI device's runtime state, which will cause other
> controllers can not resume xHCI device (issuing xhci_resume()) if the
> xHCI device suspend automatically by its child device. Thus we should
> get the runtime count for xHCI device in xhci_plat_probe() in case
> xHCI device will also suspend automatically by its child device.
> According to that, for xHCI device's parent: dwc3 device, we should
> put the xHCI device's runtime count to suspend xHCI device manually.
>

Any more comments?

-- 
Baolin.wang
Best Regards
--
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: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase

[Baolin Wang]

On 17 February 2017 at 16:04, Felipe Balbi <ba...@kernel.org> wrote:
>
> Hi,
>
> Baolin Wang <baolin.w...@linaro.org> writes:
>>>> (One possible approach would be to have the setup routine return
>>>> different values for explicit and implicit status stages -- for
>>>> example, return 1 if it wants to submit an explicit status request.
>>>> That wouldn't be very different from the current
>>>> USB_GADGET_DELAYED_STATUS approach.)
>>>
>>> not really, no. The idea was for composite.c and/or functions to support
>>> both methods (temporarily) and use "gadget->wants_explicit_stages" to
>>> explicitly queue DATA and STATUS. That would mean that f_mass_storage
>>> wouldn't have to return DELAYED_STATUS if
>>> (gadget->wants_explicit_stages).
>>>
>>> After all UDCs are converted over and set wants_explicit_stages (which
>>> should all be done in a single series), then we get rid of the flag and
>>> the older method of DELAYED_STATUS.
>>
>> (Sorry for late reply due to my holiday)
>> I also met the problem pointed by Alan, from my test, I still want to
>> need one return value to indicate if it wants to submit an explicit
>> status request. Think about the Control-IN with a data stage, we can
>> not get the STATUS phase request from usb_ep_queue() call, and we need
>
> why not? wLength tells you that this is a 3-stage transfer. Gadget
> driver should be able to figure out that it needs to usb_ep_queue()
> another request for status stage.
>
>> to handle this STATUS phase request in dwc3_ep0_xfernotready(). But
>> Control-OUT will get one 0-length IN request for the status stage from
>> usb_ep_queue(), so we need one return value from setup routine to
>
> no we don't :-)
>
>> distinguish these in dwc3_ep0_xfernotready(), or we can not handle
>> status request correctly. Maybe I missed something else.
>>>
>>>> On the other hand, I am very doubtful about requiring explicit setup
>>>> requests.
>>>
>>> right, me too ;-)
>>
>> So do you suggest me continue to try to do this? Thanks.
>
> explicit setup? no
> explicit status? yes
>
> If you don't wanna do it, it's fine :-) I'll just add to my TODO
> list. It just depends on how much other tasks you have on your end ;-)

OK, I will take some time to check and test again. It will be better
if I send out one RFC patch to review.

-- 
Baolin.wang
Best Regards
--
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: dwc3: ep0: Fix the possible missed request for handling delay STATUS phase

[Baolin Wang]

On 23 January 2017 at 19:57, Felipe Balbi <ba...@kernel.org> wrote:
>
> Hi,
>
> Alan Stern <st...@rowland.harvard.edu> writes:
>> On Mon, 16 Jan 2017, Felipe Balbi wrote:
>>
>>> > The gadget driver never calls usb_ep_queue in order to receive the next
>>> > SETUP packet; the UDC driver takes care of SETUP handling
>>> > automatically.
>>>
>>> yeah, that's another thing I'd like to change. Currently, we have no
>>> means to either try to implement device-initiated LPM without adding a
>>> ton of hacks to UDC drivers. If we require upper layers (composite.c,
>>> most of the time) to usb_ep_queue() separate requests for all 3 phases
>>> of a ctrl transfer, we can actually rely on the fact that a new SETUP
>>> phase hasn't been queued yet to trigger U3 entry.
>>
>> I haven't given any thought to LPM.
>
> okay
>
>> However, requiring gadget drivers to request SETUP packets seems rather
>> questionable.  It flies against the USB spec, which requires
>
> right, maybe SETUP is a bit of an overkill. DATA and STATUS, however,
> should be doable.
>
>> peripherals to accept SETUP packets at any time -- a device is not
>> allowed to NAK or STALL a SETUP packet (see 8.4.6.4 in the USB-2 spec).
>> In fact, the hardware in UDCs probably isn't capable of doing it.
>>
>> This means that to do what you want, the UDC driver would have to
>> accept SETUP packets at any time, and store the most recent packet
>> contents.  Then, when the gadget driver submits a request, the UDC
>> driver would give it this stored data.  It would also have to detect
>
> that's right, I missed that part.
>
>> and prevent a nasty race where the gadget driver tries to queue a
>> request on ep0 that is a response to an old SETUP, one that has already
>> been overwritten.  I'm not even sure preventing this race would be
>> possible in your scheme.
>>
>> The advantage to invoking the gadget driver's setup callback directly
>> from the UDC driver's interrupt handler is that the gadget driver will
>> know immediately when an old SETUP has become stale.  (That's what
>> ep0_req_tag is for in f_mass_storage.)  It also provides a concurrency
>> guarantee, because the driver does not re-enable UDC SETUP interrupts
>> until the handler is finished.
>>
>>> Another detail that this helps is that PM (overall) becomes simpler as,
>>> most likely, we won't need to mess with transfer cancellation, for
>>> example.
>>
>> System PM on a gadget is always troublesome.  Even if the USB
>> connection is a wakeup source, it may not be possible to guarantee that
>> the gadget can wake up quickly enough to handle an incoming packet.
>
> that's true.
>
>>> > You are suggesting that status stage requests should not be queued
>>> > automatically by UDC drivers but instead queued explicitly by gadget
>>> > drivers.  This would mean changing every UDC driver and every gadget
>>> > driver.
>>>
>>> yes, a bit of work but has been done before. One example that comes to
>>> mind is when I added ->udc_start() and ->udc_stop(). It's totally
>>> doable. We can, for instance, add a temporary
>>> "wants_explicit_ctrl_phases"  flag to struct usb_gadget which, if set,
>>> will tell composite.c (or whatever) that the UDC wants explicitly queued
>>> ctrl phases.
>>
>> The term used in the USB spec is "stage", not "phase".  "Phase" refers
>> to the packets making up a single transaction: token, data, and
>> handshake.
>>
>> Also, data stages are already explicit.  So your temporary flag might
>> better be called "wants_explicit_status_stages".
>
> I stand corrected ;-)
>
>>> Then add support for that to each UDC and set the flag. Once all are
>>> converted, add one extra patch to remove the flag and the legacy
>>> code. This has, of course, the draw back of increasing complexity until
>>> everything is converted over; but if it's all done in a single series, I
>>> can't see any problems with that.
>>>
>>> > Also, it won't fix the race that Baolin Wang found.  The setup routine
>>>
>>> well, it will help... see below.
>>>
>>> > is always called in interrupt context, so it can't sleep.  Doing
>>> > anything non-trivial will require a separate task, and it's possible
>>> > that this task will try to enqueue the data-stage or status-stage
>>> > request before the UDC drive

Re: [PATCH v5 1/2] usb: host: plat: Enable xhci plat runtime PM

[Baolin Wang]

Hi Robert,

On 26 January 2017 at 01:30, Robert Foss  wrote:
> Looks good to me.
>
> Feel free to add my r-b.

OK, thanks for your reviewing.

-- 
Baolin.wang
Best Regards
--
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