linux-kernel - Re: [PATCH 2/2] i2c: Clear client->irq in i2c_device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 30 Oct 2018 11:51:20 +0000
From:   Charles Keepax <ckeepax@...nsource.cirrus.com>
To:     Benjamin Tissoires <benjamin.tissoires@...hat.com>
CC:     Wolfram Sang <wsa@...-dreams.de>,
        Linux I2C <linux-i2c@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        <patches@...nsource.cirrus.com>
Subject: Re: [PATCH 2/2] i2c: Clear client->irq in i2c_device_remove

On Mon, Oct 29, 2018 at 11:15:47AM +0100, Benjamin Tissoires wrote:
> On Sun, Oct 28, 2018 at 11:31 PM Wolfram Sang <wsa@...-dreams.de> 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 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 issue by clearing client->irq in i2c_device_remove,
> > > forcing i2c_device_probe to lookup the mapping again.
> > >
> > > Signed-off-by: Charles Keepax <ckeepax@...nsource.cirrus.com>
> >
> > Adding Benjamin here again. Also, should there be a Fixes: tag?
> 
> Not sure if the circumstances are preventing me to think straight, but
> how can you reprobe the i2c_device?

You just head into /sys/bus/i2c/drivers/<the_driver> and use the
unbind file to remove the driver. You can then probe the driver
again using the bind file.

> And in all cases, for the Host notify part, having the IRQ already set
> shouldn't be an issue.

To be clear this isn't a theoretical issue this is something I
can replicate very easily. The problem comes in when you unbind
both the I2C device and the device that is providing its IRQ. In
my case the I2C device is a speaker amp and the device providing
IRQs is an audio CODEC.

When the device providing the IRQ is unbound it will delete the
IRQ mapping. For the I2C device to acquire its IRQ something
needs to recreate that mapping, this would normally happen (in a
DT system) as a result of the of_irq_get/_by_name. But as
client->irq is already set this doesn't happen, causing the I2C
device to fail probe because it couldn't locate its IRQ.

I can provide some stack traces or something if that would help
to clarify the issue?

Thanks,
Charles