[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20160419163748.9129940005@mail.lysator.liu.se>
Date: Tue, 19 Apr 2016 18:37:41 +0200
From: Peter Rosin <peda@...ator.liu.se>
To: Crestez Dan Leonard <leonard.crestez@...el.com>,
linux-kernel@...r.kernel.org
CC: Peter Rosin <peda@...ntia.se>, Wolfram Sang <wsa@...-dreams.de>,
Jonathan Corbet <corbet@....net>,
Peter Korsgaard <peter.korsgaard@...co.com>,
Guenter Roeck <linux@...ck-us.net>,
Jonathan Cameron <jic23@...nel.org>,
Hartmut Knaack <knaack.h@....de>,
Lars-Peter Clausen <lars@...afoo.de>,
Peter Meerwald <pmeerw@...erw.net>,
Antti Palosaari <crope@....fi>,
Mauro Carvalho Chehab <mchehab@....samsung.com>,
Rob Herring <robh+dt@...nel.org>,
Frank Rowand <frowand.list@...il.com>,
Grant Likely <grant.likely@...aro.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"David S. Miller" <davem@...emloft.net>,
Kalle Valo <kvalo@...eaurora.org>,
Joe Perches <joe@...ches.com>, Jiri Slaby <jslaby@...e.com>,
Daniel Baluta <daniel.baluta@...el.com>,
Adriana Reus <adriana.reus@...el.com>,
Lucas De Marchi <lucas.demarchi@...el.com>,
Matt Ranostay <matt.ranostay@...el.com>,
Krzysztof Kozlowski <k.kozlowski@...sung.com>,
Terry Heo <terryheo@...gle.com>, Hans@...ator.liu.se,
Verkuil@...ator.liu.se
Subject: Re: [PATCH v6 08/24] iio: imu: inv_mpu6050: convert to use an explicit i2c mux core
<hans.verkuil@...co.com>,Arnd Bergmann <arnd@...db.de>,Tommi Rantala <tt.rantala@...il.com>,linux-i2c@...r.kernel.org,linux-doc@...r.kernel.org,linux-iio@...r.kernel.org,linux-media@...r.kernel.org,devicetree@...r.kernel.org
Message-ID: <B09CD200-56D1-4BE0-B567-90CC23507ED5@...ator.liu.se>
On April 19, 2016 5:58:11 PM CEST, Crestez Dan Leonard <leonard.crestez@...el.com> wrote:
> On 04/03/2016 11:52 AM, Peter Rosin wrote:
> > From: Peter Rosin <peda@...ntia.se>
> >
> > 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(&client->dev));
> > - st->mux_adapter = i2c_add_mux_adapter(client->adapter,
> > - &client->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, &client->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:[<ffffffff81481aed>] [<ffffffff81481aed>]
> mutex_lock+0xd/0x30
> [ 5.565374] Call Trace:
> [ 5.565374] [<ffffffff813be34c>]
> inv_mpu6050_select_bypass+0x1c/0xa0
> ...
> [ 5.565374] [<ffffffff81392141>] i2c_transfer+0x51/0x90
> ...
> [ 5.565374] [<ffffffff81392cb5>]
> i2c_smbus_read_i2c_block_data+0x45/0xd0
> [ 5.565374] [<ffffffff813bec5a>] ak8975_probe+0x14a/0x5c0
> ...
> [ 5.565374] [<ffffffff813933d8>] i2c_new_device+0x178/0x1e0
> [ 5.565374] [<ffffffff8139362d>] of_i2c_register_device+0xdd/0x1a0
> [ 5.565374] [<ffffffff8139372b>] of_i2c_register_devices+0x3b/0x60
> [ 5.565374] [<ffffffff81393e88>] i2c_register_adapter+0x178/0x410
> [ 5.565374] [<ffffffff81394203>] i2c_add_adapter+0x73/0x90
> [ 5.565374] [<ffffffff81395f3d>] i2c_mux_add_adapter+0x2ed/0x400
> [ 5.565374] [<ffffffff81396091>] i2c_mux_one_adapter+0x41/0x70
> [ 5.565374] [<ffffffff813be48a>] 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
Duh. Obvious now that you point it out. Thanks for catching this!
I will just remove the i2c_mux_one_adapter interface for v7 and
have the affected drivers do i2c_mux_alloc as a separate step
(which was one of your suggested paths forward...)
Thanks again, and sorry for the inconvenience,
Peter
(Written on my phone, sorry for crappy formatting)
Powered by blists - more mailing lists