Hi,
On 21-03-17 16:37, Oliver Neukum wrote:
Am Dienstag, den 21.03.2017, 15:48 +0100 schrieb Hans de Goede:
Hi,
On 21-03-17 15:05, Oliver Neukum wrote:
Hi,
I am quite uncomfortable with code in the kernel that will crash
the machine if it ever runs. Yet I am also uncomfortable with code
that would run forever.
That is exactly how I feel, I did not realize (yet) that taking
the error path would always cause a freeze later, I've been assuming
that the timeout was caused by the bus already being stuck, not
that the timeout would cause the bus to get stuck because a
semaphore request must be followed through on.
Those options are not mutually exclusive.
If your theory is right we may well want to bump up the timeout
to say 2 or 3 seconds.
We never saw a failure with 500ms. That is pretty solid.
Yet a true error would likely have catastrophic results.
It seems to me that the problem is not when to proceed
to error handling, but how the error is handled.
Do you have any documentation on that?
Nope I have no documentation at all, just some experience
from poking at the hw.
[hans@shalem linux]$ scripts/get_maintainer.pl -f drivers/i2c/busses/i2c-designware-baytrail.c
Jarkko Nikula <jarkko.nikula@xxxxxxxxxxxxxxx> (maintainer:SYNOPSYS DESIGNWARE I2C DRIVER)
Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> (reviewer:SYNOPSYS DESIGNWARE I2C DRIVER)
Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx> (reviewer:SYNOPSYS DESIGNWARE I2C DRIVER)
Wolfram Sang <wsa@xxxxxxxxxxxxx> (maintainer:I2C SUBSYSTEM)
linux-i2c@xxxxxxxxxxxxxxx (open list:SYNOPSYS DESIGNWARE I2C DRIVER)
linux-kernel@xxxxxxxxxxxxxxx (open list)
There are 3 persons in there from Intel, you may want to
contact them about this.
Should we forcibly set the semaphore to the state that signifies
a successful take over?
Regards,
Hans
--
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
