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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id B24F5CCD1AB for ; Fri, 24 Oct 2025 07:32:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: Content-Type:In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date: Message-ID:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=38gY834GUHR+j6861lRqgRvynKkRDCinlWSi9NmcSr0=; b=id7tAcNahpbPYk6VG9Ks9uXgQZ NnJIs03c8hXWoLtx7KcB9CTRC1DRVkRfYMMZqJhXg9ourfx9AyU/6sZ+8tZXPWQ+j5SM64W9/dY9H WnAKwEhuwuVnm4VdYbMelUj8rwfWAdhWT8yyYCRO1F/OvsIdQnfQfzNrLbFA/LQgPZwRYsjhACUA3 o8rrhXi4TnsdoL9l5KTuAKPBWOSPkD169xrgLLU9ks0q8t5AbWScO2uWJu3rHS/B04fwI+KxYV/iE bKqtzjePfo+eGnqbra0LPkWtmUrYGtHJQD3WFfTk6ht4bXYgsHmcwXjdLhLH8xPXw0CL+43RnEot0 Vbzh145g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vCCHn-00000008VNE-0RYV; Fri, 24 Oct 2025 07:32:31 +0000 Received: from mgamail.intel.com ([198.175.65.9]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vCCHi-00000008VKR-0pzZ for linux-arm-kernel@lists.infradead.org; Fri, 24 Oct 2025 07:32:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1761291147; x=1792827147; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=eaxooXoJIwmcd0CEY30Yd6if/sFPAp16VRbJcMq8Keg=; b=jfbkYdpNd3xf8j11mHQRKOv5I+dQnYgbzExkug2J8oTMwB61Z6JOS3ke QKVSR30FNA9Tdb9ZAGBT73zLaEQou8MF/hUPkMT9osyhnG5oAPaa2XKF9 F5MJ+FKSGporT+VbQBDfULYt3tGV34Cuncv5NAiaTE5lORDwfB2e2/g0N JA1Ucj+JsBbiuzXGwvS8RO9gJhW4Ge2gKWR8MdXNBCSrZdZjX8ZiDN5al Wnb+YlC2c1bKPkr2lc9adbxKbcJ1oKq3FCV3ylR/rFdQ/w/Q3sulHbqfB bUafiRCESna4FKh96kg0lvyzlh1K+MwAm6cp2p+EZk/Davo1hmBkfGXQu w==; X-CSE-ConnectionGUID: g0nga0m7Q0CBvvXocfVGUA== X-CSE-MsgGUID: DgRiJp7zTjiGzCL+EHbx8A== X-IronPort-AV: E=McAfee;i="6800,10657,11586"; a="86100610" X-IronPort-AV: E=Sophos;i="6.19,251,1754982000"; d="scan'208";a="86100610" Received: from orviesa005.jf.intel.com ([10.64.159.145]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2025 00:32:26 -0700 X-CSE-ConnectionGUID: yNWj9OsXSROF0TUUq8ct3g== X-CSE-MsgGUID: zkApki+9SzmjUPgtZniraQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.19,251,1754982000"; d="scan'208";a="189491561" Received: from carterle-desk.ger.corp.intel.com (HELO [10.245.246.211]) ([10.245.246.211]) by orviesa005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2025 00:32:18 -0700 Message-ID: <3907f4ea-31c2-42fb-b4ff-a6952874a9bb@linux.intel.com> Date: Fri, 24 Oct 2025 10:32:25 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 00/10] gpio: improve support for shared GPIOs To: Bartosz Golaszewski Cc: Kees Cook , Mika Westerberg , Dmitry Torokhov , Andrew Morton , Linus Walleij , Manivannan Sadhasivam , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Saravana Kannan , Greg Kroah-Hartman , Andy Shevchenko , Catalin Marinas , Will Deacon , Srinivas Kandagatla , Liam Girdwood , Mark Brown , Jaroslav Kysela , Takashi Iwai , linux-hardening@vger.kernel.org, linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sound@vger.kernel.org, linux-arm-msm@vger.kernel.org, Bartosz Golaszewski References: <20251022-gpio-shared-v2-0-d34aa1fbdf06@linaro.org> From: =?UTF-8?Q?P=C3=A9ter_Ujfalusi?= Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20251024_003226_294271_0075CDD8 X-CRM114-Status: GOOD ( 20.79 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 24/10/2025 10:20, Bartosz Golaszewski wrote: > On Fri, Oct 24, 2025 at 9:17 AM Péter Ujfalusi > wrote: >> >> >> >> On 22/10/2025 16:10, Bartosz Golaszewski wrote: >>> Problem statement: GPIOs are implemented as a strictly exclusive >>> resource in the kernel but there are lots of platforms on which single >>> pin is shared by multiple devices which don't communicate so need some >>> way of properly sharing access to a GPIO. What we have now is the >>> GPIOD_FLAGS_BIT_NONEXCLUSIVE flag which was introduced as a hack and >>> doesn't do any locking or arbitration of access - it literally just hand >>> the same GPIO descriptor to all interested users. >> >> I had few stabs on this in the past, all got somehow derailed, one >> example was: >> https://lkml.org/lkml/2019/10/30/311 >> > > The main issue I see with this approach is adding an actual device > node for the shared GPIO which is now not accepted in DT bindings. We > only create nodes for actual HW components. Right, that policy came later, true. All the information is > already in the device-tree, we just need to scan it which is what I'm > trying to do here. I had a prototype later without the sofware-node which worked for the use case I had, but over the years I dropped it, it was a bit of hassle to roll it for nothing. One can argue that the shared-gpio node is describing the solder blob where the GPIO line is split and routed to two different component. With the approach one can handle cases where the level is inverted by a passive component for one of the device for example - unfortunately I have seen such a board marvel as well. The device's binding will tell _how_ it expects the GPIO's active level, which might or might not match with the real level of the GPIO line and if one of the device's branch have an inverter, that is going to be interesting to work out in conjunction with the other devices non inverted 'direct' line to the same GPIO. Never the less, it is great that someone is trying to get this supported! > > Bartosz -- Péter