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

Michael Zoran mzoran at crowfest.net
Thu Jan 19 05:12:11 PST 2017

On Thu, 2017-01-19 at 13:22 +0100, Greg KH wrote:
> 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
> > 
> > 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.

Yes, it should and ideally it should aways be built by the error
checking robots.  What isn't clear to me is if it is really ready to be
included on default kernel images on platforms that have nothing to do
with the RPI. Or even platforms other then ARM or ARM64.

I can't think of any issues with the driver, but it's a very big driver
written with low quality code.  It seems there needs to a phase in
driver development where the driver is being constantly compiled and
checked in the background yet not quite ready to end up "everywhere". 

> > 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 :)

Yes, it does. But I don't want to be the owner just yet just because I
"touched" 90% of the lines in the driver:)

> > http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2
> > 017-
> > 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.


More information about the linux-rpi-kernel mailing list