Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754568AbcDYLSF (ORCPT ); Mon, 25 Apr 2016 07:18:05 -0400 Received: from mga09.intel.com ([134.134.136.24]:6652 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753875AbcDYLSD (ORCPT ); Mon, 25 Apr 2016 07:18:03 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.24,532,1455004800"; d="scan'208";a="791834440" Subject: Re: [PATCH 3/5] iio: inv_mpu6050: Check WHO_AM_I register on probe To: Jonathan Cameron , linux-iio@vger.kernel.org References: Cc: linux-kernel@vger.kernel.org, Hartmut Knaack , Lars-Peter Clausen , Peter Meerwald-Stadler , Daniel Baluta From: Crestez Dan Leonard Message-ID: <571DFCE7.1030300@intel.com> Date: Mon, 25 Apr 2016 14:17:59 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1240 Lines: 25 On 04/24/2016 02:14 PM, Jonathan Cameron wrote: > On 20/04/16 14:15, Crestez Dan Leonard wrote: >> This can be used to distinguish mpu6500. This is a warning rather than >> an error because the differences are mostly irrelevant and it's nice to >> avoid breaking users with slightly incorrect ACPI/DT. >> >> Signed-off-by: Crestez Dan Leonard > Would we be better off fixing their configuration though by using the right part > if we can identify it? So if wrong, maybe we should search the info table to > figure out what it is? I'm not certain on this though as then we are trying to > deal with unknown future cases - maybe what you have here is the best balance. I'm not sure about that. One issue is that 6000/6050/9150 have the same WHOAMI value and can't be distinguished this way. They also seem to identical interfaces. Models MPU6500 and MPU9250 report different WHOAMI values. Changing chip_type based on the WHOAMI would require some additional refactoring. Placing that in a separate patch might be worthwhile anyway. >> +#define INV_MPU6050_REG_WHOAMI 117 >> + >> +#define INV_MPU6000_WHOAMI_VALUE 0x68 >> +#define INV_MPU6050_WHOAMI_VALUE 0x68 >> +#define INV_MPU6500_WHOAMI_VALUE 0x70