public inbox for netdev@vger.kernel.org
 help / color / mirror / Atom feed
From: Badal Nilawar <badal.nilawar@intel.com>
To: dri-devel@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: badal.nilawar@intel.com, rodrigo.vivi@intel.com,
	wojciech.drewek@intel.com, michael.brooks@intel.com,
	heikki.krogerus@intel.com, michael.j.ruhl@intel.com,
	thomas.hellstrom@linux.intel.com, michal.winiarski@intel.com,
	anshuman.gupta@intel.com, jacob.e.keller@intel.com,
	maarten.lankhorst@linux.intel.com, matthew.brost@intel.com,
	anthony.l.nguyen@intel.com, przemyslaw.kitszel@intel.com,
	mika.westerberg@linux.intel.com,
	andriy.shevchenko@linux.intel.com,
	singaravelan.nallasellan@intel.com, kelvin.gardiner@intel.com,
	jk@codeconstruct.com.au, matt@codeconstruct.com.au,
	andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com, james.ausmus@intel.com
Subject: [RFC PATCH 0/1] Proposal for in-band firmware update over PLDM-MCTP
Date: Tue,  5 May 2026 01:04:21 +0530	[thread overview]
Message-ID: <20260504193420.1232842-3-badal.nilawar@intel.com> (raw)

Problem statement: 

The CRI platform includes a dedicated I2C controller for in-band access to AMC.
AMC firmware updates leverage PLDM over MCTP, using the I2C controller as the
physical transport, enabled by the Linux kernel's MCTP-I2C driver
(drivers/net/mctp/mctp-i2c.c), which manages MCTP framing and delivery over the
I2C bus.

CRI Inband firmware update flow

        +-----------------------------------+
        |         User Space                |
        |	(PLDM requester/responder)  | 
        |   PLDM client via AF_MCTP socket  |
        +-----------------------------------+
                          |
        +-----------------------------------+
        |        net/mctp core              |
        |   (routing, EID resolution,       |
        |    MCTP framing)                  |
        +-----------------------------------+
                          |
        +-----------------------------------+
        |           mctp-i2c.c              |
        |   MCTP transport over i2c         |
        +-----------------------------------+
                          |
        +-----------------------------------+
        |          AMC Firmware             |
        |	(PLDM requester/responder)  | 
        |  MCTP Decode -> PLDM Processing   |
        +-----------------------------------+

Future GPU platforms may not include a dedicated I2C controller for MCTP
access; however, the requirement to support PLDM over MCTP persists. To
address this, a vendor-specific mailbox-based transport is proposed to
carry MCTP messages between the host and the GPU/AMC.

Solution:

The proposed approach involves implementing an MCTP transport layer with
binding type MCTP_PHYS_BINDING_VENDOR (0xFF) and incorporating it either
into the drivers/net/mctp/ directory or the drivers/gpu/drm/xe subsystem.
The latter is particularly fitting, as Xe is the exclusive consumer of
this functionality.


Option 1: MCTP Transport as Part of drivers/gpu/drm/xe Subsystem

Under this design, the Xe KMD takes sole ownership of the MCTP mailbox
transport layer. The implementation is introduced as a new source file,
xe-mctp-mailbox.c, placed within the drivers/gpu/drm/xe/ driver tree.

Although xe-mctp-mailbox.c resides within the Xe subsystem, it does not
operate in isolation from the broader networking stack. It integrates
with the standard Linux MCTP stack by registering an MCTP net device
via mctp_register_netdev(), allowing the net/mctp core to manage
routing, EID resolution, and MCTP framing in the usual way.
This means Xe retains direct ownership of the mailbox MMIO interface
(status, and data registers via BAR), while still participating as
transport in the MCTP network subsystem.


  +--------------------------------------------------+
  |                  User Space                      |
  |         (PLDM Requester / Responder)             |
  |       PLDM Client via AF_MCTP Socket             |
  +--------------------------------------------------+
                         |
                    AF_MCTP API
                         |
  +--------------------------------------------------+
  |              net/mctp Core                       |
  |    (Routing, EID Resolution, MCTP Framing)       |
  +--------------------------------------------------+
            |                        ^
            | mctp_register_netdev() | netdev / mctp_dev ops
            |   (called by Xe KMD)   |
  +--------------------------------------------------+
  | [NEW] drivers/gpu/drm/xe/xe-mctp-mailbox.c       |
  |                                                  |
  |   Owned by  : Xe KMD (drivers/gpu/drm/xe/)       |
  |   - Registers directly as MCTP net device        |
  |   - Implements MCTP transport over Mailbox MMIO  |
  +--------------------------------------------------+
                         |
           Direct MMIO access (BAR registers)
                         |
  +--------------------------------------------------+
  |         Intel Mailbox MMIO Registers             |
  |    (Doorbell, Status, Data Registers via BAR)    |
  +--------------------------------------------------+
                         |
              Hardware Mailbox Interface
                         |
  +--------------------------------------------------+
  |             GPU / AMC Firmware                   |
  |         (PLDM Requester / Responder)             |
  |   Mailbox Handler --> MCTP Decode                |
  |              --> PLDM Processing                 |
  +--------------------------------------------------+

Pros:
    + Tightly coupled with Xe and doesn't polute current generic mctp
      subsystem with vendor specific mailbox solution.
Cons:
    - Not a generic layer; cannot be easily reused or consumed
      by other drivers or subsystems outside of Xe.

RFC Patch: "xe/xe_mctp_mailbox: Add support for MCTP transport over mailbox"

Option 2: MCTP Transport as Part of net/mctp Subsystem

The MCTP mailbox driver (intel-mctp-mailbox.c) resides under
drivers/net/mctp/ and registers itself as an Auxiliary Bus Driver on the
Linux auxiliary bus. The Xe KMD is responsible for constructing an
Auxiliary Bus Device which encapsulates the mailbox ops and registering
it against the MCTP auxiliary bus driver. This binding allows the MCTP
layer to send and receive messages through the GPU mailbox interface.

  +--------------------------------------------------+
  |                  User Space                      |
  |         (PLDM Requester / Responder)             |
  |       PLDM Client via AF_MCTP Socket             |
  +--------------------------------------------------+
                         |
                    AF_MCTP API
                         |
  +--------------------------------------------------+
  |              net/mctp Core                       |
  |    (Routing, EID Resolution, MCTP Framing)       |
  +--------------------------------------------------+
                         |
              mctp_dev ops / netdev interface
                         |
  +--------------------------------------------------+
  | [NEW] drivers/net/mctp/intel-mctp-mailbox.c      |
  |                                                  |
  |   Registered as: Auxiliary Bus Driver            |
  |   - Binds to Auxiliary Device exposed by Xe KMD  |
  |   - Accesses mailbox ops shared via aux device   |
  +--------------------------------------------------+
       |                              |
       | auxiliary_driver_register()  | auxiliary_device_register()
       |                              |
  +--------------------+   +-------------------------+
  | Auxiliary Bus      |<->| Auxiliary Device        |
  | Driver             |   | (created by Xe KMD)     |
  | (intel-mctp-       |   | - Contains mailbox_ops  |
  |  mailbox.c)        |   |                         |
  | drivers/net/mctp/  |   |                         |
  +--------------------+   +-------------------------+
                         |
              mailbox_ops (send/recv via MMIO)
                         |
  +--------------------------------------------------+
  |         Intel Mailbox MMIO Registers             |
  |    (Status, Data Registers via BAR)              |
  +--------------------------------------------------+
                         |
              Hardware Mailbox Interface
                         |
  +--------------------------------------------------+
  |             GPU / AMC Firmware                   |
  |       (PLDM Requester / Responder)               |
  |   Mailbox Handler --> MCTP Decode                |
  |       --> PLDM Processing                        |
  +--------------------------------------------------+


Pros:
    + Natively part of the MCTP stack.
    + Consistent with existing MCTP transport implementations
      such as mctp-i2c and mctp-i3c. Probe occurs naturally
      when the auxiliary device is created, following standard
      kernel device model patterns.
Cons:
    - Introduction of vendor specific cases along with current
      generic mctp entries

	
Open for other ideas and suggestions.

Note: This RFC is prepared with AI assistance (e.g. GitHub Copilot etc).

Badal Nilawar (1):
  xe/xe_mctp_mailbox: Add support for MCTP transport over mailbox

 drivers/gpu/drm/xe/Makefile          |   1 +
 drivers/gpu/drm/xe/xe_device.c       |   3 +
 drivers/gpu/drm/xe/xe_device_types.h |   4 +
 drivers/gpu/drm/xe/xe_mctp_mailbox.c | 186 +++++++++++++++++++++++++++
 drivers/gpu/drm/xe/xe_mctp_mailbox.h |  14 ++
 5 files changed, 208 insertions(+)
 create mode 100644 drivers/gpu/drm/xe/xe_mctp_mailbox.c
 create mode 100644 drivers/gpu/drm/xe/xe_mctp_mailbox.h

-- 
2.54.0


             reply	other threads:[~2026-05-04 19:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-04 19:34 Badal Nilawar [this message]
2026-05-04 19:34 ` [RFC PATCH 1/1] xe/xe_mctp_mailbox: Add support for MCTP transport over mailbox Badal Nilawar
2026-05-05  2:15   ` Jeremy Kerr
2026-05-05  8:23   ` Andy Shevchenko
2026-05-05  2:15 ` [RFC PATCH 0/1] Proposal for in-band firmware update over PLDM-MCTP Jeremy Kerr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260504193420.1232842-3-badal.nilawar@intel.com \
    --to=badal.nilawar@intel.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=anshuman.gupta@intel.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=davem@davemloft.net \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=edumazet@google.com \
    --cc=heikki.krogerus@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jacob.e.keller@intel.com \
    --cc=james.ausmus@intel.com \
    --cc=jk@codeconstruct.com.au \
    --cc=kelvin.gardiner@intel.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=matt@codeconstruct.com.au \
    --cc=matthew.brost@intel.com \
    --cc=michael.brooks@intel.com \
    --cc=michael.j.ruhl@intel.com \
    --cc=michal.winiarski@intel.com \
    --cc=mika.westerberg@linux.intel.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=przemyslaw.kitszel@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=singaravelan.nallasellan@intel.com \
    --cc=thomas.hellstrom@linux.intel.com \
    --cc=wojciech.drewek@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox