linux-kernel - Re: [PATCH 0/2] etzkx accelerometer support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 8 Aug 2013 15:25:24 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Andi Shyti <andi@...zian.org>
Cc:	oatilla@...il.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] etzkx accelerometer support

On Fri, Aug 09, 2013 at 12:21:08AM +0200, Andi Shyti wrote:
> Hi Greg,
> 
> > > > > these two patches provide the etzkx device driver which supports
> > > > > the following accelerometers:
> > > > 
> > > > Why isn't this a drivers/iio/accel/ driver instead of a misc driver?
> > > > Please make this an iio driver, then you will be using the correct
> > > > user/kernel api to talk to your device.
> > > 
> > > I was thinking it may be an issue, but it's not iio because the
> > > time I developed the driver, iio was in the first staging period
> > > and mainly because the on the board I'm using I cannot update the
> > > Kernel to use the latest iio.
> > > 
> > > I guess you don't like the promise "I can do it later" once the
> > > supplier sends me a development board (which is planned) :)
> > 
> > Sure, I'll gladly accept "I can do it later" from anyone, as long as you
> > don't mind my, "I will merge it later" as well :)
> > 
> > Sorry, I can't accept a driver now, that is known to going to be
> > changing the kernel/user api in the future.  So please, rewrite it to
> > use IIO, that's what that interface / subsystem is there for.
> 
> What about submitting this accelerometer driver under staging
> even if it's still not iio and slowly put it in shape?

There are a number of staging iio drivers already, why not put it there?

I don't want to accept a driver with a user/kernel interface that we
know is wrong, into staging.  What is wrong with taking a few days to
fix this up now?  If you aren't willing to do it now, why would I
believe that you will be willing to do it in the future once it is in
staging?  :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/