On 2016-04-07 19:28, De Marchi, Lucas wrote: > Hi Christian, > > On Thu, 2016-04-07 at 15:37 +0200, Christian Ruppert wrote: >> Dear Lucas, >> >> Sorry for the late reply but I had to put our test environment back >> together to check this patch. I'll keep it around for a while in case >> you have further iterations to test. > > np, I'll try to iterate faster on this patch now, too. > >> On Linux-4.6.0-rc2 the behaviour is still the same: The kernel locks up >> in an irq loop at dwi2c driver probe time. If I don't apply the patch >> everything works fine and the system boots and talks normally on the i2c >> bus. > > :( > > I really hoped this would work in your case. > >> One solution might be to add a device-tree (and acpi) flag to tell the >> driver that it does not need to expect any nastily behaved devices on >> the bus. If this flag is given, the driver could use the faster >> disable-interrupt strategy. Without the flag we need to fall back to the >> conservative disable-i2c-controller strategy. > > I'd like to try some other approaches before that. What if we start with it > disabled and enable at first use? I think this might work in our case and be worth a try. When thinking about it, it might even be cleaner to add a way to specify a list of reset pins (e.g. through the GPIO reset framework) to trigger before activating the bus. This would allow for more than one badly behaved devices on the bus and also render everything more independent of the probe order. I'm afraid that the general case (bad device behaviour after the first transfer) still cannot be covered by this strategy but I'm not sure if I have a way to test this. > After that we keep the approach of just > disabling the interrupts. I can prep a patch for that. OK, I'll give it a try when it's ready. Greetings, Christian -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
