Hello everyone,
I’ve recently been experimenting with chaining multiple Greybus nodes to
a single host over I²C (QWIIC port [0]). This general idea is not new
(see MicroMod Qwiic Pro Kit [1]), although those setups do not use Greybus.
Since I²C does not allow a slave to initiate transfers, it is not well
suited for node-initiated events (e.g. interrupts, SVC-initiated
control). However, for my current use case I am primarily interested in
polling-based functionality, so this limitation is acceptable.
In a typical Greybus topology, an Application Processor (AP), an SVC,
and one or more modules are connected via UniPro. In practice, because
most application processors lack a native UniPro interface, they connect
through a bridge device that also implements the SVC.
For the I²C-based setup described above, I have considered the following
topologies:
1. Separate co-processor (SVC/Bridge)
This approach is reasonable on SoCs such as TI AM6254, which include
an M4F core that can serve as the SVC/bridge and control the I²C bus.
However, on devices like TI AM62L, which lack such a core, introducing
an additional processor solely for Greybus does not seem justified.
Also, this would make the above much less portable, since it expects a
hardware component, not all BeagleBoard.org boards have.
```
+----+ +---------------+ +----------+
| AP | <--- bus ----> | SVC / Bridge | <--- I2C ----> |
Module |
+----+ +---------------+ +----------+
|
| +----------+
`----------- I2C ----> | Module |
+----------+
```
2. SVC per node
Each node implements its own SVC. Since an I²C slave cannot initiate
communication, the AP must already know the address of each SVC/module.
This also seems inefficient when chaining multiple nodes.
```
+----+ +----------------+
| AP | <--- I2C ---> | SVC / Module |
+----+ +----------------+
|
| +----------------+
`---- I2C ----> | SVC / Module |
+----------------+
```
3. SVC/Bridge functionality inside the AP
For this use case, this seems to be the most practical option.
To clarify, I am not proposing any new data paths in the Greybus
pipeline. The idea is to have a reusable an SVC/bridge implementation
similar to what exists in greybus-zephyr [2][3], but hosted within the AP.
```
+-------------+ +-----------+
| AP / SVC | <--- I2C ---> | Module |
+-------------+ +-----------+
|
| +----------+
`-- I2C ---> | Module |
+----------+
```
Before proceeding further, I would appreciate feedback on this
approach—particularly whether there are concerns with option 3, or if
there are alternative designs I should consider.
Best regards,
Ayush Singh
[0]: https://www.sparkfun.com/qwiic
[1]:
https://www.digikey.in/en/maker/projects/micromod-qwiic-pro-kit-project-gui…
[2]:
https://github.com/beagleboard/greybus-zephyr/blob/main/subsys/greybus/svc.…
[3]:
https://github.com/beagleboard/greybus-zephyr/blob/main/subsys/greybus/apbr…
When `flashing_mode` is set, `gb_tty_receive()` routes incoming bytes to
`cc1352_bootloader_rx()`. That helper appends the new bytes to the shared
`rx_buffer` with `memcpy()` but does not check that the chunk fits in the
remaining space first. The normal HDLC receive path already enforces
`MAX_RX_HDLC`, so do the same here before appending bootloader data.
If a packet would overflow the receive buffer, drop it and reset the
bootloader receive state instead of copying past the end of `rx_buffer`.
Signed-off-by: Pengpeng Hou <pengpeng(a)iscas.ac.cn>
---
drivers/greybus/gb-beagleplay.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/greybus/gb-beagleplay.c b/drivers/greybus/gb-beagleplay.c
index 87186f891a6a..bca3132adacd 100644
--- a/drivers/greybus/gb-beagleplay.c
+++ b/drivers/greybus/gb-beagleplay.c
@@ -535,6 +535,12 @@ static size_t cc1352_bootloader_rx(struct gb_beagleplay *bg, const u8 *data,
int ret;
size_t off = 0;
+ if (count > sizeof(bg->rx_buffer) - bg->rx_buffer_len) {
+ dev_err_ratelimited(&bg->sd->dev, "Bootloader RX buffer overflow");
+ bg->rx_buffer_len = 0;
+ return count;
+ }
+
memcpy(bg->rx_buffer + bg->rx_buffer_len, data, count);
bg->rx_buffer_len += count;
--
2.50.1 (Apple Git-155)
From: Sanjay Chitroda <sanjayembeddedse(a)gmail.com>
Hi all,
This patch series replaces manual cleanup and explicit kfree() calls with
the __free attribute from <linux/cleanup.h>. This modernizes the memory
management style and simplifies common error paths without altering any
functional behavior.
The __free attribute provides automatic scope-based cleanup, making
resource management clearer and reducing the chances of missing cleanup
on early returns.
No functional changes are intended in this series.
Testing:
- Compiled with W=1
- Build-tested on i86_64
Based on:
<linux-v7.0-rc2>
Feel free to share your valuable input in context of the cleanup API.
Thanks,
Sanjay Chitroda
Sanjay Chitroda (7):
staging: greybus: simplify cleanup using __free
iio: ssp_sensors: simplify cleanup using __free
iio: st_sensors: simplify cleanup using __free
media: mediatek: vcodec: simplify cleanup using __free
media: chips-media: coda: simplify cleanup using __free
media: allegro: simplify cleanup using __free
staging: rtl8723bs: simplify cleanup using __free
drivers/iio/common/ssp_sensors/ssp_spi.c | 9 +-
.../iio/common/st_sensors/st_sensors_core.c | 7 +-
.../media/platform/allegro-dvt/allegro-core.c | 95 +++++--------------
.../platform/chips-media/coda/coda-bit.c | 4 +-
.../platform/chips-media/coda/coda-jpeg.c | 39 ++++----
.../mediatek/vcodec/common/mtk_vcodec_dbgfs.c | 3 +-
drivers/staging/greybus/camera.c | 27 ++----
drivers/staging/greybus/loopback.c | 35 +++-----
drivers/staging/greybus/raw.c | 6 +-
.../staging/rtl8723bs/hal/rtl8723b_hal_init.c | 13 +--
drivers/staging/rtl8723bs/hal/sdio_ops.c | 37 ++------
11 files changed, 78 insertions(+), 197 deletions(-)
--
2.34.1