Re: [PATCH v7 00/24] i2c mux cleanup and locking update

[Crestez Dan Leonard]

On 04/20/2016 06:17 PM, Peter Rosin wrote:
> v7 compared to v6:
> - Removed i2c_mux_reserve_adapters, and all realloc attempts in
>   i2c_mux_add_adapter. Supply a maximum number of adapters in i2c_mux_alloc
>   instead.
> - Removed i2c_mux_one_adapter since it is was hard to use correctly, which
>   was evident from the crash in the mpu6050 driver (on a mpu9150 chip) 
> reported
>   by Crestez Dan Leonard. Also, it didn't make things all that much simpler
>   anyway (even if used correctly).
> - Rename i2c_mux_core:adapters into i2c_mux_core:num_adapters.
> - Some grammar and spelling fixes.

I tested this new version on mpu9150 and there are no more obvious
deadlocks or crashes. The magnetometer and accel/gyro can be used at the
same time without issues.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 08/24] iio: imu: inv_mpu6050: convert to use an explicit i2c mux core

[Crestez Dan Leonard]

On 04/03/2016 11:52 AM, Peter Rosin wrote:
> From: Peter Rosin 
> 
> Allocate an explicit i2c mux core to handle parent and child adapters
> etc. Update the select/deselect ops to be in terms of the i2c mux core
> instead of the child adapter.
> 
> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_acpi.c
> @@ -136,16 +133,15 @@ static int inv_mpu_probe(struct i2c_client *client,
>   return result;
>  
>   st = iio_priv(dev_get_drvdata(>dev));
> - st->mux_adapter = i2c_add_mux_adapter(client->adapter,
> -   >dev,
> -   client,
> -   0, 0, 0,
> -   inv_mpu6050_select_bypass,
> -   inv_mpu6050_deselect_bypass);
> - if (!st->mux_adapter) {
> - result = -ENODEV;
> + st->muxc = i2c_mux_one_adapter(client->adapter, >dev, 0, 0,
> +0, 0, 0,
> +inv_mpu6050_select_bypass,
> +inv_mpu6050_deselect_bypass);
> + if (IS_ERR(st->muxc)) {
> + result = PTR_ERR(st->muxc);
>   goto out_unreg_device;
>   }
> + st->muxc->priv = client;

I just tested this patch on mpu9150 (combo mpu6050+ak8975) and I got a
crash on probe which looks sort of like this:

[5.565374] RIP: 0010:[] []
mutex_lock+0xd/0x30
[5.565374] Call Trace:
[5.565374]  [] inv_mpu6050_select_bypass+0x1c/0xa0
...
[5.565374]  [] i2c_transfer+0x51/0x90
...
[5.565374]  [] i2c_smbus_read_i2c_block_data+0x45/0xd0
[5.565374]  [] ak8975_probe+0x14a/0x5c0
...
[5.565374]  [] i2c_new_device+0x178/0x1e0
[5.565374]  [] of_i2c_register_device+0xdd/0x1a0
[5.565374]  [] of_i2c_register_devices+0x3b/0x60
[5.565374]  [] i2c_register_adapter+0x178/0x410
[5.565374]  [] i2c_add_adapter+0x73/0x90
[5.565374]  [] i2c_mux_add_adapter+0x2ed/0x400
[5.565374]  [] i2c_mux_one_adapter+0x41/0x70
[5.565374]  [] inv_mpu_probe+0xba/0x1a0

This happens because muxc->priv is not initialized when probing devices
behind the mux as described by devicetree. This can be easily fixed by
using muxc->dev instead of muxc->priv, or perhaps by calling
i2c_mux_alloc, initializing priv and later doing i2c_mux_add_adapter.

These fixes are driver-specific and other drivers might experience
similar issues. Perhaps i2c_mux_one_adapter should take void *priv just
like old i2c_add_mux_adapter?

After I fix this locally the deadlock when reading from both devices no
longer happens.

--
Regards,
Leonard
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html