On 4 May 2016 18:24:43 BST, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: >On Wed, May 04, 2016 at 08:49:06AM +0100, Jonathan Cameron wrote: >> On 03/05/16 19:54, Crestez Dan Leonard wrote: >> > On 05/01/2016 10:58 PM, Jonathan Cameron wrote: >> >> On 27/04/16 16:56, One Thousand Gnomes wrote: >> >>> On Tue, 26 Apr 2016 18:07:55 -0500 >> >>> Michael Welling <mwelling@xxxxxxxx> wrote: >> >>> >> >>>> On Tue, Apr 26, 2016 at 11:26:51PM +0100, One Thousand Gnomes >wrote: >> >>>>> >> >>>>> This now causes us to crash and burn on the ASUS T100TA >Baytrail/T >> >>>>> platforms >> >>>>> >> >>>> >> >>>> I believe this regression has already been patched. >> >>>> >> >>>> Check the latest commits in linux-next. >> >>>> >> >>>> >https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/drivers/iio/imu/inv_mpu6050/inv_mpu_i2c.c >> >>>> >> >>>> See if the latest patches fix your issue. >> >>> >> >>> It does - as this is a regression can we please get those fixes >into the >> >>> next -rc ? >> >>> >> >> I'm afraid I'm lost in this one - which patch caused the >regression and >> >> which one fixed it? The only patches I can immediately see in >next >> >> both introduce and then squish a similar bug, but neither of them >> >> has hit Linus' tree yet. >> >> >> >> Or are we dealing with what was fixed in: >> >> c816d9e7 iio: imu: mpu6050: fix possible NULL dereferences >> >> I had understood that one as more hypothetical than real... >> >> >> >> Unfortunately I'm travelling and I suspect that means this will >only get >> >> in just after the release (so for 4.6.1) once I've confirmed which >fixes >> >> we actually need to backport. >> >> >> > Commit >> > c816d9e7: iio: imu: mpu6050: fix possible NULL dereferences >> > Fixes: >> > 33da559f: iio: imu: mpu6050: add mpu6500 register settings >> > >> > As far as I can tell this crash will always happen when the device >is >> > probed via ACPI. >> >> Hi Greg, >> >> A quick heads up. >> >> Unfortunately this regression has come up whilst I'm travelling and >> don't have appropriate signing keys with me to do a pull request. >> Should be able to do one tomorrow evening as I'll back home. >> >> Turns out the 'possible' is quite common and causing a mess. >> Even better the fix actually has a fix as well... >> >> Fastest option is probably a cherry pick of: >> >> c816d9e7: iio: imu: mpu6050: fix possible NULL dereferences >> 718ba46e: iio: imu: mpu6050: Fix name/chip_id when using ACPI > >From where? Doh. Both already in your staging-next. Confusion was over the seriousness of the issue so went via wrong route. > >> >> I'll send you a pull request of my >> togreg-in-a-hurry branch tomorrow. >> >> Sorry for these being so late in the cycle. >> >> Anyhow, run for train time. > >You can always just send me patches, no need for it to always be a pull >request if you can't do that for some reason. Good point, nothing like limited time to make one an idiot sometimes! Jonathan > >thanks, > >greg k-h -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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
