From patchwork Wed Jun 28 10:26:33 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 106508 Delivered-To: patch@linaro.org Received: by 10.140.101.44 with SMTP id t41csp838496qge; Wed, 28 Jun 2017 03:27:42 -0700 (PDT) X-Received: by 10.98.211.140 with SMTP id z12mr10111904pfk.231.1498645662159; Wed, 28 Jun 2017 03:27:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1498645662; cv=none; d=google.com; s=arc-20160816; b=tJ3cWLJFZB/EdtSDCc/UbOn4Q1k3tGZGBsupTTtM4uu09lnjHDLFL4mMNJRjYkqIzj A5A56oLP60WUn2pWR8kVFT/jBRbLEy1Y3BDxyU+ded8PO9DPtFLRsDDZPdARRX2B1hod AJ0BR6m7yIQObrSfY5s/RmrEs3z/9U7/procMtTwJ6Mf4vMlbA0B1pacs4baupkWD9jL bJMrAg0gNyjaxYd3f90NV0r7PECwAHJdwJOhDjGfmSLqeGpLnlENz/K88qYzYG7CtGUS gI3FaHl1zwHaxK+xAvWkaWkv4yQGYtVs0AawwbzOojDiWI4cQmAbAyhyMA9rdZhYTnsU 6Zgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=xBMmj/q3SKFDPLnt0yJTXGKziDzleVFTtZIfHVs04EI=; b=PMrv3iuwnZxLREhymK1j4PzAemJGPN6BskctTQ4eIWrEsobeLXfne5SaZvYZ477hkl /KUllUYWCchNXirb1DFzSgkWj1/+VFmLENxV7i/vPr0QZhLDFoGUtvd9DMqSV49Sa6xc W8JQiG1zhVvZ6sq7DebHxw78hk1cKcoLWRrfSkCTHvsFLcCC+ZDqipVHMytxdgau/UCB ADokAu/Nf4Q3ShIdEuoO5IaqlEIFWmfL0T8H0T6L+RrvUzjLhaeGTp2DQOX8X7ht34TN 5jq0pxKWeLoRZa6ybFtnW0cPfbOSEzCQxS3VM/UXtw/IqJX8a+sbQobQGRj92pOr+k0M lIiw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.b=R7JkEQ4x; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m63si1320730pfk.76.2017.06.28.03.27.41; Wed, 28 Jun 2017 03:27:42 -0700 (PDT) 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; dkim=pass header.i=@linaro.org header.b=R7JkEQ4x; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751795AbdF1K1R (ORCPT + 25 others); Wed, 28 Jun 2017 06:27:17 -0400 Received: from mail-pf0-f180.google.com ([209.85.192.180]:35597 "EHLO mail-pf0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751616AbdF1K1J (ORCPT ); Wed, 28 Jun 2017 06:27:09 -0400 Received: by mail-pf0-f180.google.com with SMTP id c73so31344001pfk.2 for ; Wed, 28 Jun 2017 03:27:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=xBMmj/q3SKFDPLnt0yJTXGKziDzleVFTtZIfHVs04EI=; b=R7JkEQ4xwuSvfFpPCEFEiyaaRp1HqrWfIn5vian0YCUBx8YlrC0ABEcUvWO7ZBlz+Y oB27a2Yin1DJYzN/BrbCxSK+eiUar0I1P2Hbzwt3B//HIPhaLYnKSsGLa6pp1yo83afO abja1tW0xE3HXqo/7co9OYi8d8RD+OMGclNjI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=xBMmj/q3SKFDPLnt0yJTXGKziDzleVFTtZIfHVs04EI=; b=WTZoPf9FnIK3qcFzCkkZFySHxR0wfqQg0E84MsGT00FxbeOmhIuuaQP6uaaHoNhuZG hJXoFddIv2uqSBpyz4WuZBtzE2ZT6r4wPigG+3d6/w14DZsWNgyOuLvBBwWyMbWA8hbM RAuqlQLfb3LEa6QMyTWPn6Ys1i9EJxtPcef8HqlWZ0ne2FYCPcX1gn0TESCrEgu2Ni+s Z5CwolqXWgXelp/PxO+YktKLjTjh2likbVw4TTfxY3IgriEMlB0mxHRfb3wijGXQV0zv 4vzVPUBFRylDy1Siycfwgv80MfutFfIVcQ0ZjUMxLWn1qSwa9CfYjEadI+n/dxjTW9up kVeQ== X-Gm-Message-State: AKS2vOw9eCToYT8rkg+bYI6R52s5nwG9SiiVn79rfR6E6Lqu+SI6bq2v BRX7tyUH+jsWrWJF X-Received: by 10.98.1.72 with SMTP id 69mr9929353pfb.124.1498645628850; Wed, 28 Jun 2017 03:27:08 -0700 (PDT) Received: from localhost ([122.171.238.149]) by smtp.gmail.com with ESMTPSA id g10sm4463184pfc.38.2017.06.28.03.27.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jun 2017 03:27:07 -0700 (PDT) From: Viresh Kumar To: Greg Kroah-Hartman Cc: Viresh Kumar , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Rafael Wysocki , Vincent Guittot , Stephen Boyd , Mark Brown , Shiraz Hashim , Rob Herring , rnayak@codeaurora.org Subject: [RFC 0/5] drivers: Add boot constraints core Date: Wed, 28 Jun 2017 15:56:33 +0530 Message-Id: X-Mailer: git-send-email 2.13.0.71.gd7076ec9c9cb Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, I am sending this RFC to get early comments before I put too much effort in the solution proposed here. The solution isn't fully complete yet. Problem statement: Some devices are powered ON by the bootloaders before the bootloader handovers control to Linux. It maybe important for those devices to keep working until the time a Linux device driver probes the device and reconfigure its resources. A typical example of that can be the LCD controller, which is used by the bootloaders to show image(s) while the machine is booting into Linux. The LCD controller can be using some resources, like clk, regulators, etc, that are shared between several devices. These shared resources should be programmed so that all the users of them are satisfied. If a user (X) driver gets probed before the LCD controller driver in this case, then it may end up reconfiguring these resources to ranges satisfying the current users (only user X) and that can make the LCD screen unstable. Of course we can have more complex cases where the same resource is getting used by two devices while the kernel boots and the order in which devices get probed wouldn't matter as the other device will surely break then. Proposed solution: This patchset introduces the concept of boot-constraints, which are set by the different parts of the kernel (on behalf of the bootloaders) and the kernel will satisfy them until the time driver for such a device is probed (successfully or unsuccessfully). Once the driver's probe() routine is called, the driver core removes the constraints set for the particular device. Only the power-supply constraint type is supported for now. This can be used across platforms working with DT, ACPI, etc and has no dependency on those. What's left ? There are a couple of problems which aren't solved yet: o EPROBE_DEFER: Deferred probing is a major problem that needs to be solved. Because we want to add the constraint ASAP (i.e. before most of the drivers are registered), we would end up doing that right after the device is created. That is very early in the kernel boot cycle and its very much possible that the resource we need to get (in order to set the constraint) isn't available yet. Like regulator in case of supply constraint. Now how do we control that the constraint is set right after the resource is available, and before any other user of the resource comes up ? One way out is to set "driver_deferred_probe_enable" to 'true' (drivers/base/dd.c), after we got EPROBE_DEFER for any of the constraints. That would make sure that all the deferred drivers get a chance to get probed again, after addition of every new device. Without this change, we probe all the deferred devices only after late_init. But that may not work as it depends on a new workqueue thread for doing this work, and no one is stopping another driver to get registered by that time. I also thought about using the "functional dependency" stuff [1] that Rafael introduced earlier, but that too has its own challenges. Specifically, we may not have the device structures available for all the consumers/suppliers to start with. o DT support will be added at first and I am planning to add the constraints right from drivers/of/platform.c after the AMBA and platform devices are created automatically from DT. Some sort of bindings (per constraint type) are required to be defined for that of course. We can think about other interfaces (like ACPI) as well, if we have any users right now. But yeah, the first thing is to get some sort of feedback for the proposed solution. :) FWIW, I started discussing this with Mark Brown earlier [2] and this series is a follow-up to that discussion. -- viresh [1] commit 9ed9895370ae ("driver core: Functional dependencies tracking support") [2] https://marc.info/?l=linux-kernel&m=149423887617635 Viresh Kumar (5): drivers: Add boot constraints core drivers: boot_constraint: Add support for supply constraints drivers: boot_constraint: Add boot_constraints_disable kernel parameter drivers: boot_constraint: Add debugfs support drivers: Code to test boot constraints Documentation/admin-guide/kernel-parameters.txt | 2 + drivers/base/Kconfig | 11 + drivers/base/Makefile | 1 + drivers/base/boot_constraint.c | 402 ++++++++++++++++++++++++ drivers/base/dd.c | 20 +- drivers/base/test_plat_boot_constraint.c | 51 +++ include/linux/boot_constraint.h | 35 +++ 7 files changed, 515 insertions(+), 7 deletions(-) create mode 100644 drivers/base/boot_constraint.c create mode 100644 drivers/base/test_plat_boot_constraint.c create mode 100644 include/linux/boot_constraint.h -- 2.13.0.71.gd7076ec9c9cb