From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 71CB7429E45; Sat, 28 Feb 2026 17:46:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300793; cv=none; b=beV1+LtMVcBdtIeghj76VFr+5Cx10yz9SQXY4hyA29qywxCLFFWqZG97X/N4CoWuMLzP0yzthqXMkoCS+qdOUF7ZLXL8bWZHXjAoue9tDyVSLSSA1Za11OzPnN8vC0UnOzgQt76p4akPW7NpJrUs3xkf4xnu3J5PDLVjCV1mSRc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772300793; c=relaxed/simple; bh=IymXDE+KqA+YMw3aZHf+yx0denkWGPnhBUAVRO0hsY0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KljGN0OLXqSQ2+9T7dhZk6thyZ2osrLAOdNmsHwzZfxHmecHTGF+mwhjT8HC/KPAE3wEpp05naWxDyoNzSS7zHM0LWu4WF/NxPdqXC8WgIdMuqE5pRQkc7AiGFhTuogOnxmNmGpkvKIYBeX3T4h3Hqh9pledPn28ISiyEgLeVgk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=K9P5eNtJ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="K9P5eNtJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54C70C116D0; Sat, 28 Feb 2026 17:46:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772300793; bh=IymXDE+KqA+YMw3aZHf+yx0denkWGPnhBUAVRO0hsY0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=K9P5eNtJTGqqZ5MYMPD01BX7HBR6xcd7Xk9JZoopcAFiJDwZ52qobc121IGot16qV ck8Bvzg9HNRNgdz5C4wpna4QkmIARMXXxwDpoKORsmu4/6k+TXeMQHhwzTyK0NN048 1YSuYgg7tluEyoUeM9lq5OZWxlMVqTAtmxvL3LfBtlgT4oP5h37nA4RXiUKDP43LPM q1thOm9ti+PRHZVg64DTp2oXOxPDNQM6sKsDpKlEcVeTQG1qIIB1sx8/xNyZ7/HqHc Zts949tAL/lRPyU8m8VCcW0tF8+SBKSl9p6MeJP3xF28gGIqUbpOhsjgISb6wbTrIc VHqxq2hykg3ww== From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Bartosz Golaszewski , Andy Shevchenko , Hans de Goede , Sasha Levin Subject: [PATCH 6.19 825/844] gpio: swnode: restore the swnode-name-against-chip-label matching Date: Sat, 28 Feb 2026 12:32:18 -0500 Message-ID: <20260228173244.1509663-826-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260228173244.1509663-1-sashal@kernel.org> References: <20260228173244.1509663-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit From: Bartosz Golaszewski [ Upstream commit ff91965ad8b214e0771bc5a15253f14f583a7649 ] Using the remote firmware node for software node lookup is the right thing to do. The GPIO controller we want to resolve should have the software node we scooped out of the reference attached to it. However, there are existing users who abuse the software node API by creating dummy swnodes whose name is set to the expected label string of the GPIO controller whose pins they want to control and use them in their local swnode references as GPIO properties. This used to work when we compared the software node's name to the chip's label. When we switched to using a real fwnode lookup, these users broke down because the firmware nodes in question were never attached to the controllers they were looking for. Restore the label matching as a fallback to fix the broken users but add a big FIXME urging for a better solution. Cc: stable@vger.kernel.org # v6.18, v6.19 Fixes: 216c12047571 ("gpio: swnode: allow referencing GPIO chips by firmware nodes") Link: https://lore.kernel.org/all/aYkdKfP5fg6iywgr@jekhomev/ Acked-by: Andy Shevchenko Reviewed-by: Hans de Goede Link: https://patch.msgid.link/20260211085313.16792-1-bartosz.golaszewski@oss.qualcomm.com Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin --- drivers/gpio/gpiolib-swnode.c | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/drivers/gpio/gpiolib-swnode.c b/drivers/gpio/gpiolib-swnode.c index b44f35d684590..f02f5a61ddb83 100644 --- a/drivers/gpio/gpiolib-swnode.c +++ b/drivers/gpio/gpiolib-swnode.c @@ -43,6 +43,25 @@ static struct gpio_device *swnode_get_gpio_device(struct fwnode_handle *fwnode) fwnode_lookup: gdev = gpio_device_find_by_fwnode(fwnode); + if (!gdev && gdev_node && gdev_node->name) + /* + * FIXME: We shouldn't need to compare the GPIO controller's + * label against the software node that is supposedly attached + * to it. However there are currently GPIO users that - knowing + * the expected label of the GPIO chip whose pins they want to + * control - set up dummy software nodes named after those GPIO + * controllers, which aren't actually attached to them. In this + * case gpio_device_find_by_fwnode() will fail as no device on + * the GPIO bus is actually associated with the fwnode we're + * looking for. + * + * As a fallback: continue checking the label if we have no + * match. However, the situation described above is an abuse + * of the software node API and should be phased out and the + * following line - eventually removed. + */ + gdev = gpio_device_find_by_label(gdev_node->name); + return gdev ?: ERR_PTR(-EPROBE_DEFER); } -- 2.51.0