| 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
| ||
|
Date: Wed, 22 Aug 2012 22:24:10 +0530 From: Chinmay V S <cvs268@...il.com> To: "AnilKumar, Chimata" <anilkumar@...com>, carmine.iascone@...com Cc: Arnd Bergmann <arnd@...db.de>, "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>, "eric.piel@...mplin-utc.net" <eric.piel@...mplin-utc.net>, "jic23@....ac.uk" <jic23@....ac.uk>, "greg@...ah.com" <greg@...ah.com>, "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>, "broonie@...nsource.wolfsonmicro.com" <broonie@...nsource.wolfsonmicro.com>, "dmitry.torokhov@...il.com" <dmitry.torokhov@...il.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org> Subject: Re: [PATCH v2] lis3lv02d: Add STMicroelectronics lis331dlh digital accelerometer > Look at this application note which talks about the outdata values > for 2G range (page 12/31) http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/CD00215823.pdf Had been through the application note earlier. The table5 (on page 12) that you refer to, does NOT contradict either 12/16bit, as in all the examples the lower 4 bits are zero. So i don't see how one can assume from these examples that for +/-2G they one should consider 12/16bits. A nice side-effect of using 12|13|14bits for +/-2|4|8G is that the values returned by the driver are in mG in all the 3 modes. > Corresponding to the 4G and 8G I got the details form older > patches (SHIFT_ADJ_4G and SHIFT_ADJ_8G). > http://driverdev.linuxdriverproject.org/pipermail/devel/2010-November/009685.html > > We can easily interpret number of bits for 4G and 8G from 2G > information. Going through the code of this driver i can see what you are talking about. Depending on the full-scale-range the device is being configured for, the number of bits used to represent acceleration in the driver is changed. Again judging from the code, the driver is always returning acceleration at a constant accuracy i.e. 1mG in all the 3 modes (+/-2|4|8G)i.e. +/-2G is mode means value can be anywhere from +/-2048mG, (requiring 12bits.) +/-4G in the range of +/-4096mG, requiring 13bits. +/-8G i.e. +/-8192mG, requiring 14bits. Was this done... a. ...because LIS331DLH's theoretical MAX accuracy is ~1mG If yes, then using 12bits is fine. -OR- b. ...so that the driver will report values at a constant scale(i.e.mG) regardless of the mode? If yes, then maybe we could consider using the additional bits to obtain the maximum possible accuracy the LIS331DLH supports rather than choosing to discard the LSBits. (Can anyone please confirm the above?) Going through the datasheet of LIS331DLH, http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00213470.pdf we see that accuracy/sensitivity of the device as per Table 2.1 (page9/38) is 1|2|4mG in +/-2|4|8Gmodes respectively. It is mentioned in the footnotes that the readings were taken at 12bit resolution(a point in favour of using 12bits ourselves). But its is still NOT clear whether the accuracy/sensitivity are the LIS331DLH's physical limits or whether they stem from the fact that ONLY 12bits were used during the rating tests. I hope i'm not being too much of a PIA. My sole intention is to see that we do NOT unintentionally lose track of the device capabilities in the midst of all these driver iterations. Thank you for your patience. PS: One more nitpick > LIS3331DLH spec says 1LSBs(...) LIS3331DLH --> LIS331DLH -- regards ChinmayVS -- 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/
Powered by blists - more mailing lists