linux-kernel - [RFC PATCH v2 06/12] greybus: cpc: introduce CPC header structure

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251114150738.32426-7-damien.riegel@silabs.com>
Date: Fri, 14 Nov 2025 10:07:32 -0500
From: Damien Riégel <damien.riegel@...abs.com>
To: greybus-dev@...ts.linaro.org, Johan Hovold <johan@...nel.org>,
        Alex Elder <elder@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org
Cc: Silicon Labs Kernel Team <linux-devel@...abs.com>,
        Damien Riégel <damien.riegel@...abs.com>
Subject: [RFC PATCH v2 06/12] greybus: cpc: introduce CPC header structure

CPC main features are reliable transmission and remote's receive window
management. To implement these features, an additional header is needed.
This header is prepended to all Greybus messages.

Reliable transmission: to make transmission reliable, messages are
sequenced and acknowledged. That constitutes two bytes of the header,
one for the sequence number, one for the acknowledgment number. If a
message is not acked in a timely manner, a retransmission mechanism will
attempt another transmission. That mechanism will be implemented in a
future patch set.

Remote's receive window: the remote advertises the number of reception
buffers that are available on this cport. The other peer must take care
of not sending more messages than advertised by the remote. This is a
sort of flow control. That accounts for one byte in the header.

The remaining byte carries some flags. For instance, there is a flag to
indicate if it's a CPC message or a Greybus message.

Signed-off-by: Damien Riégel <damien.riegel@...abs.com>
---
 drivers/greybus/cpc/header.h | 43 ++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)
 create mode 100644 drivers/greybus/cpc/header.h

diff --git a/drivers/greybus/cpc/header.h b/drivers/greybus/cpc/header.h
new file mode 100644
index 00000000000..84c47f105b3
--- /dev/null
+++ b/drivers/greybus/cpc/header.h
@@ -0,0 +1,43 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2025, Silicon Laboratories, Inc.
+ */
+
+#ifndef __CPC_HEADER_H
+#define __CPC_HEADER_H
+
+#include <linux/greybus.h>
+#include <linux/types.h>
+
+#define CPC_HEADER_MAX_RX_WINDOW	U8_MAX
+
+/**
+ * struct cpc header - Representation of CPC header.
+ * @ctrl_flags: contains the type of frame and other control flags.
+ * @recv_wnd: number of buffers that the cport can receive without blocking.
+ * @seq: sequence number.
+ * @ack: acknowledge number, indicate to the remote the next sequence number
+ *	 this peer expects to see.
+ *
+ * Each peer can confirm reception of frames by setting the acknowledgment number to the next frame
+ * it expects to see, i.e. setting the ack number to X effectively acknowledges frames with sequence
+ * number up to X-1.
+ *
+ * CPC is designed around the concept that each cport has its pool of reception buffers. The number
+ * of buffers in a pool is advertised to the remote via the @recv_wnd attribute. This acts as
+ * software flow-control, and a peer shall not send frames to a remote if the @recv_wnd is zero.
+ *
+ * The hight-bit (0x80) of the control byte indicates if the frame targets CPC or Greybus. If the
+ * bit is set, the frame should be interpreted as CPC control frames. For simplicity, control frames
+ * have the same encoding as Greybus frames.
+ */
+struct cpc_header {
+	__u8	ctrl_flags;
+	__u8	recv_wnd;
+	__u8	seq;
+	__u8	ack;
+} __packed;
+
+#define CPC_HEADER_SIZE			(sizeof(struct cpc_header))
+
+#endif
-- 
2.49.0