Message-ID: <c9f9d997-1844-4628-bc30-bff8725ef75c@amperemail.onmicrosoft.com>
Date: Fri, 12 Sep 2025 11:54:56 -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 12:44, Adam Young wrote:
>
> 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.
>
>
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.


>
>

Powered by blists - more mailing lists