So lots of this is what the guys on #emc have been saying from the beginning. I now see the light and see why you would not want to support lots of devices right in the HM2 driver. So I think that all that the only information that the hm2 driver needs is what SPI channels you plan to use and how many "frames" to put on each SPI port. This is what SWPadnos suggested for something similar:
Meaning 4 frames on port 0, port 1 OFF, 5 frames on port 2, and port 3 OFF. This would create a set of HAL pins for each frame. They are as follows:
CD (U32) This is the channel descriptor for the frame
SEND (U32) This is pin for the bits to send, the length in bits is specified in the channel descriptor.
RECEIVE(U32) This is a pin for the resulting bits from the frame
READ(BIT) This is a bit that specifies if the frame should be sent during the hm2 read or write functions. If the bit is set, then the frame is sent during the read function.
ENABLE(BIT) Enable or disable the frame.
A driver could then be made for each device. There isn't really anything to difficult to do here. I believe that a simple realtime component could be written for any new device. Then the HAL pins connected and the interface should be very flexible. The device drivers should even be able to send internalization data to devices without any special features from the HM2 driver.
Let me know if I've got something wrong here. Of course I haven't address anything about how HM2 will actually do any of this, but it appears that a conclusion about this stuff needs to come first.