[PATCH 6/9] VC04_SERVICES: Add compat ioctl handler for "await completion"

[Greg KH]

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