On Thu, May 02, 2019 at 04:32:51PM +0100, Charles Keepax wrote:
On Thu, May 02, 2019 at 03:32:24PM +0300, Jarkko Nikula wrote:
On 4/30/19 6:56 PM, Sasha Levin wrote:
This commit has been processed because it contains a "Fixes:" tag, fixing commit: c5eb1190074c PCI / PM: Allow runtime PM without callback functions.
The bot has tested the following trees: v5.0.10, v4.19.37.
v5.0.10: Build OK! v4.19.37: Failed to apply! Possible dependencies: 6f108dd70d30 ("i2c: Clear client->irq in i2c_device_remove") 93b6604c5a66 ("i2c: Allow recovery of the initial IRQ by an I2C client device.")
How should we proceed with this patch?
There's also dependency to commit b9bb3fdf4e87 ("i2c: Remove unnecessary call to irq_find_mapping")
Without it 93b6604c5a66 doesn't apply.
Otherwise my patch don't have dependency into these so I can have another version for 4.19 if needed.
I got impression from the mail thread for 6f108dd70d30 that it could be also stable material but cannot really judge.
Charles: does your commits b9bb3fdf4e87 and 6f108dd70d30 with the fix 93b6604c5a66 qualify for 4.19? (background: my fix doesn't apply without them but doesn't depend on them).
b9bb3fdf4e87 ("i2c: Remove unnecessary call to irq_find_mapping")
I don't think this one would make sense to backport it's not fixing any issues it just removes a redundant call. The call just repeats work it does no harm.
6f108dd70d30 ("i2c: Clear client->irq in i2c_device_remove") 93b6604c5a66 ("i2c: Allow recovery of the initial IRQ by an I2C client device.")
These two are much more of a grey area, they do fix an actual issue, although that issue only happens when you unbind and rebind both an I2C device and the device providing its IRQs. A couple of us have been trying to look for a better fix as well which further complicates matters.
I would suggest you just backport your patch and leave these ones. As evidenced by the fixup patch there is a slight chance of regressions from backporting this fix and the issue it fixes is clearly not something people are normally hitting.
I've queued all of these up now, as they make sense to have for 4.19.y.
thanks,
greg k-h