Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp3707006ybl; Tue, 21 Jan 2020 05:43:50 -0800 (PST) X-Google-Smtp-Source: APXvYqxSBa/maxf1zH4oMyiDzY7ZOQDSN1BbibS1xDsHl585ebswwZaRdgrAgb++3Vw2SrSONu7u X-Received: by 2002:a05:6808:486:: with SMTP id z6mr3083196oid.117.1579614230220; Tue, 21 Jan 2020 05:43:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579614230; cv=none; d=google.com; s=arc-20160816; b=wSukfY4edwMFeRMUoxSEp1rtcEsbYPK+m8XhX7lBs2LJqM7HT4OWmo4dMOJLab0dE+ K5Ph2ypKnQPEHvABTNxEwrBPbvQtUbkizQxgcuC5vSJo8HRjljxTryqOLMEV/+YBvAhA /Sow8fKfs+EFSXuZdBZwTDezrUqHqlXjyF6cpPWUWCWSQ9J+YOWExsVLHUc02o+jFnXc hPD2Ghxbrr7dk9eZWXwcVUFZYCXVYG8oECuTGrwiDhjg8Q6Yojz7ZeMXVKAevT+eoigN 1wzErd//zHJe/yYytPPvTqucWxvG+/in0Qa4Yfq5OaYl8B4dA+W26y//UjD10H/zXM39 WlzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=fxAebtMQp7/iVMaTVsv7PrLpQXclARJlhM/VXxnJHzY=; b=Y2CbHxFp3IwemYZAQNTSaDLZB06juriaVYBmeaMDiI7sWY2iOORhrjjLu1jyENQvHS ayFjREoDTBtkm/8RAJxFLEsprjTxMFxSfaArVWjU+MUIcyZ2gfQtvF/7oRMm6twE6H5A MWYmDQP/lldft6hcWy1aTJL/NBGnx4Sea8twxG0OGY7CIfwQaaLtpWDZvkc1Ydu+2Ivu 7XZmli6JQ8gzNI+EX41yNBsRDMDn+TxVSqTTA3vznJ/poWn3R+CHg89a4uaRh6+CoZ0p gZIMFSWf/a0n3eJMv961MgAnE7iQeOg40rcilOxKXn3ggV2axp6RHit+sdHbtzQ9Rm9b 45og== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b10si19381095oic.153.2020.01.21.05.43.37; Tue, 21 Jan 2020 05:43:50 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729251AbgAUNmJ (ORCPT + 99 others); Tue, 21 Jan 2020 08:42:09 -0500 Received: from mga17.intel.com ([192.55.52.151]:4186 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728982AbgAUNlp (ORCPT ); Tue, 21 Jan 2020 08:41:45 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jan 2020 05:41:44 -0800 X-IronPort-AV: E=Sophos;i="5.70,346,1574150400"; d="scan'208";a="307199828" Received: from paasikivi.fi.intel.com ([10.237.72.42]) by orsmga001-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jan 2020 05:41:40 -0800 Received: from punajuuri.localdomain (punajuuri.localdomain [192.168.240.130]) by paasikivi.fi.intel.com (Postfix) with ESMTP id BE67F20435; Tue, 21 Jan 2020 15:41:38 +0200 (EET) Received: from sailus by punajuuri.localdomain with local (Exim 4.92) (envelope-from ) id 1ittn3-0005Jn-5L; Tue, 21 Jan 2020 15:41:57 +0200 From: Sakari Ailus To: linux-i2c@vger.kernel.org Cc: Wolfram Sang , "Rafael J. Wysocki" , linux-acpi@vger.kernel.org, Bingbu Cao , linux-media@vger.kernel.org, Chiranjeevi Rapolu , Hyungwoo Yang , Bartosz Golaszewski , Arnd Bergmann , linux-kernel@vger.kernel.org, Greg Kroah-Hartman , rajmohan.mani@intel.com, Tomasz Figa Subject: [PATCH v4 0/6] Support running driver's probe for a device powered off Date: Tue, 21 Jan 2020 15:41:51 +0200 Message-Id: <20200121134157.20396-1-sakari.ailus@linux.intel.com> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. I've tested these on Linux-next, Bartosz's at24/for-next, Wolfram's i2c/for-next as well as Linux media master today; the patches apply to all without trouble. since v3 : - Rework the 2nd patch based on Rafael's comments - Rework description of the ACPI low power state helper function, according to Rafael's text. - Rename and rework the same function as acpi_dev_state_low_power(). - Reflect the changes in commit message as well. - Added a patch to document the probe-low-power _DSD property. since v2 : - Remove extra CONFIG_PM ifdefs; these are not needed. - Move the checks for power state hints from drivers/base/dd.c to drivers/i2c/i2c-base-core.c; these are I²C devices anyway. - Move the probe_low_power field from struct device_driver to struct i2c_driver. since v1: - Rename probe_powered_off struct device field as probe_low_power and reflect the similar naming to the patches overall. - Work with CONFIG_PM disabled, too. Rajmohan Mani (1): media: i2c: imx319: Support probe while the device is off Sakari Ailus (5): i2c: Allow driver to manage the device's power state during probe ACPI: Add a convenience function to tell a device is in low power state ov5670: Support probe whilst the device is in a low power state at24: Support probing while off Documentation: ACPI: Document probe-low-power _DSD property .../acpi/dsd/probe-low-power.rst | 28 +++++++++++++++++ Documentation/firmware-guide/acpi/index.rst | 1 + drivers/acpi/device_pm.c | 31 +++++++++++++++++++ drivers/i2c/i2c-core-base.c | 15 +++++++-- drivers/media/i2c/imx319.c | 23 ++++++++------ drivers/media/i2c/ov5670.c | 23 ++++++++------ drivers/misc/eeprom/at24.c | 31 +++++++++++++------ include/linux/acpi.h | 5 +++ include/linux/i2c.h | 3 ++ 9 files changed, 129 insertions(+), 31 deletions(-) create mode 100644 Documentation/firmware-guide/acpi/dsd/probe-low-power.rst -- 2.20.1