From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B7E25C04A6B for ; Fri, 10 May 2019 10:09:27 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 92D9620881 for ; Fri, 10 May 2019 10:09:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727234AbfEJKJ0 (ORCPT ); Fri, 10 May 2019 06:09:26 -0400 Received: from mga18.intel.com ([134.134.136.126]:54995 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727053AbfEJKJ0 (ORCPT ); Fri, 10 May 2019 06:09:26 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 May 2019 03:09:26 -0700 X-ExtLoop1: 1 Received: from paasikivi.fi.intel.com ([10.237.72.42]) by fmsmga005.fm.intel.com with ESMTP; 10 May 2019 03:09:24 -0700 Received: from punajuuri.localdomain (punajuuri.localdomain [192.168.240.130]) by paasikivi.fi.intel.com (Postfix) with ESMTPS id B3B12201EF; Fri, 10 May 2019 13:09:23 +0300 (EEST) Received: from sailus by punajuuri.localdomain with local (Exim 4.89) (envelope-from ) id 1hP2T4-0003ov-KY; Fri, 10 May 2019 13:09:30 +0300 From: Sakari Ailus 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> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@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. 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