public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/5] ACPI: Enable driver and firmware hints to control power at probe time
Date: Mon, 26 Aug 2019 16:51:51 +0300	[thread overview]
Message-ID: <20190826135151.GS31967@paasikivi.fi.intel.com> (raw)
In-Reply-To: <20190826133439.GA13275@kroah.com>

On Mon, Aug 26, 2019 at 03:34:39PM +0200, Greg Kroah-Hartman wrote:
> On Mon, Aug 26, 2019 at 01:32:00PM +0300, Sakari Ailus wrote:
> > Hi Greg,
> > 
> > On Mon, Aug 26, 2019 at 10:43:43AM +0200, Greg Kroah-Hartman wrote:
> > 
> > ...
> > 
> > > > diff --git a/include/linux/device.h b/include/linux/device.h
> > > > index 6717adee33f01..4bc0ea4a3201a 100644
> > > > --- a/include/linux/device.h
> > > > +++ b/include/linux/device.h
> > > > @@ -248,6 +248,12 @@ enum probe_type {
> > > >   * @owner:	The module owner.
> > > >   * @mod_name:	Used for built-in modules.
> > > >   * @suppress_bind_attrs: Disables bind/unbind via sysfs.
> > > > + * @probe_low_power: The driver supports its probe function being called while
> > > > + *		     the device is in a low power state, independently of the
> > > > + *		     expected behaviour on combination of a given bus and
> > > > + *		     firmware interface etc. The driver is responsible for
> > > > + *		     powering the device on using runtime PM in such case.
> > > > + *		     This configuration has no effect if CONFIG_PM is disabled.
> > > >   * @probe_type:	Type of the probe (synchronous or asynchronous) to use.
> > > >   * @of_match_table: The open firmware table.
> > > >   * @acpi_match_table: The ACPI match table.
> > > > @@ -285,6 +291,7 @@ struct device_driver {
> > > >  	const char		*mod_name;	/* used for built-in modules */
> > > >  
> > > >  	bool suppress_bind_attrs;	/* disables bind/unbind via sysfs */
> > > > +	bool probe_low_power;
> > > 
> > > Ick, no, this should be a bus-specific thing to handle such messed up
> > > hardware.  Why polute this in the driver core?
> > 
> > The alternative could be to make it I²C specific indeed; the vast majority
> > of camera sensors are I²C devices these days.
> 
> Why is this even needed to be a bus/device attribute at all?  You are
> checking the firmware property in the probe function, just do the logic
> there as you are, what needs to be saved to the bus's logic?

By the time the driver gets hold of the device, or gets to control its
power state, the I²C framework has already called dev_pm_domain_attach() to
power on the device. The I²C drivers on ACPI based systems expect the
device to be powered on for probe.

-- 
Sakari Ailus
sakari.ailus@linux.intel.com

  reply	other threads:[~2019-08-26 13:51 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-26  8:31 [PATCH v2 0/5] Support running driver's probe for a device powered off Sakari Ailus
2019-08-26  8:31 ` [PATCH v2 1/5] ACPI: Enable driver and firmware hints to control power at probe time Sakari Ailus
2019-08-26  8:43   ` Greg Kroah-Hartman
2019-08-26 10:32     ` Sakari Ailus
2019-08-26 13:34       ` Greg Kroah-Hartman
2019-08-26 13:51         ` Sakari Ailus [this message]
2019-08-28  8:55         ` Rafael J. Wysocki
2019-08-28  9:57           ` Sakari Ailus
2019-08-28 12:35             ` Rafael J. Wysocki
2019-08-26  8:46   ` Greg Kroah-Hartman
2019-08-26 10:29     ` Sakari Ailus
2019-08-26  8:31 ` [PATCH v2 2/5] ACPI: Add a convenience function to tell a device is suspended in probe Sakari Ailus
2019-08-26  8:31 ` [PATCH v2 3/5] ov5670: Support probe whilst the device is in a low power state Sakari Ailus
2019-08-26  8:31 ` [PATCH v2 4/5] media: i2c: imx319: Support probe while the device is off Sakari Ailus
2019-08-26  8:31 ` [PATCH v2 5/5] at24: Support probing while off Sakari Ailus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190826135151.GS31967@paasikivi.fi.intel.com \
    --to=sakari.ailus@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox