Number ioctl commands from DMDRVI_IOCTL_CUSTOM_BASE, answer the rest with -ENOTTY

[JohnAmadis]

Part of choco-technologies/dmod-ecosystem#17. Fixes the misclassified GPIO nodes reported on STM32F746G-DISCO in choco-technologies/dmsdio#2.

Breaking: release as dmgpio 2.0, together with dmspi 2.0 (choco-technologies/dmspi#6) and dmsdio (choco-technologies/dmsdio#2).

The ioctl command values change. Consumers send them through Dmod_Ioctl() on the GPIO node, so dmgpio never appears in their .dmd. dmgpio@>=2.0 is only a build-time requirement, and nothing prevents mixing versions on the board:

• dmgpio 2.0 with dmspi 1.x breaks software chip select. dmspi sends 1, which dmgpio now rejects with -ENOTTY.
• dmspi 2.0 with dmgpio 1.0 works only by accident: 1.0 truncates 0x1001 to the byte 1.

The board image (dmod-boot flash.dmd) has to take all three together.

Problem

With dmdevfs ≥ 1.1, every GPIO node was reported as both a monitor and a block device. That meant one dmdevmon instance per pin (~40 on STM32F746G-DISCO, each logging refresh failed (-22)) plus a partition scan. On top of that, every probe toggled the pins.

1. Truncated command. dmgpio_dmdrvi_ioctl() switched on (dmgpio_ioctl_cmd_t)command. arm-none-eabi uses short enums (sizeof == 1), so GCC truncates the command to a byte (uxtb r3, r2 before tbb). DMDRVI_IOCTL_BLOCK_GET_INFO (0x100) and DMDRVI_IOCTL_MONITOR_GET_POLICY (0x200) both became 0 = toggle_pins and returned 0. A host build (4-byte enums) never shows this.
2. Command range. dmgpio numbered its commands from 0. dmdrvi reserves everything below DMDRVI_IOCTL_CUSTOM_BASE (0x1000) for standard commands, which generic code may send to any node. As a result, 1–4 were also DMDRVI_IOCTL_NET_*.

Fix

• dmgpio_ioctl_cmd_t now starts at DMDRVI_IOCTL_CUSTOM_BASE.
  • dmgpio_types.h includes dmdrvi_ioctl.h.
  • dmgpio and dmgpio_port (headers only, via dmgpio_port.h) link dmdrvi@>=2.0.
• switch (command) on the int.
• Every other command returns -ENOTTY without a log entry, as dmdrvi requires. dmdevfs asks every node.
• README and docs/api-reference.md show the real commands (they listed ones dmgpio does not have), the numbering and the return values.

stm32f7 disassembly after the change: only 0x1000..0x1004 reach the jump table. Everything else, including 0x100/0x200, returns -25 = -ENOTTY:

33c: f5a2 5280 sub.w r2, r2, #4096
340: 2a04      cmp   r2, #4
342: d832      bhi.n 3aa            ; -> mvn.w r0, #24  (-ENOTTY)
344: e8df f002 tbb   [pc, r2]

Consumers

Across the choco-technologies driver repositories, only two modules send dmgpio ioctls:

• dmspi: software chip select. Changed in Build against dmgpio 2.0; number ioctls from DMDRVI_IOCTL_CUSTOM_BASE dmspi#6.
• dmsdio: card detect. Changed in Implement the SD memory protocol and dmdrvi device model dmsdio#2.

dmuart, dmspi, dmfmc and dmeth use dmgpio only for pin muxing in .ini board files, and dmeth mentions it only in a comment. None of them needs a rebuild.

Test plan

• stm32f4/stm32f7 builds (the CI matrix) with no warnings. The disassembly shows the new range and the -ENOTTY path.
• Root cause reproduced: sizeof(enum) == 1 with arm-none-eabi-gcc -mcpu=cortex-m7, and uxtb in the released dmdrvi_dmgpio_ioctl.
• dmspi and dmsdio build against a local dmgpio 2.0 package from this branch. test_dmspi passes 6/6 and test_dmsdio 41/41.
• On target, with default report=all:
  • GPIO nodes are no longer reported as monitor/block;
  • pins do not toggle at dmdevfs mount;
  • no "Unknown ioctl command" errors;
  • dmsdio card detect and dmspi software CS still work.

🤖 Generated with Claude Code

https://claude.ai/code/session_01TgkwHQKqf6c4DzypSKzZT7