mctpd: Handle discovery messages #16
Conversation
This commit adds mctp_nl_addr_{add,del} helpers for sending
RTM_{NEW,DEL}ADDR messages. This mirrors the existing
mctp_nl_route_{add,del} helpers.
Signed-off-by: Khang Nguyen <[email protected]>
As per the DSP0238 spec, an endpoint needs to use physical addressing to reply to discovery messages until it is assigned an EID. This commit adds a helper to send physical addressed responses. Signed-off-by: Khang Nguyen <[email protected]>
This commit adds support for Prepare for Endpoint Discovery messages specified in DSP0236, section 12.13. Signed-off-by: Khang Nguyen <[email protected]>
This commit adds support for Endpoint Discovery messages, specified in DSP0236 section 12.14. Signed-off-by: Khang Nguyen <[email protected]>
Currently, mctpd handles Set EID message as a bus owner, which means it assumes it has at least one local EID and rejects all Set Endpoint ID requests. This commit handles the case where mctpd runs on an endpoint and it has no EID set yet. Signed-off-by: Khang Nguyen <[email protected]>
|
All look great, thanks. We should probably include some top-level configuration on whether mctpd is running as an endpoint vs bus owner (and/or do we need to distingush a TMBO?). Even a command-line argument would be sufficient there. For example, this would affect the Set Endpoint ID handling; in bus-owner mode, we would reject all Set Endpoint ID commands; rather than being conditional on whether an EID is already assigned. In endpoint mode, it should be totally fine for the bus owner to reassign EIDs. Is that something you'd like to do? If not, I can implement as a base change. |
|
@jk-ozlabs Sorry for the late reply. I made a MR to add the BO configuration at #14, if that is what you meant. |
Ah! Thank you. I should have started there. |
This PR adds support for replying to discovery messages, when
mctpdruns on an endpoint: