[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160302170630.GA5439@katana>
Date: Wed, 2 Mar 2016 18:06:30 +0100
From: Wolfram Sang <wsa@...-dreams.de>
To: Daniel Baluta <daniel.baluta@...el.com>
Cc: Jonathan Cameron <jic23@...nel.org>,
Hartmut Knaack <knaack.h@....de>,
Lars-Peter Clausen <lars@...afoo.de>,
Peter Meerwald-Stadler <pmeerw@...erw.net>,
"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-i2c@...r.kernel.org,
Lucas De Marchi <lucas.demarchi@...el.com>,
Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
Ge Gao <ggao@...ensense.com>,
Adriana Reus <adi.reus@...il.com>, Crt Mori <cmo@...exis.com>,
Michael Welling <mwelling@...e.org>
Subject: Re: [RFC PATCH 9/9] iio: imu: inv_mpu6050: Fix deadlock between i2c
adapter lock and mpu lock
> I looked into the I2C adapter / mux code but I got lost rapidly :). It
> feels like the natural solution would be for the I2C core to not hold
> the adapter lock while doing transactions on the muxed child adapter.
The patch series I mentioned to you does exactly that. It locks only the
mux side of the muxed bus, not the whole parent adapter. It didn't work
for you because the mux driver maybe needed some adaptions as well?
However, I am still undecided if that series should go upstream because
it makes the mux code another magnitude more complex. And while this
seems to be the second issue which could be fixed by that series, both
issues are corner cases, so I am not sure it is worth the complexity.
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists