From patchwork Wed Mar 21 16:58:45 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Boyd X-Patchwork-Id: 888946 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=linux-gpio-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=chromium.org Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=chromium.org header.i=@chromium.org header.b="QD9CPgO4"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 405wyW5rSzz9s0y for ; Thu, 22 Mar 2018 03:59:47 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752006AbeCUQ6x (ORCPT ); Wed, 21 Mar 2018 12:58:53 -0400 Received: from mail-pg0-f67.google.com ([74.125.83.67]:37587 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751883AbeCUQ6v (ORCPT ); Wed, 21 Mar 2018 12:58:51 -0400 Received: by mail-pg0-f67.google.com with SMTP id n11so2160714pgp.4 for ; Wed, 21 Mar 2018 09:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id; bh=S9WbFNTDRHS0WOJz2d86Nb6fKzIlnt1KD4/kO6wn9A4=; b=QD9CPgO4QlayCstbPgXei/F4ASLgxXwoUZRzp53QygbkCyd9zSVo4XGlRCZbpNIBTK C+DjuV92DYcfeOSEUT3W/mNxtyz3uF/fZB1TPpeKjwffVOlu1/VUNkNjqFRyXMBWfnU6 FrWm6fFuKF0tQ2nV4MKwnc7dMJgLmlMWysmao= 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=S9WbFNTDRHS0WOJz2d86Nb6fKzIlnt1KD4/kO6wn9A4=; b=IqdQEvkBqO/JIlcv0z3YcwUPJRQ5yncHYFyuPSUMfYQuILAYx0yvX0ULnZMIc8f8p8 5CXkONYnAS0d+eUu83Iew4i2bjMTaAnqs2lp6J8LwzlBrDUprbNKnyC27p1QyfLczrWG vUYdAiK7wXn29qwwi/zSK4czihJ1fGY9+6wyYd+wOzTXKbv38JwDZ9kJ7bGj8LIsf31+ uHtvLmce2Zz4pc1KrBgGKVwcNQmOCTAREYXrFPMlJMWC+g01DMLiTptdUbviNh52T8qP SwpgYl5oT286AEQXIty/lAAGHMjb28nvOftcH1HJ1Bf8wqNGus287NqqJq0Q5ht8NOcx XCsw== X-Gm-Message-State: AElRT7GAa/e8UH9qnMoqEC/LaLy3CWbBg7XsVQYVzrH5qEfqLF+4oCM4 E5LpoHDnCi+hjJJCd40rcyCgOw== X-Google-Smtp-Source: AG47ELta5lD/EAS81eugTW745KVJ7fxjH7FC2bl7+unlmGL8DG56YaGNfepC1j+o6xX4kiwCRxDi9g== X-Received: by 10.98.20.143 with SMTP id 137mr5955043pfu.78.1521651531237; Wed, 21 Mar 2018 09:58:51 -0700 (PDT) Received: from swboyd.mtv.corp.google.com ([2620:0:1000:1511:d30e:62c6:f82c:ff40]) by smtp.gmail.com with ESMTPSA id u28sm10121806pfl.19.2018.03.21.09.58.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Mar 2018 09:58:50 -0700 (PDT) From: Stephen Boyd To: Linus Walleij Cc: linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, linux-arm-msm@vger.kernel.org, Timur Tabi , Bjorn Andersson , Grant Likely , linux-gpio@vger.kernel.org, Andy Shevchenko Subject: [PATCH v3 0/3] Support qcom pinctrl protected pins Date: Wed, 21 Mar 2018 09:58:45 -0700 Message-Id: <20180321165848.89751-1-swboyd@chromium.org> X-Mailer: git-send-email 2.16.2.804.g6dcf76e118-goog Sender: linux-gpio-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org This patchset proposes a solution to describing the valid pins for a pin controller in a generic way so that qcom platforms can expose the pins that are really available. Typically, this has been done by having drivers and firmware descriptions only use pins they know they have access to, and that still works now because we no longer read the pin direction at boot. But there are still some userspace drivers and debugfs facilities that don't know what pins are available and attempt to read everything they can. On qcom platforms, this may lead to a system hang, which isn't very nice behavior, even if root is the only user that can trigger it. The proposal is to describe the valid pins and then not allow things to cause problems by using the invalid pins. Obviously, the firmware may mess this up, so this is mostly a nice to have feature or a safety net so that things don't blow up easily. Changes from v2: * Renamed binding to 'gpio-reserved-ranges' * Reworked gpiolib patch to not use irqdomains * Update qcom driver patch to use new valid_mask field Changes from v1: * Pushed into gpiolib-of core under irq valid line logic * Fixed up qcom driver patch to free stuff properly and remove custom code * Dropped export patch as it got picked up * Renamed binding to 'reserved-gpio-ranges' Stephen Boyd (3): dt-bindings: gpio: Add a gpio-reserved-ranges property gpiolib: Support 'gpio-reserved-ranges' property pinctrl: qcom: Don't allow protected pins to be requested .../devicetree/bindings/gpio/gpio.txt | 7 +- drivers/gpio/gpiolib-of.c | 24 +++++++ drivers/gpio/gpiolib.c | 50 ++++++++++++++ drivers/pinctrl/qcom/pinctrl-msm.c | 69 +++++++++++++++++-- include/linux/gpio/driver.h | 16 +++++ 5 files changed, 159 insertions(+), 7 deletions(-)