Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Heiko Stuebner <heiko@sntech.de>
To:     Quentin Schulz <foss+kernel@0leil.net>
Cc:     linus.walleij@linaro.org, brgl@bgdev.pl, jay.xu@rock-chips.com,
        linux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
        foss+kernel@0leil.net,
        Quentin Schulz <quentin.schulz@theobroma-systems.com>,
        stable@vger.kernel.org
Subject: Re: [PATCH 2/2] gpio: rockchip: request GPIO mux to pinctrl when setting direction
Date:   Fri, 23 Sep 2022 20:41:15 +0200
Message-ID: <3292995.CbtlEUcBR6@phil>
In-Reply-To: <20220923145141.3463754-3-foss+kernel@0leil.net>
References: <20220923145141.3463754-1-foss+kernel@0leil.net> <20220923145141.3463754-3-foss+kernel@0leil.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

Am Freitag, 23. September 2022, 16:51:41 CEST schrieb Quentin Schulz:
> From: Quentin Schulz <quentin.schulz@theobroma-systems.com>
> 
> Before the split of gpio and pinctrl sections in their own driver,
> rockchip_set_mux was called in pinmux_ops.gpio_set_direction for
> configuring a pin in its GPIO function.
> 
> This is essential for cases where pinctrl is "bypassed" by gpio
> consumers otherwise the GPIO function is not configured for the pin and
> it does not work. Such was the case for the sysfs/libgpiod userspace
> GPIO handling.
> 
> Let's call pinctrl_gpio_direction_input/output when setting the
> direction of a GPIO so that the pinctrl core requests from the rockchip
> pinctrl driver to put the pin in its GPIO function.
> 
> Fixes: 9ce9a02039de ("pinctrl/rockchip: drop the gpio related codes")
> Fixes: 936ee2675eee ("gpio/rockchip: add driver for rockchip gpio")
> Cc: stable@vger.kernel.org
> Signed-off-by: Quentin Schulz <quentin.schulz@theobroma-systems.com>

cool, thanks a lot for reimplementing this

Reviewed-by: Heiko Stuebner <heiko@sntech.de>