From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754260Ab1KNO7J (ORCPT ); Mon, 14 Nov 2011 09:59:09 -0500 Received: from cantor2.suse.de ([195.135.220.15]:42188 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751999Ab1KNO7H (ORCPT ); Mon, 14 Nov 2011 09:59:07 -0500 Date: Mon, 14 Nov 2011 15:59:06 +0100 Message-ID: From: Takashi Iwai To: =?UTF-8?B?w4lyaWM=?= Piel Cc: Andrew Morton , linux-kernel@vger.kernel.org Subject: Re: [PATCH] lis3lv02d: Avoid zero-division In-Reply-To: <4EBD653A.8060701@tremplin-utc.net> References: <4EB8A8B6.1010205@tremplin-utc.net> <4EBD653A.8060701@tremplin-utc.net> User-Agent: Wanderlust/2.15.6 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.7 Emacs/23.3 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At Fri, 11 Nov 2011 19:11:06 +0100, Éric Piel wrote: > > Op 08-11-11 07:19, Takashi Iwai schreef: > > At Tue, 08 Nov 2011 04:57:42 +0100, > > Éric Piel wrote: > >> > >> Op 03-11-11 13:09, Takashi Iwai schreef: > >>> In some weird situation, HP DriveGuard chip can't read ODR value > >>> correctly, and it results in a zero-division Oops in lis3lv02d driver. > >>> This patch fixes the Oops by checking the value appopriately, and skips > >>> if any weird value is read. > >> Hi Takashi, > >> Actually, a similar patch already just landed in linus' tree: > >> 1510dd5954 (lis3lv02d: avoid divide by zero due to unchecked) > >> > >> However, in the patch applied, the device is disabled (until next > >> reboot) while in yours, the sleep is just skipped. Does it work again > >> after the read of odr fails? If so, maybe I could improve the current > >> version by, after the odr read fails, sleeping a long and safe time and > >> then trying to read the odr again. Then if it fails again, we give up, > >> otherwise the device can be used again. > > > > I guess it's possible to use the device afterward. The possible > > reason is either the chip is set to an invalid mode or ACPI isn't set > > up properly. But this path usually means that ACPI does work more or > > less since you could read WHOAMI. > > > >> Do you have such a device yourself? Could you let me know if after a > >> failing read of the odr, the device keeps working? > > > > I have a machine but I'm not quite sure how to reproduce this error. > > It happened casually during the installation of a new system, so it's > > not so trivial to switch the module during it... > Dear Takashi, > > I've looked more at the error. Now it seems to me that the fact that > get_odr() returns 0 is not because there is a problem with the device > but just because it is powered off: for the "3dc" device, this reflects > in rate of 0. We assume that the ACPI code does turn the device on, but > it might not do it, or the device might still need more time to fully > initialize. So, just turning the device on and waiting a bit long should > work fine. Sounds reasonable. FWIW, I got the zero-division error only in a rare case, while the installation of a system. > However, looking for the spec document of lis3dc (or hp3dc), I couldn't > find any reference to such device. I've found documents for lis3dh, with > apparently same registers and WHOAMI value. However, contrarily to what > is currently expected, it's a 16-bit device, not 8-bit. So my main > question is: are you sure the device you have is 8-bit? Isn't your > device a 16-bit lis3dh? Do you have the spec of lis3dc/hp3dc? The device works with 8bit mode well, and the values I get from the joystick device is almost same as the old lis3 chip on other HP laptops. So I suppose this is 8bit device. I have also no spec for this chip. I was informed from HP a little bit about their new stuff to add the support in hp_accel driver, but not in details, unfortunately. thanks, Takashi