Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp332709imm; Wed, 17 Oct 2018 00:29:05 -0700 (PDT) X-Google-Smtp-Source: ACcGV62+nd1Rl0zA5G3eoFdFmT5pqy74ZIWGONaoexS7vfVhAb7ef/bzKHM9G9hXmSYLbcAi1YoC X-Received: by 2002:a63:3f07:: with SMTP id m7-v6mr23944860pga.115.1539761345276; Wed, 17 Oct 2018 00:29:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539761345; cv=none; d=google.com; s=arc-20160816; b=uzOEMikEXA7qJ/gGWH6mStXT3bD1hEUZktA9MtEwCTtnlHvakPatdMXqQxeQXg37fL IW6ODccJl43n/UBb1aYLSwfNsDe0xJhplbEf1/5CwvN6E58hgvMUXHryF6martD9I9re 7YtGRGvf00a2GZLu4pSJxbLusEh9gcd/xadoMnb1QB8NhMmoMTA7q7graAYz9osRNvjS FQSFBWnyJN3mtSCN2/QjbMZuwedyVNE02CXHqO0qVVuMMjkX2pmoTqv6vmRoD1MeDuy/ +WLfigbHuBeqQ3Qi5jK3o+u10N+i3tVb9NNRd9rAfqYmwx251PVu01A8phFLMQaGumPD uljw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:subject:user-agent:message-id :references:cc:in-reply-to:from:to:content-transfer-encoding :mime-version:dkim-signature; bh=RmIt7YtbYhBGPm0jiqFZbiShqHgvye+kA/LXBmFXz6k=; b=jSU4vUQOfzjRCmosLSLqaIX3ZEMyeTF+oaVahiHMGYTLt6Ep1cSsZJ7kgfZKj5jAGI QXRlaDP0KQ8hYVfQSXToXewxPacOA7z0uu0fkhiK7F9UVfUIF+kslhKUDxWnm95S0SX+ cCrEa3R+HRPy7P2GKtlSnPtWECAbn/mdpLnTMw1ldF6IzRvvtGGSSvRBjft/4u+Hezru Knu9AXkNuZKcnyv7boiFRy8qGXoaI97ao10BAQTzDnNnsdxwyW3Bfme5S8/nFIxAZYqh h0ABRvsT7DoSrXLzlE55XnEtIGmPLdGBwfdnyIVILBgKJP3Px6F3uA9Z57PfeVoRAnlW z08w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=0rzE2JKA; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l192-v6si16912605pfc.6.2018.10.17.00.28.48; Wed, 17 Oct 2018 00:29:05 -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=@kernel.org header.s=default header.b=0rzE2JKA; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727023AbeJQPWj (ORCPT + 99 others); Wed, 17 Oct 2018 11:22:39 -0400 Received: from mail.kernel.org ([198.145.29.99]:49430 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726622AbeJQPWj (ORCPT ); Wed, 17 Oct 2018 11:22:39 -0400 Received: from localhost (unknown [104.132.0.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E359D2151D; Wed, 17 Oct 2018 07:28:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1539761299; bh=W6x5JRvHd9CwWDYeQh25O+q4n4MqnjaAVACdOieQUBA=; h=To:From:In-Reply-To:Cc:References:Subject:Date:From; b=0rzE2JKA89GyY3DY7lUckCBp0ZgB7vYIez/XDEMP0LV3RD2D+lLS9NSe0IlJhE8Ud 0mBYHRP4p35W/9P1kHfnb+YUNOqW7x4CpcQDqrjHmtu3kbz8r/JKMu4Jb6KAuxqnhN ZCxYkO3UiTfAa9lUiSb8oUJ4UtiN68uoyfrhE8ro= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable To: Sodagudi Prasad From: Stephen Boyd In-Reply-To: <91594b8e6578d542dc7cbebf34458b0c@codeaurora.org> Cc: bjorn.andersson@linaro.org, linus.walleij@linaro.org, linux-gpio@vger.kernel.org, sboyd@codeaurora.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org References: <9aec322678417753fe4022691f4bfdbe@codeaurora.org> <153897864285.119890.13024399324598460044@swboyd.mtv.corp.google.com> <5848ff92c1388b7d6904e88b57bbfec8@codeaurora.org> <91594b8e6578d542dc7cbebf34458b0c@codeaurora.org> Message-ID: <153976129822.5275.14566790707614483813@swboyd.mtv.corp.google.com> User-Agent: alot/0.7 Subject: Re: protected pins and debugfs Date: Wed, 17 Oct 2018 00:28:18 -0700 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Sodagudi Prasad (2018-10-16 19:00:45) > On 2018-10-10 12:40, Sodagudi Prasad wrote: > > On 2018-10-07 23:04, Stephen Boyd wrote: > >> Quoting Sodagudi Prasad (2018-10-03 05:38:24) > >>> = > >>> for (i =3D 0; i < chip->ngpio; i++, gpio++) { > >>> + label =3D gpiochip_is_requested(chip, i); > >>> + if (!label) > >>> + continue; > >>> msm_gpio_dbg_show_one(s, NULL, chip, i, gpio); > >>> - seq_puts(s, "\n"); > >>> } > >>> } > >>> = > >> = > >> Does something not work with the following code in > >> msm_gpio_dbg_show_one()? > >> = > >> = > >> if (!gpiochip_line_is_valid(chip, offset)) > >> return; > > = > > Hi Stephen, > > I didnt realize that these changes are merged on tip. I was testing on > > 4.14 kernel. > > = > > https://lore.kernel.org/patchwork/patch/878107/ > > https://lore.kernel.org/patchwork/patch/878106/ > > https://lore.kernel.org/patchwork/patch/878109/ > = > = > Hi Stephen, > = > After checking this further, adding "gpio-reserved-ranges" in not good = > option. Because of the following reasons. > 1) These gpio information changes from platform to platform. So need to = > maintain reserved-range properly for each platform. This was known. The best approach was to populate this based on what the firmware chooses to lock down, which didn't seem to change very often from what I recall being told. > 2) Also some of the gpio can be changed to secure/protected gpio = > dynamically based on the use case. This is new information. How exactly do these pins change dynamically? Perhaps gpiolib needs to gain more support for the mask to change at runtime instead of being populated once at boot time from DT. Seems like a patch could be written for gpiolib to handle that if it really is something that needs to be done. > = > It looks adding the "gpio-reserved-ranges" ranges is not good option for = > most of the platforms. > = > Can you please check the initial patch suggested in this thread? Please = > let me know if you have any other options for the above points. > = The initial patch in this thread takes a Qualcomm centric approach to the problem, which probably works just fine, but we would like to push the solution to problem into the core framework so that other SoCs can benefit from common code. Please look into handling the runtime swapping in the gpiolib core so that we don't have a one-off solution for Qualcomm here.