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. 2. Even through I'll be making a gazillion changes, it needs to be clear I'm not the origin of the driver. 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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
