linux-kernel - Re: [lm-sensors] [PATCH 2.6.25.4] hwmon: HP Mobile Data Protection System 3D ACPI driver

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <4847A3C5.60600@tremplin-utc.net>
Date:	Thu, 05 Jun 2008 10:28:53 +0200
From:	Eric Piel <eric.piel@...mplin-utc.net>
To:	Riku Voipio <riku.voipio@...ial.fi>
Cc:	Yan Burman <burman.yan@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	HWMON <lm-sensors@...sensors.org>,
	spi-devel-general@...ts.sourceforge.net, jic23@....ac.uk,
	pau@...ack.org
Subject: Re: [lm-sensors] [PATCH 2.6.25.4] hwmon: HP Mobile Data Protection
 System 3D ACPI	driver

Riku Voipio wrote:
> Yan Burman wrote:
>> +==================
>> +
>> +Supported chips:
>> +
>> +  * STMicroelectronics LIS3LV02DL and LIS3LV02DQ
>> +
> These chips are connected to either I2C or SPI - This is the 4th driver for
> (apparently) these same chips:
> 
> http://docwiki.gumstix.org/Lis3lv02dq_spi.c
> http://svn.openmoko.org/branches/src/target/kernel/2.6.24.x/patches/lis302dl.patch 
> 
> http://article.gmane.org/gmane.linux.kernel.spi.devel/1010
Hi!
Thanks a lot for these links (which I was not aware of). They indeed 
seem to handle the same hardware (all via spi). To be even more 
complete, here is a link we received off-list for accessing the same 
hardware via I²C:
http://pof.eslack.org/HTC/shift/i2c-gsensor.tar.gz

There are for sure some nice things we could borrow ;-)
> 
>> +    depends on ACPI && INPUT && X86
>>   
> 
> 
>> +/* The actual chip is STMicroelectronics LIS3LV02DL or LIS3LV02DQ
>> + * that seems to be connected via SPI */
>>   
> Perhaps it would make more sense implement support for SPI
> bus on the laptop and use the SPI interface directly instead or
> routing via the ACPI hiding layer?
Getting rid of ACPI could be nice, as it tends to be rather slow. 
However, so far we've stick to it because it ensures that for the ~15 
different models of HP laptop, we can access the hardware exactly the 
same way. I have the gut feeling that if HP spent some time to add an 
interface in ACPI, there was some kind of reason.

However, I know nothing about SPI. Maybe you'll tell that if this chip 
is on the SPI bus, it will always be accessed the same way, located at 
the same address... or whatever that can ensure us that from the moment 
we know this device is in the laptop (and that's easy via HPQ0004) we 
cannot mess up. In that case, going to SPI would be definitely worthy.

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