Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp1114031rwb; Fri, 23 Sep 2022 08:21:04 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4IbPU686bKqToLe8n6cFK0o4+WnHV1+UhT7zB2v2QoD6CFqMCaheMVuUv6e5XfvwpNzW3e X-Received: by 2002:a17:907:d14:b0:781:d294:4bea with SMTP id gn20-20020a1709070d1400b00781d2944beamr7385727ejc.418.1663946464393; Fri, 23 Sep 2022 08:21:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663946464; cv=none; d=google.com; s=arc-20160816; b=04lpaO42gxtOaq4wIe8HkDTXrNBT7+R+Cf5/0Eu+mhE8ck4BPL0/MCojGPRnkC0Jlv Z9otQTx4avtxxmCcLmtYTss1PlFp9F7OAdoyji9naBmA4R7j0YJ1M+rGXXqxEeOS6CXB LO6QRwcE21+oKyjl7Cpq5Rl6EM5I28DOmtJ7EN5cbDN0YC4vOnDivV0UlngJ0THPb/bG juhEgVK6wcrLLDpOkNBW5quZdiiEPfDO4g1pRnujziRIkaEv0hmecHZUF42cXaXP2nrU UnGebXUdQXCwArKgbA9zlLbRGXxSN4X1VeXrWp0pFmAkTofRreGiIT5JNDT8V+4RtNL9 BXLQ== 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=dFFOdvRMZlVcU1lbMG1zu9cwscs2uArg/uviS5oc+sM=; b=Di16+kdGPjKGBrkbIXg2ujfk0CChm1UDEPXUTPgay7Dw4kQy+iYSOBcV67hj26OQKH LFud8dhBr5zkiqLN5cHQyvnL54ewU+SckRN6TWuEecpQSrR8dfoESoPKm1lnW8RrsSsr 7EpS2RuPrDm28q6/mU9rvx+f9nNhSbHNfXPoamNRmWYOgs3vVXjsrkJQ9eN07cpdtJql K+/5nhgEPPVf3bzXOQoV5lL8mKWAiUMY3rYdYY2TT2WWEPt2aX8le+ZWvH0LDHJdh30N cBV25nArO+wdZjNnig1+v156SiSyXP2hZXwTMpfeQHhO/ZpNkdzHHVqpFmz4ObCQoECV gVSg== 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 v5-20020a50d585000000b00445eb9dfb3dsi6970714edi.353.2022.09.23.08.20.38; Fri, 23 Sep 2022 08:21:04 -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 S230018AbiIWOwM (ORCPT + 99 others); Fri, 23 Sep 2022 10:52:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48352 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229577AbiIWOwL (ORCPT ); Fri, 23 Sep 2022 10:52:11 -0400 Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::223]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AF3FB12B4BF; Fri, 23 Sep 2022 07:52:09 -0700 (PDT) Received: (Authenticated sender: foss@0leil.net) by mail.gandi.net (Postfix) with ESMTPSA id 2271C60003; Fri, 23 Sep 2022 14:52:02 +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 0/2] fix gpio-sysfs/libgpiod for rockchip Date: Fri, 23 Sep 2022 16:51:39 +0200 Message-Id: <20220923145141.3463754-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. 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 | 6 ++++++ drivers/pinctrl/pinctrl-rockchip.c | 13 +++++++++++++ 2 files changed, 19 insertions(+) -- 2.37.3