Skip to content

mctpd: Add AttemptDiscoveryNotify D-Bus method for endpoint role#159

Open
msnidhin wants to merge 1 commit into
CodeConstruct:mainfrom
msnidhin:discovery_notify
Open

mctpd: Add AttemptDiscoveryNotify D-Bus method for endpoint role#159
msnidhin wants to merge 1 commit into
CodeConstruct:mainfrom
msnidhin:discovery_notify

Conversation

@msnidhin

Copy link
Copy Markdown
Contributor

Expose AttemptDiscoveryNotify on au.com.codeconstruct.MCTP.Endpoint1 on the per-interface D-Bus path when the link role is ENDPOINT_ROLE_ENDPOINT.

The method accepts a physical hardware address and sends a physical-addressed Discovery Notify control message (opcode 0x0D) to the target, allowing an endpoint to proactively trigger discovery by the bus owner.

Also fix mctp_ctrl_validate_response to use strict less-than when comparing exp_size against sizeof(struct mctp_ctrl_resp). The previous <= incorrectly rejected responses whose complete structure is exactly the base response size, such as Discovery Notify.

@msnidhin

Copy link
Copy Markdown
Contributor Author

Follow up PR for
https://discord.com/channels/775381525260664832/778790638563885086/1488825384471625799

@msnidhin msnidhin force-pushed the discovery_notify branch 2 times, most recently from 6036f4f to d5934f4 Compare June 30, 2026 05:08

@jk-ozlabs jk-ozlabs left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The implementation looks good here (some fairly minor comments inline) but there are some items that I don't think we had covered on the earlier discussion.

As a naïve approach, we could do the Discovery Notify automatically when we're bringing-up an interface that is one of the Discovery-Notify-requiring types. However, that's not always possible, because:

  • we don't always know when that is required (as DSP0233 specifies)
  • we don't always know how to address the bus owner

Could you elaborate on your use-case here to see how we should be handling the former? If it's just a matter of knowing the bus-owner address, this could possibly be designed as more of an interface to supply the bus-owner address, and then we would decide on sending the Discovery Notify as appropriate. If that's not feasible, that's fine, but I would like to know the factors involved there.

Comment thread docs/mctpd.md
Comment on lines +238 to +241
Some physical transports (such as MCTP-over-I3C) require the endpoint to
send a Discovery Notify to announce its presence before the bus owner will
enumerate it. On those interfaces this method can be called before the
endpoint will be assigned an EID.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This isn't exactly correct; in most cases, the I3C peer has explicit knowledge of the presence of the new MCTP endpoint.

I'm not clear on your specific use-case here, could you expand this on the scenario where this is required?

Comment thread docs/mctpd.md
.AttemptDiscoveryNotify method ay - -
```

#### `.AttemptDiscoveryNotify`: `ay`

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is only applicable for certain transport binding types, we may want to put this into an interface that is specific to those transports, rather than Endpoint1 which should be common across all. Any thoughts on that?

Comment thread src/mctpd.c
struct mctp_ctrl_resp *rsp;

if (exp_size <= sizeof(*rsp)) {
if (exp_size < sizeof(*rsp)) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd prefer this as a separate fix.

Comment thread src/mctpd.c
Comment on lines +4025 to +4032
struct mctp_ctrl_cmd_discovery_notify req = { 0 };
struct mctp_ctrl_resp_discovery_notify *resp = NULL;
dest_phys desti = { 0 }, *dest = &desti;
struct link *link = data;
struct ctx *ctx = link->ctx;
struct mctp_ctrl_cmd cmd = { 0 };
uint8_t iid;
int rc;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor, but if you're reworking, can you reverse-christmas-tree these?

Comment thread src/mctpd.c

rc = message_read_hwaddr(call, dest);
if (rc < 0)
goto err;

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is taking the mctp_ctrl_cmd_free path, but the surrounding conditionals do not. You don't have cmd->resp set here, so I don't think you need the cleanup.

Comment thread src/mctpd.c
return sd_bus_reply_method_return(call, "");
err:
mctp_ctrl_cmd_free(&cmd);
set_berr(ctx, rc, berr);

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the significance of returning an error in the API here? Do we need to fail this at all?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(to be clear: yes, we should fail on invalid arguments etc, but do we need to fail on specifics of the peer response - or lack of one?)

Comment thread docs/mctpd.md

Bridge endpoints should be initialised with `AssignEndpoint` instead.

### Endpoint interface: `au.com.codeconstruct.MCTP.Endpoint1` interface (on interface objects)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

drop the "(on interface objects)"; this is covered by the "Endpoint Interface" term there (it's a bit confusing on the two meanings of "interface" here, but I don't think a third reference helps).

Expose AttemptDiscoveryNotify on au.com.codeconstruct.MCTP.Endpoint1
on the per-interface D-Bus path when the link role is
ENDPOINT_ROLE_ENDPOINT.

The method accepts a physical hardware address and sends a
physical-addressed Discovery Notify control message (opcode 0x0D)
to the target, allowing an endpoint to proactively trigger
discovery by the bus owner.

Also fix mctp_ctrl_validate_response to use strict less-than when
comparing exp_size against sizeof(struct mctp_ctrl_resp). The
previous <= incorrectly rejected responses whose complete structure
is exactly the base response size, such as Discovery Notify.

Signed-off-by: Nidhin MS <nidhin.ms@intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants