Build against dmgpio 2.0; number ioctls from DMDRVI_IOCTL_CUSTOM_BASE

[JohnAmadis]

Part of choco-technologies/dmod-ecosystem#17.

Put this on the board together with dmgpio ≥ 1.1 (choco-technologies/dmgpio#37, released as v1.1).

dmspi drives the software chip select through Dmod_Ioctl() on the GPIO node, so dmgpio does not appear in dmspi.dmd. dmgpio@>=1.1 is only checked at build time; at run time nothing stops versions from mixing:

• dmgpio 1.1 with an older dmspi: the software CS stops working (-ENOTTY).
• This dmspi with dmgpio 1.0: works only by accident, because 1.0 truncates the command to a byte.

dmspi's own ioctl values change too, so modules sending dmspi ioctls must be rebuilt.

Summary

1. Build against dmgpio ≥ 1.1 (chip select)

dmgpio 1.1 numbers its ioctl commands from DMDRVI_IOCTL_CUSTOM_BASE. As a result dmgpio_ioctl_cmd_set_pins_state, which drives the software CS, has a new value.

2. The same change for dmspi's own commands

dmspi had the same problems:

• Its commands started at 1, inside the standard dmdrvi range (DMDRVI_IOCTL_NET_* = 0x01..).
• Anything >= dmspi_ioctl_cmd_max got a logged -EINVAL. dmdevfs probes every node with 0x100/0x200, so every SPI node logged two errors.
• Commands below 1 were not range-checked at all.

This PR applies the change dmgpio, dmdma and dmtty already got:

• dmspi_ioctl_cmd_t starts at DMDRVI_IOCTL_CUSTOM_BASE. dmspi_types.h includes dmdrvi_ioctl.h, and dmspi_port and spitest fetch the dmdrvi headers for it. dmdrvi is pinned to >= 2.0.
• Every command outside [get_role, max) returns -ENOTTY without a log entry.
• docs/api-reference.md describes the numbering and the return value.
• spitest lives in this repo and is rebuilt with it. No other module sends dmspi ioctls; I checked the choco-technologies driver repositories.

Test plan

• Against the released dmgpio 1.1, in chocotechnologies/dmod:1.0.4:
  • CI steps on x86_64 (dmspi, test_dmspi, x86_64 loopback dmspi_port): test_dmspi passes 6/6.
  • The new step calls dmspi through the dmdrvi DIF the way dmdevfs does. The block/monitor/network probes, 0, -1 and dmspi_ioctl_cmd_max all give -ENOTTY. dmspi_ioctl_cmd_get_role == DMDRVI_IOCTL_CUSTOM_BASE, and it answers master.
  • stm32f4/stm32f7 builds of dmspi, dmspi_port, spitest and test_dmspi: no warnings.
• On target with dmgpio 1.1:
  • software CS still toggles around transfers (spitest loopback);
  • no ioctl errors from SPI nodes at dmdevfs mount.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TgkwHQKqf6c4DzypSKzZT7