On 9/8/25 12:44, Adam Young wrote:

On 9/8/25 11:20, Sudeep Holla wrote:

quoted

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.

I will post an updated version of my patch series that starts to follows 
this second path.  I will not include the CPPC patch in there yet, as I 
need to get my head around what they are doing inside that driver.

Is there a forum in which I should cross post the Mailbox changes?  I 
plan on creating a new, mailbox API level  call back and I assume there 
will be a larger audience interested in reviewing that.