Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933250AbcDYSJZ (ORCPT ); Mon, 25 Apr 2016 14:09:25 -0400 Received: from saturn.retrosnub.co.uk ([178.18.118.26]:42489 "EHLO saturn.retrosnub.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932989AbcDYSJX (ORCPT ); Mon, 25 Apr 2016 14:09:23 -0400 Subject: Re: [PATCH 3/5] iio: inv_mpu6050: Check WHO_AM_I register on probe To: Crestez Dan Leonard , linux-iio@vger.kernel.org References: <571DFCE7.1030300@intel.com> Cc: linux-kernel@vger.kernel.org, Hartmut Knaack , Lars-Peter Clausen , Peter Meerwald-Stadler , Daniel Baluta From: Jonathan Cameron Message-ID: Date: Mon, 25 Apr 2016 19:09:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <571DFCE7.1030300@intel.com> 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: 1329 Lines: 27 On 25/04/16 12:17, Crestez Dan Leonard wrote: > 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. > Agreed. >>> +#define INV_MPU6050_REG_WHOAMI 117 >>> + >>> +#define INV_MPU6000_WHOAMI_VALUE 0x68 >>> +#define INV_MPU6050_WHOAMI_VALUE 0x68 >>> +#define INV_MPU6500_WHOAMI_VALUE 0x70