subsys: usb: host: support for usb host cdc-ecm class by D-Veda · Pull Request #100289 · zephyrproject-rtos/zephyr

D-Veda · 2025-12-01T10:03:47Z

Dependencies:

This implementation contains all commits from #94590 and in addition:

Add CDC-ECM class driver usbh_cdc_ecm.c
Add ethernet network interface support for USB host

github-actions · 2025-12-01T10:04:29Z

Hello @D-Veda, and thank you very much for your first pull request to the Zephyr project!
Our Continuous Integration pipeline will execute a series of checks on your Pull Request commit messages and code, and you are expected to address any failures by updating the PR. Please take a look at our commit message guidelines to find out how to format your commit messages, and at our contribution workflow to understand how to update your Pull Request. If you haven't already, please make sure to review the project's Contributor Expectations and update (by amending and force-pushing the commits) your pull request if necessary.
If you are stuck or need help please join us on Discord and ask your question there. Additionally, you can escalate the review when applicable. 😊

maass-hamburg · 2025-12-01T10:35:04Z

@@ -0,0 +1,1157 @@
+/*


this is a ethernet driver, so it belongs in drivers/ethernet/. I know there are already others there, but these should probably be moved too. I don't like ethernet drivers and its api be scattered all over the tree. (should be limited to the ethernet and wifi drivers and the net subsystem)

this is blocking

It seems like a bit of discussion would help to decide:

Where USB classes (host/device) that implement a driver API are implemented. This would imply most USB classes move, or it would be an exception just for CDC-ECM.

Whether source in drivers/ are allowed to call functions from subsystem/. I've not seen anything in the doc but suspect this could interest several parties to review which model to use.

How about pursuing with the implementation details in the meantime that the location of tes code is discussed?

Thank you for the review!

Drivers are allowed to use subsystems.

For example there is the random subsystem subsys/random/, it implements /include/zephyr/random/random.h, which includes sys_rand_get(). Btw the random subsystem uses the entropy_driver_api, if that is selected to be the source of randomness.

For the ethernet drivers, we have a common dt prop zephyr,random-mac-address if that is set, the ethernet mac address is randomly generated with sys_rand_get() during the init of the ethernet driver.

Other example are sd cards in zephyr. (that might be similar enough to usb, as it also has a sd subsystem above the sdhc drivers and api)

The sd card or disk (dt compatible zephyr,sdmmc-disk, drivers/disk/sdmmc_subsys.c) implements the disk api (zephyr/drivers/disk.h) and uses the SD subsystem (subsys/sd) and that uses the sdhc drivers (include/zephyr/drivers/sdhc.h).

We also have drivers for a SDIO wifi card in tree, which uses the sd subsystem it is in
drivers/wifi/infineon/airoc_whd_hal_sdio.c and not in subsys/sd.

Even bigger: We have a crypto device api and one of the drivers is zephyr/drivers/crypto/crypto_mbedtls_shim.c and it is using mbedTLS, which even is a separate module.

Drivers can use anything what they need.

Another thing is control and ensuring quality. There is a reason we have Driver Areas in the maintainers.yml and that in addition to the vendor specific areas for their drivers.
For this PR I wasn't added because I'm the ethernet maintainer, no it was just because I'm also a collaborator for DHCP in the networking subsystem and it's sample got changed.

How about pursuing with the implementation details in the meantime that the location of tes code is discussed?

Sure

Thank you for your overview of driver <-> subsystem dependencies. I think I heard this "subsystem/driver" split about a particular driver, not as a general guideline.

For this PR I wasn't added because I'm the ethernet maintainer, no it was just because I'm also a collaborator for DHCP in the networking subsystem and it's sample got changed.

Regardless the solution, there would need to make sure that MAINTAINERS.yml pings correctly everyone involved.

@jfischer-no can you please share your thoughts on the location of this driver.

All the USB host class drivers that use USBH class driver API and implement a USB class specification or other very well known standard must be placed in subsys/usb/host/class. Similar to what we do with USB device support.

Also, considering that there is not even an Ethernet controller driver API, the complaints and claims here are absolutely unfounded and inappropriate.

The commit usb: host: class: cdc_ecm: Add CDC-ECM host class driver implementation places correctly a new USB host CDC ECM driver in subsys/usb/host/class.

All the USB host class drivers are drivers and as such should not be in subsys/* but instead in drivers/*

carlescufi · 2026-04-16T13:00:15Z

Architecture WG meeting:

@maass-hamburg says that drivers that implements a driver API should be located in drivers/, so in this case, drivers/ethernet
@jfischer-no counters that the USB stack is well layered today and the USB class code belongs in subsys/usb
Discussion
@maass-hamburg says that you place the driver based on the API it implements, so it belongs in drivers/
@pdgendt says that if it's described in Devicetree and should act as a driver with struct device it belongs in drivers/. There are also checks that rely on drivers being in the drivers/ path. The fact that the drivers are mostly made of USB code is not an argument, because that also true for native_sim drivers
@fabiobaltieri mentions that Linux has them in drivers/usb/class/, and not in drivers/serial or drivers/ethernet, probably because of maintainership. @fabiobaltieri thinks the current structure subsys/usb/class is fine
@nordicjm draws a parallelism with the retained memory and the retention subsystem. Prefers having it in subsys/ since it's a virtual device
@maass-hamburg mentions that vendors have files all over the tree, and this should be consistent with USB as well. In the end is a real driver, even though the device is virtual
@jfischer-no rejects the arguments, and focuses on the fact that most code is related to USB

maass-hamburg · 2026-04-16T11:41:10Z

@@ -0,0 +1,1157 @@
+/*


All the USB host class drivers are drivers and as such should not be in subsys/* but instead in drivers/*

maass-hamburg · 2026-04-20T08:52:08Z

+	max_segment_size = ctx->max_segment_size;
+	k_mutex_unlock(&ctx->mutex);
+
+	total_len = net_buf_frags_len(buf);
+	if (total_len > max_segment_size || total_len > CONFIG_USBH_CDC_ECM_DATA_BUF_POOL_SIZE) {
+		return -EMSGSIZE;
+	}
+
+	tx_buf = net_buf_alloc(&usbh_cdc_ecm_data_pool, K_NO_WAIT);
+	if (tx_buf == NULL) {
+		LOG_WRN("failed to allocate data buffer for transmitting");
+		return -ENOMEM;
+	}
+
+	if (net_buf_linearize(tx_buf->data, net_buf_tailroom(tx_buf), buf, 0, total_len) !=
+	    total_len) {
+		LOG_ERR("data linearization failed for transmitting");
+		ret = -EIO;
+		goto cleanup;
+	}
+
+	net_buf_add(tx_buf, total_len);
+
+	ret = usbh_cdc_ecm_start_data_out_xfer(ctx, tx_buf);
+	if (ret != 0) {
+		goto cleanup;
+	}
+
+	return 0;
+
+cleanup:
+	if (tx_buf != NULL) {
+		net_buf_unref(tx_buf);
+	}
+


leave it for now.

But for the non-cachable memory, these host controller drivers should instead add cache management functions in the future

josuah

Sorry for this very incomplete review as I am short on time today.

#99097 (comment) does not seem to be interested in modifying his PR to make it closer to this one. Would you be interested in trying to rebase your PR on top of his content?

If finding modifications needed to #99097, they could then be submitted as review comments to his PR.

josuah

Some various feedback around queued_xfers.list, which can hopefully be avoided.

D-Veda · 2026-05-04T17:03:57Z

The latest CDC-ECM implementation has improved the following issues

Reduce the use of mutexes, hold locks only in necessary competitive environments, and use atomic flags in USB callbacks to avoid data contention
Refine and streamline the descriptor matching mechanism
Simplify the MAC address query mechanism by first querying according to the default LANGID, and then obtain the LANGID in turn if it fails
Improve the two-way concurrency mechanism, interrupt in multiplexes xfer and associated buf, bulk IN multiplexes xfer, only when data needs to be forwarded to the Ethernet protocol stack to assign new buf associated with xfer, bulk out callback multiplexes xfer to trigger ZLP transmission
All Ethernet interface operations implement error rollback operations (e.g., set packet filter / multicast filter fails, rolling back the previous value)
Streamline the xfer recycling mechanism, only when the dequeue triggers the callback, the xfer will be released, and the rest of the cases are just paused xfer, canceling the dlist tracking mechanism
Streamlined implementation of multicast filters/statistics, updated CDC-ECM statistics-related macros

maass-hamburg · 2026-05-04T17:16:45Z

+static void carrier_work_handler(struct k_work *work)
+{
+	struct k_work_delayable *dwork = k_work_delayable_from_work(work);
+	struct carrier_work_ctx *const carrier_work =
+		CONTAINER_OF(dwork, struct carrier_work_ctx, dwork);
+	struct cdc_ecm_host_data *const host_data =
+		CONTAINER_OF(carrier_work, struct cdc_ecm_host_data, carrier_work);
+	int state;
+
+	state = atomic_set(&carrier_work->pending_state, CDC_ECM_DEVICE_WORK_CARRIER_STATE_NONE);
+
+	if (!atomic_test_bit(&host_data->flags, CDC_ECM_DEVICE_FLAG_CONNECTED) ||
+	    !atomic_test_bit(&host_data->flags, CDC_ECM_DEVICE_FLAG_FORWARDING)) {
+		return;
+	}
+
+	switch (state) {
+	case CDC_ECM_DEVICE_WORK_CARRIER_STATE_ON:
+		LOG_DBG("Carrier ON (deferred)");
+		net_eth_carrier_on(host_data->eth_iface);
+		break;
+
+	case CDC_ECM_DEVICE_WORK_CARRIER_STATE_OFF:
+		LOG_DBG("Carrier OFF (deferred)");
+		net_eth_carrier_off(host_data->eth_iface);
+		break;
+
+	default:
+		break;
+	}
+}


why is this in a work queue?
net_eth_carrier_on and net_eth_carrier_off should be called directly

Here’s the issue: if a network device supports the ETHERNET_HW_FILTERING feature, and the USB host’s interrupt IN callback in the USB subsystem receives a link-switching notification from the USB device, then if net_eth_carrier_on() is called directly, the network subsystem will directly invoke the code in the ETHERNET_CONFIG_TYPE_FILTER section of .set_config and this code, in turn, calls the USB host’s control transfer function usbh_req_setup(). Thus, the overall call logic is equivalent to triggering a USB control transfer within the USB transfer callback. However, since the usbh_req_setup() is a synchronous API, the thread containing the USB callback will remain blocked until the synchronous usbh_req_setup() API completes, and since the callback triggered by usbh_req_setup is also in the current coroutine, this causes the usbh_req_setup() triggered within the transfer callback to always return a timeout.

@josuah Is it possible to improve the implementation of usbh_req_setup() to support calling it from within a USB transfer callback? If not, is there a better solution here?

Have you tested it?

because that is the implementation of net_eth_carrier_on and net_eth_carrier_off:

zephyr/subsys/net/l2/ethernet/ethernet.c

Lines 895 to 912 in c855ede

void net_eth_carrier_on(struct net_if *iface)

{

struct ethernet_context *ctx = net_if_l2_data(iface);

if (!atomic_test_and_set_bit(&ctx->flags, ETH_CARRIER_UP)) {

k_work_submit(&ctx->carrier_work);

}

}

void net_eth_carrier_off(struct net_if *iface)

{

struct ethernet_context *ctx = net_if_l2_data(iface);

if (atomic_test_and_clear_bit(&ctx->flags, ETH_CARRIER_UP)) {

k_work_submit(&ctx->carrier_work);

}

}

the network subsystem itself uses a workqueue for the real action

there is a difference between net_eth_carrier_on and net_if_carrier_on

I checked it locally, directly call can work without issue. Now the work queue is removed. Thanks for the reminder.

maass-hamburg · 2026-05-04T17:22:37Z

+	if (is_broadcast) {
+		atomic_add(&host_data->stats[USB_CDC_ECM_STAT_BROADCAST_BYTES_RCV], buf_len);
+		atomic_inc(&host_data->stats[USB_CDC_ECM_STAT_BROADCAST_FRAMES_RCV]);
+	} else if (is_multicast) {
+		atomic_add(&host_data->stats[USB_CDC_ECM_STAT_MULTICAST_BYTES_RCV], buf_len);
+		atomic_inc(&host_data->stats[USB_CDC_ECM_STAT_MULTICAST_FRAMES_RCV]);
+	} else {
+		atomic_add(&host_data->stats[USB_CDC_ECM_STAT_DIRECTED_BYTES_RCV], buf_len);
+		atomic_inc(&host_data->stats[USB_CDC_ECM_STAT_DIRECTED_FRAMES_RCV]);
+	}
+#endif
+
+	return 0;


is this needed we already collect these stats in

zephyr/subsys/net/l2/ethernet/ethernet.c

Lines 167 to 182 in 7d0ba33

static void ethernet_update_rx_stats(struct net_if *iface, size_t length,

bool dst_broadcast, bool dst_eth_multicast)

{

if (!IS_ENABLED(CONFIG_NET_STATISTICS_ETHERNET)) {

return;

}

eth_stats_update_bytes_rx(iface, length);

eth_stats_update_pkts_rx(iface);

if (dst_broadcast) {

eth_stats_update_broadcast_rx(iface);

} else if (dst_eth_multicast) {

eth_stats_update_multicast_rx(iface);

}

}

(via net_recv_data)

maass-hamburg · 2026-05-04T17:28:37Z

+}
+
+#if defined(CONFIG_NET_STATISTICS_ETHERNET)
+static struct net_stats_eth *eth_get_stats(const struct device *dev, struct net_if *iface)


the returned struct net_stats_eth pointer is not only for reading, but also for saving. take a look at subsys/net/l2/ethernet/eth_stats.h

your export_statistics works only for reading.

you need to provide a mutable struct net_stats_eth here.

also don't do double work, please check wich fields are already filled by the networking subsystem.

maass-hamburg · 2026-05-04T17:31:03Z

+#if defined(CONFIG_NET_STATISTICS_ETHERNET)
+	if (buf_len > 0) {
+		atomic_inc(&host_data->stats[USB_CDC_ECM_STAT_XMIT_OK]);
+
+		if (is_broadcast) {
+			atomic_add(&host_data->stats[USB_CDC_ECM_STAT_BROADCAST_BYTES_XMIT],
+				   buf_len);
+			atomic_inc(&host_data->stats[USB_CDC_ECM_STAT_BROADCAST_FRAMES_XMIT]);
+		} else if (is_multicast) {
+			atomic_add(&host_data->stats[USB_CDC_ECM_STAT_MULTICAST_BYTES_XMIT],
+				   buf_len);
+			atomic_inc(&host_data->stats[USB_CDC_ECM_STAT_MULTICAST_FRAMES_XMIT]);
+		} else {
+			atomic_add(&host_data->stats[USB_CDC_ECM_STAT_DIRECTED_BYTES_XMIT],
+				   buf_len);
+			atomic_inc(&host_data->stats[USB_CDC_ECM_STAT_DIRECTED_FRAMES_XMIT]);
+		}
+	}
+#endif


maass-hamburg · 2026-05-04T17:40:40Z

Just to mention, not every optional feature needs to be in the initial PR, for example statistics are not needed for networking to work. it is a nice to have and can be added in a later PR. If you really want it in here, put it in its own commit.

D-Veda · 2026-05-04T19:07:49Z

Just to mention, not every optional feature needs to be in the initial PR, for example statistics are not needed for networking to work. it is a nice to have and can be added in a later PR. If you really want it in here, put it in its own commit.

The statistics part feature is moved out now.

Updates: - Add Ethernet Statistics Feature Selector marcos - Add CONNECTION_SPEED_CHANGE notification macro - Add Ethernet Power Management Pattern activation macros Signed-off-by: Dv Alan <zhangyang.shen@nxp.com>

Add 4 functions to handle USB string descriptor operations: - usbh_req_desc_str() to retrieve USB string descriptors from device - usbh_desc_is_valid_string() to validate string descriptor type - usbh_desc_get_supported_langs() to get supported languages list - usbh_desc_str_utfle16_to_ascii() to convert UTF-16LE string to ASCII Co-authored-by: Johann Fischer <johann.fischer@nordicsemi.no> Signed-off-by: Dv Alan <zhangyang.shen@nxp.com>

Implements USB CDC-ECM standard protocol and integrates USB-to-Ethernet devices as network interfaces into Zephyr network stack Co-authored-by: Santhosh Charles <santhosh@linumiz.com> Signed-off-by: Dv Alan <zhangyang.shen@nxp.com>

sonarqubecloud · 2026-05-06T09:47:07Z

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

zephyrbot added area: Tests Issues related to a particular existing or missing test platform: NXP NXP area: Boards/SoCs area: Devicetree Bindings area: USB Universal Serial Bus area: Networking area: Samples Samples area: Devicetree labels Dec 1, 2025

zephyrbot requested review from JarmouniA, MarkWangChinese, dbaluta, decsny, dleach02, jfischer-no, josuah, jukkar, maass-hamburg, manuargue, mmahadevan108, nashif, rlubos, rruuaanng and tmon-nordic December 1, 2025 10:05

zephyrbot assigned jfischer-no Dec 1, 2025

D-Veda changed the title ~~Usbh cdc ecm support subsys: usb: host: Add USB Host CDC ECM Class Support for Ethernet~~ subsys: usb: host: support for usb host cdc-ecm class Dec 1, 2025

jukkar removed their request for review December 1, 2025 10:15

maass-hamburg requested changes Dec 1, 2025

View reviewed changes

D-Veda marked this pull request as draft December 1, 2025 10:42

maass-hamburg requested changes Dec 1, 2025

View reviewed changes

Comment thread subsys/usb/host/class/usbh_cdc_ecm.c Outdated

Comment thread subsys/usb/host/class/usbh_cdc_ecm.c Outdated

Comment thread subsys/usb/host/class/usbh_cdc_ecm.c Outdated

Comment thread subsys/usb/host/class/usbh_cdc_ecm.c Outdated

jfischer-no added this to the v4.5.0 milestone Apr 16, 2026

D-Veda force-pushed the usbh_cdc_ecm_support branch from 7f51652 to e67d72b Compare April 20, 2026 06:04

maass-hamburg reviewed Apr 20, 2026

View reviewed changes

carlescufi moved this from Todo to In Progress in Architecture Review Apr 20, 2026

josuah reviewed Apr 24, 2026

View reviewed changes

Comment thread include/zephyr/usb/class/usb_cdc.h Outdated

josuah reviewed Apr 24, 2026

View reviewed changes

Comment thread subsys/usb/host/class/usbh_cdc_ecm.c Outdated

josuah reviewed Apr 24, 2026

View reviewed changes

Comment thread subsys/usb/host/class/usbh_cdc_ecm.c Outdated

josuah mentioned this pull request Apr 24, 2026

subsys: usb: host: Add USB Host CDC ECM Class Support for Ethernet #99097

Open

MarkWangChinese mentioned this pull request Apr 27, 2026

MAINTAINERS: Add MarkWangChinese as collaborator for USB #107904

Merged

josuah reviewed Apr 28, 2026

View reviewed changes

Comment thread subsys/usb/host/class/usbh_cdc_ecm.c

Comment thread subsys/usb/host/class/usbh_cdc_ecm.c Outdated

Comment thread subsys/usb/host/class/usbh_cdc_ecm.c Outdated

Comment thread subsys/usb/host/class/usbh_cdc_ecm.c Outdated

Comment thread subsys/usb/host/class/usbh_cdc_ecm.c Outdated

josuah reviewed Apr 29, 2026

View reviewed changes

Comment thread subsys/usb/host/class/usbh_cdc_ecm.c Outdated

Comment thread subsys/usb/host/class/usbh_cdc_ecm.c Outdated

Comment thread subsys/usb/host/class/usbh_cdc_ecm.c Outdated

kartben assigned tmon-nordic May 4, 2026

D-Veda force-pushed the usbh_cdc_ecm_support branch from e67d72b to 2561c10 Compare May 4, 2026 15:33

D-Veda requested review from josuah and maass-hamburg May 4, 2026 15:37

D-Veda force-pushed the usbh_cdc_ecm_support branch from 2561c10 to 01dfed3 Compare May 4, 2026 17:02

D-Veda force-pushed the usbh_cdc_ecm_support branch from 01dfed3 to 5822aa9 Compare May 4, 2026 17:23

maass-hamburg requested changes May 4, 2026

View reviewed changes

D-Veda force-pushed the usbh_cdc_ecm_support branch from 5822aa9 to 9aac218 Compare May 4, 2026 19:06

D-Veda requested a review from maass-hamburg May 4, 2026 19:13

maass-hamburg reviewed May 4, 2026

View reviewed changes

Comment thread subsys/usb/host/class/usbh_cdc_ecm.c Outdated

Comment thread subsys/usb/host/class/usbh_cdc_ecm.c Outdated

D-Veda force-pushed the usbh_cdc_ecm_support branch from 9aac218 to e5acb05 Compare May 4, 2026 19:56

D-Veda and others added 3 commits May 6, 2026 17:06

usb: class: cdc: Add ECM related macros

9b100f1

Updates: - Add Ethernet Statistics Feature Selector marcos - Add CONNECTION_SPEED_CHANGE notification macro - Add Ethernet Power Management Pattern activation macros Signed-off-by: Dv Alan <zhangyang.shen@nxp.com>


	void net_eth_carrier_on(struct net_if *iface)
	{
	struct ethernet_context *ctx = net_if_l2_data(iface);

	if (!atomic_test_and_set_bit(&ctx->flags, ETH_CARRIER_UP)) {
	k_work_submit(&ctx->carrier_work);
	}
	}

	void net_eth_carrier_off(struct net_if *iface)
	{
	struct ethernet_context *ctx = net_if_l2_data(iface);

	if (atomic_test_and_clear_bit(&ctx->flags, ETH_CARRIER_UP)) {
	k_work_submit(&ctx->carrier_work);
	}
	}


	static void ethernet_update_rx_stats(struct net_if *iface, size_t length,
	bool dst_broadcast, bool dst_eth_multicast)
	{
	if (!IS_ENABLED(CONFIG_NET_STATISTICS_ETHERNET)) {
	return;
	}

	eth_stats_update_bytes_rx(iface, length);
	eth_stats_update_pkts_rx(iface);
	if (dst_broadcast) {
	eth_stats_update_broadcast_rx(iface);
	} else if (dst_eth_multicast) {
	eth_stats_update_multicast_rx(iface);
	}
	}

Conversation

D-Veda commented Dec 1, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

github-actions Bot commented Dec 1, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

maass-hamburg Dec 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

josuah Dec 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

carlescufi commented Apr 16, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

josuah left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

josuah left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

D-Veda commented May 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

maass-hamburg commented May 4, 2026

Uh oh!

D-Veda commented May 4, 2026

Uh oh!

D-Veda commented Dec 1, 2025 •

edited

Loading

maass-hamburg Dec 3, 2025 •

edited

Loading

josuah Dec 3, 2025 •

edited

Loading

D-Veda commented May 4, 2026 •

edited

Loading