GPIO support in USBSDMuxDrive

[hamztouiz]

Feature request: GPIO support in USBSDMuxDriver

Description

The current USBSDMuxDriver only exposes basic mode control:

• set_mode
• get_mode

However, the underlying usbsdmux tool already supports GPIO operations:

• gpio <n> get
• gpio <n> high/low

These capabilities are not currently exposed in the driver.

Problem

This limitation prevents using the GPIOs of the USB-SD-Mux in HIL setups. In practice, this blocks use cases such as:

• resetting the DUT
• controlling power lines
• synchronizing external hardware during tests

In our case, this is particularly needed to simulate SD card insertion and removal events in our automated tests.

As a result, additional external tools or workarounds are required, even though the hardware already supports it.

Proposed solution

Extend USBSDMuxDriver with minimal GPIO support, for example:

• gpio_get(gpio: int) -> int
• gpio_set(gpio: int, value: int)

This would directly map to the existing usbsdmux CLI without introducing additional complexity.

Benefits

• Enables simulation of SD card insertion/removal in automated HIL tests
• Unlocks more advanced hardware control scenarios
• Aligns the driver capabilities with the underlying tool
• Keeps the implementation simple and backward-compatible

Additional context

GPIO support is already implemented and stable in the usbsdmux tool, so this would mainly be an exposure of existing functionality in Labgrid.

Contribution

I’d be happy to implement this as a PR if this is considered useful and if I’m not missing any existing mechanism or design constraint.

Please let me know if this aligns with the project direction.

[Emantor]

Sure, the initial implementation of the USBSDMuxDriver still dates back to the initial device release, IOs were only added for the fast version. The question becomes whether we want to implement this on top of the existing driver or add a new resource and driver. Separate resource and driver would have the advantage that the IO ports could be used on another place.

[hamztouiz]

Thanks for the feedback!

I'm open to both approaches. A separate resource and driver would indeed provide better separation of concerns and allow the I/O ports to be used independently o.

That said, a few things make me lean toward extending the existing USBSDMuxDriver directly:

• The USB-SD-Mux only exposes 2 GPIOs, and they are physically tied to the device. In practice, it seems unlikely that someone would want to use them on a separate place, independently from the mux itself.
• More importantly, the GPIO control code would necessarily differ between the USB-SD-Mux and any other component. This means a truly generic I/O driver would also require defining a dedicated Labgrid protocol.

Extending the existing driver keeps the implementation minimal, avoids introducing a new resource/driver/protocol triplet, and stays closer to the actual hardware model.

That said, I'm relatively new to contributing to Labgrid and may be missing design patterns or conventions I'm not yet aware of. I'm fully open to guidance and happy to follow whichever direction you think is best.

[Emantor]

I think extending the USBSDMuxDriver should be fine.

[hamztouiz]

This is addressed in PR #1891.