This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Fri Apr 26 23:19:48 2024 >From spaans Sat Jan 24 00:39:59 2015 Received: from pop.ziggo.nl [212.54.42.19] by squeeze.vs19.net with POP3 (fetchmail-6.3.21) for (single-drop); Sat, 24 Jan 2015 00:39:59 +0100 (CET) Received: from md4.tb.mail.iss.local ([212.54.34.100]) by mc5.tb.mail.iss.local (Dovecot) with LMTP id L6u6F+vawlSQCAAAh0Kp1A for ; Sat, 24 Jan 2015 00:38:33 +0100 Received: from mx1.gn.mail.iss.as9143.net ([212.54.34.100]) by md4.tb.mail.iss.local (Dovecot) with LMTP id mt9iNsTrgFQBSgAAkz+7wA ; Sat, 24 Jan 2015 00:38:48 +0100 Received: from vger.kernel.org ([209.132.180.67]) by mx1.gn.mail.iss.as9143.net with esmtp (Exim 4.82) (envelope-from ) id 1YEno8-0000C0-De for bmw12-lkml@ziggo.nl; Sat, 24 Jan 2015 00:38:33 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752284AbbAWXiY (ORCPT ); Fri, 23 Jan 2015 18:38:24 -0500 Received: from mout.gmx.net ([212.227.15.15]:53856 "EHLO mout.gmx.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751709AbbAWXiW (ORCPT ); Fri, 23 Jan 2015 18:38:22 -0500 Received: from [192.168.0.80] ([178.8.242.86]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LfjlS-1XuK5b3OlG-00pP9r; Sat, 24 Jan 2015 00:38:10 +0100 Message-Id: <54C2DB5F.2050106@gmx.de> Date: Sat, 24 Jan 2015 00:38:07 +0100 From: Hartmut Knaack User-Agent: Mozilla/5.0 (X11; Linux i686; rv:34.0) Gecko/20100101 Firefox/34.0 SeaMonkey/2.31 Mime-Version: 1.0 To: "Pandruvada, Srinivas" , "Baluta, Daniel" Cc: "lars@metafoo.de" , "linux-kernel@vger.kernel.org" , "jic23@kernel.org" , "Purdila, Octavian" , "linux-iio@vger.kernel.org" , "Westerb Subject: Re: [RFC PATCH] iio: ak8975: Make sure chipset is always initialized References: <1418923002-901-1-git-send-email-daniel.baluta@intel.com> <5494A3D6.60607@gmx.de> <1419110796.2843.6.camel@spandruv-hsb-test> <1419110952.2843.8.camel@spandruv-hsb-test> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:VLqBP8w91a3bYWySWecuQtiVJWKpq+jdrzPNZv37O0RVovU6YAF 4IOgf0jRlh6i+/2OlnkZRlGjfKZabRjC7kUobPaz/j6VBYvqbjs0LaUmeNq+kaA7mi4Y4lU ARvUf6awkSmRhU27Zq28NdRv0PdijEiJjPvq6382SFktgqsgAGA3HVaZHGPInsdiCgyTOLY veSRmMQJ2jwSXta8rk55Q== X-UI-Out-Filterresults: notjunk:1; Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-Id: X-Mailing-List: linux-kernel@vger.kernel.org X-Ziggo-spamsetting: Instelling=Gemiddeld Scorelimiet=14 X-Ziggo-spambar: / X-Ziggo-spamscore: 0.2 X-Ziggo-spamreport: BAYES_00=-1.9,CM_CTENC_8BIT=0.1,CM_SPACED_DATE=0.5,FREEMAIL_FORGED_FROMDOMAIN=0.001,FREEMAIL_FROM=0.5,HEADER_FROM_DIFFERENT_DOMAINS=0.001,L_TAB_IN_FROM=2,RCVD_IN_JMF_W=-1,RCVD_IN_MSPIKE_H3=-0.01,RCVD_IN_MSPIKE_WL=-0.01,T_RP_MATCHES_RCVD=-0.01 X-Ziggo-Spam-Status: No X-Spam-Status: No X-Spam-Flag: No Pandruvada, Srinivas schrieb am 19.01.2015 um 17:56: > On Mon, 2015-01-19 at 18:49 +0200, Daniel Baluta wrote: >> On Mon, Jan 19, 2015 at 6:44 PM, Pandruvada, Srinivas >> wrote: >>> On Mon, 2015-01-19 at 16:40 +0200, Daniel Baluta wrote: >>>> Hello, >>>> >>>> On Sat, Dec 20, 2014 at 11:29 PM, Pandruvada, Srinivas >>>> wrote: >>>>> +Mika >>>>> >>>>> On Sat, 2014-12-20 at 13:26 -0800, Srinivas Pandruvada wrote: >>>>>> On Sat, 2014-12-20 at 00:25 +0200, Daniel Baluta wrote: >>>>>>> On Sat, Dec 20, 2014 at 12:16 AM, Hartmut Knaack wrote: >>>>>>>> Daniel Baluta schrieb am 18.12.2014 um 18:16: >>>>>>>>> When using ACPI, if acpi_match_device fails then chipset enum will be >>>>>>>>> uninitialized and &ak_def_array[chipset] will point to some bad address. >>>>>>>>> >>>>>> I am missing something. You are enumerated over i2c device, which was >>>>>> created from ACPI PNP resource. There is a valid handle or and the >>>>>> device has an ACPI companion at the least. If this failing, I have to >>>>>> check the code for acpi i2c. >>>>>> Can you check why this check failed? We may have bug in i2c handling. >>>> >>>> You are right about this. Under normal circumstances, if probe is called >>>> then acpi_match_device will not fail. I even tried to remove the >>>> device after probe >>>> but before acpi_match_device, anyhow acpi_match_device was still successful :) >>>> >>>> This is more a matter of code correctness. >>>> >>>> In ak8975_match_acpi_device we have: >>>> >>>> » const struct acpi_device_id *id; >>>> >>>> » id = acpi_match_device(dev->driver->acpi_match_table, dev); >>>> » if (!id) >>>> » » return NULL; >>>> » *chipset = (int)id->driver_data; >>>> >>>> Compiler complains on the fact that chipset might be uninitialized >>>> if this returns NULL, and we shouldn't ignore this warning even this case >>>> will never happen. >>>> >>> Will this fix? >>> data->chipset = AK8975; >>> before >>> ak8975_match_acpi_device(&client->dev, &data->chipset); >>> This would fix the compiler warning, but doesn't seem the right solution for this issue. Quoting the description of acpi_match_device: "Return a pointer to the first matching ID on success or %NULL on failure." So, even if it is very unlikely to for it to fail - if it does fail, the error should be handled as quick as possible. I would favor Daniels solution to check for a valid assignment of name. >> >> Yes, this is done in the original patch: >> >> + *chipset = AK_MAX_TYPE; > Since data memory is not zero alloced, other member of data are anyway > initialized, so adding this also may be better. If there did not occur an error condition, it will be assigned a value before being checked for valid ranges. And if there is an error, probe should be aborted, anyway. So initializing *chipset doesn't seem to add any benefit IMHO. >> >> .. and fixes the warning. >> >> Daniel. > > N�����r��y���b�X��ǧv�^�)޺{.n�+����{��*"��^n�r���z���h����&���G���h�(�階�ݢj"���m�����z�ޖ���f���h���~�mml== > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/