| Message ID | dfa042b7-8b80-ee2b-451b-7cedaeadfd02@omprussia.ru |
|---|---|
| Headers | show |
| Series | Fix deferred probing in the I2C bus drivers | expand |
Hello~ On 4/17/21 11:57 PM, Sergey Shtylyov wrote: > Here are 2 patches against the 'i2c/for-current' branch of Wolfram's 'linux.git' repo. > The affected drivers call platform_get_irq() but override its result in case of error > which prevents the deferred probing from working. > > [1/2] i2c: iop3xx: fix deferred probing > [2/2] i2c: synquacer: fix deferred probing Please hold on with this series; I'm gonna add another patch... MBR, Sergey
On 5/28/21 11:57 PM, Sergey Shtylyov wrote: [...] >> Here are 2 patches against the 'i2c/for-current' branch of Wolfram's 'linux.git' repo. >> The affected drivers call platform_get_irq() but override its result in case of error >> which prevents the deferred probing from working. >> >> [1/2] i2c: iop3xx: fix deferred probing >> [2/2] i2c: synquacer: fix deferred probing > > Please hold on with this series; I'm gonna add another patch... Actually, I'm unsure about drivers/i2c/busses/i2c-pca-platform.c: normally it uses polling iff the (considered optional) IRQ can't be set up (irq < 0 returned from platform_get_irq_optional()) then polling mode is used. I have a patch to propaate -EPROBE_DEFER upstream but I'm not sure what is better : sefer the probe (and potentially falling permanently iff the kernel wouldn't able to finally set up the IRQ or to start the I2C driver in the polling mode right away. Does these doubts even make sense? :-) MBR, Sergey
On 5/30/21 6:53 PM, Sergey Shtylyov wrote: [...] >>> Here are 2 patches against the 'i2c/for-current' branch of Wolfram's 'linux.git' repo. >>> The affected drivers call platform_get_irq() but override its result in case of error >>> which prevents the deferred probing from working. >>> >>> [1/2] i2c: iop3xx: fix deferred probing >>> [2/2] i2c: synquacer: fix deferred probing >> >> Please hold on with this series; I'm gonna add another patch... > > Actually, I'm unsure about drivers/i2c/busses/i2c-pca-platform.c: normally it > uses polling iff the (considered optional) IRQ can't be set up (irq < 0 returned > from platform_get_irq_optional()) then polling mode is used. I started to be tautologcial, should really re-read the msgs before seding... :-) > I have a patch to > propaate -EPROBE_DEFER upstream but I'm not sure what is better : sefer the probe Propagate, of/c. :-) > (and potentially falling permanently iff the kernel wouldn't able to finally set Wasn't. :-) > up the IRQ or to start the I2C driver in the polling mode right away. Does these > doubts even make sense? :-) MBR, Sergey