linux-kernel - Re: [PATCH] Add STMicroelectronics LPS001WP pressure sensor device driver into misc

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:	Tue, 15 Mar 2011 17:50:33 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Jonathan Cameron <jic23@....ac.uk>
Cc:	Jean Delvare <khali@...ux-fr.org>,
	mems applications <mems.applications@...com>,
	rdunlap@...otime.net, carmine.iascone@...com, matteo.dameno@...com,
	rubini@...vis.unipv.it, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Guenter Roeck <guenter.roeck@...csson.com>,
	Greg KH <greg@...ah.com>,
	"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>
Subject: Re: [PATCH] Add STMicroelectronics LPS001WP pressure sensor device driver into misc

On Tuesday 15 March 2011, Jonathan Cameron wrote:
> On 03/15/11 13:29, Arnd Bergmann wrote:
> > On Tuesday 15 March 2011, Jonathan Cameron wrote:
> >> An interesting idea though I'm not entirely sure how it would
> >> work in practice.
> >> Two options occurred whilst cycling in this morning.
> >> 1) Spit functionality out in staging. This would give a core
> >> set that is basically the sysfs only stuff.  To do that we'd
> >> have to define a struct iio_dev_basic and make it an element
> >> of the iio_dev.  Prior to that we'd probably need to make pretty
> >> much all accesses into iio_dev via macros / inline functions 
> >> which would not be a trivial undertaking.
> > 
> > I think if you try to maintain compatibility between the
> > basic drivers and the complex stuff in the same tree, you
> > won't be able to gain much. Any major changes to address the TODO
> > items would still potentially impact all drivers.
>
> True though the todo's I know about shouldn't cause trouble for
> the simple drivers.

Ok. If that's the case, it may be simpler to just get the
core into shape for merging, and then do one driver at a
time, but leave all other drivers in staging.

However, without having looked at the code, I would still
assume that it's not that easy and you will actually break
drivers by fixing the core.

> >> That would leave the ugly drivers in staging to pull over
> >> as they get fixed up.
> > 
> > Yes. Or, with my variant, leave a copy of the core as well.
>
> Sure, depending on what is left there.  If we have moved all of the
> above across then there the non staging version should do everything
> the staging version does..

Yes. If they still have a compatible in-kernel API.
 
> > Then leave the complex drivers until you have the infrastructure
> > for them in the new core version.
> Then the key thing is going to be convincing people that there is
> a reason for a lot of what will go in early on, but they'll need to
> look at staging to see why... I guess the version going into mainline
> may need a lot of comments in the code.  Note for some whole classes
> of devices there are only 'complex' drivers.

Well, all the code is in the kernel in the staging drivers, so
any reviewer can look there to see how it's used. You can always
point to a specific driver in the changelog as an example when
a core component gets posted for review in order to have it
in the mainline tree.

	Arnd
--
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/