[PATCH] i2c: Prevent runtime suspend of adapter when Host Notify is required

[PATCH] i2c: Prevent runtime suspend of adapter when Host Notify is required

[Jarkko Nikula]

Multiple users have reported their Synaptics touchpad has stopped
working between v4.20.1 and v4.20.2 when using SMBus interface.

The culprit for this appeared to be commit c5eb1190074c ("PCI / PM: Allow
runtime PM without callback functions") that fixed the runtime PM for
i2c-i801 SMBus adapter. Those Synaptics touchpad are using i2c-i801
for SMBus communication and testing showed they are able to get back
working by preventing the runtime suspend of adapter.

Normally when i2c-i801 SMBus adapter transmits with the client it resumes
before operation and autosuspends after.

However, if client requires SMBus Host Notify protocol, what those
Synaptics touchpads do, then the host adapter must not go to runtime
suspend since then it cannot process incoming SMBus Host Notify commands
the client may send.

Fix this by keeping I2C/SMBus adapter active in case client requires
Host Notify.

Reported-by: Keijo Vaara <ferdasyn@rocketmail.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203297
Fixes: c5eb1190074c ("PCI / PM: Allow runtime PM without callback functions")
Cc: stable@vger.kernel.org # v4.20+
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
---
Keijo: could you test this does it fix the issue you reported? This is
practically the same diff I sent earlier what you probably haven't tested yet.
I wanted to send a commitable fix in case it works since I'll be out of
office in a few coming days.
---
 drivers/i2c/i2c-core-base.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
index 38af18645133..8149c9e32b69 100644
--- a/drivers/i2c/i2c-core-base.c
+++ b/drivers/i2c/i2c-core-base.c
@@ -327,6 +327,8 @@ static int i2c_device_probe(struct device *dev)
 
 		if (client->flags & I2C_CLIENT_HOST_NOTIFY) {
 			dev_dbg(dev, "Using Host Notify IRQ\n");
+			/* Keep adapter active when Host Notify is required */
+			pm_runtime_get_sync(&client->adapter->dev);
 			irq = i2c_smbus_host_notify_to_irq(client);
 		} else if (dev->of_node) {
 			irq = of_irq_get_byname(dev->of_node, "irq");
@@ -431,6 +433,8 @@ static int i2c_device_remove(struct device *dev)
 	device_init_wakeup(&client->dev, false);
 
 	client->irq = client->init_irq;
+	if (client->flags & I2C_CLIENT_HOST_NOTIFY)
+		pm_runtime_put(&client->adapter->dev);
 
 	return status;
 }
-- 
2.20.1

Re: [PATCH] i2c: Prevent runtime suspend of adapter when Host Notify is required

[Rafael J. Wysocki]

On Tue, Apr 30, 2019 at 4:23 PM Jarkko Nikula
<jarkko.nikula@linux.intel.com> wrote:
>
> Multiple users have reported their Synaptics touchpad has stopped
> working between v4.20.1 and v4.20.2 when using SMBus interface.
>
> The culprit for this appeared to be commit c5eb1190074c ("PCI / PM: Allow
> runtime PM without callback functions") that fixed the runtime PM for
> i2c-i801 SMBus adapter. Those Synaptics touchpad are using i2c-i801
> for SMBus communication and testing showed they are able to get back
> working by preventing the runtime suspend of adapter.
>
> Normally when i2c-i801 SMBus adapter transmits with the client it resumes
> before operation and autosuspends after.
>
> However, if client requires SMBus Host Notify protocol, what those
> Synaptics touchpads do, then the host adapter must not go to runtime
> suspend since then it cannot process incoming SMBus Host Notify commands
> the client may send.
>
> Fix this by keeping I2C/SMBus adapter active in case client requires
> Host Notify.
>
> Reported-by: Keijo Vaara <ferdasyn@rocketmail.com>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=203297
> Fixes: c5eb1190074c ("PCI / PM: Allow runtime PM without callback functions")
> Cc: stable@vger.kernel.org # v4.20+
> Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>

Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Or please let me know if you want me to take this.

> ---
> Keijo: could you test this does it fix the issue you reported? This is
> practically the same diff I sent earlier what you probably haven't tested yet.
> I wanted to send a commitable fix in case it works since I'll be out of
> office in a few coming days.
> ---
>  drivers/i2c/i2c-core-base.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> index 38af18645133..8149c9e32b69 100644
> --- a/drivers/i2c/i2c-core-base.c
> +++ b/drivers/i2c/i2c-core-base.c
> @@ -327,6 +327,8 @@ static int i2c_device_probe(struct device *dev)
>
>                 if (client->flags & I2C_CLIENT_HOST_NOTIFY) {
>                         dev_dbg(dev, "Using Host Notify IRQ\n");
> +                       /* Keep adapter active when Host Notify is required */
> +                       pm_runtime_get_sync(&client->adapter->dev);
>                         irq = i2c_smbus_host_notify_to_irq(client);
>                 } else if (dev->of_node) {
>                         irq = of_irq_get_byname(dev->of_node, "irq");
> @@ -431,6 +433,8 @@ static int i2c_device_remove(struct device *dev)
>         device_init_wakeup(&client->dev, false);
>
>         client->irq = client->init_irq;
> +       if (client->flags & I2C_CLIENT_HOST_NOTIFY)
> +               pm_runtime_put(&client->adapter->dev);
>
>         return status;
>  }
> --
> 2.20.1
>

Re: [PATCH] i2c: Prevent runtime suspend of adapter when Host Notify is required

[Keijo Vaara]

On Tue, Apr 30, 2019 at 4:23 PM Jarkko Nikula
<jarkko.nikula@linux.intel.com> wrote:
>
> ---
> Keijo: could you test this does it fix the issue you reported? This is
> practically the same diff I sent earlier what you probably haven't tested yet.
> I wanted to send a commitable fix in case it works since I'll be out of
> office in a few coming days.
> ---
>  drivers/i2c/i2c-core-base.c | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> index 38af18645133..8149c9e32b69 100644
> --- a/drivers/i2c/i2c-core-base.c
> +++ b/drivers/i2c/i2c-core-base.c
> @@ -327,6 +327,8 @@ static int i2c_device_probe(struct device *dev)
>
>                if (client->flags & I2C_CLIENT_HOST_NOTIFY) {
>                        dev_dbg(dev, "Using Host Notify IRQ\n");
> +                      /* Keep adapter active when Host Notify is required */
> +                      pm_runtime_get_sync(&client->adapter->dev);
>                        irq = i2c_smbus_host_notify_to_irq(client);
>                } else if (dev->of_node) {
>                        irq = of_irq_get_byname(dev->of_node, "irq");
> @@ -431,6 +433,8 @@ static int i2c_device_remove(struct device *dev)
>        device_init_wakeup(&client->dev, false);
>
>        client->irq = client->init_irq;
> +      if (client->flags & I2C_CLIENT_HOST_NOTIFY)
> +              pm_runtime_put(&client->adapter->dev);
>
>        return status;
>  }
> --
> 2.20.1
>

Thanks guys, I've tested the patch and can confirm it fixes the issue.

Re: [PATCH] i2c: Prevent runtime suspend of adapter when Host Notify is required

[Jarkko Nikula]

On 4/30/19 6:56 PM, Sasha Levin wrote:
> Hi,
> 
> [This is an automated email]
> 
> 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).

-- 
Jarkko

Re: [PATCH] i2c: Prevent runtime suspend of adapter when Host Notify is required

[Charles Keepax]

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.

Thanks,
Charles

Re: [PATCH] i2c: Prevent runtime suspend of adapter when Host Notify is required

[Charles Keepax]

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.

Thanks,
Charles

Re: [PATCH] i2c: Prevent runtime suspend of adapter when Host Notify is required

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1362 bytes --]

On Tue, Apr 30, 2019 at 05:23:22PM +0300, Jarkko Nikula wrote:
> Multiple users have reported their Synaptics touchpad has stopped
> working between v4.20.1 and v4.20.2 when using SMBus interface.
> 
> The culprit for this appeared to be commit c5eb1190074c ("PCI / PM: Allow
> runtime PM without callback functions") that fixed the runtime PM for
> i2c-i801 SMBus adapter. Those Synaptics touchpad are using i2c-i801
> for SMBus communication and testing showed they are able to get back
> working by preventing the runtime suspend of adapter.
> 
> Normally when i2c-i801 SMBus adapter transmits with the client it resumes
> before operation and autosuspends after.
> 
> However, if client requires SMBus Host Notify protocol, what those
> Synaptics touchpads do, then the host adapter must not go to runtime
> suspend since then it cannot process incoming SMBus Host Notify commands
> the client may send.
> 
> Fix this by keeping I2C/SMBus adapter active in case client requires
> Host Notify.
> 
> Reported-by: Keijo Vaara <ferdasyn@rocketmail.com>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=203297
> Fixes: c5eb1190074c ("PCI / PM: Allow runtime PM without callback functions")
> Cc: stable@vger.kernel.org # v4.20+
> Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>

Applied to for-current-fixed, thanks!


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH] i2c: Prevent runtime suspend of adapter when Host Notify is required

[Greg KH]

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