On Thu, Jan 10, 2019 at 01:32:36PM +, Charles Keepax wrote:
> On Thu, Jan 10, 2019 at 12:47:56AM +0300, Yauhen Kharuzhy wrote:
> > On Fri, Oct 19, 2018 at 09:59:58AM +0100, Charles Keepax wrote:
> > > The IRQ will be mapped in i2c_device_probe only if client->irq is zero and
> > > i2c_device_re
On Thu, Jan 10, 2019 at 12:47:56AM +0300, Yauhen Kharuzhy wrote:
> On Fri, Oct 19, 2018 at 09:59:58AM +0100, Charles Keepax wrote:
> > The IRQ will be mapped in i2c_device_probe only if client->irq is zero and
> > i2c_device_remove does not clear this. When rebinding an I2C device,
> > whos IRQ pro
On Fri, Oct 19, 2018 at 09:59:58AM +0100, Charles Keepax wrote:
> The IRQ will be mapped in i2c_device_probe only if client->irq is zero and
> i2c_device_remove does not clear this. When rebinding an I2C device,
> whos IRQ provider has also been rebound this means that an IRQ mapping
> will never b
On Fri, Oct 19, 2018 at 09:59:58AM +0100, Charles Keepax wrote:
> The IRQ will be mapped in i2c_device_probe only if client->irq is zero and
> i2c_device_remove does not clear this. When rebinding an I2C device,
> whos IRQ provider has also been rebound this means that an IRQ mapping
> will never b
> It's a bit of a long chain and fairly tricky to say exactly when
> the bug was introduced but I think this is probably the closest
> match:
>
> Fixes: 2fd36c552649 ("i2c: core: Map OF IRQ at probe time")
Thank you for checking! Then, I'll just leave it and cc stable so it can
be applied as lon
On Tue, Oct 30, 2018 at 02:55:50PM +, Wolfram Sang wrote:
>
> > No, that's fine. Now I get this, and I totally agree with the approach:
> >
> > Reviewed-by: Benjamin Tissoires
>
> Thanks! If one of you could provide me with a Fixes tag (for this. or
> both patches?), that would be most help
> No, that's fine. Now I get this, and I totally agree with the approach:
>
> Reviewed-by: Benjamin Tissoires
Thanks! If one of you could provide me with a Fixes tag (for this. or
both patches?), that would be most helpful.
signature.asc
Description: PGP signature
On Tue, Oct 30, 2018 at 12:51 PM Charles Keepax
wrote:
>
> On Mon, Oct 29, 2018 at 11:15:47AM +0100, Benjamin Tissoires wrote:
> > On Sun, Oct 28, 2018 at 11:31 PM Wolfram Sang wrote:
> > >
> > > On Fri, Oct 19, 2018 at 09:59:58AM +0100, Charles Keepax wrote:
> > > > The IRQ will be mapped in i2c
On Mon, Oct 29, 2018 at 11:15:47AM +0100, Benjamin Tissoires wrote:
> On Sun, Oct 28, 2018 at 11:31 PM Wolfram Sang wrote:
> >
> > On Fri, Oct 19, 2018 at 09:59:58AM +0100, Charles Keepax wrote:
> > > The IRQ will be mapped in i2c_device_probe only if client->irq is zero and
> > > i2c_device_remov
On Sun, Oct 28, 2018 at 11:31 PM Wolfram Sang wrote:
>
> On Fri, Oct 19, 2018 at 09:59:58AM +0100, Charles Keepax wrote:
> > The IRQ will be mapped in i2c_device_probe only if client->irq is zero and
> > i2c_device_remove does not clear this. When rebinding an I2C device,
> > whos IRQ provider has
On Fri, Oct 19, 2018 at 09:59:58AM +0100, Charles Keepax wrote:
> The IRQ will be mapped in i2c_device_probe only if client->irq is zero and
> i2c_device_remove does not clear this. When rebinding an I2C device,
> whos IRQ provider has also been rebound this means that an IRQ mapping
> will never b
The IRQ will be mapped in i2c_device_probe only if client->irq is zero and
i2c_device_remove does not clear this. When rebinding an I2C device,
whos IRQ provider has also been rebound this means that an IRQ mapping
will never be created, causing the I2C device to fail to acquire its
IRQ. Fix this i
12 matches
Mail list logo
