Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp3659226rwb; Fri, 30 Sep 2022 06:43:46 -0700 (PDT) X-Google-Smtp-Source: AMsMyM6gJA6+70NTehhi1vOqNPeb5rUbr2pahuKgYeHg4QrHNsvFJeTQ78RaVAbJGJ4mQIJ05HiW X-Received: by 2002:a17:906:794b:b0:783:8db0:95a5 with SMTP id l11-20020a170906794b00b007838db095a5mr6646912ejo.728.1664545426416; Fri, 30 Sep 2022 06:43:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664545426; cv=none; d=google.com; s=arc-20160816; b=U0qF6jc7+zwEK9pRYh+XAoiBm38wqrgTIQHC+c9RuViUoTesfSKFXb2ajZApPe3gPB rT8EtRu9QZVJ0ZP4ryunuFkLrHUC0MvAxP68sPJBD0WXv77RO4YLlR9FdNrYgo82i+DS jh7xRWc2fQx5J/JmGJv9k0IMH7KngJL8QEPuyyhwpoUcs8vlnXy2wc3Jo9gZP+7EbDf/ +dQAGEsvqsddpE49VnDVtsitpxriP4h0+zAwEs/s+UnCdW7Bl0X9TTtRnVZqHvWn8vMd iTG1J4ePdm2wMTksAV9Jpi6zfn3A4rbY4X7ntp39sQSVVHFisJiFk3UbrFp1lUMN5U9b T2OQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:content-transfer-encoding:mime-version :message-id:date:subject:cc:from; bh=Wi0Pf30zBE7KeOZSUTEUsvHQbms+IAJlnBzMuivgZF4=; b=QfBZjx8tdls42MN3sTwzmJVX54MGSJG1Dlg3iqzZt9D8q/2pcWsjYZp5jgtToTZEUD 4OnekewpASxaHddOwhQr4ql52Ibfa/DfUp3RTfu86qqf2Z3IrevpGNEP9rrcWEB0F5vW t9hCkmf3aW1A+Vhg3Vl+nZQSVrptQD71nMfpTUmL4Z+FVfn5FGD/IPJkek4asf59B9J2 93bT9psx1yvgO89Dp7BierEEVe35CUR0UJSvy2xbP/zUtVpF1Aji1+WZjONeayZ706MR wjXoRs8P/NrQ/wb2CboLgJrcBHbn/+ljnlpp2+VJ5pMPBp9vhhU4zoarUfOHl8Lbzw+1 Yofw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id cr10-20020a056402222a00b00457f784f648si1911661edb.480.2022.09.30.06.43.20; Fri, 30 Sep 2022 06:43:46 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231237AbiI3NU4 (ORCPT + 99 others); Fri, 30 Sep 2022 09:20:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57538 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230131AbiI3NUy (ORCPT ); Fri, 30 Sep 2022 09:20:54 -0400 Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::227]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BE71CC997E; Fri, 30 Sep 2022 06:20:52 -0700 (PDT) Received: (Authenticated sender: foss@0leil.net) by mail.gandi.net (Postfix) with ESMTPSA id F29AB20007; Fri, 30 Sep 2022 13:20:45 +0000 (UTC) From: Quentin Schulz Cc: linus.walleij@linaro.org, brgl@bgdev.pl, heiko@sntech.de, 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 Subject: [PATCH v2 0/2] fix gpio-sysfs/libgpiod for rockchip Date: Fri, 30 Sep 2022 15:20:31 +0200 Message-Id: <20220930132033.4003377-1-foss+kernel@0leil.net> X-Mailer: git-send-email 2.37.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net To: unlisted-recipients:; (no To-header on input) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Quentin Schulz Since the split of gpio and pinctrl in their own driver, gpio-sysfs and libgpiod userspace GPIO handling has been broken because the pins aren't put into their GPIO function anymore since pinctrl subsystem is "bypassed" when requesting GPIOs from userspace. This fixes it by making the gpio driver actually request from the pinctrl subsystem to put the pin in its GPIO function when the GPIO direction is set in userspace. I discovered the issue because we have a GPIO the user needs to control from userspace to flash FW on an on-board STM32 that is actually on the same pin as one used by the flash controller. Considering the storage medium tried by the BOOTROM is emmc->nor->nand->sdmmc, booting from emmc didn't show the issue because the default function for pins is GPIO and the flash controller pins didn't need to be muxed by the BOOTROM. However, if there's nothing on emmc, the BOOTROM does the pinmux for SPI controller and puts the pins in their flash mode and therefore the handling of that pin as a GPIO from userspace was not possible, but only when booting on something else than eMMC. This restores the behavior as seen in v5.14 and earlier. v2: - fix missing header; reported by kernel test robot Cheers, Quentin Quentin Schulz (2): pinctrl: rockchip: add pinmux_ops.gpio_set_direction callback gpio: rockchip: request GPIO mux to pinctrl when setting direction drivers/gpio/gpio-rockchip.c | 7 +++++++ drivers/pinctrl/pinctrl-rockchip.c | 13 +++++++++++++ 2 files changed, 20 insertions(+) -- 2.37.3