Re: [PATCH v3 14/14] greybus: cpc: add CPC SDIO host driver

[Damien Riégel]

On Fri Feb 13, 2026 at 4:35 AM EST, Jérôme Pouiller wrote:
> Hello Damien,
>
> On Thursday 12 February 2026 15:43:52 Central European Standard Time Damien Riégel wrote:
>> From: Gabriel Beaulieu <gabriel.beaulieu@xxxxxxxxxx>
>> 
>> This introduces a new module gb-cpc-sdio, in order to communicate with a
>> Greybus CPC device over SDIO.
>> 
>> Most of the complexity stems from aggregation: packets are aggregated to
>> minimize the number of CMD53s. In the first block, the first le32 is the
>> number of packets in this transfer. Immediately after that are all the
>> packet headers (CPC + Greybus). This lets the device process all the
>> headers in a single interrupt, and prepare the ADMA descriptors for all
>> the payloads in one go.
>> 
>> Payloads start at the beginning of the second block and are concatained.
>> Their lengths must be 32-bit aligned, so the driver takes care of adding
>> and removing padding if necessary.
>> 
>> Signed-off-by: Gabriel Beaulieu <gabriel.beaulieu@xxxxxxxxxx>
>> Signed-off-by: Damien Riégel <damien.riegel@xxxxxxxxxx>
>> ---
>> Changes in v3:
>>   - rework defines to group together address-related defines and remove
>>     orphaned value
>>   - remove trivial comments
>>   - all RX and TX are now done from the workqueue. In previous
>>     iterations, transfers could either be done from the threaded IRQ or
>>     from the workqueue.
>>   - remove erroneous SDIO VID/PID
>>   - remove padding between headers and payloads when aggregating
>> 
>> Changes in v2:
>>   - change formatting from %lu to %zu when printing size_t's
>>   - remove "/**" kernel-doc marker for static functions not actually
>>     using the kernel-doc format
>>   - reduce header inclusion list
>>   - use reverse christmas tree variable declarations consistently
>>   - update aggregation functions to try to be more legible
>>   - use define instead of constant value 0x0C for the address where to
>>     read the number of bytes the device wants to send
>> 
>>  drivers/greybus/cpc/Kconfig  |  12 +
>>  drivers/greybus/cpc/Makefile |   3 +
>>  drivers/greybus/cpc/sdio.c   | 480 +++++++++++++++++++++++++++++++++++
>>  3 files changed, 495 insertions(+)
>>  create mode 100644 drivers/greybus/cpc/sdio.c
>> 
> [...]
>> +static const struct sdio_device_id sdio_ids[] = {
>> +	/* No official ID */
>> +	{ SDIO_DEVICE(0x0000, 0x1000), },
>
> Can you provide some details about how it's work? I assume Silabs sells
> OEM products and each vendor has to set their own VID/PID, that's it?
>
> I assume Silabs also has samples products. How it works for them? Is
> there a default VID/PID or the sample firmware won't compile until the
> user changes the VID/PID?

That's not something we have defined yet, but I think we could at least
define one VID/PID for "Greybus/CPC compatible devices", that every
vendor could use if they don't make any changes to the protocol. Each
vendor would have to create the manifest based on their products (like
enable WiFi for product X, enable WiFi & Bluetooth for product Y).

> In any case, I believe we can't publish a driver with VID = 0.

Noted, the patchset can't be applied as is. I'll check what the process
is to assign a VID/PID.

> (BTW, I suggest to include linux-mmc@xxxxxxxxxxxxxxx as recipient of
> this PR).

I decided to wait a bit to avoid creating noise on linux-mmc,
considering this patchset is still in early review phase, but I'll add
that list for future versions.

thanks,
damien