[PATCH 0/4] Add support for charging battery in Nokia RX-51

[PATCH 0/4] Add support for charging battery in Nokia RX-51

[Pali Rohár]

This patch series finally bringing support for charging battery on
Nokia N900 (RX-51) without any proprietary Nokia bits in userspace.

Pali Roh?r (4):
  usb: musb: Call atomic_notifier_call_chain when status is changed
  power: isp1704_charger: Fix driver to work with changes introduced in
    v3.5
  power: isp1704_charger: Add callback function set_current
  RX-51: Add platform function and data for bq24150a charger

 arch/arm/mach-omap2/board-rx51-peripherals.c |   56 +++++++++++++-
 drivers/power/isp1704_charger.c              |  107 ++++++++++++++------------
 drivers/usb/musb/omap2430.c                  |    3 +
 drivers/usb/phy/phy-twl4030-usb.c            |    2 +
 include/linux/power/isp1704_charger.h        |    1 +
 5 files changed, 117 insertions(+), 52 deletions(-)

-- 
1.7.10.4

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

More power supply drivers depends on vbus events and without it they not
working. Power supply drivers using usb_register_notifier, so to deliver
events it is needed to call atomic_notifier_call_chain.

So without atomic notifier power supply driver isp1704 not retrieving
vbus status and reporting bogus values to userspace and also to board
platform data functions. Without proper data charger drivers trying to
charge battery also when charger is disconnected or do not start charging
when wallcharger connects.

Atomic notifier in musb driver was used before v3.5 and was replaced with
omap mailbox. This patch adding atomic_notifier_call_chain call from
function omap_musb_set_mailbox.

Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
---
 drivers/usb/musb/omap2430.c       |    3 +++
 drivers/usb/phy/phy-twl4030-usb.c |    2 ++
 2 files changed, 5 insertions(+)

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f44e8b5..5c40252 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 	default:
 		dev_dbg(dev, "ID float\n");
 	}
+
+	atomic_notifier_call_chain(&musb->xceiv->notifier,
+			musb->xceiv->last_event, NULL);
 }
 
 
diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index 8f78d2d..efe6155 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	if (device_create_file(&pdev->dev, &dev_attr_vbus))
 		dev_warn(&pdev->dev, "could not create sysfs file\n");
 
+	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
+
 	/* Our job is to use irqs and status from the power module
 	 * to keep the transceiver disabled when nothing's connected.
 	 *
-- 
1.7.10.4

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> More power supply drivers depends on vbus events and without it they not
> working. Power supply drivers using usb_register_notifier, so to deliver
> events it is needed to call atomic_notifier_call_chain.
> 
> So without atomic notifier power supply driver isp1704 not retrieving
> vbus status and reporting bogus values to userspace and also to board
> platform data functions. Without proper data charger drivers trying to
> charge battery also when charger is disconnected or do not start charging
> when wallcharger connects.
> 
> Atomic notifier in musb driver was used before v3.5 and was replaced with
> omap mailbox. This patch adding atomic_notifier_call_chain call from
> function omap_musb_set_mailbox.
> 
> Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> ---
>  drivers/usb/musb/omap2430.c       |    3 +++
>  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
>  2 files changed, 5 insertions(+)
> 
> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index f44e8b5..5c40252 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
>  	default:
>  		dev_dbg(dev, "ID float\n");
>  	}
> +
> +	atomic_notifier_call_chain(&musb->xceiv->notifier,
> +			musb->xceiv->last_event, NULL);

let's add a wrapper for this:

static inline int usb_phy_notify(struct usb phy *x, unsigned val, void *v)
{
	return atomic_notifier_call_chain(&x->notifier, val, v);
}

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130917/df17f742/attachment-0001.sig>

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
> index 8f78d2d..efe6155 100644
> --- a/drivers/usb/phy/phy-twl4030-usb.c
> +++ b/drivers/usb/phy/phy-twl4030-usb.c
> @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
>  	if (device_create_file(&pdev->dev, &dev_attr_vbus))
>  		dev_warn(&pdev->dev, "could not create sysfs file\n");
>  
> +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);

BTW, this is a bugfix, send separately.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130917/dde12078/attachment.sig>

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

On Tuesday 17 September 2013 17:48:59 you wrote:
> On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > More power supply drivers depends on vbus events and without
> > it they not working. Power supply drivers using
> > usb_register_notifier, so to deliver events it is needed to
> > call atomic_notifier_call_chain.
> > 
> > So without atomic notifier power supply driver isp1704 not
> > retrieving vbus status and reporting bogus values to
> > userspace and also to board platform data functions.
> > Without proper data charger drivers trying to charge
> > battery also when charger is disconnected or do not start
> > charging when wallcharger connects.
> > 
> > Atomic notifier in musb driver was used before v3.5 and was
> > replaced with omap mailbox. This patch adding
> > atomic_notifier_call_chain call from function
> > omap_musb_set_mailbox.
> > 
> > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> > ---
> > 
> >  drivers/usb/musb/omap2430.c       |    3 +++
> >  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
> >  2 files changed, 5 insertions(+)
> > 
> > diff --git a/drivers/usb/musb/omap2430.c
> > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252 100644
> > --- a/drivers/usb/musb/omap2430.c
> > +++ b/drivers/usb/musb/omap2430.c
> > @@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct
> > omap2430_glue *glue)
> > 
> >  	default:
> >  		dev_dbg(dev, "ID float\n");
> >  	
> >  	}
> > 
> > +
> > +	atomic_notifier_call_chain(&musb->xceiv->notifier,
> > +			musb->xceiv->last_event, NULL);
> 
> let's add a wrapper for this:
> 
> static inline int usb_phy_notify(struct usb phy *x, unsigned
> val, void *v) {
> 	return atomic_notifier_call_chain(&x->notifier, val, v);
> }

Where to add this wrapper? To omap2430.c? or some include file?

On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > 100644
> > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > platform_device *pdev)
> > 
> >  	if (device_create_file(&pdev->dev, &dev_attr_vbus))
> >  	
> >  		dev_warn(&pdev->dev, "could not create sysfs file\n");
> > 
> > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> 
> BTW, this is a bugfix, send separately.

What to send separately?

This full patch 1/4 is bugfix. And I did not understand what you 
want. Maybe it could be easier for you to apply this small 3+2 
lines patch how you need.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130917/b9164414/attachment.sig>

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Roh?r wrote:
> On Tuesday 17 September 2013 17:48:59 you wrote:
> > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > > More power supply drivers depends on vbus events and without
> > > it they not working. Power supply drivers using
> > > usb_register_notifier, so to deliver events it is needed to
> > > call atomic_notifier_call_chain.
> > > 
> > > So without atomic notifier power supply driver isp1704 not
> > > retrieving vbus status and reporting bogus values to
> > > userspace and also to board platform data functions.
> > > Without proper data charger drivers trying to charge
> > > battery also when charger is disconnected or do not start
> > > charging when wallcharger connects.
> > > 
> > > Atomic notifier in musb driver was used before v3.5 and was
> > > replaced with omap mailbox. This patch adding
> > > atomic_notifier_call_chain call from function
> > > omap_musb_set_mailbox.
> > > 
> > > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> > > ---
> > > 
> > >  drivers/usb/musb/omap2430.c       |    3 +++
> > >  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
> > >  2 files changed, 5 insertions(+)
> > > 
> > > diff --git a/drivers/usb/musb/omap2430.c
> > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252 100644
> > > --- a/drivers/usb/musb/omap2430.c
> > > +++ b/drivers/usb/musb/omap2430.c
> > > @@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct
> > > omap2430_glue *glue)
> > > 
> > >  	default:
> > >  		dev_dbg(dev, "ID float\n");
> > >  	
> > >  	}
> > > 
> > > +
> > > +	atomic_notifier_call_chain(&musb->xceiv->notifier,
> > > +			musb->xceiv->last_event, NULL);
> > 
> > let's add a wrapper for this:
> > 
> > static inline int usb_phy_notify(struct usb phy *x, unsigned
> > val, void *v) {
> > 	return atomic_notifier_call_chain(&x->notifier, val, v);
> > }
> 
> Where to add this wrapper? To omap2430.c? or some include file?

<linux/usb/phy.h>

> On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > > 100644
> > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > platform_device *pdev)
> > > 
> > >  	if (device_create_file(&pdev->dev, &dev_attr_vbus))
> > >  	
> > >  		dev_warn(&pdev->dev, "could not create sysfs file\n");
> > > 
> > > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > 
> > BTW, this is a bugfix, send separately.
> 
> What to send separately?
> 
> This full patch 1/4 is bugfix. And I did not understand what you 
> want. Maybe it could be easier for you to apply this small 3+2 
> lines patch how you need.

This hunk here (initializaing notifier head) is a separate bug fix and
needs its own patch.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130917/a7e83fbb/attachment.sig>

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
> On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Roh?r wrote:
> > On Tuesday 17 September 2013 17:48:59 you wrote:
> > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > > > More power supply drivers depends on vbus events and
> > > > without it they not working. Power supply drivers using
> > > > usb_register_notifier, so to deliver events it is
> > > > needed to call atomic_notifier_call_chain.
> > > > 
> > > > So without atomic notifier power supply driver isp1704
> > > > not retrieving vbus status and reporting bogus values
> > > > to userspace and also to board platform data functions.
> > > > Without proper data charger drivers trying to charge
> > > > battery also when charger is disconnected or do not
> > > > start charging when wallcharger connects.
> > > > 
> > > > Atomic notifier in musb driver was used before v3.5 and
> > > > was replaced with omap mailbox. This patch adding
> > > > atomic_notifier_call_chain call from function
> > > > omap_musb_set_mailbox.
> > > > 
> > > > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> > > > ---
> > > > 
> > > >  drivers/usb/musb/omap2430.c       |    3 +++
> > > >  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
> > > >  2 files changed, 5 insertions(+)
> > > > 
> > > > diff --git a/drivers/usb/musb/omap2430.c
> > > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252
> > > > 100644 --- a/drivers/usb/musb/omap2430.c
> > > > +++ b/drivers/usb/musb/omap2430.c
> > > > @@ -305,6 +305,9 @@ static void
> > > > omap_musb_set_mailbox(struct omap2430_glue *glue)
> > > > 
> > > >  	default:
> > > >  		dev_dbg(dev, "ID float\n");
> > > >  	
> > > >  	}
> > > > 
> > > > +
> > > > +	atomic_notifier_call_chain(&musb->xceiv->notifier,
> > > > +			musb->xceiv->last_event, NULL);
> > > 
> > > let's add a wrapper for this:
> > > 
> > > static inline int usb_phy_notify(struct usb phy *x,
> > > unsigned val, void *v) {
> > > 
> > > 	return atomic_notifier_call_chain(&x->notifier, val, v);
> > > 
> > > }
> > 
> > Where to add this wrapper? To omap2430.c? or some include
> > file?
> 
> <linux/usb/phy.h>
> 
> > On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > > b/drivers/usb/phy/phy-twl4030-usb.c index
> > > > 8f78d2d..efe6155 100644
> > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > > platform_device *pdev)
> > > > 
> > > >  	if (device_create_file(&pdev->dev, &dev_attr_vbus))
> > > >  	
> > > >  		dev_warn(&pdev->dev, "could not create sysfs
> > > >  		file\n");
> > > > 
> > > > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > > 
> > > BTW, this is a bugfix, send separately.
> > 
> > What to send separately?
> > 
> > This full patch 1/4 is bugfix. And I did not understand what
> > you want. Maybe it could be easier for you to apply this
> > small 3+2 lines patch how you need.
> 
> This hunk here (initializaing notifier head) is a separate bug
> fix and needs its own patch.

So will you do that? Or it is needed to resend this one line hunk 
again in new email again?

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130917/2aec70d8/attachment.sig>

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

On Tue, Sep 17, 2013 at 09:28:42PM +0200, Pali Roh?r wrote:
> On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
> > On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Roh?r wrote:
> > > On Tuesday 17 September 2013 17:48:59 you wrote:
> > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > > > > More power supply drivers depends on vbus events and
> > > > > without it they not working. Power supply drivers using
> > > > > usb_register_notifier, so to deliver events it is
> > > > > needed to call atomic_notifier_call_chain.
> > > > > 
> > > > > So without atomic notifier power supply driver isp1704
> > > > > not retrieving vbus status and reporting bogus values
> > > > > to userspace and also to board platform data functions.
> > > > > Without proper data charger drivers trying to charge
> > > > > battery also when charger is disconnected or do not
> > > > > start charging when wallcharger connects.
> > > > > 
> > > > > Atomic notifier in musb driver was used before v3.5 and
> > > > > was replaced with omap mailbox. This patch adding
> > > > > atomic_notifier_call_chain call from function
> > > > > omap_musb_set_mailbox.
> > > > > 
> > > > > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> > > > > ---
> > > > > 
> > > > >  drivers/usb/musb/omap2430.c       |    3 +++
> > > > >  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
> > > > >  2 files changed, 5 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/usb/musb/omap2430.c
> > > > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252
> > > > > 100644 --- a/drivers/usb/musb/omap2430.c
> > > > > +++ b/drivers/usb/musb/omap2430.c
> > > > > @@ -305,6 +305,9 @@ static void
> > > > > omap_musb_set_mailbox(struct omap2430_glue *glue)
> > > > > 
> > > > >  	default:
> > > > >  		dev_dbg(dev, "ID float\n");
> > > > >  	
> > > > >  	}
> > > > > 
> > > > > +
> > > > > +	atomic_notifier_call_chain(&musb->xceiv->notifier,
> > > > > +			musb->xceiv->last_event, NULL);
> > > > 
> > > > let's add a wrapper for this:
> > > > 
> > > > static inline int usb_phy_notify(struct usb phy *x,
> > > > unsigned val, void *v) {
> > > > 
> > > > 	return atomic_notifier_call_chain(&x->notifier, val, v);
> > > > 
> > > > }
> > > 
> > > Where to add this wrapper? To omap2430.c? or some include
> > > file?
> > 
> > <linux/usb/phy.h>
> > 
> > > On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > > > b/drivers/usb/phy/phy-twl4030-usb.c index
> > > > > 8f78d2d..efe6155 100644
> > > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > > > platform_device *pdev)
> > > > > 
> > > > >  	if (device_create_file(&pdev->dev, &dev_attr_vbus))
> > > > >  	
> > > > >  		dev_warn(&pdev->dev, "could not create sysfs
> > > > >  		file\n");
> > > > > 
> > > > > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > > > 
> > > > BTW, this is a bugfix, send separately.
> > > 
> > > What to send separately?
> > > 
> > > This full patch 1/4 is bugfix. And I did not understand what
> > > you want. Maybe it could be easier for you to apply this
> > > small 3+2 lines patch how you need.
> > 
> > This hunk here (initializaing notifier head) is a separate bug
> > fix and needs its own patch.
> 
> So will you do that? Or it is needed to resend this one line hunk 
> again in new email again?

new patch, new email

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130917/c6cd20bc/attachment.sig>

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

On Wednesday 18 September 2013 03:49:42 Felipe Balbi wrote:
> On Tue, Sep 17, 2013 at 09:28:42PM +0200, Pali Roh?r wrote:
> > On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
> > > On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Roh?r wrote:
> > > > On Tuesday 17 September 2013 17:48:59 you wrote:
> > > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > > > > > More power supply drivers depends on vbus events and
> > > > > > without it they not working. Power supply drivers
> > > > > > using usb_register_notifier, so to deliver events
> > > > > > it is needed to call atomic_notifier_call_chain.
> > > > > > 
> > > > > > So without atomic notifier power supply driver
> > > > > > isp1704 not retrieving vbus status and reporting
> > > > > > bogus values to userspace and also to board
> > > > > > platform data functions. Without proper data
> > > > > > charger drivers trying to charge battery also when
> > > > > > charger is disconnected or do not start charging
> > > > > > when wallcharger connects.
> > > > > > 
> > > > > > Atomic notifier in musb driver was used before v3.5
> > > > > > and was replaced with omap mailbox. This patch
> > > > > > adding atomic_notifier_call_chain call from
> > > > > > function omap_musb_set_mailbox.
> > > > > > 
> > > > > > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> > > > > > ---
> > > > > > 
> > > > > >  drivers/usb/musb/omap2430.c       |    3 +++
> > > > > >  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
> > > > > >  2 files changed, 5 insertions(+)
> > > > > > 
> > > > > > diff --git a/drivers/usb/musb/omap2430.c
> > > > > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252
> > > > > > 100644 --- a/drivers/usb/musb/omap2430.c
> > > > > > +++ b/drivers/usb/musb/omap2430.c
> > > > > > @@ -305,6 +305,9 @@ static void
> > > > > > omap_musb_set_mailbox(struct omap2430_glue *glue)
> > > > > > 
> > > > > >  	default:
> > > > > >  		dev_dbg(dev, "ID float\n");
> > > > > >  	
> > > > > >  	}
> > > > > > 
> > > > > > +
> > > > > > +	atomic_notifier_call_chain(&musb->xceiv->notifier,
> > > > > > +			musb->xceiv->last_event, NULL);
> > > > > 
> > > > > let's add a wrapper for this:
> > > > > 
> > > > > static inline int usb_phy_notify(struct usb phy *x,
> > > > > unsigned val, void *v) {
> > > > > 
> > > > > 	return atomic_notifier_call_chain(&x->notifier, val,
> > > > > 	v);
> > > > > 
> > > > > }
> > > > 
> > > > Where to add this wrapper? To omap2430.c? or some
> > > > include file?
> > > 
> > > <linux/usb/phy.h>
> > > 
> > > > On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
> > > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
> > > > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > > > > b/drivers/usb/phy/phy-twl4030-usb.c index
> > > > > > 8f78d2d..efe6155 100644
> > > > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > > > > @@ -705,6 +705,8 @@ static int
> > > > > > twl4030_usb_probe(struct platform_device *pdev)
> > > > > > 
> > > > > >  	if (device_create_file(&pdev->dev,
> > > > > >  	&dev_attr_vbus))
> > > > > >  	
> > > > > >  		dev_warn(&pdev->dev, "could not create sysfs
> > > > > >  		file\n");
> > > > > > 
> > > > > > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > > > > 
> > > > > BTW, this is a bugfix, send separately.
> > > > 
> > > > What to send separately?
> > > > 
> > > > This full patch 1/4 is bugfix. And I did not understand
> > > > what you want. Maybe it could be easier for you to
> > > > apply this small 3+2 lines patch how you need.
> > > 
> > > This hunk here (initializaing notifier head) is a separate
> > > bug fix and needs its own patch.
> > 
> > So will you do that? Or it is needed to resend this one line
> > hunk again in new email again?
> 
> new patch, new email

Guys, WHY ARE YOU SO STUPID AND ARROGANT?

Sorry but, need to copy full isolated patch/hunk from one mail to
another is hassling. So what you want from me? Do all those non
sense working only because yesterday you had bad day? Or what?

Everything needed with described information was in first mail.
Also second hunk has full isolated "git diff" output, so it is for
you really big problem to copy it? Or you did not see that patch?

I really did not understand what you wanted from me.

============================
==== BEGINNING OF PATCH ====
============================

This is bugfix and sending this patch separately from all other patches.
This patch is visibly isolated from all others and could be readable also
by disabled people. For other handicapped people I suggest to increase
font size and other text settings in program which view this patch.
For visually impaired people I suggest to use some text-to-speech software.

This is small 2 lines patch, diff starting after next visible break.

This patch initializing notifier head in tw4030 usb code which is missing.
Initialization code is needed for using any atomic_notifier_* functions.

Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>

===========================
==== BEGINNING OF DIFF ====
===========================

diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index 8f78d2d..efe6155 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	if (device_create_file(&pdev->dev, &dev_attr_vbus))
 		dev_warn(&pdev->dev, "could not create sysfs file\n");
 
+	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
+
 	/* Our job is to use irqs and status from the power module
 	 * to keep the transceiver disabled when nothing's connected.
 	 *

======================
==== END OF PATCH ====
======================

PS: This is end of email and patch is above ^^^^

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130918/9c5970c0/attachment.sig>

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Javier Martinez Canillas]

On Wed, Sep 18, 2013 at 10:20 AM, Pali Roh?r <pali.rohar@gmail.com> wrote:
> On Wednesday 18 September 2013 03:49:42 Felipe Balbi wrote:
>> On Tue, Sep 17, 2013 at 09:28:42PM +0200, Pali Roh?r wrote:
>> > On Tuesday 17 September 2013 18:08:35 Felipe Balbi wrote:
>> > > On Tue, Sep 17, 2013 at 06:05:15PM +0200, Pali Roh?r wrote:
>> > > > On Tuesday 17 September 2013 17:48:59 you wrote:
>> > > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
>> > > > > > More power supply drivers depends on vbus events and
>> > > > > > without it they not working. Power supply drivers
>> > > > > > using usb_register_notifier, so to deliver events
>> > > > > > it is needed to call atomic_notifier_call_chain.
>> > > > > >
>> > > > > > So without atomic notifier power supply driver
>> > > > > > isp1704 not retrieving vbus status and reporting
>> > > > > > bogus values to userspace and also to board
>> > > > > > platform data functions. Without proper data
>> > > > > > charger drivers trying to charge battery also when
>> > > > > > charger is disconnected or do not start charging
>> > > > > > when wallcharger connects.
>> > > > > >
>> > > > > > Atomic notifier in musb driver was used before v3.5
>> > > > > > and was replaced with omap mailbox. This patch
>> > > > > > adding atomic_notifier_call_chain call from
>> > > > > > function omap_musb_set_mailbox.
>> > > > > >
>> > > > > > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
>> > > > > > ---
>> > > > > >
>> > > > > >  drivers/usb/musb/omap2430.c       |    3 +++
>> > > > > >  drivers/usb/phy/phy-twl4030-usb.c |    2 ++
>> > > > > >  2 files changed, 5 insertions(+)
>> > > > > >
>> > > > > > diff --git a/drivers/usb/musb/omap2430.c
>> > > > > > b/drivers/usb/musb/omap2430.c index f44e8b5..5c40252
>> > > > > > 100644 --- a/drivers/usb/musb/omap2430.c
>> > > > > > +++ b/drivers/usb/musb/omap2430.c
>> > > > > > @@ -305,6 +305,9 @@ static void
>> > > > > > omap_musb_set_mailbox(struct omap2430_glue *glue)
>> > > > > >
>> > > > > >     default:
>> > > > > >             dev_dbg(dev, "ID float\n");
>> > > > > >
>> > > > > >     }
>> > > > > >
>> > > > > > +
>> > > > > > +   atomic_notifier_call_chain(&musb->xceiv->notifier,
>> > > > > > +                   musb->xceiv->last_event, NULL);
>> > > > >
>> > > > > let's add a wrapper for this:
>> > > > >
>> > > > > static inline int usb_phy_notify(struct usb phy *x,
>> > > > > unsigned val, void *v) {
>> > > > >
>> > > > >       return atomic_notifier_call_chain(&x->notifier, val,
>> > > > >       v);
>> > > > >
>> > > > > }
>> > > >
>> > > > Where to add this wrapper? To omap2430.c? or some
>> > > > include file?
>> > >
>> > > <linux/usb/phy.h>
>> > >
>> > > > On Tuesday 17 September 2013 17:49:17 Felipe Balbi wrote:
>> > > > > On Sun, Sep 08, 2013 at 10:50:36AM +0200, Pali Roh?r wrote:
>> > > > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
>> > > > > > b/drivers/usb/phy/phy-twl4030-usb.c index
>> > > > > > 8f78d2d..efe6155 100644
>> > > > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
>> > > > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
>> > > > > > @@ -705,6 +705,8 @@ static int
>> > > > > > twl4030_usb_probe(struct platform_device *pdev)
>> > > > > >
>> > > > > >     if (device_create_file(&pdev->dev,
>> > > > > >     &dev_attr_vbus))
>> > > > > >
>> > > > > >             dev_warn(&pdev->dev, "could not create sysfs
>> > > > > >             file\n");
>> > > > > >
>> > > > > > +   ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
>> > > > >
>> > > > > BTW, this is a bugfix, send separately.
>> > > >
>> > > > What to send separately?
>> > > >
>> > > > This full patch 1/4 is bugfix. And I did not understand
>> > > > what you want. Maybe it could be easier for you to
>> > > > apply this small 3+2 lines patch how you need.
>> > >
>> > > This hunk here (initializaing notifier head) is a separate
>> > > bug fix and needs its own patch.
>> >
>> > So will you do that? Or it is needed to resend this one line
>> > hunk again in new email again?
>>
>> new patch, new email
>
> Guys, WHY ARE YOU SO STUPID AND ARROGANT?
>
> Sorry but, need to copy full isolated patch/hunk from one mail to
> another is hassling. So what you want from me? Do all those non
> sense working only because yesterday you had bad day? Or what?
>
> Everything needed with described information was in first mail.
> Also second hunk has full isolated "git diff" output, so it is for
> you really big problem to copy it? Or you did not see that patch?
>
> I really did not understand what you wanted from me.
>
> ============================
> ==== BEGINNING OF PATCH ====
> ============================
>
> This is bugfix and sending this patch separately from all other patches.
> This patch is visibly isolated from all others and could be readable also
> by disabled people. For other handicapped people I suggest to increase
> font size and other text settings in program which view this patch.
> For visually impaired people I suggest to use some text-to-speech software.
>
> This is small 2 lines patch, diff starting after next visible break.
>
> This patch initializing notifier head in tw4030 usb code which is missing.
> Initialization code is needed for using any atomic_notifier_* functions.
>
> Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
>
> ===========================
> ==== BEGINNING OF DIFF ====
> ===========================
>
> diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
> index 8f78d2d..efe6155 100644
> --- a/drivers/usb/phy/phy-twl4030-usb.c
> +++ b/drivers/usb/phy/phy-twl4030-usb.c
> @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
>         if (device_create_file(&pdev->dev, &dev_attr_vbus))
>                 dev_warn(&pdev->dev, "could not create sysfs file\n");
>
> +       ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> +
>         /* Our job is to use irqs and status from the power module
>          * to keep the transceiver disabled when nothing's connected.
>          *
>
> ======================
> ==== END OF PATCH ====
> ======================
>
> PS: This is end of email and patch is above ^^^^
>

Hi Pali,

There is no need to be rude.

Felipe asked you to do the split since he believes that the notifier
chain call for musb xceiv and the twl->phy notifier head init should
be done in two separate patches.

I agree with him since is better to separate bugfixs from new features
for different reasons. For example if is found that a feature has to
be reverted, then this won't revert a bugfix causing a regression.
Also, it is easier to review and the bugfix patch can be cherry-picked
by stable kernels.

You said that to copy isolated patch/hunk from one mail to another is
hassling so why do you want Felipe to do that? He like most most
sub-system maintainers is very busy so if we want the kernel to scale
we have to help them to make their live easier.

So,  I don't understand from where your anger comes for just the need
to split your patch in two and send correct patches with git
send-email so Felipe can apply easily with git am mbox or whatever
worfklow he has.

This is not the first time you contribute to the kernel so you know
that the above patch s not only not in the correct format to be
applied but also has a very offensive commit changelog that is not
suitable for the kernel.

Take a deep breath, grab a mug of coffee and then just split your
patches and repost as v2, I'm sure you spent more time writing that
angry email that what it would have taken to do it properly ;-)

> --
> Pali Roh?r
> pali.rohar at gmail.com

Best regards,
Javier

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pavel Machek]

Hi!

> >> > So will you do that? Or it is needed to resend this one line
> >> > hunk again in new email again?
> >>
> >> new patch, new email
> >
> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
> >
> > Sorry but, need to copy full isolated patch/hunk from one mail to
> > another is hassling. So what you want from me? Do all those non
> > sense working only because yesterday you had bad day? Or what?
...
> 
> Hi Pali,
> 
> There is no need to be rude.
> 
> Felipe asked you to do the split since he believes that the notifier
> chain call for musb xceiv and the twl->phy notifier head init should
> be done in two separate patches.

Actually, there is need to be rude, because Felipe fails to act as
maintainer. Instead of fixing bugs in his code, he bounces bugfix
patches, points people to random READMEs and wastes everyones time.
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Javier Martinez Canillas]

On Wed, Sep 18, 2013 at 3:30 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> >> > So will you do that? Or it is needed to resend this one line
>> >> > hunk again in new email again?
>> >>
>> >> new patch, new email
>> >
>> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
>> >
>> > Sorry but, need to copy full isolated patch/hunk from one mail to
>> > another is hassling. So what you want from me? Do all those non
>> > sense working only because yesterday you had bad day? Or what?
> ...
>>
>> Hi Pali,
>>
>> There is no need to be rude.
>>
>> Felipe asked you to do the split since he believes that the notifier
>> chain call for musb xceiv and the twl->phy notifier head init should
>> be done in two separate patches.
>
> Actually, there is need to be rude, because Felipe fails to act as
> maintainer. Instead of fixing bugs in his code, he bounces bugfix
> patches, points people to random READMEs and wastes everyones time.
>                                                                         Pavel
>

I don't know what are you talking about (if that happened in another
thread then I need more context). Felipe is not bouncing any bugfix
but just asked to split the patch in two since the patch was solving
two separate issues so is way better to have it in two separate
patches for the reasons I explained before.

So, as far as I can tell Felipe did exactly what I would expect from a
maintainer. He took the time to review the patches sent to him and
gave feedback. If the sender doesn't want to take his feedback into
account and prefer to send pretty insulting emails instead that is his
choice but I would say that is this not the greatest approach to get
your code merged (to say the least).

Best regards,
Javier

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pavel Machek]

Hi!

> >> >> > So will you do that? Or it is needed to resend this one line
> >> >> > hunk again in new email again?
> >> >>
> >> >> new patch, new email
> >> >
> >> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
> >> >
> >> > Sorry but, need to copy full isolated patch/hunk from one mail to
> >> > another is hassling. So what you want from me? Do all those non
> >> > sense working only because yesterday you had bad day? Or what?
...
> > Actually, there is need to be rude, because Felipe fails to act as
> > maintainer. Instead of fixing bugs in his code, he bounces bugfix
> > patches, points people to random READMEs and wastes everyones time.
> 
> I don't know what are you talking about (if that happened in another
> thread then I need more context). Felipe is not bouncing any bugfix

Take a look here:

https://lkml.org/lkml/2013/9/17/286

I clearly state that patch can not be tested as required for "proper"
submission, but offer patch anyway. I get irrelevant boilerplate on
patch format.

> but just asked to split the patch in two since the patch was solving
> two separate issues so is way better to have it in two separate
> patches for the reasons I explained before.
> 
> So, as far as I can tell Felipe did exactly what I would expect from a
> maintainer. He took the time to review the patches sent to him and

I'd expect maintainer to, well, maintain code. It means actually
fixing bugs in his code, when he's pointed at them.

> gave feedback. If the sender doesn't want to take his feedback into
> account and prefer to send pretty insulting emails instead that is his
> choice but I would say that is this not the greatest approach to get
> your code merged (to say the least).

Clearly not. But Pali found bug in code Felipe should
maintain. Instead of "thank you for bug report, I applied this one
line of your code to fix it", Pali got "new patch, new email" for his
efforts. That is how you train dogs, not how you should treat kernel
contributors.

Now, it is possible that Felipe just has problems with english, as he
called me piece of wood in https://lkml.org/lkml/2013/9/17/476 , but
he appears more arogant than usual over email.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pavel Machek]

Hi!

> > gave feedback. If the sender doesn't want to take his feedback into
> > account and prefer to send pretty insulting emails instead that is his
> > choice but I would say that is this not the greatest approach to get
> > your code merged (to say the least).
> 
> Clearly not. But Pali found bug in code Felipe should
> maintain. Instead of "thank you for bug report, I applied this one
> line of your code to fix it", Pali got "new patch, new email" for his
> efforts. That is how you train dogs, not how you should treat kernel
> contributors.
> 
> Now, it is possible that Felipe just has problems with english, as he
> called me piece of wood in https://lkml.org/lkml/2013/9/17/476 , but
> he appears more arogant than usual over email.

Actually he called me "piece of wood with garbage in it". I guess I
have right to be offended. I'm baby in the next email. Hmm.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

Hi,

On Wed, Sep 18, 2013 at 04:35:37PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > gave feedback. If the sender doesn't want to take his feedback into
> > > account and prefer to send pretty insulting emails instead that is his
> > > choice but I would say that is this not the greatest approach to get
> > > your code merged (to say the least).
> > 
> > Clearly not. But Pali found bug in code Felipe should
> > maintain. Instead of "thank you for bug report, I applied this one
> > line of your code to fix it", Pali got "new patch, new email" for his
> > efforts. That is how you train dogs, not how you should treat kernel
> > contributors.
> > 
> > Now, it is possible that Felipe just has problems with english, as he
> > called me piece of wood in https://lkml.org/lkml/2013/9/17/476 , but
> > he appears more arogant than usual over email.
> 
> Actually he called me "piece of wood with garbage in it". I guess I
> have right to be offended. I'm baby in the next email. Hmm.

what a baby. Grow up dude, just grow up. I said your commit log has
garbage which shouldn't be there (there was a typo you're instead of
your).

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130918/d419425d/attachment.sig>

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Javier Martinez Canillas]

On Wed, Sep 18, 2013 at 4:22 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
>> >> >> > So will you do that? Or it is needed to resend this one line
>> >> >> > hunk again in new email again?
>> >> >>
>> >> >> new patch, new email
>> >> >
>> >> > Guys, WHY ARE YOU SO STUPID AND ARROGANT?
>> >> >
>> >> > Sorry but, need to copy full isolated patch/hunk from one mail to
>> >> > another is hassling. So what you want from me? Do all those non
>> >> > sense working only because yesterday you had bad day? Or what?
> ...
>> > Actually, there is need to be rude, because Felipe fails to act as
>> > maintainer. Instead of fixing bugs in his code, he bounces bugfix
>> > patches, points people to random READMEs and wastes everyones time.
>>
>> I don't know what are you talking about (if that happened in another
>> thread then I need more context). Felipe is not bouncing any bugfix
>
> Take a look here:
>
> https://lkml.org/lkml/2013/9/17/286
>
> I clearly state that patch can not be tested as required for "proper"
> submission, but offer patch anyway. I get irrelevant boilerplate on
> patch format.
>

Felipe didn't complain about you not being to be able to test the
patch (most of the times compile tested if enough) what he said was:

"Seriously though, read that file, you're commit log has garbage in it
which shouldn't go to git history".

which is totally true, if you want to comment things that don't have
to go to the backlog you can't comment between the --- after your
s-o-b and before the first diff. That's were you should puts comments
like "Hi! or Here's suggested patch. I don't have the hardware, so it
is completely untested."

>> but just asked to split the patch in two since the patch was solving
>> two separate issues so is way better to have it in two separate
>> patches for the reasons I explained before.
>>
>> So, as far as I can tell Felipe did exactly what I would expect from a
>> maintainer. He took the time to review the patches sent to him and
>
> I'd expect maintainer to, well, maintain code. It means actually
> fixing bugs in his code, when he's pointed at them.
>
>> gave feedback. If the sender doesn't want to take his feedback into
>> account and prefer to send pretty insulting emails instead that is his
>> choice but I would say that is this not the greatest approach to get
>> your code merged (to say the least).
>
> Clearly not. But Pali found bug in code Felipe should
> maintain. Instead of "thank you for bug report, I applied this one
> line of your code to fix it", Pali got "new patch, new email" for his
> efforts. That is how you train dogs, not how you should treat kernel
> contributors.
>

No, you misunderstood the role of the maintainers. Maintainers should
be custodian of a part of the kernel but not responsible for every
single line of code on their sub-systems. If a piece of code is buggy
then the people using and that take care of that should be fixing and
maintainers should review and suggest improvements to the patches. As
long as a piece of code keep compiling then it is harmless even if is
buggy and nobody cares about it. If it is so broken that it doesn't
even compile then the maintainer can decide to just drop it since no
one else seems to care about it.

If someone finds a bug on a piece of code is because that people care
about that functionality. Maintainers are really busy people and can
jump and fix any random bug that someone finds on a piece of code just
because it is the subsystem they maintainer neither they have to
blindly merge any crappy patch just because they don't have time (or
interest) in fixing a reported bug on a piece of code.

> Now, it is possible that Felipe just has problems with english, as he
> called me piece of wood in https://lkml.org/lkml/2013/9/17/476 , but
> he appears more arogant than usual over email.
>

Clearly he meant "your commit log has garbage" instead of you're, that's a typo.

>                                                                 Pavel

But neither Felipe needs someone to defend him nor I have time to keep
arguing with you.

Have nice day!
Javier

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

On Wednesday 18 September 2013 15:57:13 Javier Martinez Canillas 
wrote:
> to split the patch in two since the patch was solving
> two separate issues

My patch does not solving *two* issues. It is *one* regression 
and both parts of patch are needed for fixing it. Read commit 
message again. It does not make sense to split patch fixing kernel 
regression into more one line patches - or please clarify why.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130918/e9dbd364/attachment.sig>

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

On Wed, Sep 18, 2013 at 05:56:12PM +0200, Pali Roh?r wrote:
> On Wednesday 18 September 2013 15:57:13 Javier Martinez Canillas 
> wrote:
> > to split the patch in two since the patch was solving
> > two separate issues
> 
> My patch does not solving *two* issues. It is *one* regression 
> and both parts of patch are needed for fixing it. Read commit 
> message again. It does not make sense to split patch fixing kernel 
> regression into more one line patches - or please clarify why.

issue 1) twl4030-usb.c doesn't initialize atomic notifier head
issue 2) musb doesn't call notifier chain

do you need a drawing ?

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130918/09be804b/attachment.sig>

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

On Wednesday 18 September 2013 18:36:49 Felipe Balbi wrote:
> On Wed, Sep 18, 2013 at 05:56:12PM +0200, Pali Roh?r wrote:
> > On Wednesday 18 September 2013 15:57:13 Javier Martinez
> > Canillas
> > 
> > wrote:
> > > to split the patch in two since the patch was solving
> > > two separate issues
> > 
> > My patch does not solving *two* issues. It is *one*
> > regression and both parts of patch are needed for fixing
> > it. Read commit message again. It does not make sense to
> > split patch fixing kernel regression into more one line
> > patches - or please clarify why.
> 
> issue 1) twl4030-usb.c doesn't initialize atomic notifier head
> issue 2) musb doesn't call notifier chain
> 
> do you need a drawing ?

Regression 1) power supply drivers not working since v3.5

Look at firsts emails.


Do you really have problem to do what *you* need with 1 line 
patch which I sent? Or what what you want?

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130918/7f96b2a0/attachment.sig>

[PATCH 1/4] usb: musb: Call atomic_notifier_call_chain when status is changed

[Felipe Balbi]

On Wed, Sep 18, 2013 at 06:43:49PM +0200, Pali Roh?r wrote:
> On Wednesday 18 September 2013 18:36:49 Felipe Balbi wrote:
> > On Wed, Sep 18, 2013 at 05:56:12PM +0200, Pali Roh?r wrote:
> > > On Wednesday 18 September 2013 15:57:13 Javier Martinez
> > > Canillas
> > > 
> > > wrote:
> > > > to split the patch in two since the patch was solving
> > > > two separate issues
> > > 
> > > My patch does not solving *two* issues. It is *one*
> > > regression and both parts of patch are needed for fixing
> > > it. Read commit message again. It does not make sense to
> > > split patch fixing kernel regression into more one line
> > > patches - or please clarify why.
> > 
> > issue 1) twl4030-usb.c doesn't initialize atomic notifier head
> > issue 2) musb doesn't call notifier chain
> > 
> > do you need a drawing ?
> 
> Regression 1) power supply drivers not working since v3.5
> 
> Look at firsts emails.
> 
> 
> Do you really have problem to do what *you* need with 1 line 
> patch which I sent? Or what what you want?

if you had already resent patches the way I requested, they'd already be
applied. Instead you chose to troll the people who are trying to helping
out.

You have two issues being fixed in the same patch and that's not
acceptable.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130918/68a1dfef/attachment-0001.sig>

[PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

[Pali Rohár]

&twl->phy.notifier is not initalized

Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>

diff --git a/drivers/usb/phy/phy-twl4030-usb.c b/drivers/usb/phy/phy-twl4030-usb.c
index 8f78d2d..efe6155 100644
--- a/drivers/usb/phy/phy-twl4030-usb.c
+++ b/drivers/usb/phy/phy-twl4030-usb.c
@@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct platform_device *pdev)
 	if (device_create_file(&pdev->dev, &dev_attr_vbus))
 		dev_warn(&pdev->dev, "could not create sysfs file\n");
 
+	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
+
 	/* Our job is to use irqs and status from the power module
 	 * to keep the transceiver disabled when nothing's connected.
 	 *
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130918/48b5af9e/attachment.sig>

[PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

[Pali Rohár]

On Wednesday 18 September 2013 19:03:33 Pali Roh?r wrote:
> &twl->phy.notifier is not initalized
> 
> Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> 
> diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> 100644
> --- a/drivers/usb/phy/phy-twl4030-usb.c
> +++ b/drivers/usb/phy/phy-twl4030-usb.c
> @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> platform_device *pdev) if (device_create_file(&pdev->dev,
> &dev_attr_vbus)) dev_warn(&pdev->dev, "could not create sysfs
> file\n");
> 
> +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> +
>  	/* Our job is to use irqs and status from the power module
>  	 * to keep the transceiver disabled when nothing's
> connected. *

I sent above patch week ago. Did you already included it?

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130925/e77b7f6a/attachment.sig>

[PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

[Felipe Balbi]

Hi,

On Wed, Sep 25, 2013 at 10:17:38AM +0200, Pali Roh?r wrote:
> On Wednesday 18 September 2013 19:03:33 Pali Roh?r wrote:
> > &twl->phy.notifier is not initalized
> > 
> > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> > 
> > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > 100644
> > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > platform_device *pdev) if (device_create_file(&pdev->dev,
> > &dev_attr_vbus)) dev_warn(&pdev->dev, "could not create sysfs
> > file\n");
> > 
> > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > +
> >  	/* Our job is to use irqs and status from the power module
> >  	 * to keep the transceiver disabled when nothing's
> > connected. *
> 
> I sent above patch week ago. Did you already included it?

look at my testing branch.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130925/4582c849/attachment.sig>

[PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

[Pavel Machek]

On Wed 2013-09-25 15:33:33, Felipe Balbi wrote:
> Hi,
> 
> On Wed, Sep 25, 2013 at 10:17:38AM +0200, Pali Roh?r wrote:
> > On Wednesday 18 September 2013 19:03:33 Pali Roh?r wrote:
> > > &twl->phy.notifier is not initalized
> > > 
> > > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> > > 
> > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > > 100644
> > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > platform_device *pdev) if (device_create_file(&pdev->dev,
> > > &dev_attr_vbus)) dev_warn(&pdev->dev, "could not create sysfs
> > > file\n");
> > > 
> > > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > > +
> > >  	/* Our job is to use irqs and status from the power module
> > >  	 * to keep the transceiver disabled when nothing's
> > > connected. *
> > 
> > I sent above patch week ago. Did you already included it?
> 
> look at my testing branch.

Felipe prefers you to go MAINTAINERS file for

git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git

entry. After few clicks, you'll find out your two patches in 

https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/log/?h=testing

. So yes, it seems that after 10+ flames Felipe was _not_ lazy to
send, "Thanks for a patch" mail was too much work.

Apparently, we'll need  Documentation/HowToBeGoodMaintainer file...

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH usb 1/2] usb: musb: Add missing ATOMIC_INIT_NOTIFIER_HEAD

[Felipe Balbi]

Hi,

On Thu, Sep 26, 2013 at 02:00:59AM +0200, Pavel Machek wrote:
> > On Wed, Sep 25, 2013 at 10:17:38AM +0200, Pali Roh?r wrote:
> > > On Wednesday 18 September 2013 19:03:33 Pali Roh?r wrote:
> > > > &twl->phy.notifier is not initalized
> > > > 
> > > > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> > > > 
> > > > diff --git a/drivers/usb/phy/phy-twl4030-usb.c
> > > > b/drivers/usb/phy/phy-twl4030-usb.c index 8f78d2d..efe6155
> > > > 100644
> > > > --- a/drivers/usb/phy/phy-twl4030-usb.c
> > > > +++ b/drivers/usb/phy/phy-twl4030-usb.c
> > > > @@ -705,6 +705,8 @@ static int twl4030_usb_probe(struct
> > > > platform_device *pdev) if (device_create_file(&pdev->dev,
> > > > &dev_attr_vbus)) dev_warn(&pdev->dev, "could not create sysfs
> > > > file\n");
> > > > 
> > > > +	ATOMIC_INIT_NOTIFIER_HEAD(&twl->phy.notifier);
> > > > +
> > > >  	/* Our job is to use irqs and status from the power module
> > > >  	 * to keep the transceiver disabled when nothing's
> > > > connected. *
> > > 
> > > I sent above patch week ago. Did you already included it?
> > 
> > look at my testing branch.
> 
> Felipe prefers you to go MAINTAINERS file for
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git
> 
> entry. After few clicks, you'll find out your two patches in 
> 
> https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/log/?h=testing
> 
> . So yes, it seems that after 10+ flames Felipe was _not_ lazy to
> send, "Thanks for a patch" mail was too much work.
> 
> Apparently, we'll need  Documentation/HowToBeGoodMaintainer file...

I only send my automated emails after properly testing them. They sit in
'testing' for as long as necessary. After all the test is done, they'll
be moved to 'next' at which point you get your email notification and
they reach linux-next for the next day.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131001/529e96bf/attachment-0001.sig>

[PATCH usb 2/2] usb: musb: Call atomic_notifier_call_chain when status is changed

[Pali Rohár]

More power supply drivers depends on vbus events and without it they not
working. Power supply drivers using usb_register_notifier, so to deliver
events it is needed to call atomic_notifier_call_chain.

So without atomic notifier power supply driver isp1704 not retrieving
vbus status and reporting bogus values to userspace and also to board
platform data functions. Without proper data charger drivers trying to
charge battery also when charger is disconnected or do not start charging
when wallcharger connects.

Atomic notifier in musb driver was used before v3.5 and was replaced with
omap mailbox. This patch adding atomic_notifier_call_chain call from
function omap_musb_set_mailbox.

Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>

diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f44e8b5..5c40252 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -305,6 +305,9 @@ static void omap_musb_set_mailbox(struct omap2430_glue *glue)
 	default:
 		dev_dbg(dev, "ID float\n");
 	}
+
+	atomic_notifier_call_chain(&musb->xceiv->notifier,
+			musb->xceiv->last_event, NULL);
 }
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130918/1407c00d/attachment.sig>

[PATCH 2/4] power: isp1704_charger: Fix driver to work with changes introduced in v3.5

[Pali Rohár]

* omap musb driver does not report USB_EVENT_ENUMERATED event anymore
* omap musb driver reporting USB_EVENT_VBUS when charger is connected
* read last event from phy->last_event (instead from ulpi register)
* do not call wall charger detection more times

Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
---
 drivers/power/isp1704_charger.c |   91 +++++++++++++++++----------------------
 1 file changed, 40 insertions(+), 51 deletions(-)

diff --git a/drivers/power/isp1704_charger.c b/drivers/power/isp1704_charger.c
index fc04d19..f726cb6 100644
--- a/drivers/power/isp1704_charger.c
+++ b/drivers/power/isp1704_charger.c
@@ -2,6 +2,7 @@
  * ISP1704 USB Charger Detection driver
  *
  * Copyright (C) 2010 Nokia Corporation
+ * Copyright (C) 2012 - 2013 Pali Roh?r <pali.rohar@gmail.com>
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -65,10 +66,6 @@ struct isp1704_charger {
 	unsigned		present:1;
 	unsigned		online:1;
 	unsigned		current_max;
-
-	/* temp storage variables */
-	unsigned long		event;
-	unsigned		max_power;
 };
 
 static inline int isp1704_read(struct isp1704_charger *isp, u32 reg)
@@ -231,56 +228,59 @@ static inline int isp1704_charger_detect(struct isp1704_charger *isp)
 	return ret;
 }
 
+static inline int isp1704_charger_detect_dcp(struct isp1704_charger *isp)
+{
+	if (isp1704_charger_detect(isp) &&
+		isp1704_charger_type(isp) == POWER_SUPPLY_TYPE_USB_DCP)
+		return true;
+	else
+		return false;
+}
+
 static void isp1704_charger_work(struct work_struct *data)
 {
-	int			detect;
-	unsigned long		event;
-	unsigned		power;
 	struct isp1704_charger	*isp =
 		container_of(data, struct isp1704_charger, work);
 	static DEFINE_MUTEX(lock);
 
-	event = isp->event;
-	power = isp->max_power;
-
 	mutex_lock(&lock);
 
-	if (event != USB_EVENT_NONE)
-		isp1704_charger_set_power(isp, 1);
-
-	switch (event) {
+	switch (isp->phy->last_event) {
 	case USB_EVENT_VBUS:
-		isp->online = true;
+		/* do not call wall charger detection more times */
+		if (!isp->present) {
+			isp->online = true;
+			isp->present = 1;
+			isp1704_charger_set_power(isp, 1);
+
+			/* detect wall charger */
+			if (isp1704_charger_detect_dcp(isp)) {
+				isp->psy.type = POWER_SUPPLY_TYPE_USB_DCP;
+				isp->current_max = 1800;
+			} else {
+				isp->psy.type = POWER_SUPPLY_TYPE_USB;
+				isp->current_max = 500;
+			}
 
-		/* detect charger */
-		detect = isp1704_charger_detect(isp);
-
-		if (detect) {
-			isp->present = detect;
-			isp->psy.type = isp1704_charger_type(isp);
+			/* enable data pullups */
+			if (isp->phy->otg->gadget)
+				usb_gadget_connect(isp->phy->otg->gadget);
 		}
 
-		switch (isp->psy.type) {
-		case POWER_SUPPLY_TYPE_USB_DCP:
-			isp->current_max = 1800;
-			break;
-		case POWER_SUPPLY_TYPE_USB_CDP:
+		if (isp->psy.type != POWER_SUPPLY_TYPE_USB_DCP) {
 			/*
 			 * Only 500mA here or high speed chirp
 			 * handshaking may break
 			 */
-			isp->current_max = 500;
-			/* FALLTHROUGH */
-		case POWER_SUPPLY_TYPE_USB:
-		default:
-			/* enable data pullups */
-			if (isp->phy->otg->gadget)
-				usb_gadget_connect(isp->phy->otg->gadget);
+			if (isp->current_max > 500)
+				isp->current_max = 500;
+
+			if (isp->current_max > 100)
+				isp->psy.type = POWER_SUPPLY_TYPE_USB_CDP;
 		}
 		break;
 	case USB_EVENT_NONE:
 		isp->online = false;
-		isp->current_max = 0;
 		isp->present = 0;
 		isp->current_max = 0;
 		isp->psy.type = POWER_SUPPLY_TYPE_USB;
@@ -298,12 +298,6 @@ static void isp1704_charger_work(struct work_struct *data)
 
 		isp1704_charger_set_power(isp, 0);
 		break;
-	case USB_EVENT_ENUMERATED:
-		if (isp->present)
-			isp->current_max = 1800;
-		else
-			isp->current_max = power;
-		break;
 	default:
 		goto out;
 	}
@@ -314,16 +308,11 @@ out:
 }
 
 static int isp1704_notifier_call(struct notifier_block *nb,
-		unsigned long event, void *power)
+		unsigned long val, void *v)
 {
 	struct isp1704_charger *isp =
 		container_of(nb, struct isp1704_charger, nb);
 
-	isp->event = event;
-
-	if (power)
-		isp->max_power = *((unsigned *)power);
-
 	schedule_work(&isp->work);
 
 	return NOTIFY_OK;
@@ -462,13 +451,13 @@ static int isp1704_charger_probe(struct platform_device *pdev)
 	if (isp->phy->otg->gadget)
 		usb_gadget_disconnect(isp->phy->otg->gadget);
 
+	if (isp->phy->last_event == USB_EVENT_NONE)
+		isp1704_charger_set_power(isp, 0);
+
 	/* Detect charger if VBUS is valid (the cable was already plugged). */
-	ret = isp1704_read(isp, ULPI_USB_INT_STS);
-	isp1704_charger_set_power(isp, 0);
-	if ((ret & ULPI_INT_VBUS_VALID) && !isp->phy->otg->default_a) {
-		isp->event = USB_EVENT_VBUS;
+	if (isp->phy->last_event == USB_EVENT_VBUS &&
+			!isp->phy->otg->default_a)
 		schedule_work(&isp->work);
-	}
 
 	return 0;
 fail2:
-- 
1.7.10.4

[PATCH 2/4] power: isp1704_charger: Fix driver to work with changes introduced in v3.5

[Anton Vorontsov]

On Sun, Sep 08, 2013 at 10:50:37AM +0200, Pali Roh?r wrote:
> * omap musb driver does not report USB_EVENT_ENUMERATED event anymore
> * omap musb driver reporting USB_EVENT_VBUS when charger is connected
> * read last event from phy->last_event (instead from ulpi register)
> * do not call wall charger detection more times
> 
> Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>

Applied, thanks a lot!

(Per others' review comments I am assuming that the second isp1704 patch
will be reworked to support device-tree, so I am not applying it.)

Thanks,

Anton

[PATCH 3/4] power: isp1704_charger: Add callback function set_current

[Pali Rohár]

This patch add callback function set_current to platform data.
Driver will call this function when isp1704 change current
and board provided this callback funtion in platform data.

This patch is needed for Nokia RX-51 to tell bq2415x charging
chip about connected wallcharger events.

Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
---
 drivers/power/isp1704_charger.c       |   16 ++++++++++++++++
 include/linux/power/isp1704_charger.h |    1 +
 2 files changed, 17 insertions(+)

diff --git a/drivers/power/isp1704_charger.c b/drivers/power/isp1704_charger.c
index f726cb6..4f20a1a 100644
--- a/drivers/power/isp1704_charger.c
+++ b/drivers/power/isp1704_charger.c
@@ -91,6 +91,18 @@ static void isp1704_charger_set_power(struct isp1704_charger *isp, bool on)
 }
 
 /*
+ * Set charger current from isp1704 if a function for it
+ * has been provided with platform data.
+ */
+static void isp1704_charger_set_current(struct isp1704_charger *isp, int mA)
+{
+	struct isp1704_charger_data *board = isp->dev->platform_data;
+
+	if (board && board->set_current)
+		board->set_current(mA);
+}
+
+/*
  * Determine is the charging port DCP (dedicated charger) or CDP (Host/HUB
  * chargers).
  *
@@ -257,6 +269,7 @@ static void isp1704_charger_work(struct work_struct *data)
 			if (isp1704_charger_detect_dcp(isp)) {
 				isp->psy.type = POWER_SUPPLY_TYPE_USB_DCP;
 				isp->current_max = 1800;
+				isp1704_charger_set_current(isp, 1800);
 			} else {
 				isp->psy.type = POWER_SUPPLY_TYPE_USB;
 				isp->current_max = 500;
@@ -277,6 +290,8 @@ static void isp1704_charger_work(struct work_struct *data)
 
 			if (isp->current_max > 100)
 				isp->psy.type = POWER_SUPPLY_TYPE_USB_CDP;
+
+			isp1704_charger_set_current(isp, isp->current_max);
 		}
 		break;
 	case USB_EVENT_NONE:
@@ -297,6 +312,7 @@ static void isp1704_charger_work(struct work_struct *data)
 			usb_gadget_disconnect(isp->phy->otg->gadget);
 
 		isp1704_charger_set_power(isp, 0);
+		isp1704_charger_set_current(isp, 0);
 		break;
 	default:
 		goto out;
diff --git a/include/linux/power/isp1704_charger.h b/include/linux/power/isp1704_charger.h
index 68096a6..d154b02 100644
--- a/include/linux/power/isp1704_charger.h
+++ b/include/linux/power/isp1704_charger.h
@@ -24,6 +24,7 @@
 
 struct isp1704_charger_data {
 	void		(*set_power)(bool on);
+	void		(*set_current)(int mA);
 };
 
 #endif
-- 
1.7.10.4

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Pali Rohár]

This patch will register bq24150a charger in RX-51 board data.
Patch also adding platform function between isp1704 and bq2415x
drivers for detecting charger type.

So finally charging battery on Nokia N900 (RX-51) working
automatically without any proprietary Nokia bits in userspace.

Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
---
 arch/arm/mach-omap2/board-rx51-peripherals.c |   56 +++++++++++++++++++++++++-
 1 file changed, 55 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c b/arch/arm/mach-omap2/board-rx51-peripherals.c
index 9c2dd10..a993ffe 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -25,6 +25,7 @@
 #include <linux/gpio_keys.h>
 #include <linux/mmc/host.h>
 #include <linux/power/isp1704_charger.h>
+#include <linux/power/bq2415x_charger.h>
 #include <linux/platform_data/spi-omap2-mcspi.h>
 #include <linux/platform_data/mtd-onenand-omap2.h>
 
@@ -270,6 +271,44 @@ static struct platform_device rx51_battery_device = {
 	.id	= -1,
 };
 
+static enum bq2415x_mode rx51_charger_mode = BQ2415X_MODE_OFF;
+static void *rx51_charger_hook_data;
+static void (*rx51_charger_hook)(enum bq2415x_mode mode, void *data);
+
+static int rx51_charger_set_hook(
+		void (*hook)(enum bq2415x_mode mode, void *data), void *data)
+{
+	rx51_charger_hook = hook;
+	rx51_charger_hook_data = data;
+	if (rx51_charger_hook)
+		rx51_charger_hook(rx51_charger_mode, rx51_charger_hook_data);
+	return 1;
+}
+
+static void rx51_charger_set_current(int mA)
+{
+	enum bq2415x_mode mode;
+
+	pr_info("RX-51: Charger current limit is %d mA\n", mA);
+
+	if (mA == 0)
+		mode = BQ2415X_MODE_OFF;
+	else if (mA < 500)
+		mode = BQ2415X_MODE_NONE;
+	else if (mA < 1800)
+		mode = BQ2415X_MODE_HOST_CHARGER;
+	else
+		mode = BQ2415X_MODE_DEDICATED_CHARGER;
+
+	if (rx51_charger_mode == mode)
+		return;
+
+	rx51_charger_mode = mode;
+
+	if (rx51_charger_hook)
+		rx51_charger_hook(rx51_charger_mode, rx51_charger_hook_data);
+}
+
 static void rx51_charger_set_power(bool on)
 {
 	gpio_set_value(RX51_USB_TRANSCEIVER_RST_GPIO, on);
@@ -277,6 +316,7 @@ static void rx51_charger_set_power(bool on)
 
 static struct isp1704_charger_data rx51_charger_data = {
 	.set_power	= rx51_charger_set_power,
+	.set_current	= rx51_charger_set_current,
 };
 
 static struct platform_device rx51_charger_device = {
@@ -1017,6 +1057,16 @@ static struct aic3x_pdata rx51_aic3x_data2 = {
 	.gpio_reset = 60,
 };
 
+static struct bq2415x_platform_data rx51_bq24150a_platform_data = {
+	.current_limit = 100,			/* mA */
+	.weak_battery_voltage = 3400,		/* mV */
+	.battery_regulation_voltage = 4200,	/* mV */
+	.charge_current = 650,			/* mA */
+	.termination_current = 100,		/* mA */
+	.resistor_sense = 68,			/* m ohm */
+	.set_mode_hook = &rx51_charger_set_hook,
+};
+
 static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[] = {
 	{
 		I2C_BOARD_INFO("tlv320aic3x", 0x18),
@@ -1044,7 +1094,11 @@ static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_2[] = {
 	{
 		I2C_BOARD_INFO("tpa6130a2", 0x60),
 		.platform_data = &rx51_tpa6130a2_data,
-	}
+	},
+	{
+		I2C_BOARD_INFO("bq24150a", 0x6b),
+		.platform_data = &rx51_bq24150a_platform_data,
+	},
 };
 
 static struct i2c_board_info __initdata rx51_peripherals_i2c_board_info_3[] = {
-- 
1.7.10.4

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Sebastian Reichel]

Hi Pali,

On Sun, Sep 08, 2013 at 10:50:39AM +0200, Pali Roh?r wrote:
> This patch will register bq24150a charger in RX-51 board data.
> Patch also adding platform function between isp1704 and bq2415x
> drivers for detecting charger type.
> 
> So finally charging battery on Nokia N900 (RX-51) working
> automatically without any proprietary Nokia bits in userspace.

cool :)

> index 9c2dd10..a993ffe 100644
> --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
> +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c

AFAIK platform code for omap3 based boards is supposed to be removed
in the near future [0]. Device Tree does not support the glue layer, so
probably a small rx51 specific driver is needed.

[0] https://lkml.org/lkml/2013/8/12/70

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130909/f57a5e5d/attachment-0001.sig>

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Pali Rohár]

On Sunday 08 September 2013 10:50:39 Pali Roh?r wrote:
> This patch will register bq24150a charger in RX-51 board data.
> Patch also adding platform function between isp1704 and
> bq2415x drivers for detecting charger type.
> 
> So finally charging battery on Nokia N900 (RX-51) working
> automatically without any proprietary Nokia bits in userspace.
> 
> Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> ---
>  arch/arm/mach-omap2/board-rx51-peripherals.c |   56
> +++++++++++++++++++++++++- 1 file changed, 55 insertions(+),
> 1 deletion(-)
> 
> diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
> b/arch/arm/mach-omap2/board-rx51-peripherals.c index
> 9c2dd10..a993ffe 100644
> --- a/arch/arm/mach-omap2/board-rx51-peripherals.c
> +++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
> @@ -25,6 +25,7 @@
>  #include <linux/gpio_keys.h>
>  #include <linux/mmc/host.h>
>  #include <linux/power/isp1704_charger.h>
> +#include <linux/power/bq2415x_charger.h>
>  #include <linux/platform_data/spi-omap2-mcspi.h>
>  #include <linux/platform_data/mtd-onenand-omap2.h>
> 
> @@ -270,6 +271,44 @@ static struct platform_device
> rx51_battery_device = { .id	= -1,
>  };
> 
> +static enum bq2415x_mode rx51_charger_mode =
> BQ2415X_MODE_OFF; +static void *rx51_charger_hook_data;
> +static void (*rx51_charger_hook)(enum bq2415x_mode mode, void
> *data); +
> +static int rx51_charger_set_hook(
> +		void (*hook)(enum bq2415x_mode mode, void *data), void
> *data) +{
> +	rx51_charger_hook = hook;
> +	rx51_charger_hook_data = data;
> +	if (rx51_charger_hook)
> +		rx51_charger_hook(rx51_charger_mode,
> rx51_charger_hook_data); +	return 1;
> +}
> +
> +static void rx51_charger_set_current(int mA)
> +{
> +	enum bq2415x_mode mode;
> +
> +	pr_info("RX-51: Charger current limit is %d mA\n", mA);
> +
> +	if (mA == 0)
> +		mode = BQ2415X_MODE_OFF;
> +	else if (mA < 500)
> +		mode = BQ2415X_MODE_NONE;
> +	else if (mA < 1800)
> +		mode = BQ2415X_MODE_HOST_CHARGER;
> +	else
> +		mode = BQ2415X_MODE_DEDICATED_CHARGER;
> +
> +	if (rx51_charger_mode == mode)
> +		return;
> +
> +	rx51_charger_mode = mode;
> +
> +	if (rx51_charger_hook)
> +		rx51_charger_hook(rx51_charger_mode,
> rx51_charger_hook_data); +}
> +
>  static void rx51_charger_set_power(bool on)
>  {
>  	gpio_set_value(RX51_USB_TRANSCEIVER_RST_GPIO, on);
> @@ -277,6 +316,7 @@ static void rx51_charger_set_power(bool
> on)
> 
>  static struct isp1704_charger_data rx51_charger_data = {
>  	.set_power	= rx51_charger_set_power,
> +	.set_current	= rx51_charger_set_current,
>  };
> 
>  static struct platform_device rx51_charger_device = {
> @@ -1017,6 +1057,16 @@ static struct aic3x_pdata
> rx51_aic3x_data2 = { .gpio_reset = 60,
>  };
> 
> +static struct bq2415x_platform_data
> rx51_bq24150a_platform_data = { +	.current_limit = 100,			
/*
> mA */
> +	.weak_battery_voltage = 3400,		/* mV */
> +	.battery_regulation_voltage = 4200,	/* mV */
> +	.charge_current = 650,			/* mA */
> +	.termination_current = 100,		/* mA */
> +	.resistor_sense = 68,			/* m ohm */
> +	.set_mode_hook = &rx51_charger_set_hook,
> +};
> +
>  static struct i2c_board_info __initdata
> rx51_peripherals_i2c_board_info_2[] = { {
>  		I2C_BOARD_INFO("tlv320aic3x", 0x18),
> @@ -1044,7 +1094,11 @@ static struct i2c_board_info __initdata
> rx51_peripherals_i2c_board_info_2[] = { {
>  		I2C_BOARD_INFO("tpa6130a2", 0x60),
>  		.platform_data = &rx51_tpa6130a2_data,
> -	}
> +	},
> +	{
> +		I2C_BOARD_INFO("bq24150a", 0x6b),
> +		.platform_data = &rx51_bq24150a_platform_data,
> +	},
>  };
> 
>  static struct i2c_board_info __initdata
> rx51_peripherals_i2c_board_info_3[] = {

Tony, can you look and review this board patch?

I think that this patch series it the most important for Nokia 
N900, because it finally bringing charging support. And without 
charging battery it very hard to use phone which has power supply 
only from battery.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130920/f25e367a/attachment.sig>

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Tony Lindgren]

* Pali Roh?r <pali.rohar@gmail.com> [130920 12:29]:
> On Sunday 08 September 2013 10:50:39 Pali Roh?r wrote:
> > This patch will register bq24150a charger in RX-51 board data.
> > Patch also adding platform function between isp1704 and
> > bq2415x drivers for detecting charger type.
> > 
> > So finally charging battery on Nokia N900 (RX-51) working
> > automatically without any proprietary Nokia bits in userspace.
...
 
> > @@ -277,6 +316,7 @@ static void rx51_charger_set_power(bool
> > on)
> > 
> >  static struct isp1704_charger_data rx51_charger_data = {
> >  	.set_power	= rx51_charger_set_power,
> > +	.set_current	= rx51_charger_set_current,
> >  };

We want to get rid of the platform data callbacks here,
there no longer any need to keep these under arch/arm.

> Tony, can you look and review this board patch?

Yes, looks like this can all be done in the driver nowadays.
You can use drivers/reset for the set_power. Or if it's really
controlling the regulator, then the regulator framework. The
info can be passed in a .dts file for those.

The .set_current you can do in the driver based on the
compatible flag.
 
> I think that this patch series it the most important for Nokia 
> N900, because it finally bringing charging support. And without 
> charging battery it very hard to use phone which has power supply 
> only from battery.

Right, let's get this driver updated to use the device tree
based init and that way this file is no longer needed.
I would like to $ grep -i grandmom ~/.phonebook | call too :)

I forgot how this charger is wired up, but maybe take a
look at commit d7bf353f (bq24190_charger: Add support for TI
BQ24190 Battery Charger) for the DT parts.

Regards,

Tony

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Pali Rohár]

Hello,

On Monday 23 September 2013 20:03:00 you wrote:
> * Pali Roh?r <pali.rohar@gmail.com> [130920 12:29]:
> > On Sunday 08 September 2013 10:50:39 Pali Roh?r wrote:
> > > This patch will register bq24150a charger in RX-51 board
> > > data. Patch also adding platform function between isp1704
> > > and bq2415x drivers for detecting charger type.
> > > 
> > > So finally charging battery on Nokia N900 (RX-51) working
> > > automatically without any proprietary Nokia bits in
> > > userspace.
> 
> ...
> 
> > > @@ -277,6 +316,7 @@ static void
> > > rx51_charger_set_power(bool on)
> > > 
> > >  static struct isp1704_charger_data rx51_charger_data = {
> > >  
> > >  	.set_power	= rx51_charger_set_power,
> > > 
> > > +	.set_current	= rx51_charger_set_current,
> > > 
> > >  };
> 
> We want to get rid of the platform data callbacks here,
> there no longer any need to keep these under arch/arm.
> 

Where to put rx51 board specified functions?
It cannot go to DT, because DT does not support C/ASM code.

> > Tony, can you look and review this board patch?
> 
> Yes, looks like this can all be done in the driver nowadays.
> You can use drivers/reset for the set_power. Or if it's really
> controlling the regulator, then the regulator framework. The
> info can be passed in a .dts file for those.
> 
> The .set_current you can do in the driver based on the
> compatible flag.
> 

It is not as simple as it looks. This is reason why I submited 
this patch long time after I submited bq2415x driver.

Problem is that for rx51 is needed specific function which connect 
to two drivers (bq2415x and isp1704) plus it call specific rx51 
board functions.

Something which cannot be in DT (unless DT support C/ASM code).

> > I think that this patch series it the most important for
> > Nokia N900, because it finally bringing charging support.
> > And without charging battery it very hard to use phone
> > which has power supply only from battery.
> 
> Right, let's get this driver updated to use the device tree
> based init and that way this file is no longer needed.
> I would like to $ grep -i grandmom ~/.phonebook | call too :)
> 

Patches for modem support are being prepared for upstreaming :-) 
so after that it is up to you to create "call" script as you want

> I forgot how this charger is wired up, but maybe take a
> look at commit d7bf353f (bq24190_charger: Add support for TI
> BQ24190 Battery Charger) for the DT parts.
> 
> Regards,
> 
> Tony

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130923/2395c3e1/attachment.sig>

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Sebastian Reichel]

On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Roh?r wrote:
> It is not as simple as it looks. This is reason why I submited 
> this patch long time after I submited bq2415x driver.
> 
> Problem is that for rx51 is needed specific function which connect 
> to two drivers (bq2415x and isp1704) plus it call specific rx51 
> board functions.
> 
> Something which cannot be in DT (unless DT support C/ASM code).

mh could isp1704 driver expose the data via the regulator framework?
Then the bq2415x chip can just use the regulator framework. This
should make converting to DT easy (by giving the bq2415x chip the
isp1704 as regulator) and uses existing standard interfaces.

> Patches for modem support are being prepared for upstreaming :-) 
> so after that it is up to you to create "call" script as you want

I'm on it. RFC round will be sent out this week. It seems
hwmod data is already finished, since i didn't get feedback for
that patch :)

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130923/853a6857/attachment.sig>

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Pali Rohár]

On Monday 23 September 2013 22:00:09 Sebastian Reichel wrote:
> On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Roh?r wrote:
> > It is not as simple as it looks. This is reason why I
> > submited this patch long time after I submited bq2415x
> > driver.
> > 
> > Problem is that for rx51 is needed specific function which
> > connect to two drivers (bq2415x and isp1704) plus it call
> > specific rx51 board functions.
> > 
> > Something which cannot be in DT (unless DT support C/ASM
> > code).
> 
> mh could isp1704 driver expose the data via the regulator
> framework?

No, isp1704 is power supply driver and export data via power 
supply (sysfs) interface. It is not regulator but charger driver.

> Then the bq2415x chip can just use the regulator
> framework. This should make converting to DT easy (by giving
> the bq2415x chip the isp1704 as regulator) and uses existing
> standard interfaces.
> 
> > Patches for modem support are being prepared for upstreaming
> > :-) so after that it is up to you to create "call" script
> > as you want
> 
> I'm on it. RFC round will be sent out this week. It seems
> hwmod data is already finished, since i didn't get feedback
> for that patch :)
> 
> -- Sebastian

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130923/07adf26c/attachment.sig>

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Sebastian Reichel]

On Mon, Sep 23, 2013 at 10:06:46PM +0200, Pali Roh?r wrote:
> On Monday 23 September 2013 22:00:09 Sebastian Reichel wrote:
> > On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Roh?r wrote:
> > > It is not as simple as it looks. This is reason why I
> > > submited this patch long time after I submited bq2415x
> > > driver.
> > > 
> > > Problem is that for rx51 is needed specific function which
> > > connect to two drivers (bq2415x and isp1704) plus it call
> > > specific rx51 board functions.
> > > 
> > > Something which cannot be in DT (unless DT support C/ASM
> > > code).
> > 
> > mh could isp1704 driver expose the data via the regulator
> > framework?
> 
> No, isp1704 is power supply driver and export data via power 
> supply (sysfs) interface. It is not regulator but charger driver.

well it does not charge the battery directly, but just provides a
power line with 5 Volt and a specified amount of current to the
system, doesn't it?

>From my POV this is a candiate for the regulator framework:

https://www.kernel.org/doc/Documentation/power/regulator/overview.txt

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130923/458b2b62/attachment.sig>

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Tony Lindgren]

* Sebastian Reichel <sre@ring0.de> [130923 13:55]:
> On Mon, Sep 23, 2013 at 10:06:46PM +0200, Pali Roh?r wrote:
> > On Monday 23 September 2013 22:00:09 Sebastian Reichel wrote:
> > > On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Roh?r wrote:
> > > > It is not as simple as it looks. This is reason why I
> > > > submited this patch long time after I submited bq2415x
> > > > driver.
> > > > 
> > > > Problem is that for rx51 is needed specific function which
> > > > connect to two drivers (bq2415x and isp1704) plus it call
> > > > specific rx51 board functions.
> > > > 
> > > > Something which cannot be in DT (unless DT support C/ASM
> > > > code).
> > > 
> > > mh could isp1704 driver expose the data via the regulator
> > > framework?
> > 
> > No, isp1704 is power supply driver and export data via power 
> > supply (sysfs) interface. It is not regulator but charger driver.
> 
> well it does not charge the battery directly, but just provides a
> power line with 5 Volt and a specified amount of current to the
> system, doesn't it?
> 
> From my POV this is a candiate for the regulator framework:
> 
> https://www.kernel.org/doc/Documentation/power/regulator/overview.txt

Yes I think we should be able handle that rail with the
regulator framework.

Regards,

Tony

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Pavel Machek]

Hi!

> > No, isp1704 is power supply driver and export data via power 
> > supply (sysfs) interface. It is not regulator but charger driver.
> 
> well it does not charge the battery directly, but just provides a
> power line with 5 Volt and a specified amount of current to the
> system, doesn't it?

I don't want to talk about isp1704, but...

LiION charger is just something that provides 4.2V power line with
C/10 current limitation...

(IOW line between regulators and chargers is very very thin, if it
even exists).

									Pavel

            (who did use laboratory power supply as emergency battery charger)
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Pali Rohár]

On Monday 23 September 2013 22:47:15 Sebastian Reichel wrote:
> On Mon, Sep 23, 2013 at 10:06:46PM +0200, Pali Roh?r wrote:
> > On Monday 23 September 2013 22:00:09 Sebastian Reichel wrote:
> > > On Mon, Sep 23, 2013 at 09:16:18PM +0200, Pali Roh?r wrote:
> > > > It is not as simple as it looks. This is reason why I
> > > > submited this patch long time after I submited bq2415x
> > > > driver.
> > > > 
> > > > Problem is that for rx51 is needed specific function
> > > > which connect to two drivers (bq2415x and isp1704) plus
> > > > it call specific rx51 board functions.
> > > > 
> > > > Something which cannot be in DT (unless DT support C/ASM
> > > > code).
> > > 
> > > mh could isp1704 driver expose the data via the regulator
> > > framework?
> > 
> > No, isp1704 is power supply driver and export data via power
> > supply (sysfs) interface. It is not regulator but charger
> > driver.
> 
> well it does not charge the battery directly, but just
> provides a power line with 5 Volt and a specified amount of
> current to the system, doesn't it?
> 

No, isp1704 driver is doing fastcharger detection (and then 
export charger type via sysfs power supply) based on musb usb 
events.

Real charging (enabling/disabling and setting properties) is done 
by bq24150a chip which has own power driver bq2415x_charger.

As already wrote this is not simple and this is reason why I sent 
board data and functions only now...

> From my POV this is a candiate for the regulator framework:
> 
> https://www.kernel.org/doc/Documentation/power/regulator/overv
> iew.txt
> 
> -- Sebastian

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130924/23254e9e/attachment.sig>

[PATCH 4/4] RX-51: Add platform function and data for bq24150a charger

[Sebastian Reichel]

Hi,

On Tue, Sep 24, 2013 at 07:05:47PM +0200, Pali Roh?r wrote:
> No, isp1704 driver is doing fastcharger detection (and then 
> export charger type via sysfs power supply) based on musb usb 
> events.
> 
> Real charging (enabling/disabling and setting properties) is done 
> by bq24150a chip which has own power driver bq2415x_charger.
> 
> As already wrote this is not simple and this is reason why I sent 
> board data and functions only now...

Yes, I'm aware of this. Technically the isp1704 does not provide the
5 volt line, but for the system as a whole that fact does not really
matter.

The isp1704 can provide its functionality via the regulator API
as a simple regulator device. It provides information about the
power "it can supply".

The bq24150a on the other hand can just use the regulator via the
consumer interface.

The regulator framework provides capabilities for events:
"Regulators can notify consumers of external events"

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130924/649da08c/attachment.sig>

[PATCH 0/4] Add support for charging battery in Nokia RX-51

[Pali Rohár]

On Sunday 08 September 2013 10:50:35 Pali Roh?r wrote:
> This patch series finally bringing support for charging
> battery on Nokia N900 (RX-51) without any proprietary Nokia
> bits in userspace.
> 
> Pali Roh?r (4):
>   usb: musb: Call atomic_notifier_call_chain when status is
> changed power: isp1704_charger: Fix driver to work with
> changes introduced in v3.5
>   power: isp1704_charger: Add callback function set_current
>   RX-51: Add platform function and data for bq24150a charger
> 
>  arch/arm/mach-omap2/board-rx51-peripherals.c |   56
> +++++++++++++- drivers/power/isp1704_charger.c              |
>  107 ++++++++++++++------------ drivers/usb/musb/omap2430.c  
>                |    3 + drivers/usb/phy/phy-twl4030-usb.c    
>        |    2 + include/linux/power/isp1704_charger.h       
> |    1 + 5 files changed, 117 insertions(+), 52 deletions(-)

Hello, can you review this patch series?

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130914/5e97a21a/attachment.sig>

[PATCH 0/4] Add support for charging battery in Nokia RX-51

[Pali Rohár]

On Sunday 08 September 2013 10:50:35 Pali Roh?r wrote:
> This patch series finally bringing support for charging
> battery on Nokia N900 (RX-51) without any proprietary Nokia
> bits in userspace.
> 
> Pali Roh?r (4):
>   usb: musb: Call atomic_notifier_call_chain when status is
> changed power: isp1704_charger: Fix driver to work with
> changes introduced in v3.5
>   power: isp1704_charger: Add callback function set_current
>   RX-51: Add platform function and data for bq24150a charger
> 
>  arch/arm/mach-omap2/board-rx51-peripherals.c |   56
> +++++++++++++- drivers/power/isp1704_charger.c              |
>  107 ++++++++++++++------------ drivers/usb/musb/omap2430.c  
>                |    3 + drivers/usb/phy/phy-twl4030-usb.c    
>        |    2 + include/linux/power/isp1704_charger.h       
> |    1 + 5 files changed, 117 insertions(+), 52 deletions(-)

Anton, can you review this patch series, specially power supply 
code (changes to isp1704_charger.c driver)?

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130921/ac95098d/attachment.sig>