The concept: Create an MCU ID string that will be added to the board Firmware when it is compiled.
The ID would be matched to a variable string defined in the MCU configuration in printer.cfg on startup.
If the ID reported by the MCU on connection by the host does not match the configuration string klipper will shut down the MCU.
Reason: As demonstrated by Nero3d with the Sonic Pad recently some boards are close enough in design that a configuration intended for another manufactures board may unintentionally start and run in a dangerous configuration. In Neros case the Sonic Pad was shipped with a default configuration for a Creality printer unknown to him at the time. He had connected the sonic pad to an MKS Robin board that had already been configured for Klipper. The Creality silent board and the MKS Robin were close enough in design that Klipper was able to connect and run with the MKS board. Due to pin differences in the 2 systems the Creality configuration pulled pin PC3 high for an endstop. The MKS Robin uses PC3 for the hotend heater… That difference combined with the Creality thermistor pins being tied to a display in the MKS Robin lead to a dangerous thermal runaway condition.
An MCU ID would be defined by the user during the makmenuconfig operation and incorporated into the compiled firmware.
A matching field would be added into the printer.cfg MCU definition
[mcu] serial: /dev/serial/by-id/usb-1a86_USB2.0-Serial-if00-port0 mcuid:skrpico
On startup when the host connects to the MCU it will retrieve the MCU ID compiled in the firmware and compare it to the MCU ID string defined in the MCU config fie. If the MCU IDs do not match Klipper will post an error and not proceed with enabling any pin definitions.