Re: [PATCH v2 2/2] gpio: axiado: add SGPIO controller support

On 7/29/2026 10:28 PM, Linus Walleij wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> Hi Petar,
>
> thanks for your patch!
>
> On Wed, Jul 29, 2026 at 9:02 AM Petar Stepanovic <[email protected]> wrote:
>
>> Add support for the Axiado SGPIO controller.
>>
>> Each SGPIO position provides one input GPIO and one output GPIO with
>> fixed directions. The driver registers the controller as a gpio_chip,
>> supports interrupts on input GPIOs, and uses regmap for register access.
>>
>> Signed-off-by: Petar Stepanovic <[email protected]>
> (...)
>
>> +static int ax3000_sgpio_set(struct gpio_chip *chip, unsigned int offset,
>> +                            int value)
>> +static int ax3000_sgpio_get_direction(struct gpio_chip *chip,
>> +                                     unsigned int offset)
>> +{
>> +       if (!(offset % 2))
>> +               return GPIO_LINE_DIRECTION_IN;
>> +
>> +       return GPIO_LINE_DIRECTION_OUT;
>> +}
> So every second GPIO is input only and every second GPIO is output
> only?
>
> How does this look *phycially* on the outside of the chip?
>
> I'm a bit worried that the input and output would be to the same pin or
> something, in which case they are the same GPIO line.
>
> The cover letter says " Each SGPIO position provides one fixed-direction
> input GPIO and one fixed-direction output GPIO." and I'm suspicious
> about this.
>
> What is an "SGPIO position"?
>
> If a position is something like a physical line controlled by both an
> input and an output driver block, it is the same GPIO line in Linux
> terms, it will be used as output if a LED is connected there and
> it will be used as input if a key is connected there, and we have
> 64 or 128 GPIOs, not 128 or 256.

Yes, every pair consists of one input-only GPIO and one output-only GPIO,
but they do not represent two directions of the same physical pin.

“SGPIO position” refers to one bit slot in the serialized SGPIO frame, not
to a physical SoC pin. For each position, the controller samples one bit
from the dedicated SGPIO data-input signal and transmits an independent bit
through the dedicated SGPIO data-output signal. These are separate physical
signals and are normally connected to separate input and output shift
registers.

Therefore, the input and output associated with a position are independent
GPIO lines in Linux and their directions cannot be changed. For position
|n|, offset |2 * n| represents the input and offset |2 * n + 1| represents
the output. With |N| SGPIO positions, the GPIO controller exposes |2 * N|
GPIO lines.

I agree that the term “SGPIO position” is unclear. I will update the cover
letter and binding description to define it as a serial bit slot and
clarify that each slot carries one independent input bit and one
independent output bit over separate serial data signals.

>
>> +static int ax3000_sgpio_get(struct gpio_chip *chip, unsigned int offset)
>> +{
>> +static int ax3000_sgpio_dir_in(struct gpio_chip *chip, unsigned int offset)
>> +static int ax3000_sgpio_dir_out(struct gpio_chip *chip, unsigned int offset,
> The GPIO line handling looks like:
>
> 1. some translation
> 2. Standard things
>
> which is usually what we use regmap-gpio for, and we have added a few
> features to it recently. Some are even in linux-next, can you check it out
> and see if you could use the library?

Thanks for the suggestion. I checked the recent |gpio-regmap| additions,
and the library appears suitable for the standard GPIO operations in this
driver.

The fixed-direction support can describe the even offsets as input-only
and the odd offsets as output-only, while a custom register/mask
translation callback can map each GPIO pair to the corresponding bit in
the separate input and output register banks.

I will prototype the conversion for the next version. I still need to
verify that the output registers support the read-modify-write access
expected by |gpio-regmap|, since the current driver maintains a software
shadow of the output state. The controller-specific interrupt handling
will remain in the driver and will need to be integrated with the
|gpio-regmap| GPIO chip.

Best regards,
Petar