Message-ID: <bbe0a7fa-7c7e-4d59-839c-23e8fa55a750@amperemail.onmicrosoft.com>
Date: Mon, 8 Sep 2025 12:44:28 -0400
From: Adam Young <admiyo@...eremail.onmicrosoft.com>
To: Sudeep Holla <sudeep.holla@....com>
Cc: admiyo@...amperecomputing.com, Jassi Brar <jassisinghbrar@...il.com>,
 "Rafael J. Wysocki" <rafael@...nel.org>, Len Brown <lenb@...nel.org>,
 Robert Moore <robert.moore@...el.com>, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, Jeremy Kerr <jk@...econstruct.com.au>,
 Matt Johnston <matt@...econstruct.com.au>,
 "David S . Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
 Paolo Abeni <pabeni@...hat.com>,
 Jonathan Cameron <Jonathan.Cameron@...wei.com>,
 Huisong Li <lihuisong@...wei.com>
Subject: Re: [PATCH v23 1/2] mailbox/pcc: support mailbox management of the
 shared buffer


On 9/8/25 11:20, Sudeep Holla wrote:
> If you are really interesting to consolidating, then move all the buffer
> management into the core. Just don't introduce things that just work on
> your platform and for your use case. You need move all the drivers to this
> new model of accessing the buffers. Otherwise I see no point as it is just
> another churn but in core mailbox PCC driver instead of a client driver
> using PCC. So, I am not OK with the change as is and needs to be reworked
> or reverted. I need sometime to understand your email and requirements.

This is kindof a large request.  I can start working on getting the 
other drivers to use the common mechanisms, but I do not have a way to 
test most of them, and there are numerous drivers.  I don't like making 
changes that I cannot test myself, but if we can get the other driver 
maintainers to test and review, I am happy to participate.

I know we use the CPPC driver, and I can show how that one would be 
consolidated.

Here is a potential path forward:

1. Revert the current patch, specifically to remove the callback function.

2.  I will post a minimal patch for the change to the mailbox api

3.  I will post patches that modify the other drivers to pass NULL in to 
the send_message path.  These will need to be reviewed and tested by the 
other driver maintainers

4. I will post a revised patch that only performs the buffer management 
for the send path.  This is essential for the MCTP over PCC driver, and 
for anything that wants to follow the PCC spec correctly.  This will 
remove pcc_mchan->manage_writes = false; This path will be triggered by 
passing a non-NULL pointer into the send data path. This is roughly half 
to the current patch.

5.  I will post a revised patch that makes use of the mailbox API 
callback defined in step 2 to allocate the memory used for the read stage.

6.I will repost my MCTP over PCC driver  that makes  use  of the updated 
patches.

Any point after step 3, we can start migrating the drivers to use the 
send mechanism.  After step 5 we can migrate the drivers to use the 
receive mechanism.


A shorter path forward would be:

1.   I will post a minimal patch for the change to the mailbox api

2. I will post a revised PCC Mailbox patch that makes use of the 
callback function, as well as an updated MCTP-PCC driver that makes use 
of that callback.  We deprecate the existing rx_alloc callback in the 
PCC Mailbox driver and ignore it in the PCC Mailbox.

3. Convert the other drivers to use the managed send/receive mechanism.

4.  Remove the flag pcc_mchan->manage_writes

I will stay engaged through the entire process, to include providing 
patches for the updated drivers, testing whatever I have access to, and 
reviewing all code that comes along these paths. I obviously prefer the 
shorter path, as it will allow me to get the MCTP-PCC driver merged. My 
team is going to be writing another, similar Mailbox implementation to 
the PCC mailbox. The more common behavior between the two 
implementations, the less code we will have to vary between drivers that 
make use of the mailboxes.

Powered by blists - more mailing lists