linux-kernel - Re: [PATCH v4 5/6] at24: Support probing while off

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]

Message-ID: <CAMpxmJVPTKW+sYSJ3dnfF8nLAOKEa4Ob7bpxG0KD3Tkdm+rtYw@mail.gmail.com>
Date:   Thu, 12 Mar 2020 14:10:32 +0100
From:   Bartosz Golaszewski <bgolaszewski@...libre.com>
To:     Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc:     linux-i2c <linux-i2c@...r.kernel.org>,
        Wolfram Sang <wsa@...-dreams.de>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        linux-acpi@...r.kernel.org, Bingbu Cao <bingbu.cao@...el.com>,
        linux-media <linux-media@...r.kernel.org>,
        Chiranjeevi Rapolu <chiranjeevi.rapolu@...el.com>,
        Hyungwoo Yang <hyungwoo.yang@...el.com>,
        Arnd Bergmann <arnd@...db.de>,
        LKML <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Rajmohan Mani <rajmohan.mani@...el.com>,
        Tomasz Figa <tfiga@...omium.org>
Subject: Re: [PATCH v4 5/6] at24: Support probing while off

śr., 11 mar 2020 o 09:56 Sakari Ailus <sakari.ailus@...ux.intel.com> napisał(a):
>
> Hi Bartosz,
>
> Thanks for the reply.
>
> On Wed, Jan 29, 2020 at 02:36:17PM +0100, Bartosz Golaszewski wrote:
> > wt., 21 sty 2020 o 14:41 Sakari Ailus <sakari.ailus@...ux.intel.com> napisał(a):
> > >
> > > In certain use cases (where the chip is part of a camera module, and the
> > > camera module is wired together with a camera privacy LED), powering on
> > > the device during probe is undesirable. Add support for the at24 to
> > > execute probe while being powered off. For this to happen, a hint in form
> > > of a device property is required from the firmware.
> > >
> > > Signed-off-by: Sakari Ailus <sakari.ailus@...ux.intel.com>
> > > ---
> > >  drivers/misc/eeprom/at24.c | 31 +++++++++++++++++++++----------

[snip!]

> > >
> > >  static int at24_remove(struct i2c_client *client)
> > >  {
> > > +       bool low_power;
> > > +
> > >         pm_runtime_disable(&client->dev);
> > > -       pm_runtime_set_suspended(&client->dev);
> > > +       low_power = acpi_dev_state_low_power(&client->dev);
> >
> > This is inconsistent. You define the low_power field in the context
> > structure (BTW the name low_power is a bit vague here - without
> > looking at its assignment it would make me think it's about something
> > battery-related, how about 'off_at_probe'?) and instead of reusing
>
> The field was called probe_powered_off in v1, but I changed it to
> probe_low_power (and renamed related functions etc.) based on review
> comments --- for the device may not be powered off actually.
>

But is it actually ever low-power? What are the possible logical
states of the device? If I understood correctly: it's either off or on
at probe - not actually low-power. Am I missing something? In your
cover letter you're writing: "These patches enable calling (and
finishing) a driver's probe function without powering on the
respective device on busses where the practice is to power on the
device for probe." To me there's no mention of a low-power state,
which makes the name 'probe_low_power' seem completely unrelated.

> > this field here, you call acpi_dev_state_low_power() again. Either
> > don't store the context for the life-time of the device if not
> > necessary or don't call acpi_dev_state_low_power() at remove, although
> > the commit message doesn't describe whether the latter is done on
> > purpose.
>
> Right. probe-low-power property has the same effect on remove for
> consistency, i.e. the device can remain in low power state during remove.
> This is documented in probe_low_power field documentation in the first
> patch.
>

Just please don't store any state if you're not using it outside of
the probe() function.

Bartosz