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=-4.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS,T_DKIMWL_WL_HIGH,URIBL_BLOCKED autolearn=unavailable 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 BF1AAC28CC5 for ; Sat, 8 Jun 2019 14:22:23 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 942E2214D8 for ; Sat, 8 Jun 2019 14:22:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="THJI0IrL"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="a8zCjMPg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 942E2214D8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=eqfX+iRrOiPNg40nd7NvHZkVamx75VK02sS/pA6YQ5Y=; b=THJI0IrLlimijg teyjzYh1qWXzSXuMBFmrtfSiJQGbHD2n8aAU/pjWuEO+c3G2ZEymS5f/jLOp1T6v9kltME78awgXB brqEDNUdmw7sxtuMq8WGuORnImN52Gt6t4HWikwlkxjTlIKi5NvCx/GcT19tY+wk/HbYvWxKgtffx Y13eTdht+45zItDK8FXnFODfCMdaMuGNqdxM2OqM4S9aQLACldl1sjZdtQRgWKGTlFlA2gzbPZ2Z/ 4KRtV925TVuO5/RUsTl9hPn1ZucBtXBPU+ilYOhIpPuEThQV/7X9mM/CZYtV1gnPO4xK0aRZ+/Fsx 5e6BdSZBdYGTfIIw2ryw==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hZcEa-0003D1-Uo; Sat, 08 Jun 2019 14:22:16 +0000 Received: from mail-lf1-x142.google.com ([2a00:1450:4864:20::142]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hZcEY-0003Br-E5 for linux-arm-kernel@lists.infradead.org; Sat, 08 Jun 2019 14:22:15 +0000 Received: by mail-lf1-x142.google.com with SMTP id r15so3665246lfm.11 for ; Sat, 08 Jun 2019 07:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aIUAKPG6L/Uk7RNnahoThkSWUC4nrgmZui5o+1IQtNk=; b=a8zCjMPgP8flEe8AX4DYltakrbTeXlf4HJdUBQFer/b0IPJPCfVav33LROaOIvkRBh d/ezKZe+qMrAcg+2zaULmB+dIX8setyM8Dw/amQKtBtuGvpqfUZdtCABo4QaT5ZFUGGd fksqElAG9w2gwbE6Q6S46627rrHHqLiRDCA8eScKkVkurpN9O6Dge+avOCJxW9CwIBjE vWmpOGwdimteMBWpy3R6+1wtE1HyS9jIIsl6y+9pjv6itruHNG55mTSg6Qzlisw2u1sl d/rKG06wFYR5828vG892iuyGTPq8CV75uQK3Cx8ndRZlvQhTZTCv/wvDzZyIGlw+oOwZ bmxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aIUAKPG6L/Uk7RNnahoThkSWUC4nrgmZui5o+1IQtNk=; b=uGoDeM7Uw38bDRuK/Y74zPgE9vK9+Tz5asQ0gD9KRiPwgidkxIjAgD7nYTmyZi2ybT 9DOipXN8B2k6YXa7sFlxCCzFXD9vLkISoxnrgTppCpXSRKnnrrkFhsF70PjNl/7rX41t VBGfdNuUS/3gQp9UTs6KOlHg/FO952oQ9naByUSA9BJqvIDXUmXSob+ic5ZXWtVfiuXK rJiI6DJHfgYZNnJA8n7kNxMA8kXdmI/cWkfcgBbTEI3PP/Lf10O4mD+gHlWmqrF1+kUG ANNecW7UhqxQWnu3m62SoDIL9+Ht4Tmsd50ZtYcCR5yatSBewYSIWXKcB7V39UMED1ns 97Dg== X-Gm-Message-State: APjAAAXPFYfJ/czYFSqWakHxHoyevi8JprDCYNxRySA3YuAYSzLEx6SS MDVGRFHJYZjSJkN+tHOtlUGXv13G69AhynFyNbx0Mg== X-Google-Smtp-Source: APXvYqx2MoGtkoQjUm5Wa5IOCM/k/orM6EKwAwZG7AXIo8rcqREn8WTPkR2Fc2Pbt++tRSEdz7xZS6GOynFOOaZSLRQ= X-Received: by 2002:ac2:598d:: with SMTP id w13mr28511822lfn.165.1560003730786; Sat, 08 Jun 2019 07:22:10 -0700 (PDT) MIME-Version: 1.0 References: <20190607082901.6491-1-lee.jones@linaro.org> <20190607082901.6491-3-lee.jones@linaro.org> In-Reply-To: From: Linus Walleij Date: Sat, 8 Jun 2019 16:22:03 +0200 Message-ID: Subject: Re: [PATCH v2 3/8] pinctrl: msm: Add ability for drivers to supply a reserved GPIO list To: Ard Biesheuvel X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190608_072214_484582_6D037B95 X-CRM114-Status: GOOD ( 19.29 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Felipe Balbi , Wolfram Sang , Greg Kroah-Hartman , "open list:GPIO SUBSYSTEM" , linux-usb , Linux Kernel Mailing List , Bjorn Andersson , David Brown , alokc@codeaurora.org, linux-i2c , linux-arm-msm , Andy Gross , Jeffrey Hugo , Lee Jones , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jun 7, 2019 at 1:10 PM Ard Biesheuvel wrote: > On Fri, 7 Jun 2019 at 10:29, Lee Jones wrote: > > > > When booting MSM based platforms with Device Tree or some ACPI > > implementations, it is possible to provide a list of reserved pins > > via the 'gpio-reserved-ranges' and 'gpios' properties respectively. > > However some ACPI tables are not populated with this information, > > thus it has to come from a knowledgable device driver instead. > > > > Here we provide the MSM common driver with additional support to > > parse this informtion and correctly populate the widely used > > 'valid_mask'. > > > > Signed-off-by: Lee Jones > > I'm not sure if this is the correct approach. Presumably, on ACPI > systems, all the pinctl stuff is already set up by the firmware, and > so we shouldn't touch *any* pins unless they have been requested > explicitly. Is there any way we can support this in the current > framework? I don't suppose anything but the GPIO portions of the pinctrl driver is ever used under ACPI. I guess in an ideal ACPI world noone (like userspace) would ever use a GPIO because ACPI would have all GPIOs assigned a particular purpose, so accessing any of them would lead to a crash. But in practice it seems a lot of GPIOs are available and used for example by userspace hacks, so just blacklisting the ones that cannot be accessed by the GPIO subsystem seems like a viable compromise. Then we have the ACPI paradigm of pin control being controlled by ACPI: this is also great in theory, but it seems like the ACPI firmware has in cases forgot or omitted to implement some of it and people need to access it anyways. The people writing the default firmware cannot think out or test all usecases, so some will be left open-ended to non-firmware authoring users. This is why drivers/pinctrl/intel/* exists despite being for exclusively ACPI platforms. Being able to control pins also from the kernel has become a viable compromise. Yours, Linus Walleij _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel