docs, CHANGELOG: Add details of VDM type registration behaviour

Signed-off-by: Jeremy Kerr <jk@codeconstruct.com.au>

Author: jk-ozlabs

CHANGELOG.md

@@ -12,6 +12,15 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
 
 1. Fixed `mctp-bench` compile on musl libc
 
+### Changed
+
+1. `mctpd`'s `RegisterTypeSupport` dbus method will no longer allow the
+   VDM messaging types (0x7e and 0x7f) to be registered, as these do not
+   make sense without a corresponding VDM type registration.
+
+   Registering a VDM type will automatically include the corresponding VDM type
+   in the Get Message Type Support response.
+
 ### Added
 
 1. `mctpd` now implements the Get Vendor Define Message Support control protocol

docs/mctpd.md

@@ -50,6 +50,10 @@ If the message type is already registered, then dbus call will fail.
  - `<versions>` Versions supported for this message type formatted as uint32
    integers as specified in DSP0236
 
+The `msg_type` value must be a valid message type, and cannot be one of the
+VDM types (0x7e or 0x7f). Those VDM types are handled by the
+`RegisterVDMTypeSupport` method instead.
+
 De-registration is automatic - the specified types (and versions) are registered
 for as long as the dbus sender remains attached to the message bus, and are
 unregistered on disconnect.
@@ -72,6 +76,9 @@ If the VDM type is already registered, then dbus call will fail.
    - For IANA format: 32-bit unsigned integer (`u`)
  - `<command set type>` Command set type (16-bit unsigned integer) as defined by the vendor
 
+Registering a VDM type will cause the corresponding VDM type value (0x7e or
+0x7f) to be returned in mctpd's Get Message Type Support response.
+
 De-registration is automatic - the specified VDM types are registered for as
 long as the dbus sender remains attached to the message bus, and are
 removed when the sender disconnects.