Open-collector GPIO usage question

Open-collector GPIO usage question

[Matthias Urlichs]

[-- Attachment #1.1: Type: text/plain, Size: 793 bytes --]

Hi,

so I want to efficiently implement a bit-bang-ish protocol, meaning I'd 
like to use events instead of busy-looping.

The hardware uses open-collector wiring.

This doesn't seem possible with Linux GPIO.

I cannot set input and output flags at the same time. Getting events 
requires the input flag while the open-drain output flag requires, well, 
output. Owch.

AFAICS all of this is enforced by 
drivers/gpio/gpiolib-cdev.c::gpio_v2_line_flags_validate(), so not gpio 
driver specific.

As some hardware seems capable enough to trigger an interrupt on raw 
port levels even if configured for "output", this seems overly 
restrictive … also, I happen to not have enough GPIO ports to use two 
per wire.

Thoughts?

-- 
-- regards
-- 
-- Matthias Urlichs


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: Open-collector GPIO usage question

[Kent Gibson]

On Fri, Nov 21, 2025 at 07:59:47PM +0100, Matthias Urlichs wrote:
> Hi,
> 
> so I want to efficiently implement a bit-bang-ish protocol, meaning I'd like
> to use events instead of busy-looping.
> 
> The hardware uses open-collector wiring.
> 
> This doesn't seem possible with Linux GPIO.
> 
> I cannot set input and output flags at the same time. Getting events
> requires the input flag while the open-drain output flag requires, well,
> output. Owch.
> 

The uAPI supports either a receiver role (input) or transmitter role
(output).  You are not locked into either role - the requested line can be
switched between the two as necessary [1].  So half-duplex.
But, as you say, it doesn't support both simultaneously, so no full-duplex
transceiver.

Should you require that you have two options, either a use a second
pin, an option you reject, or write an in-kernel driver for your
protocol.

> AFAICS all of this is enforced by
> drivers/gpio/gpiolib-cdev.c::gpio_v2_line_flags_validate(), so not gpio
> driver specific.

cdev is user facing and is validating user input.
It does not follow that it is the source of the restriction.

> 
> As some hardware seems capable enough to trigger an interrupt on raw port
> levels even if configured for "output", this seems overly restrictive …
> also, I happen to not have enough GPIO ports to use two per wire.

Some.  Not most.
This is functionality that the vast majority of users do not require, but
if you think it would be benificial then you can always submit a patch.
But, to be clear, this will require more than removing that check in cdev.

Cheers,
Kent.

[1] https://www.kernel.org/doc/html/latest/userspace-api/gpio/gpio-v2-line-set-config-ioctl.html