Hi Greg, >>> 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 am sorry if you feel like ignored by us. I understand your point that code clean should go first to get out of staging tree. Actually we are giving effort code-clean work in parallel as well. And from now on we will definitely spend more time for code cleaning. However we also need to add necessary features in time to make progress in current project. Again we will put more time to code cleaning from now on and in the meantime, we may need to add small new features and some bug fixes. I hope your best understanding. Thanks Nohee -----Original Message----- From: Greg KH [mailto:greg@xxxxxxxxx] Sent: Thursday, October 21, 2010 10:31 AM To: Grant Grundler Cc: Nohee Ko; devel@xxxxxxxxxxxxxxxxxxxxxx; Brett Rudley; Henry Ptasinski; Venkat Rao Subject: Re: [PATCH] staging:brcm80211:brcmfmac:add dongle power on/off functions On Thu, Oct 21, 2010 at 10:03:19AM -0700, Grant Grundler wrote: > On Wed, Oct 20, 2010 at 9:04 PM, Greg KH <greg@xxxxxxxxx> wrote: > > On Wed, Oct 20, 2010 at 06:22:57PM -0700, nohee ko wrote: > >> Add dongle power on/off functions. > >> Power save feature is essential in wi-fi > >> fullmac model. And this feature was missing. > > > > Nice feature. > > > > Unfortunately this patch (and your second one) goes against the "no more > > features" rule I said, and you all agreed to, a few days ago. > > 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? I don't see any patches here from you. 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? greg k-h > > Broadcom knows staging-next isn't where they can "compete" with other > wireless device mfg's. Beating them more with a stick isn't going to help. > > While it's annoying to see Broadcom not submit more cleanup stuff, > it would be more pragmatic to let Broadcom add features that require > specialized knowledge *whenever they can* and continue to accept > "cleanup" patches from everyone (*including* Broadcom). I haven't seen > any shortage of cleanup patches for this driver. > > Also, four times now I've pulled staging-next-2.6 and tested brcm drivers > using autotest suite (available on git.chromium.org) created by Sam Leffler > and Paul Stewart. NOT including new features just means it will be that > much longer before I (or anyone else) can regression test with those features. > > > > Also, the merge window for new stuff for .37 is now over. > > staging-next-2.6 is subject to merge windows? Why? > Sorry - this must be a FAQ but google is failing to find a > "staging-next-2.6 FAQ". > > > So, care to start work on fixing other stuff in the driver first? Then > > I will be glad to take these two patches, but until then, I will not. > > Is there a list of "other stuff" someplace? > If these are in previously posted code reviews, I can look for those. > > Here is my own list: > o remove get_fs/get_ds() usage - I believe this is 2.4 left-overs. > o consistent use of "ndev" vs "dev" (ie struct netdevice) > o use linux/xxx.h, not asm/xxx.h (kernel janitor work) > o rework wl_debug_level setting (it's a mess of pointless accessor functions) > o delete include/pcicfg.h > > I'm not working on any of these things at the moment - other firedrills. :( > > thanks, > grant _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
