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  wrote:
> On Tue, Mar 07 2017, Baolin Wang wrote:
>
>> On 3 March 2017 at 10:23, NeilBrown  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 v19 0/4] Introduce usb charger framework to deal with the usb gadget power negotation

[NeilBrown]

On Tue, Mar 07 2017, Baolin Wang wrote:

> On 3 March 2017 at 10:23, NeilBrown  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.

NeilBrown


signature.asc
Description: PGP signature

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

[Lee Jones]

On Tue, 14 Mar 2017, Baolin Wang wrote:

> Hi,
> 
> On 14 March 2017 at 17:57, Lee Jones  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.

I Acked one of the patches 9 months ago since it contained an MFD
change.

Yes, if you could drop me from any new submissions, that'd be great,
thanks.

> [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 
> Signed-off-by: Baolin Wang 
> Acked-by: Lee Jones 
> Acked-by: Charles Keepax 
> Acked-by: Peter Chen 
> Acked-by: Sebastian Reichel 
> ...
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 14 March 2017 at 17:57, Lee Jones  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 
Signed-off-by: Baolin Wang 
Acked-by: Lee Jones 
Acked-by: Charles Keepax 
Acked-by: Peter Chen 
Acked-by: Sebastian Reichel 
...

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

[Lee Jones]

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?

Please be careful when submitting patches, since a lot of us have
enough mail to contend with already.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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

[Jun Li]

Hi,

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Monday, March 13, 2017 4:44 PM
> To: Jun Li <jun...@nxp.com>
> Cc: NeilBrown <ne...@suse.com>; Felipe Balbi <ba...@kernel.org>; Greg KH
> <gre...@linuxfoundation.org>; Sebastian Reichel <s...@kernel.org>; Dmitry
> Eremin-Solenikov <dbarysh...@gmail.com>; David Woodhouse
> <dw...@infradead.org>; r...@kernel.org; Marek Szyprowski
> <m.szyprow...@samsung.com>; Ruslan Bilovol <ruslan.bilo...@gmail.com>;
> Peter Chen <peter.c...@freescale.com>; Alan Stern
> <st...@rowland.harvard.edu>; grygorii.stras...@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda...@renesas.com>; Lee Jones <lee.jo...@linaro.org>;
> Mark Brown <broo...@kernel.org>; John Stultz <john.stu...@linaro.org>;
> Charles Keepax <ckee...@opensource.wolfsonmicro.com>;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB <linux-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.

Li Jun

> >
> > So now the only to do work is to find a common place to send the
> > notification out (based on gadget speed and sate).
> 
> Yes.
> 
> --
> Baolin.wang
> Best Regards
N�r��yb�X��ǧv�^�)޺{.n�+{��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

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

[Jun Li]

Hi,

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Friday, March 10, 2017 6:52 PM
> To: Jun Li <jun...@nxp.com>
> Cc: NeilBrown <ne...@suse.com>; Felipe Balbi <ba...@kernel.org>; Greg KH
> <gre...@linuxfoundation.org>; Sebastian Reichel <s...@kernel.org>; Dmitry
> Eremin-Solenikov <dbarysh...@gmail.com>; David Woodhouse
> <dw...@infradead.org>; r...@kernel.org; Marek Szyprowski
> <m.szyprow...@samsung.com>; Ruslan Bilovol <ruslan.bilo...@gmail.com>;
> Peter Chen <peter.c...@freescale.com>; Alan Stern
> <st...@rowland.harvard.edu>; grygorii.stras...@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda...@renesas.com>; Lee Jones <lee.jo...@linaro.org>;
> Mark Brown <broo...@kernel.org>; John Stultz <john.stu...@linaro.org>;
> Charles Keepax <ckee...@opensource.wolfsonmicro.com>;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB <linux-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
> >> >> >> >> > must be able to find the extcon and trigger a notification.
> >> >> >> >> > Maybe one part can detect VBUS, another can measure the
> >> >> >> >> > resistance on ID and a third can work through the state
> >> >> >> >> > 

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

[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

[Jun Li]

Hi

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Friday, March 10, 2017 3:15 PM
> To: Jun Li <jun...@nxp.com>
> Cc: NeilBrown <ne...@suse.com>; Felipe Balbi <ba...@kernel.org>; Greg KH
> <gre...@linuxfoundation.org>; Sebastian Reichel <s...@kernel.org>; Dmitry
> Eremin-Solenikov <dbarysh...@gmail.com>; David Woodhouse
> <dw...@infradead.org>; r...@kernel.org; Marek Szyprowski
> <m.szyprow...@samsung.com>; Ruslan Bilovol <ruslan.bilo...@gmail.com>;
> Peter Chen <peter.c...@freescale.com>; Alan Stern
> <st...@rowland.harvard.edu>; grygorii.stras...@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda...@renesas.com>; Lee Jones <lee.jo...@linaro.org>;
> Mark Brown <broo...@kernel.org>; John Stultz <john.stu...@linaro.org>;
> Charles Keepax <ckee...@opensource.wolfsonmicro.com>;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB <linux-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 VBUS notification, especially for detecting the
> >> >> >> charger type by
> >> >> software?
> >> >> >>
> >> >> >
> >> >> > My understanding is phy/usb_phy as the connection point, will
> >> >> > send the notification to PMIC driver which actuall

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

[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

[Jun Li]

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Thursday, March 09, 2017 7:23 PM
> To: Jun Li <jun...@nxp.com>
> Cc: NeilBrown <ne...@suse.com>; Felipe Balbi <ba...@kernel.org>; Greg KH
> <gre...@linuxfoundation.org>; Sebastian Reichel <s...@kernel.org>; Dmitry
> Eremin-Solenikov <dbarysh...@gmail.com>; David Woodhouse
> <dw...@infradead.org>; r...@kernel.org; Marek Szyprowski
> <m.szyprow...@samsung.com>; Ruslan Bilovol <ruslan.bilo...@gmail.com>;
> Peter Chen <peter.c...@freescale.com>; Alan Stern
> <st...@rowland.harvard.edu>; grygorii.stras...@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda...@renesas.com>; Lee Jones <lee.jo...@linaro.org>;
> Mark Brown <broo...@kernel.org>; John Stultz <john.stu...@linaro.org>;
> Charles Keepax <ckee...@opensource.wolfsonmicro.com>;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB <linux-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 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 kerne

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

[Jun Li]

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Thursday, March 09, 2017 2:11 PM
> To: Jun Li <jun...@nxp.com>
> Cc: NeilBrown <ne...@suse.com>; Felipe Balbi <ba...@kernel.org>; Greg KH
> <gre...@linuxfoundation.org>; Sebastian Reichel <s...@kernel.org>; Dmitry
> Eremin-Solenikov <dbarysh...@gmail.com>; David Woodhouse
> <dw...@infradead.org>; r...@kernel.org; Marek Szyprowski
> <m.szyprow...@samsung.com>; Ruslan Bilovol <ruslan.bilo...@gmail.com>;
> Peter Chen <peter.c...@freescale.com>; Alan Stern
> <st...@rowland.harvard.edu>; grygorii.stras...@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda...@renesas.com>; Lee Jones <lee.jo...@linaro.org>;
> Mark Brown <broo...@kernel.org>; John Stultz <john.stu...@linaro.org>;
> Charles Keepax <ckee...@opensource.wolfsonmicro.com>;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB <linux-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
> >> >> https://lkml.org/lkml/2017/1/3/13
> >> >>
> >> >> (2) Instead of using 'set_power' callback in phy drivers, we will
> >> >> introduce USB charger to set PMIC current drawn from USB
> >> >> configuration, moreover some 'set_power' callbacks did not
> >> >> implement anything to set PMIC current, thus rem

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

[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

[Jun Li]

Hi,

> -Original Message-
> From: Baolin Wang [mailto:baolin.w...@linaro.org]
> Sent: Tuesday, March 07, 2017 5:39 PM
> To: NeilBrown <ne...@suse.com>
> Cc: Felipe Balbi <ba...@kernel.org>; Greg KH <gre...@linuxfoundation.org>;
> Sebastian Reichel <s...@kernel.org>; Dmitry Eremin-Solenikov
> <dbarysh...@gmail.com>; David Woodhouse <dw...@infradead.org>;
> r...@kernel.org; Jun Li <jun...@nxp.com>; Marek Szyprowski
> <m.szyprow...@samsung.com>; Ruslan Bilovol <ruslan.bilo...@gmail.com>;
> Peter Chen <peter.c...@freescale.com>; Alan Stern
> <st...@rowland.harvard.edu>; grygorii.stras...@ti.com; Yoshihiro Shimoda
> <yoshihiro.shimoda...@renesas.com>; Lee Jones <lee.jo...@linaro.org>;
> Mark Brown <broo...@kernel.org>; John Stultz <john.stu...@linaro.org>;
> Charles Keepax <ckee...@opensource.wolfsonmicro.com>;
> patc...@opensource.wolfsonmicro.com; Linux PM list  p...@vger.kernel.org>; USB <linux-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() could send an extcon notification.
> >
> > Then any phy driver which adds support for setting phy->extcon_dev
> > appropriately, immediately gets the relevant notifications sent.
> 
> OK. We can make these extcon related code into phy common part.
>   

Will generic phy need add extcon as well?

> >
> >> Secondly, I also agreed

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

[Baolin Wang]

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

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

>
>> 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 drivers (phy-generic.c, phy-ab8500-usb.c and 
>> phy-gpio-vbus-usb.c)
>> used the notifier of usb_phy. phy-generic.c and phy-gpio-vbus-usb.c were 
>> used to
>> send out the connect events, and phy-ab8500-usb.c also was used to send out 
>> the
>> MUSB connect events. There are no phy drivers will notify 'vbus_draw' 
>> information
>> by the notifier of usb_phy, which was used consistently now.
>> Moreover it is 

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

[NeilBrown]

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.


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


>
> (2) Change the notifier of usb_phy to be used consistently.
> Now only 3 phy drivers (phy-generic.c, phy-ab8500-usb.c and 
> phy-gpio-vbus-usb.c)
> used the notifier of usb_phy. phy-generic.c and phy-gpio-vbus-usb.c were used 
> to
> send out the connect events, and phy-ab8500-usb.c also was used to send out 
> the
> MUSB connect events. There are no phy drivers will notify 'vbus_draw' 
> information
> by the notifier of usb_phy, which was used consistently now.
> Moreover it is difficult to change the notifier of usb_phy to be used only to
> communicate the 'vbus_draw' information, since we need to refactor and test 
> these
> related phy drivers, power drivers or some mfd drivers, which is a
> huge workload.

You missed drivers/usb/musb/omap2430.c in you list, but that hardly
matters.
phy-ab8500-usb.c appears to send vbus_draw information.

I understand your 

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

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

(2) Change the notifier of usb_phy to be used consistently.
Now only 3 phy drivers (phy-generic.c, phy-ab8500-usb.c and phy-gpio-vbus-usb.c)
used the notifier of usb_phy. phy-generic.c and phy-gpio-vbus-usb.c were used to
send out the connect events, and phy-ab8500-usb.c also was used to send out the
MUSB connect events. There are no phy drivers will notify 'vbus_draw' 
information
by the notifier of usb_phy, which was used consistently now.
Moreover it is difficult to change the notifier of usb_phy to be used only to
communicate the 'vbus_draw' information, since we need to refactor and test 
these
related phy drivers, power drivers or some mfd drivers, which is a huge 
workload.

(3) Still keep charger_type_show() API.
Firstly I think we should combine all charger related information into one
place for users, which is convenient.
Secondly not only we get charger type from extcon, but also in some scenarios
we can get charger type from USB controller driver, USB type-c driver, pmic
driver, we should also need one place to export the charger type.

Changes since v18:
 Other issues addressed in this patchset:
 - Modify the method of looking up one USB charger instance, we assume there is
 only one USB charger in the system. But leaving things there to avoid any need
 for future refactoring to touch the usb_charger_register() interface.
 - Remove usb_charger_set_current() API.
 - Rename usb charger state.
 - Remove ->get_charger_type() interface.
 - Add some documentation for ->charger_detect() interface explicitly.
 - Fix one issue: reset current to default values when cable was unplugged.
 - Only notify the max current to power users, but users can get the min current
 by usb_charger_get_current() if users want to use the min current.
 - Other small optimizations.

Changes since v17:
 - Remove goto section in usb_charger_register() function.
 - Remove 'extern' in charger.h file.
 - Move the kfree() to usb_charger_exit() function.

Changes since v16:
 - Modify the charger current range with introducing the maximum and minimum
 current.
 - Remove the getting charger type method from power supply.
 - Add the getting charger type method from extcon system.
 - Introduce new usb_charger_get_current() API for users to get the maximum and
 minimum current.
 - Rename some APIs and other optimization.

Changes since v15:
 - Add charger state checking to avoid sending out duplicate notifies to users.
 - Add one work to notify power users the current has been changed.

Changes since v14: