linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Quentin Schulz <foss+kernel@0leil.net>
To: unlisted-recipients:; (no To-header on input)
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 <quentin.schulz@theobroma-systems.com>
Subject: [PATCH v2 0/2] fix gpio-sysfs/libgpiod for rockchip
Date: Fri, 30 Sep 2022 15:20:31 +0200	[thread overview]
Message-ID: <20220930132033.4003377-1-foss+kernel@0leil.net> (raw)

From: Quentin Schulz <quentin.schulz@theobroma-systems.com>

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 <lkp@intel.com>

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


             reply	other threads:[~2022-09-30 13:20 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-30 13:20 Quentin Schulz [this message]
2022-09-30 13:20 ` [PATCH v2 1/2] pinctrl: rockchip: add pinmux_ops.gpio_set_direction callback Quentin Schulz
2022-09-30 13:20 ` [PATCH v2 2/2] gpio: rockchip: request GPIO mux to pinctrl when setting direction Quentin Schulz
2022-10-04  7:21 ` [PATCH v2 0/2] fix gpio-sysfs/libgpiod for rockchip Linus Walleij

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220930132033.4003377-1-foss+kernel@0leil.net \
    --to=foss+kernel@0leil.net \
    --cc=brgl@bgdev.pl \
    --cc=heiko@sntech.de \
    --cc=jay.xu@rock-chips.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=quentin.schulz@theobroma-systems.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).