On Wed, Jun 12, 2024 at 11:03 AM Marek Behún <kabel@xxxxxxxxxx> wrote: > > On Wed, 12 Jun 2024 10:55:55 +0200 > Marek Behún <kabel@xxxxxxxxxx> wrote: > > > > Users can still read the value of this pin but won't be able to set > > > direction to output. > > > > Users are not supposed to read value of this pin, because it is not a > > GPIO pin. The corresponding bit is not set in gpiochip.valid_mask. > > It is for example impossible to export it in /sys/class/gpio. > > > > This line is valid only as an IRQ (the > > corresponding bit is set in gpiochip.irq.valid_mask). > Ah, I missed the bit about these pins not being marked as valid. > I am starting to thing that this might be the problem, that the line is > not valid as GPIO, only as an IRQ. gpiolib seems to be unable to handle > that. > > Indeed, the definition of the function > gpiochip_irqchip_irq_valid() > first checks if the line is valid as gpio: > > static bool gpiochip_irqchip_irq_valid(const struct gpio_chip *gc, > unsigned int offset) > { > if (!gpiochip_line_is_valid(gc, offset)) > return false; > ... > TBH Maybe using the GPIO provider APIs for something that isn't a GPIO doesn't make much sense? They are called GPIO irqchips for a reason after all? How about handling the non-GPIO interrupts with regular irqchip code and only exposing actual GPIOs using gpiolib? What is the exact layout of these pins? Are the GPIOs and non-GPIOs somehow grouped together? Maybe export several separate GPIO banks? Bart