On Wed, 08 Nov 2017 18:38:39 +0200 Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > On Sun, 2017-11-05 at 18:03 -0800, Srinivas Pandruvada wrote: > > On Sun, 2017-11-05 at 14:42 +0200, Andy Shevchenko wrote: > > > On Fri, 2017-11-03 at 11:46 -0700, Srinivas Pandruvada wrote: > > > > > The AK8963 is using INVN6500. The reason is that this INVN 6500 > > > > has > > > > another master mode where a secondary sensor can be connected to > > > > it > > > > as > > > > an i2c slave. > > > > So Windows config uses this mode and hence added in the same > > > > package. > > > > > > > > But Linux INVN driver is not capable of this master mode. We use > > > > something called "bypass" mode. In this the second sensor will > > > > also > > > > be > > > > directly connected to host i2c. We have another driver handling > > > > this > > > > sensor (ak8975), so we have to add this id. > > > > > > But ak8975 is enumerated. See above log. So, I think the INVN6500 ID > > > in > > > ak 8975 driver is simple not required. > > > > This is not true in all platforms. So this is required. > > Thanks for clarification. though it would be interesting to test a > behaviour w/o this patch on platform I have and the one that has wrong > data under CNF0 resources. > As this discussion seems to have concluded the patch is a bad idea I'm dropping it. I'll add though that it would be possible to instantiate the ak8975 from the mpu6050 driver if we wanted to avoid this nasty 'hack'. Jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
