From patchwork Fri Mar 23 16:34:48 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Stephen Boyd X-Patchwork-Id: 890056 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="gJBs9K89"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 4078Ln1THCz9s0y for ; Sat, 24 Mar 2018 03:36:33 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752218AbeCWQe5 (ORCPT ); Fri, 23 Mar 2018 12:34:57 -0400 Received: from mail-pl0-f65.google.com ([209.85.160.65]:40672 "EHLO mail-pl0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751884AbeCWQe4 (ORCPT ); Fri, 23 Mar 2018 12:34:56 -0400 Received: by mail-pl0-f65.google.com with SMTP id x4-v6so7741800pln.7 for ; Fri, 23 Mar 2018 09:34:56 -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=pjnmXk7Rw64gc3wugaobGWI/OMzedc9vUbsUlKuTG0M=; b=gJBs9K89P+DYOLgRSpz6scjmJgu+vogJMjW8Q47HOQZFkGaCVYVg+65hGzNYXfTjGT CrCLwacC5pqAA3zeSzsFt8q5D1nJuz7+1DB/enOfFWfDNtP8NxZSXdFbS3SyEKt+tTxf xYRp+QTGUKN3FX2M55rkNnPomgIPiSpTqisVo= 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=pjnmXk7Rw64gc3wugaobGWI/OMzedc9vUbsUlKuTG0M=; b=FS/aR6q6GJHhSpYiZ6N7H5Pj+1MWhgfTvpO22NVNAgq6gbRpVpZH532OFagSBkb2lE /lNs7zaNmFA//aZmSqrMdlaqzYX1G/adovYs0VOawYgD33Qo+AfSIay4VyggsdfjjicB 7qNMxSmU67Fn0XAP2sqq6C6VLyFBlzQhG6UKiPr+TotYSvDd0s4bVHKWnfgKGje6FsCH lTCsAM90BBFr7prtsMhGXDAbG41l2o9/TJN+8fypcEQIll2ho4uTOwud/qAnlCODaF2O Huu6XiOqOg8fJ54HqsZHg13KM8qOwbkaQOTYHnLS4IKTXz6OdJGRVn/sHAsGD/d5NDD7 +OdA== X-Gm-Message-State: AElRT7Eq2eMGhLBafLvLVJ2oS2ZvUCN5laSdc3+BuaUixt/m2ugXsfdX +Jcy3JXVYPdjqdOLbe9zXwC+Uw== X-Google-Smtp-Source: AG47ELvf/v6ufxEjXLuYe1hl2F5a1xlmwS2uwmnRgCLu9KCr0V+4jI7LSKCypuM0frcJ15tHKXwkzA== X-Received: by 2002:a17:902:a981:: with SMTP id bh1-v6mr30795707plb.255.1521822895777; Fri, 23 Mar 2018 09:34:55 -0700 (PDT) Received: from swboyd.mtv.corp.google.com ([2620:0:1000:1511:d30e:62c6:f82c:ff40]) by smtp.gmail.com with ESMTPSA id s78sm19131294pfa.161.2018.03.23.09.34.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Mar 2018 09:34:55 -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 v4 0/5] Support qcom pinctrl protected pins Date: Fri, 23 Mar 2018 09:34:48 -0700 Message-Id: <20180323163453.96495-1-swboyd@chromium.org> X-Mailer: git-send-email 2.17.0.rc0.231.g781580f067-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 v3: * Split out allocation of mask into subroutine * Moved that allocation to kmalloc_array() * Updated qcom driver to simplifiy ACPI logic and fix mem leak 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 (5): dt-bindings: gpio: Add a gpio-reserved-ranges property gpiolib: Extract mask allocation into subroutine gpiolib: Change bitmap allocation to kmalloc_array 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 | 66 +++++++++++++++++-- drivers/pinctrl/qcom/pinctrl-msm.c | 65 +++++++++++++++++- include/linux/gpio/driver.h | 16 +++++ 5 files changed, 167 insertions(+), 11 deletions(-) Tested-by: Timur Tabi Reviewed-by: Andy Shevchenko