On Thu, Jan 19, 2017 at 04:07:15AM -0800, Michael Zoran wrote: > On Thu, 2017-01-19 at 14:34 +0300, Dan Carpenter wrote: > > On Thu, Jan 19, 2017 at 03:27:56AM -0800, Michael Zoran wrote: > > > On Thu, 2017-01-19 at 13:10 +0300, Dan Carpenter wrote: > > > All these silly white space issues in the existing code could be > > > fixed > > > in 10 seconds with netbeans or eclipse at once and we would be done > > > with it for good. Essentially just run the whole driver through > > > the > > > pretty printer. In fact, I don't know why that wasn't done with > > > the > > > initial check-in or how any of this existing code was able to be > > > checked in without a gazillion checkpatch.pl errors... > > > > checkpatch.pl can actually fix a lot of the errors it complains > > about. > > It's probably smarter about kernel requirements than netbeans is. > > > > The answer is that we don't care about checkpatch.pl for initial > > staging > > commits. Also it's partly that Greg deliberately the white space > > errors > > in there to keep the newbies busy. But if you're serious about this > > code then feel free to fix them all at once. > > > > Use checkpatch.pl --fix whatever to fix each type of warning across > > the > > whole driver and send them as a series of patches. Don't fix > > different > > types of errors in the same patch. > > > > regards, > > dan carpenter > > > > For the sake of progress, I'm certainly willing to run the whole driver > through "checkpatch.pl --fix" in stages. > > I do have two "demands" through if I go that route: > > 1. The Kconfig needs to be modified so that the driver is out of the > build by default unless pulled in by a dependency of another > driver/module or explicitly pulled in by the builder's .config or a > checked in defconfig. At least until the driver "graduates" out of the > staging tree. I'm willing to submit a patch changing the default in > Kconfig to N. Why? It should always build. > 2. Even through I'll be making a gazillion changes, it needs to be > clear I'm not the origin of the driver. The git history shows that :) > This driver isn't exactly the best example of quality software > engineering, so I don't want my head on a platter if something goes > wrong with it. Raspbian has their own requirements and at this point > the kernel for the RPI should be the only thing using this driver. At > least until it gets cleaned up. > > That said about the driver, the driver still has hope for it that it > can be fixed and I think that's the better approach then writing it > from scratch at this time. > > Another change is pending that syncs this driver up better with the RPI > downstream kernel tree. If we go that route, it's probably better to > wait until that changes gets merged in first. > > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2017- > January/098977.html Those patches are all now merged in my staging-testing branch waiting for some test builds to finish before being merged to staging-next and show up in the next linux-next release. thanks, greg k-h _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
