Linux-ACPI Archive on lore.kernel.org
 help / color / Atom feed
From: Sakari Ailus <sakari.ailus@linux.intel.com>
To: linux-acpi@vger.kernel.org
Cc: rajmohan.mani@intel.com, linux-media@vger.kernel.org
Subject: [PATCH 0/5] Support running driver's probe for a device powered off
Date: Fri, 10 May 2019 13:09:25 +0300
Message-ID: <20190510100930.14641-1-sakari.ailus@linux.intel.com> (raw)

Hi all,

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. While it generally is a driver's job to
check the that the device is there, there are cases where it might be
undesirable. (In this case it stems from a combination of hardware design
and user expectations; see below.) The downside with this change is that
if there is something wrong with the device, it will only be found at the
time the device is used. In this case (the camera sensors + EEPROM in a
sensor) I don't see any tangible harm from that though.

An indication both from the driver and the firmware is required to allow
the device's power state to remain off during probe (see the first patch).


The use case is such that there is a privacy LED next to an integrated
user-facing laptop camera, and this LED is there to signal the user that
the camera is recording a video or capturing images. That LED also happens
to be wired to one of the power supplies of the camera, so whenever you
power on the camera, the LED will be lit, whether images are captured from
the camera --- or not. There's no way to implement this differently
without additional software control (allowing of which is itself a
hardware design decision) on most CSI-2-connected camera sensors as they
simply have no pin to signal the camera streaming state.

This is also what happens during driver probe: the camera will be powered
on by the I²C subsystem calling dev_pm_domain_attach() and the device is
already powered on when the driver's own probe function is called. To the
user this visible during the boot process as a blink of the privacy LED,
suggesting that the camera is recording without the user having used an
application to do that. From the end user's point of view the behaviour is
not expected and for someone unfamiliar with internal workings of a
computer surely seems quite suspicious --- even if images are not being
actually captured.

Rajmohan Mani (1):
  media: i2c: imx319: Support probe while the device is off

Sakari Ailus (4):
  ACPI: Enable driver and firmware hints to control power at probe time
  ACPI: Add a convenience function to tell a device is suspended in
    probe
  ov5670: Support probe whilst the device is off
  at24: Support probing while off

 drivers/acpi/device_pm.c   | 42 ++++++++++++++++++++++++++++++++++++++++--
 drivers/media/i2c/imx319.c | 25 ++++++++++++++-----------
 drivers/media/i2c/ov5670.c | 25 ++++++++++++++-----------
 drivers/misc/eeprom/at24.c | 30 ++++++++++++++++++++----------
 include/linux/acpi.h       |  5 +++++
 include/linux/device.h     |  6 ++++++
 6 files changed, 99 insertions(+), 34 deletions(-)

-- 
2.11.0


             reply index

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-10 10:09 Sakari Ailus [this message]
2019-05-10 10:09 ` [PATCH 1/5] ACPI: Enable driver and firmware hints to control power at probe time Sakari Ailus
2019-05-31  9:17   ` Rafael J. Wysocki
2019-06-05 12:07     ` Sakari Ailus
2019-05-10 10:09 ` [PATCH 2/5] ACPI: Add a convenience function to tell a device is suspended in probe Sakari Ailus
2019-05-10 10:09 ` [PATCH 3/5] ov5670: Support probe whilst the device is off Sakari Ailus
2019-06-05  7:07   ` Tomasz Figa
2019-06-05 10:15     ` Sakari Ailus
2019-06-07  7:54       ` Tomasz Figa
2019-08-26  8:38         ` Sakari Ailus
2019-08-26  9:21           ` Tomasz Figa
2019-05-10 10:09 ` [PATCH 4/5] media: i2c: imx319: Support probe while " Sakari Ailus
2019-05-10 10:09 ` [PATCH 5/5] at24: Support probing while off Sakari Ailus

Reply instructions:

You may reply publically 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=20190510100930.14641-1-sakari.ailus@linux.intel.com \
    --to=sakari.ailus@linux.intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=rajmohan.mani@intel.com \
    /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

Linux-ACPI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-acpi/0 linux-acpi/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-acpi linux-acpi/ https://lore.kernel.org/linux-acpi \
		linux-acpi@vger.kernel.org linux-acpi@archiver.kernel.org
	public-inbox-index linux-acpi


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-acpi


AGPL code for this site: git clone https://public-inbox.org/ public-inbox