[RFC PATCH v2 00/12] greybus: introduce CPC as transport layer

Damien Riégel posted 12 patches 4 weeks, 1 day ago
MAINTAINERS                    |   6 +
drivers/greybus/Kconfig        |   2 +
drivers/greybus/Makefile       |   2 +
drivers/greybus/cpc/Kconfig    |  10 ++
drivers/greybus/cpc/Makefile   |   6 +
drivers/greybus/cpc/cpc.h      |  76 +++++++++
drivers/greybus/cpc/cport.c    | 107 ++++++++++++
drivers/greybus/cpc/header.c   | 146 +++++++++++++++++
drivers/greybus/cpc/header.h   |  54 +++++++
drivers/greybus/cpc/host.c     | 287 +++++++++++++++++++++++++++++++++
drivers/greybus/cpc/host.h     |  58 +++++++
drivers/greybus/cpc/protocol.c | 169 +++++++++++++++++++
12 files changed, 923 insertions(+)
create mode 100644 drivers/greybus/cpc/Kconfig
create mode 100644 drivers/greybus/cpc/Makefile
create mode 100644 drivers/greybus/cpc/cpc.h
create mode 100644 drivers/greybus/cpc/cport.c
create mode 100644 drivers/greybus/cpc/header.c
create mode 100644 drivers/greybus/cpc/header.h
create mode 100644 drivers/greybus/cpc/host.c
create mode 100644 drivers/greybus/cpc/host.h
create mode 100644 drivers/greybus/cpc/protocol.c
[RFC PATCH v2 00/12] greybus: introduce CPC as transport layer
Posted by Damien Riégel 4 weeks, 1 day ago
Hi,

This patchset brings support for Silicon Labs' CPC (Co-Processor
Communication) protocol as transport layer for Greybus. This is
introduced as a module that sits between Greybus and CPC Host Device
Driver implementations, like SDIO or SPI, which are not part of this
RFC. If there's no push back with this RFC, the final patchset ready for
upstream will include the SDIO driver.

The goal of this module is to implement some of the features of Unipro
that Greybus relies upon, like reliable transmission. CPC takes care of
detecting transmission errors and retransmit frames if necessary. That
feature is not part of the RFC to keep it concise, but it's planned for
a future patchset. There's also a flow-control feature, to prevent from
sending messages to cports that don't have anymore room.

In order to implement these features, a 4-byte header is prepended to
Greybus messages, making the whole header 12 bytes (Greybus header
itself being 8 bytes).

This RFC starts by implementing a shim layer that sits between physical
bus drivers (like SDIO and SPI) and Greybus, and progressively add more
elements to it to make it useful in its own right.

    +----------------------------------------------------+
    |                      Greybus                       |
    +----------------------------------------------------+
			     /|\
			      |
			     \|/
    +----------------------------------------------------+
    |                        CPC                         |
    +----------------------------------------------------+
	  /|\                /|\                /|\
	   |                  |                  |
	  \|/                \|/                \|/
      +----------+       +---------+       +-----------+
      |   SDIO   |       |   SPI   |       |   Others  |
      +----------+       +---------+       +-----------+


Changes in v2:
 - v1 included a new protocol for Bluetooth HCI, this has been dropped
   to focus on CPC itself
 - likewise, there was an SPI driver, it has been dropped of this RFC
   for the same reason
 - v1 introduced CPC in a big commit, this time it's been split in
   smaller commits to make review manageable

Damien Riégel (12):
  greybus: cpc: add minimal CPC Host Device infrastructure
  greybus: cpc: introduce CPC cport structure
  greybus: cpc: use socket buffers instead of gb_message in TX path
  greybus: cpc: pack cport ID in Greybus header
  greybus: cpc: switch RX path to socket buffers
  greybus: cpc: introduce CPC header structure
  greybus: cpc: account for CPC header size in RX and TX path
  greybus: cpc: add and validate sequence numbers
  greybus: cpc: acknowledge all incoming messages
  greybus: cpc: use holding queue instead of sending out immediately
  greybus: cpc: honour remote's RX window
  greybus: cpc: let host device drivers dequeue TX frames

 MAINTAINERS                    |   6 +
 drivers/greybus/Kconfig        |   2 +
 drivers/greybus/Makefile       |   2 +
 drivers/greybus/cpc/Kconfig    |  10 ++
 drivers/greybus/cpc/Makefile   |   6 +
 drivers/greybus/cpc/cpc.h      |  76 +++++++++
 drivers/greybus/cpc/cport.c    | 107 ++++++++++++
 drivers/greybus/cpc/header.c   | 146 +++++++++++++++++
 drivers/greybus/cpc/header.h   |  54 +++++++
 drivers/greybus/cpc/host.c     | 287 +++++++++++++++++++++++++++++++++
 drivers/greybus/cpc/host.h     |  58 +++++++
 drivers/greybus/cpc/protocol.c | 169 +++++++++++++++++++
 12 files changed, 923 insertions(+)
 create mode 100644 drivers/greybus/cpc/Kconfig
 create mode 100644 drivers/greybus/cpc/Makefile
 create mode 100644 drivers/greybus/cpc/cpc.h
 create mode 100644 drivers/greybus/cpc/cport.c
 create mode 100644 drivers/greybus/cpc/header.c
 create mode 100644 drivers/greybus/cpc/header.h
 create mode 100644 drivers/greybus/cpc/host.c
 create mode 100644 drivers/greybus/cpc/host.h
 create mode 100644 drivers/greybus/cpc/protocol.c

-- 
2.49.0

Re: [RFC PATCH v2 00/12] greybus: introduce CPC as transport layer
Posted by Damien Riégel 2 weeks, 4 days ago
Hi Greg, Johan, and Alex,

On Fri Nov 14, 2025 at 10:07 AM EST, Damien Riégel wrote:
> Hi,
>
> This patchset brings support for Silicon Labs' CPC (Co-Processor
> Communication) protocol as transport layer for Greybus. This is
> introduced as a module that sits between Greybus and CPC Host Device
> Driver implementations, like SDIO or SPI, which are not part of this
> RFC. If there's no push back with this RFC, the final patchset ready for
> upstream will include the SDIO driver.

Gentle poke about this RFC, I would really appreciate any kind of
feedback on it.

If it's too big I can try to make it smaller to make the review easier.
As we're committing to Greybus to enable the coexistence of different
radio stacks in one chip, we want to make sure we're heading in the
right direction and that our work has a chance to get upstreamed.


Thank you!
-- 
Damien
Re: [RFC PATCH v2 00/12] greybus: introduce CPC as transport layer
Posted by Greg Kroah-Hartman 2 weeks, 3 days ago
On Tue, Nov 25, 2025 at 10:26:36AM -0500, Damien Riégel wrote:
> Hi Greg, Johan, and Alex,
> 
> On Fri Nov 14, 2025 at 10:07 AM EST, Damien Riégel wrote:
> > Hi,
> >
> > This patchset brings support for Silicon Labs' CPC (Co-Processor
> > Communication) protocol as transport layer for Greybus. This is
> > introduced as a module that sits between Greybus and CPC Host Device
> > Driver implementations, like SDIO or SPI, which are not part of this
> > RFC. If there's no push back with this RFC, the final patchset ready for
> > upstream will include the SDIO driver.
> 
> Gentle poke about this RFC, I would really appreciate any kind of
> feedback on it.

Given my workload, I don't respond to "RFC" as obviously it's not ready
for the submitter to feel that it should be applied yet :)

> If it's too big I can try to make it smaller to make the review easier.
> As we're committing to Greybus to enable the coexistence of different
> radio stacks in one chip, we want to make sure we're heading in the
> right direction and that our work has a chance to get upstreamed.

Always make review easier for us, so yes, please make it smaller!

thanks,

greg k-h
Re: [RFC PATCH v2 00/12] greybus: introduce CPC as transport layer
Posted by Damien Riégel 1 week, 5 days ago
On Wed Nov 26, 2025 at 7:33 AM EST, Greg Kroah-Hartman wrote:
> On Tue, Nov 25, 2025 at 10:26:36AM -0500, Damien Riégel wrote:
>> Hi Greg, Johan, and Alex,
>>
>> On Fri Nov 14, 2025 at 10:07 AM EST, Damien Riégel wrote:
>> > Hi,
>> >
>> > This patchset brings support for Silicon Labs' CPC (Co-Processor
>> > Communication) protocol as transport layer for Greybus. This is
>> > introduced as a module that sits between Greybus and CPC Host Device
>> > Driver implementations, like SDIO or SPI, which are not part of this
>> > RFC. If there's no push back with this RFC, the final patchset ready for
>> > upstream will include the SDIO driver.
>>
>> Gentle poke about this RFC, I would really appreciate any kind of
>> feedback on it.
>
> Given my workload, I don't respond to "RFC" as obviously it's not ready
> for the submitter to feel that it should be applied yet :)

Noted, I'll send a non-RFC version of the patchset very soon!

>> If it's too big I can try to make it smaller to make the review easier.
>> As we're committing to Greybus to enable the coexistence of different
>> radio stacks in one chip, we want to make sure we're heading in the
>> right direction and that our work has a chance to get upstreamed.
>
> Always make review easier for us, so yes, please make it smaller!

I might have overpromised on this one :( I've already tried to limit the
scope of the patchset to be as small as possible while still being
meaningful and my goal was to add the SDIO driver to give the full
picture of what we're trying to achieve. I'll see if I can cut it down
even further.


Side note for list administrators: I can send patchset just fine with
git-send-email but posting to the list with my email client (aerc) gives
me every single time:

        The message is being held because:

            Message has implicit destination

I'm subscribed to the list and my emails seem to make it in the end (I
don't know if they are manually released or not). I looked up that error
message and I didn't find anything useful. Am I the only one having that
issue? Would be happy to find a solution.


Thank you,
-- 
Damien