generic: backport pending gpio-regmap ops patch
Some checks failed
Build Kernel / Build all affected Kernels (push) Waiting to run
Build all core packages / Build all core packages for selected target (push) Has been cancelled

This patch has been accepted for linux v6.14 so we can move it from pending
to backport.

Signed-off-by: Álvaro Fernández Rojas <noltari@gmail.com>
(cherry picked from commit 2f2e21a52b)
This commit is contained in:
Álvaro Fernández Rojas 2025-01-22 20:42:49 +01:00
parent 9d9e06a30a
commit 58d0057481
2 changed files with 30 additions and 131 deletions

View File

@ -0,0 +1,30 @@
From b0fa00fe38f673c986633c11087274deeb7ce7b0 Mon Sep 17 00:00:00 2001
From: Sander Vanheule <sander@svanheule.net>
Date: Tue, 7 Jan 2025 21:16:20 +0100
Subject: [PATCH] gpio: regmap: Use generic request/free ops
Set the gpiochip request and free ops to the generic implementations.
This way a user can provide a gpio-ranges property defined for a pinmux,
easing muxing of gpio functions. Provided that the pin controller
implementents the pinmux op .gpio_request_enable(), pins will
automatically be muxed to their GPIO function when requested.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Acked-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20250107201621.12467-1-sander@svanheule.net
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
drivers/gpio/gpio-regmap.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpio/gpio-regmap.c
+++ b/drivers/gpio/gpio-regmap.c
@@ -262,6 +262,8 @@ struct gpio_regmap *gpio_regmap_register
chip->label = config->label ?: dev_name(config->parent);
chip->can_sleep = regmap_might_sleep(config->regmap);
+ chip->request = gpiochip_generic_request;
+ chip->free = gpiochip_generic_free;
chip->get = gpio_regmap_get;
if (gpio->reg_set_base && gpio->reg_clr_base)
chip->set = gpio_regmap_set_with_clear;

View File

@ -1,131 +0,0 @@
From patchwork Tue Jan 7 20:16:20 2025
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Patchwork-Submitter: Sander Vanheule <sander@svanheule.net>
X-Patchwork-Id: 2031059
Return-Path:
<linux-gpio+bounces-14582-incoming=patchwork.ozlabs.org@vger.kernel.org>
X-Original-To: incoming@patchwork.ozlabs.org
Delivered-To: patchwork-incoming@legolas.ozlabs.org
Authentication-Results: legolas.ozlabs.org;
dkim=pass (2048-bit key;
secure) header.d=svanheule.net header.i=@svanheule.net header.a=rsa-sha256
header.s=mail1707 header.b=YjCvLC2H;
dkim-atps=neutral
Authentication-Results: legolas.ozlabs.org;
spf=pass (sender SPF authorized) smtp.mailfrom=vger.kernel.org
(client-ip=2604:1380:4601:e00::3; helo=am.mirrors.kernel.org;
envelope-from=linux-gpio+bounces-14582-incoming=patchwork.ozlabs.org@vger.kernel.org;
receiver=patchwork.ozlabs.org)
Received: from am.mirrors.kernel.org (am.mirrors.kernel.org
[IPv6:2604:1380:4601:e00::3])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature ECDSA (secp384r1))
(No client certificate requested)
by legolas.ozlabs.org (Postfix) with ESMTPS id 4YSMxB3WwSz1yPG
for <incoming@patchwork.ozlabs.org>; Wed, 8 Jan 2025 07:25:18 +1100 (AEDT)
Received: from smtp.subspace.kernel.org (relay.kernel.org [52.25.139.140])
(using TLSv1.2 with cipher ECDHE-ECDSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by am.mirrors.kernel.org (Postfix) with ESMTPS id A7B811887AD1
for <incoming@patchwork.ozlabs.org>; Tue, 7 Jan 2025 20:25:19 +0000 (UTC)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
by smtp.subspace.kernel.org (Postfix) with ESMTP id C09A21F63FE;
Tue, 7 Jan 2025 20:25:11 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=svanheule.net header.i=@svanheule.net
header.b="YjCvLC2H"
X-Original-To: linux-gpio@vger.kernel.org
Received: from polaris.svanheule.net (polaris.svanheule.net [84.16.241.116])
(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 8DD631DF97A
for <linux-gpio@vger.kernel.org>; Tue, 7 Jan 2025 20:25:07 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
arc=none smtp.client-ip=84.16.241.116
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1736281511; cv=none;
b=Xe/s+ul4S/+nhYxSMqUWJ/GXKP+J7uJo6tFw/w5bTXcmGxkbpCXTLOiTNXAhv8PMhTfsLYSQes6VF8dzDXaJxL4c8SlQsPNfGH/PqecmSvFMbZTz1XbjP9mBUCvX9lxCH8CSRavkuPuYdhss3a56TgaFzi9GifUSHCsHGs7+xk0=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1736281511; c=relaxed/simple;
bh=31kjLyaoVOzIAs1m+zMi59Ia2jUwYW56Jp1YE6hLflg=;
h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type;
b=q7miNkZBtMq3dcxL5HMjUpP3EFdQ7/xU/WnWIFVl6MK4rszqphqvaziMOK6avsn+UA5pAx2JJV8bDY8LfNhiVWwZtPfxbikjjZFm1HYlCDWmGudasM0b//K3/On625L4iqFWmVmLUdEdhvwIkJKSL4wTfN0OMz27EI272o5ygLg=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org;
dmarc=pass (p=none dis=none) header.from=svanheule.net;
spf=pass smtp.mailfrom=svanheule.net;
dkim=pass (2048-bit key) header.d=svanheule.net header.i=@svanheule.net
header.b=YjCvLC2H; arc=none smtp.client-ip=84.16.241.116
Authentication-Results: smtp.subspace.kernel.org;
dmarc=pass (p=none dis=none) header.from=svanheule.net
Authentication-Results: smtp.subspace.kernel.org;
spf=pass smtp.mailfrom=svanheule.net
Received: from terra.vega.svanheule.net (unknown [94.110.49.146])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest
SHA256)
(No client certificate requested)
(Authenticated sender: sander@svanheule.net)
by polaris.svanheule.net (Postfix) with ESMTPSA id 1E18459A0D6;
Tue, 7 Jan 2025 21:17:02 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=svanheule.net;
s=mail1707; t=1736281022;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding;
bh=yNGIiTe7uonx3NZIc6+B7LVjvR8RnIV2zq++EO7NLhg=;
b=YjCvLC2HqArIGWGFkNYmh+oloGi7ZFo7WZGlTbxuHqrQVJ6mLNoLCTCkPkX1EJWEQyNysD
Jj+7tBnAYyCrJ0NuSTD9CPW1+KwKP4wlvWpBUlayCdUJyU4rzjqmlYAI5vJ1UX8FOnvEpn
KeWjgjbeMI6dvIE7ATPFkDvMrDxR9KSEe/1pfzY3E5jh1T8tcnTRMQKTll7hSUBN63dVfJ
U7wnHRLvwx8ESIjrHDKOlsSohmV6lyQTrgEeE2RCM6SpZPNoSpPVjTinF1kPuMHNWHV+Th
6eDOblXxt859JECDowM0NjF87XJqjgph22+A1WUV4iaePO4GIWo9DQ3KhP/Pyg==
From: Sander Vanheule <sander@svanheule.net>
To: Michael Walle <mwalle@kernel.org>,
Linus Walleij <linus.walleij@linaro.org>,
Bartosz Golaszewski <brgl@bgdev.pl>,
linux-gpio@vger.kernel.org,
linux-kernel@vger.kernel.org
Cc: =?utf-8?q?=C3=81lvaro_Fern=C3=A1ndez_Rojas?= <noltari@gmail.com>,
jonas.gorski@gmail.com, kylehendrydev@gmail.com,
florian.fainelli@broadcom.com, Sander Vanheule <sander@svanheule.net>
Subject: [PATCH] gpio: regmap: Use generic request/free ops
Date: Tue, 7 Jan 2025 21:16:20 +0100
Message-ID: <20250107201621.12467-1-sander@svanheule.net>
X-Mailer: git-send-email 2.47.1
Precedence: bulk
X-Mailing-List: linux-gpio@vger.kernel.org
List-Id: <linux-gpio.vger.kernel.org>
List-Subscribe: <mailto:linux-gpio+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-gpio+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Set the gpiochip request and free ops to the generic implementations.
This way a user can provide a gpio-ranges property defined for a pinmux,
easing muxing of gpio functions. Provided that the pin controller
implementents the pinmux op .gpio_request_enable(), pins will
automatically be muxed to their GPIO function when requested.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
Acked-by: Michael Walle <mwalle@kernel.org>
---
Álvaro has submitted a similar patch today. My implementation's impact
is more limited, but I hadn't gotten around to submitting it yet.
For the original (short) discussion, see:
https://lore.kernel.org/linux-gpio/20250107102735.317446-1-noltari@gmail.com/T/#t
drivers/gpio/gpio-regmap.c | 2 ++
1 file changed, 2 insertions(+)
--- a/drivers/gpio/gpio-regmap.c
+++ b/drivers/gpio/gpio-regmap.c
@@ -262,6 +262,8 @@ struct gpio_regmap *gpio_regmap_register
chip->label = config->label ?: dev_name(config->parent);
chip->can_sleep = regmap_might_sleep(config->regmap);
+ chip->request = gpiochip_generic_request;
+ chip->free = gpiochip_generic_free;
chip->get = gpio_regmap_get;
if (gpio->reg_set_base && gpio->reg_clr_base)
chip->set = gpio_regmap_set_with_clear;