| Message ID | 201309181020.15245@pali (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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
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
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
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
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
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.
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).
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 ?
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?
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.
============================ ==== 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. *