Clarify R_RESET_DEV defaults and capability-dependent behavior

[glopesdev]

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

This proposal clarifies the R_RESET_DEV specification for devices that do not implement all of its capabilities. It defines the value a Read MUST return when the register functionality is unavailable, and specifies how each write-action bit behaves when the corresponding hardware capability is absent. It follows from #18, which standardized firmware-update triggering on bit 5 and decided that firmware-update capability is inferred from the version register.

Motivation

#18 added the UPDATE_FIRMWARE bit but left two cases undefined, and both surface for minimal devices such as those without a bootloader or without non-volatile memory.

First, the specification gives no value for a Read of R_RESET_DEV when the register functionality is not implemented. The general convention is that an optional register defaults to zero, but R_RESET_DEV cannot honestly return all-zeroes: the read-only BOOT_DEF and BOOT_EE bits MUST report boot provenance, and a Device without persistent storage MUST set BOOT_DEF and clear BOOT_EE. Such a device therefore reads 0x40, not 0x00. Without an explicit statement, 0x40 is ambiguous against "register not implemented", and all-zeroes contradicts the existing per-bit rules.

Second, the specification does not define what happens when a Write sets a bit the Device cannot honor. RST_EE and SAVE already reply with an Error when non-volatile memory is absent, but UPDATE_FIRMWARE has no equivalent path, so a device without a bootloader has no defined response.

Detailed Design

R_RESET_DEV is best understood as a per-bit contract rather than an all-or-nothing register. Under the Optional or Deprecated Registers rules, every core register, including optional ones, MUST already answer a Read with a default value, MUST return the default on a Write that has no effect, and MUST appear in the R_OPERATION_CTRL dump. So register presence on the bus is mandatory regardless of necessity; what varies between devices is which write actions are functional.

Default read value. A Device that does not implement the register functionality, or that has no non-volatile memory, MUST return 0x40 on a Read, that is BOOT_DEF set and all other bits clear. This reflects that a Device without persistent storage always boots with default register values. It is an explicit per-register exception to the zero-default convention, which the optional-register rules already allow when documented and justified.

Per-bit behavior when a capability is absent.

• RST_EE (bit 1) and SAVE (bit 2): already MUST reply with an Error when non-volatile memory is unavailable. No change.
• UPDATE_FIRMWARE (bit 5): if this bit is set and the Device does not support firmware update, the Device MUST reply with an Error, mirroring RST_EE and SAVE. Firmware-update capability is inferred from the version register per Consider standardizing trigger for Bootloader mode #18, so this Error is a defensive runtime fallback, not a capability-advertisement mechanism.
• BOOT_DEF (bit 6) and BOOT_EE (bit 7): read-only state, reported by every Device per the existing rules.
• RST_DEF (bit 0) and NAME_TO_DEFAULT (bit 3): see Unresolved Questions.

Drawbacks

The 0x40 default is a per-register exception to the zero-default convention, one more special case a reader must learn. The UPDATE_FIRMWARE error path also adds normative behavior to a bit that was only recently introduced.

Alternatives

An all-zeroes default was considered and rejected, because it contradicts the BOOT_DEF and BOOT_EE rules and is ambiguous against an unimplemented register. A dedicated firmware-update capabilities register was proposed in #18 and declined by the SRM in favor of inferring capability from the version register, so it is not reopened here. Leaving UPDATE_FIRMWARE degradation unspecified was also considered, but it leaves bootloader-less devices without a defined response.

Unresolved Questions

• Whether R_RESET_DEV should be labelled Optional or Required. Once the read default and per-bit degradation are specified, a Device behaves identically under either label, answering a Read with 0x40 and degrading each write to a defined Error or no-op, so the label signals intent, whether implementers are expected to make reboot and reset functional where the hardware allows, rather than changing wire behavior.
• The behavior of NAME_TO_DEFAULT when R_DEVICE_NAME is not implemented.
• Whether RST_DEF and reboot should be mandated as the one near-universal action, or also allowed to degrade.

Design Meetings

Follows from the SRM decision recorded in #18.

Related Issues

• Consider standardizing trigger for Bootloader mode #18