[PATCH] staging:brcm80211:brcmfmac:add dongle power on/off functions

[Greg KH]

On Thu, Oct 21, 2010 at 11:12:19AM -0700, Grant Grundler wrote:
> On Thu, Oct 21, 2010 at 10:30 AM, Greg KH <greg at kroah.com> wrote:
> ...
> >> Rules are meant to be broken. :P
> >> Seriously, I'm only seeing downside to this rule and am missing the upside.
> >
> > And I'm missing the point where your comments are relevant here.  How
> > did you get involved in the Broadcom driver work?
> 
> Job Hazard. :)  "Google is constantly evaluating new technologies."
> 
> I've spent way more than 40h looking at this driver, worked directly
> with Nohee on issues I've seen, and more hours on testing? I've shared
> my TODO list with Nohee more than a week ago and have sent some code
> changes directly to Broadcom. I don't need to take credit for changing
> "FALSE" to "false".

I changed FALSE to false, not you, or broadcom, just look at commit
0965ae88aff802ff48fa2f35fff29feff2754962 in linux-next :)

> (no offense intended to whoever submitted that patch; Just expressing my needs.)

That's nice, but this is the very first time I have every heard of this,
how was I supposed to guess this before now?

> > I don't see any  patches here from you.
> 
> Are you suggesting signed-off-by lines are the only thing worth to measure?
> Testing and code review not worth anything?

It is, but again, I have not seen anything from you for this before now.
It is between you and Broadcom for them not crediting you with anything,
how can you expect me to know this?

> Or is advice/criticism hard to accept gracefully? (e.g. "thanks, but no.")
> 
> I don't think I've deserved getting my ears boxed over this. I'm honestly
> trying to be constructive. I apologize if my message came across as if
> I own your sandbox.
> 
> BTW, factually, this comment is not true. Maybe overlooked the
> patch I submitted recently because it was mis-attributed?
> 
> commit 93ad12cf1a8c3be46d66581a7acaa1c7fce590e2
> Author: nohee ko <noheek at broadcom.com>
> Date:   Tue Oct 5 18:05:04 2010 -0700
> 
>     staging: brcm80211: bug fix for n_ssids usage and update drv_info
> 
>     -update drv_info so it's visible in "ethtool -i" output
>     -remove n_ssids usage. Fixes nullptr deref bug seen before.
> 
>     Signed-off-by: Grant Grundler <grundler at chromium.org>
>     Acked-by: Nohee Ko <noheek at broadcom.com>
>     Signed-off-by: Greg Kroah-Hartman <gregkh at suse.de>

Ick, I did overlook that.

Did you really write that?

If so, Nohee messed up big time.  You should have gotten the proper
credit for it.

Nohee, go re-read Documentation/SubmittingPatches for how to properly
attribute the author of a patch.  Please don't make that mistake again.

> > And most importantly, the developers involved AGREED with my "no more
> > features" rule, and then instantly turned around and ignored it.  How
> > would you treat such a thing if you were a maintainer?
> 
> I wouldn't have made such a rule. The rule contradicts the primary
> concept of drivers/staging: enable HW vendors to publish drivers, get
> feedback, and shepherd the technology/device support into regular
> driver tree.

Here's my feedback, "I need to see more cleanup happening before we can
take new features" :)

I've made this before to other companies.  It's a carrot to use to get
things moving when I think it isn't.

thanks,

greg k-h