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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 7C8F4C43461 for ; Thu, 8 Apr 2021 21:41:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 54FFB610D1 for ; Thu, 8 Apr 2021 21:41:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232470AbhDHVl2 (ORCPT ); Thu, 8 Apr 2021 17:41:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34110 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232628AbhDHVl0 (ORCPT ); Thu, 8 Apr 2021 17:41:26 -0400 Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6966BC061761 for ; Thu, 8 Apr 2021 14:41:10 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id n8so6447193lfh.1 for ; Thu, 08 Apr 2021 14:41:10 -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=lovVRYDMCrmQr35MOmEQNArT8X6dRKP4z/7vuxFftj8=; b=Zl5gQV8vF/H2Up0OGisn1jZyzmSAQmBLAyCjJr58ywKU6drNqMtx+3vFyntbkafr+J sgHHVjhHlavHKCObbH3PxF6AD24N1bfVNLKsHtW2H+ZZL07kKug3XKtLjuUH/eOc+h8U UD/MQe5/uXeasF1f6QPIYPhQ12wdQvvZLK6RZ9Ciwgz9Vs4r4++AU3BjvLBaUyhE0+F9 hNIGevuyRZtuq9H4ei+LL2Fa8zIiT3agwDB5NYVtX8xOg09gPydQH8iexb21QAr/Y6Wv Ty6ueBC3Da/WiHdkvaC6Njdf0Ujbl4LqeBxHaycG/INaUdxKqKr9HXiLt03+JXb51s74 72EQ== 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=lovVRYDMCrmQr35MOmEQNArT8X6dRKP4z/7vuxFftj8=; b=WtWCczxOx9RA6gVSjIvHHjO88kwzyDrRa5sCebNyRdiBRWJcKRckyYjU0zu2tCWQbp 1zsRPfeRvWwIRWp8B65raUiugL5r2PTUlwJHlSqXKItU+z8rNL2L/d/BIfc/qp5MhOl7 Af98JrL5xEeVzFwEMFqGGRNreZ+fRTcViy0a+r7rl4kueLvrzy9hkJ0DNFb7JzgQz8SK CUNdDFTvtaurbPEt1Rt15CzCTKVBq/o81hTLVOtyTQJKyuIOsBVT3FjStnloi9t0eg00 GhlQn4IDvVMu9rB2WYqIcwFACui7P3445yD93Dl6aBEQJIDEiG9Djaow01AdPYFfP+5m AilQ== X-Gm-Message-State: AOAM531235MkuLg9zVrCcU5H5eQWCKFoHXUxo4KGdpvfOUcRfFjdG+o4 KuH1/NibSSakU4GkPRJzDELW2YAAlq7m2/KqhLUIDw== X-Google-Smtp-Source: ABdhPJxcGrzxNuMjWggN3LPX6qCyslPcVVy5TwyjrTf/E9/lbetDAeYjzYqp6RtE5WF3xgPZlLpT9B3d3HVmYJ4HGpk= X-Received: by 2002:a19:ef19:: with SMTP id n25mr792331lfh.157.1617918068947; Thu, 08 Apr 2021 14:41:08 -0700 (PDT) MIME-Version: 1.0 References: <20210405200259.23525-1-petr.vorel@gmail.com> <20210405225222.GD904837@yoga> In-Reply-To: From: Linus Walleij Date: Thu, 8 Apr 2021 23:40:58 +0200 Message-ID: Subject: Re: [PATCH 1/1] arm64: dts: qcom: msm8994: Reserve gpio ranges To: Konrad Dybcio Cc: Petr Vorel , Bjorn Andersson , MSM , Andy Gross , Rob Herring , Ricardo Ribalda , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On Thu, Apr 8, 2021 at 10:05 PM Konrad Dybcio wrote: > On Qualcomm boards GPIOs that are used for "secure" (duh) peripherals, > like a fingerprint scanner, are not allowed to be controlled from Linux (the "non-secure world"). > Trying to do so causes an immediate reboot due to "attempting to violate the security". OK I see. Yeah HW security is pretty neat, making it cause a reboot seems like maybe not the best choice, but hey we know for sure what is wrong when it happens so it gives a good feeling of having everything fully inder control. Which is nice, despite the annoyance. > The GPIOs seem to all be iterated over on boot, except for the ones specified in > "gpio-reserved-ranges". (...) > So, why did it work before!? We do things like read all direction registers to check if GPIO lines are set up as input or output. If that causes reset then, well. > As a result, if such "secure" GPIOs are not declared in the DT, the board essentially dies on TLMM (pinctrl) probe > (which happens veeeery early - so that all other peripherals can set the pins as they see fit) > and that's very unpleasant to debug. Without this patch, Petr's device will simply not boot. In a way specifying it is a very correct thing to do. When they were registered with the GPIO subsystem before they were, well registered with the GPIO subsystem which means they are supposedly available for general-purpose input-output. Which they were not. They seem highly special-purpose to me. So reserving them is the right thing to do. Yours, Linus Walleij