linux-kernel - Re: [PATCH v5 1/1] i2c: Restore initial power state when we are done.

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] [day] [month] [year] [list]

Message-ID: <Y3IiCmrw4BNjgVKx@paasikivi.fi.intel.com>
Date:   Mon, 14 Nov 2022 11:10:02 +0000
From:   Sakari Ailus <sakari.ailus@...ux.intel.com>
To:     Ricardo Ribalda <ribalda@...omium.org>
Cc:     Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Wolfram Sang <wsa@...nel.org>,
        Tomasz Figa <tfiga@...omium.org>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
        Hidenori Kobayashi <hidenorik@...gle.com>,
        stable@...r.kernel.org, linux-i2c@...r.kernel.org,
        Sergey Senozhatsky <senozhatsky@...omium.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 1/1] i2c: Restore initial power state when we are done.

Hi Ricardo, Mika,

On Mon, Nov 14, 2022 at 11:51:24AM +0100, Ricardo Ribalda wrote:
> Hi Mika
> 
> Thanks for your review!
> 
> On Mon, 14 Nov 2022 at 11:33, Mika Westerberg
> <mika.westerberg@...ux.intel.com> wrote:
> >
> > Hi,
> >
> > On Sat, Nov 12, 2022 at 09:24:14PM +0100, Wolfram Sang wrote:
> > > On Thu, Nov 10, 2022 at 05:20:39PM +0100, Ricardo Ribalda wrote:
> > > > A driver that supports I2C_DRV_ACPI_WAIVE_D0_PROBE is not expected to
> > > > power off a device that it has not powered on previously.
> > > >
> > > > For devices operating in "full_power" mode, the first call to
> > > > `i2c_acpi_waive_d0_probe` will return 0, which means that the device
> > > > will be turned on with `dev_pm_domain_attach`.
> > > >
> > > > If probe fails or the device is removed the second call to
> > > > `i2c_acpi_waive_d0_probe` will return 1, which means that the device
> > > > will not be turned off. This is, it will be left in a different power
> > > > state. Lets fix it.
> > > >
> > > > Reviewed-by: Sakari Ailus <sakari.ailus@...ux.intel.com>
> > > > Cc: stable@...r.kernel.org
> > > > Fixes: b18c1ad685d9 ("i2c: Allow an ACPI driver to manage the device's power state during probe")
> > > > Signed-off-by: Ricardo Ribalda <ribalda@...omium.org>
> > >
> > > Adding I2C ACPI maintainer to CC. Mika, could you please help
> > > reviewing?
> >
> > Sure.
> >
> > > > diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c
> > > > index b4edf10e8fd0..6f4974c76404 100644
> > > > --- a/drivers/i2c/i2c-core-base.c
> > > > +++ b/drivers/i2c/i2c-core-base.c
> > > > @@ -467,6 +467,7 @@ static int i2c_device_probe(struct device *dev)
> > > >  {
> > > >     struct i2c_client       *client = i2c_verify_client(dev);
> > > >     struct i2c_driver       *driver;
> > > > +   bool do_power_on;
> > > >     int status;
> > > >
> > > >     if (!client)
> > > > @@ -545,8 +546,8 @@ static int i2c_device_probe(struct device *dev)
> > > >     if (status < 0)
> > > >             goto err_clear_wakeup_irq;
> > > >
> > > > -   status = dev_pm_domain_attach(&client->dev,
> > > > -                                 !i2c_acpi_waive_d0_probe(dev));
> > > > +   do_power_on = !i2c_acpi_waive_d0_probe(dev);
> > > > +   status = dev_pm_domain_attach(&client->dev, do_power_on);
> >
> > I think this is fine as the driver says it is OK to see the device in
> > whatever power state (I assume this is what the
> > i2c_acpi_waive_d0_probe() is supposed to be doing but there is no
> > kernel-doc, though).
> >
> > > >     if (status)
> > > >             goto err_clear_wakeup_irq;
> > > >
> > > > @@ -580,12 +581,14 @@ static int i2c_device_probe(struct device *dev)
> > > >     if (status)
> > > >             goto err_release_driver_resources;
> > > >
> > > > +   client->power_off_on_remove = do_power_on;
> > > > +
> > > >     return 0;
> > > >
> > > >  err_release_driver_resources:
> > > >     devres_release_group(&client->dev, client->devres_group_id);
> > > >  err_detach_pm_domain:
> > > > -   dev_pm_domain_detach(&client->dev, !i2c_acpi_waive_d0_probe(dev));
> > > > +   dev_pm_domain_detach(&client->dev, do_power_on);
> > > >  err_clear_wakeup_irq:
> > > >     dev_pm_clear_wake_irq(&client->dev);
> > > >     device_init_wakeup(&client->dev, false);
> > > > @@ -610,7 +613,7 @@ static void i2c_device_remove(struct device *dev)
> > > >
> > > >     devres_release_group(&client->dev, client->devres_group_id);
> > > >
> > > > -   dev_pm_domain_detach(&client->dev, !i2c_acpi_waive_d0_probe(dev));
> > > > +   dev_pm_domain_detach(&client->dev, client->power_off_on_remove);
> >
> > However, on the remove path I think we should not call
> > i2c_acpi_waive_d0_probe() at all as that has nothing to do with remove
> > (it is for whether the driver accepts any power state on probe AFAICT)
> > so this should stil be "true" here. Unless I'm missing something.
> 
> I guess the problem is that we would be undoing something (power-off),
> that we did not do.
> 
> 
> Sakari, can you think of a use-case where this can break something? If
> not I can send a v6.

I don't think there's any harm from powering the device off here. The
driver should have done it but there could be bugs...

The genpd equivalent doesn't even use the argument but powers off the
domain in any case.

-- 
Kind regards,

Sakari Ailus