I am working on a motor driver expansion board for the Raspberry Pi, similar to this smaller board, but in the standard HAT form factor. The new board also has provision for an ID EEPROM to make it fully conform to the HAT specification, but even after looking over the specification carefully, I'm having a hard time seeing any kind of substantial benefit that the EEPROM could offer. It seems largely pointless to put one on this type of add-on board, and I want to check if I'm missing something. (The board has been prototyped and tested, and it is basically ready for production aside from the decision of whether to populate the EEPROM on the PCB.)
The HAT specification says "The purpose of this [device tree] overlay is that it allows true automatic configuration of all devices attached to the HAT, as long as there are Linux device drivers available for the hardware in question." So it seems like the device tree blob could be used for setting up things like the I2C or SPI interface and loading the correct drivers for hardware connected to those interfaces, allowing high-level access to that hardware from Linux. But the motor driver add-on is intended to be controlled through low-level direct GPIO access, so it isn't clear to me what (if anything) a device tree overlay would be useful for, or even what information it should contain.
Using the GPIO map to set up GPIO pins does not seem particularly useful in this case either. If the Raspberry Pi has to interface with the motor driver by manipulating GPIOs through a program or library, it's straightforward to have that same program or library configure the pins the way they should be set up.
Having vendor info specified in the EEPROM seems cool, but would the Raspberry Pi do anything with that information?
On the whole, then, it doesn't seem like I would be missing out on much by omitting the ID EEPROM from such an add-on board. (In fact, if the board can function without an EEPROM, adding one might only serve to cause problems stacking it with another HAT when that might otherwise work fine.) Is there something I don't understand about how the information in the EEPROM is used or some other argument in favor of having an EEPROM?
I understand that by not having an ID EEPROM, the board would not meet the HAT specification and is not supposed to be called a HAT, but that is just an issue of naming. Do (potential) users find that important?