The ROHM BD72720 has 6 pins which may be configured as GPIOs. The
GPIO1 ... GPIO5 and EPDEN pins. The configuration is done to OTP at the
manufacturing, and it can't be read at runtime. The device-tree is
required to tell the software which of the pins are used as GPIOs.
Keep the pin mapping static regardless the OTP. This way the user-space
can always access the BASE+N for GPIO(N+1) (N = 0 to 4), and BASE + 5
for the EPDEN pin. Do this by setting always the number of GPIOs to 6,
and by using the valid-mask to invalidate the pins which aren't configured
as GPIOs.
First two pins can be set to be either input or output by OTP. Direction
can't be changed by software. Rest of the pins can be set as outputs
only. All of the pins support generating interrupts.
Support the Input/Output state getting/setting and the output mode
configuration (open-drain/push-pull).
Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://patch.msgid.link/22e095ca92f0677ca3d3a768ad749629fc3c2006.1765804226.git.mazziesaccount@gmail.com
Signed-off-by: Lee Jones <lee@kernel.org>
Add a new driver which provides a 1-to-many mapping for a single real
GPIO using a multiplexer. Each virtual GPIO corresponds to a multiplexer
state which, if set for the multiplexer, connects the real GPIO to the
corresponding virtual GPIO.
This can help in various usecases. One practical case is the special
hardware design of the Realtek-based XS1930-10 switch from Zyxel. It
features two SFP+ ports/cages whose signals are wired directly to the
switch SoC. Although Realtek SoCs are short on GPIOs, there are usually
enough the fit the SFP signals without any hacks.
However, Zyxel did some weird design and connected RX_LOS, MOD_ABS and
TX_FAULT of one SFP cage onto a single GPIO line controlled by a
multiplexer (the same for the other SFP cage). The single multiplexer
controls the lines for both SFP and depending on the state, the
designated 'signal GPIO lines' are connected to one of the three SFP
signals.
Because the SFP core/driver doesn't support multiplexer but needs single
GPIOs for each of the signals, this driver fills the gap between both.
It registers a gpio_chip, provides multiple virtual GPIOs and sets the
backing multiplexer accordingly.
Due to several practical issues, this is input-only and doesn't support
IRQs.
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
Reviewed-by: Thomas Richard <thomas.richard@bootlin.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20251227180134.1262138-3-jelonek.jonas@gmail.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Add a virtual GPIO proxy driver which arbitrates access to a single
shared GPIO by multiple users. It works together with the core shared
GPIO support from GPIOLIB and functions by acquiring a reference to a
shared GPIO descriptor exposed by gpiolib-shared and making sure that
the state of the GPIO stays consistent.
In general: if there's only one user at the moment: allow it to do
anything as if this was a normal GPIO (in essence: just propagate calls
to the underlying real hardware driver). If there are more users: don't
allow to change the direction set by the initial user, allow to change
configuration options but warn about possible conflicts and finally:
treat the output-high value as a reference counted, logical "GPIO
enabled" setting, meaning: the GPIO value is set to high when the first
user requests it to be high and back to low once the last user stops
"voting" for high.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20251112-gpio-shared-v4-4-b51f97b1abd8@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
This module scans the device tree (for now only OF nodes are supported
but care is taken to make other fwnode implementations easy to
integrate) and determines which GPIO lines are shared by multiple users.
It stores that information in memory. When the GPIO chip exposing shared
lines is registered, the shared GPIO descriptors it exposes are marked
as shared and virtual "proxy" devices that mediate access to the shared
lines are created. When a consumer of a shared GPIO looks it up, its
fwnode lookup is redirected to a just-in-time machine lookup that points
to this proxy device.
This code can be compiled out on platforms which don't use shared GPIOs.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20251112-gpio-shared-v4-3-b51f97b1abd8@linaro.org
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Add support for the GPIO controller found on some QIXIS FPGAs in
Layerscape boards such as LX2160ARDB and LS1046AQDS. This driver is
using gpio-regmap.
A GPIO controller has a maximum of 8 lines (all found in the same
register). Even within the same controller, the GPIO lines' direction is
fixed, which mean that both input and output lines are found in the same
register. This is why the driver also passed to gpio-regmap the newly
added .fixed_direction_output bitmap to represent the true direction of
the lines.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Michael Walle <mwalle@kernel.org> # for the gpio-regmap part
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Pull USB / Thunderbolt updates from Greg KH:
"Here is the big set of USB and thunderbolt drivers for 6.18-rc1. It
was another normal development cycle, with lots of the usual drivers
getting updates:
- Thunderbolt driver cleanups and additions
- dwc3 driver updates
- dwc2 driver updates
- typec driver updates
- xhci driver updates and additions
- offload USB engine updates for better power management
- unused tracepoint removals
- usb gadget fixes and updates as more users start to rely on these
drivers instead of the "old" function gadget drivers
- new USB device ids
- other minor driver USB driver updates
- new USB I/O driver framework and driver additions"
The last item, the usb i/o driver, has an i2c and gpio driver added
through this tree. Those drivers were acked by the respective
subsystem maintainers.
All of these have been in linux-next for a while"
* tag 'usb-6.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (132 commits)
usb: vhci-hcd: Prevent suspending virtually attached devices
USB: serial: option: add SIMCom 8230C compositions
thunderbolt: Fix use-after-free in tb_dp_dprx_work
usb: xhci: align PORTSC trace with one-based port numbering
usb: xhci: correct indentation for PORTSC tracing function
usb: xhci: improve TR Dequeue Pointer mask
usb: xhci-pci: add support for hosts with zero USB3 ports
usb: xhci: Update a comment about Stop Endpoint retries
Revert "usb: xhci: Avoid Stop Endpoint retry loop if the endpoint seems Running"
usb: gadget: f_rndis: Refactor bind path to use __free()
usb: gadget: f_ecm: Refactor bind path to use __free()
usb: gadget: f_acm: Refactor bind path to use __free()
usb: gadget: f_ncm: Refactor bind path to use __free()
usb: gadget: Introduce free_usb_request helper
usb: gadget: Store endpoint pointer in usb_request
usb: host: xhci-rcar: Add Renesas RZ/G3E USB3 Host driver support
usb: host: xhci-plat: Add .post_resume_quirk for struct xhci_plat_priv
usb: host: xhci-rcar: Move R-Car reg definitions
dt-bindings: usb: Document Renesas RZ/G3E USB3HOST
usb: gadget: f_fs: Fix epfile null pointer access after ep enable.
...
This driver implements the GPIO service on top of the SMC framework
on Apple Mac machines. In particular, these are the GPIOs present in the
PMU IC which are used to control power to certain on-board devices.
Although the underlying hardware supports various pin config settings
(input/output, open drain, etc.), this driver does not implement that
functionality and leaves it up to the firmware to configure things
properly. We also don't yet support interrupts/events. This is
sufficient for device power control, which is the only thing we need to
support at this point. More features will be implemented when needed.
To our knowledge, only Apple Silicon Macs implement this SMC feature.
Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Bartosz Golaszewski <brgl@bgdev.pl>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Sven Peter <sven@kernel.org>
Signed-off-by: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Neal Gompa <neal@gompa.dev>
Signed-off-by: Sven Peter <sven@kernel.org>
Acked-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Link: https://lore.kernel.org/r/20250610-smc-6-15-v7-6-556cafd771d3@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
intel-gpio for v6.16-1
* Split GPIO ACPI quirks to its own file
* Refactored GPIO ACPI library to shrink the code
The following is an automated git shortlog grouped by driver:
gpiolib:
- acpi: Update file references in the Documentation and MAINTAINERS
- acpi: Move quirks to a separate file
- acpi: Add acpi_gpio_need_run_edge_events_on_boot() getter
- acpi: Handle deferred list via new API
- acpi: Make sure we fill struct acpi_gpio_info
- acpi: Switch to use enum in acpi_gpio_in_ignore_list()
- acpi: Use temporary variable for struct acpi_gpio_info
- acpi: Deduplicate some code in __acpi_find_gpio()
- acpi: Reuse struct acpi_gpio_params in struct acpi_gpio_lookup
- acpi: Rename par to params for better readability
- acpi: Reduce memory footprint for struct acpi_gpio_params
- acpi: Remove index parameter from acpi_gpio_property_lookup()
- acpi: Improve struct acpi_gpio_info memory footprint
Both gpio-sim and gpio-virtuser share a mechanism to instantiate a
platform device, wait for probe completion, and retrieve the probe
success or error status synchronously. With gpio-aggregator planned to
adopt this approach for its configfs interface, it's time to factor
out the common code.
Add dev-sync-probe.[ch] to house helper functions used by all such
implementations.
No functional change.
Signed-off-by: Koichiro Den <koichiro.den@canonical.com>
Link: https://lore.kernel.org/r/20250221133501.2203897-2-koichiro.den@canonical.com
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
