linux-kernel - Re: [lm-sensors] [PATCH v2] lis3: Fix Oops with NULL platform data

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]

Message-ID: <4C9DFD59.6000708@cam.ac.uk>
Date:	Sat, 25 Sep 2010 14:47:05 +0100
From:	Jonathan Cameron <jic23@....ac.uk>
To:	Jean Delvare <khali@...ux-fr.org>
CC:	Takashi Iwai <tiwai@...e.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"lm-sensors@...sensors.org" <lm-sensors@...sensors.org>,
	Éric Piel <Eric.Piel@...mplin-utc.net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [lm-sensors] [PATCH v2] lis3: Fix Oops with NULL platform data

On 09/25/10 12:01, Jean Delvare wrote:
> On Fri, 24 Sep 2010 16:10:06 +0100, Jonathan Cameron wrote:
>> On 09/24/10 15:30, Jean Delvare wrote:
>>> That being said, I indeed would like all non-hwmon drivers to go away
>>> from drivers/hwmon. Originally we were waiting for iio to settle first,
>>> but apparently this is taking forever.
>> More developers and code reviewers always welcome!
> 
> Just to clear any confusion: this wasn't a criticism from my side. I
> understand why it takes time. All I mean is that it is not reasonable
> to delay other changes waiting for IIO to hit mainline. Because we have
> no idea when that will happen.
Not to worry ;)  I was just taking advantage to drop in a plug.
It's certainly going slower than I would like and I'm fully in favour
of drivers going into misc or similar even if we would like to
eventually take them into IIO. This is part of the reason we
have been trying to pin down interface naming etc in a more
general forum than our internal list.   Basically we are trying to
avoid a repeat of the ALS debacle. 
> 
>>> The 4 drivers I would like to
>>> kick are: ams, hdaps, lis3lv02d and applesmc. They are primarily
>>> accelerometer device drivers. Not sure where to put them,
>>> drivers/accel(erometer), drivers/misc, drivers/misc/accel(erometer),
>>> drivers/input/accel(erometer)... Opinions welcome.
>> If the primary use is as an input device then talk to Dmitry. Some
>> accelerometers are being taken into input. There are some open questions
>> on naming etc currently being debated so anyone interested should get
>> involved in those asap.
> 
> Let's see if he wants them. I seem to recall he objected to them going
> to input, on the basis that the input function was a not the key
> feature. But apparently we have one accel driver in drivers/input/misc
> (adxl34x) so maybe we can have more.
Yup, Dmitry has softened somewhat on this point for device where it really
can be argued that input is the key feature (typically the ones being used
for exactly this purpose in smart phones) in recent months so things may
have changed.

Lets wait and see.

Jonathan

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