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

login
register
mail settings
Submitter Pali Rohár
Date Sept. 8, 2013, 8:50 a.m.
Message ID <1378630239-10006-2-git-send-email-pali.rohar@gmail.com>
Download mbox | patch
Permalink /patch/273424/
State New
Headers show

Comments

Pali Rohár - Sept. 8, 2013, 8:50 a.m.
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(+)
Felipe Balbi - Sept. 17, 2013, 3:48 p.m.
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);
}
Felipe Balbi - Sept. 17, 2013, 3:49 p.m.
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.
Pali Rohár - Sept. 17, 2013, 4:05 p.m.
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.
Felipe Balbi - Sept. 17, 2013, 4:08 p.m.
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.
Pali Rohár - Sept. 17, 2013, 7:28 p.m.
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?
Felipe Balbi - Sept. 18, 2013, 1:49 a.m.
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
Javier Martinez Canillas - Sept. 18, 2013, 9:04 a.m.
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@gmail.com

Best regards,
Javier
Pavel Machek - Sept. 18, 2013, 1:30 p.m.
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
Javier Martinez Canillas - Sept. 18, 2013, 1:57 p.m.
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
Pavel Machek - Sept. 18, 2013, 2:22 p.m.
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
Pavel Machek - Sept. 18, 2013, 2:35 p.m.
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
Javier Martinez Canillas - Sept. 18, 2013, 2:53 p.m.
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
Pali Rohár - Sept. 18, 2013, 3:56 p.m.
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.
Felipe Balbi - Sept. 18, 2013, 4:25 p.m.
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).
Felipe Balbi - Sept. 18, 2013, 4:36 p.m.
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 ?
Pali Rohár - Sept. 18, 2013, 4:43 p.m.
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?
Felipe Balbi - Sept. 18, 2013, 4:48 p.m.
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.
Pali Rohár - Sept. 25, 2013, 8:17 a.m.
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?
Felipe Balbi - Sept. 25, 2013, 8:33 p.m.
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.
Pavel Machek - Sept. 26, 2013, midnight
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
Felipe Balbi - Oct. 1, 2013, 2:22 p.m.
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.

Patch

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