lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <DEMZRMIAGULC.3R4S53KVQRCH8@silabs.com>
Date: Mon, 01 Dec 2025 10:39:50 -0500
From: Damien Riégel <damien.riegel@...abs.com>
To: "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>
Cc: <greybus-dev@...ts.linaro.org>, "Johan Hovold" <johan@...nel.org>,
        "Alex
 Elder" <elder@...nel.org>, <linux-kernel@...r.kernel.org>,
        "Silicon Labs
 Kernel Team" <linux-devel@...abs.com>
Subject: Re: [RFC PATCH v2 00/12] greybus: introduce CPC as transport layer

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ