From: Ravi Gunasekaran <r-gunasekaran@ti.com>
TI's K3 SoCs comprises heterogeneous processors (Cortex A, Cortex R).
When the ethernet controller is completely managed by a core (Cortex R)
running a flavor of RTOS, in a non virtualized environment, network traffic
tunnelling between heterogeneous processors can be realized by means of
RPMsg based shared memory ethernet driver. With the shared memory used
for the data plane and the RPMsg end point channel used for control plane.
inter-core-virt-eth driver is modelled as a RPMsg based shared
memory ethernet driver for such an use case.
As a first step, register the inter-core-virt-eth as a RPMsg driver.
And introduce basic control messages for querying and responding.
Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com>
Signed-off-by: Yojana Mallik <y-mallik@ti.com>
---
drivers/net/ethernet/ti/Kconfig | 9 +++
drivers/net/ethernet/ti/Makefile | 1 +
drivers/net/ethernet/ti/icve_rpmsg_common.h | 47 +++++++++++
drivers/net/ethernet/ti/inter_core_virt_eth.c | 81 +++++++++++++++++++
drivers/net/ethernet/ti/inter_core_virt_eth.h | 27 +++++++
5 files changed, 165 insertions(+)
create mode 100644 drivers/net/ethernet/ti/icve_rpmsg_common.h
create mode 100644 drivers/net/ethernet/ti/inter_core_virt_eth.c
create mode 100644 drivers/net/ethernet/ti/inter_core_virt_eth.h
diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig
index 1729eb0e0b41..4f00cb8fe9f1 100644
--- a/drivers/net/ethernet/ti/Kconfig
+++ b/drivers/net/ethernet/ti/Kconfig
@@ -145,6 +145,15 @@ config TI_AM65_CPSW_QOS
The EST scheduler runs on CPTS and the TAS/EST schedule is
updated in the Fetch RAM memory of the CPSW.
+config TI_K3_INTERCORE_VIRT_ETH
+ tristate "TI K3 Intercore Virtual Ethernet driver"
+ help
+ This driver provides intercore virtual ethernet driver
+ capability.Intercore Virtual Ethernet driver is modelled as
+ a RPMsg based shared memory ethernet driver for network traffic
+ tunnelling between heterogeneous processors Cortex A and Cortex R
+ used in TI's K3 SoCs.
+
config TI_KEYSTONE_NETCP
tristate "TI Keystone NETCP Core Support"
select TI_DAVINCI_MDIO
diff --git a/drivers/net/ethernet/ti/Makefile b/drivers/net/ethernet/ti/Makefile
index 6e086b4c0384..24b14ca73407 100644
--- a/drivers/net/ethernet/ti/Makefile
+++ b/drivers/net/ethernet/ti/Makefile
@@ -49,3 +49,4 @@ icssg-prueth-sr1-y := icssg/icssg_prueth_sr1.o \
icssg/icssg_stats.o \
icssg/icssg_ethtool.o
obj-$(CONFIG_TI_ICSS_IEP) += icssg/icss_iep.o
+obj-$(CONFIG_TI_K3_INTERCORE_VIRT_ETH) += inter_core_virt_eth.o
diff --git a/drivers/net/ethernet/ti/icve_rpmsg_common.h b/drivers/net/ethernet/ti/icve_rpmsg_common.h
new file mode 100644
index 000000000000..7cd157479d4d
--- /dev/null
+++ b/drivers/net/ethernet/ti/icve_rpmsg_common.h
@@ -0,0 +1,47 @@
+/* SPDX-License-Identifier: GPL-2.0
+ * Texas Instruments K3 Inter Core Virtual Ethernet Driver common header
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#ifndef __ICVE_RPMSG_COMMON_H__
+#define __ICVE_RPMSG_COMMON_H__
+
+#include <linux/if_ether.h>
+
+enum icve_msg_type {
+ ICVE_REQUEST_MSG = 0,
+ ICVE_RESPONSE_MSG,
+ ICVE_NOTIFY_MSG,
+};
+
+struct request_message {
+ u32 type; /* Request Type */
+ u32 id; /* Request ID */
+} __packed;
+
+struct response_message {
+ u32 type; /* Response Type */
+ u32 id; /* Response ID */
+} __packed;
+
+struct notify_message {
+ u32 type; /* Notify Type */
+ u32 id; /* Notify ID */
+} __packed;
+
+struct message_header {
+ u32 src_id;
+ u32 msg_type; /* Do not use enum type, as enum size is compiler dependent */
+} __packed;
+
+struct message {
+ struct message_header msg_hdr;
+ union {
+ struct request_message req_msg;
+ struct response_message resp_msg;
+ struct notify_message notify_msg;
+ };
+} __packed;
+
+#endif /* __ICVE_RPMSG_COMMON_H__ */
diff --git a/drivers/net/ethernet/ti/inter_core_virt_eth.c b/drivers/net/ethernet/ti/inter_core_virt_eth.c
new file mode 100644
index 000000000000..bea822d2373a
--- /dev/null
+++ b/drivers/net/ethernet/ti/inter_core_virt_eth.c
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Texas Instruments K3 Inter Core Virtual Ethernet Driver
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#include "inter_core_virt_eth.h"
+
+static int icve_rpmsg_cb(struct rpmsg_device *rpdev, void *data, int len,
+ void *priv, u32 src)
+{
+ struct icve_common *common = dev_get_drvdata(&rpdev->dev);
+ struct message *msg = (struct message *)data;
+ u32 msg_type = msg->msg_hdr.msg_type;
+ u32 rpmsg_type;
+
+ switch (msg_type) {
+ case ICVE_REQUEST_MSG:
+ rpmsg_type = msg->req_msg.type;
+ dev_dbg(common->dev, "Msg type = %d; RPMsg type = %d\n",
+ msg_type, rpmsg_type);
+ break;
+ case ICVE_RESPONSE_MSG:
+ rpmsg_type = msg->resp_msg.type;
+ dev_dbg(common->dev, "Msg type = %d; RPMsg type = %d\n",
+ msg_type, rpmsg_type);
+ break;
+ case ICVE_NOTIFY_MSG:
+ rpmsg_type = msg->notify_msg.type;
+ dev_dbg(common->dev, "Msg type = %d; RPMsg type = %d\n",
+ msg_type, rpmsg_type);
+ break;
+ default:
+ dev_err(common->dev, "Invalid msg type\n");
+ break;
+ }
+ return 0;
+}
+
+static int icve_rpmsg_probe(struct rpmsg_device *rpdev)
+{
+ struct device *dev = &rpdev->dev;
+ struct icve_common *common;
+
+ common = devm_kzalloc(&rpdev->dev, sizeof(*common), GFP_KERNEL);
+ if (!common)
+ return -ENOMEM;
+
+ dev_set_drvdata(dev, common);
+
+ common->port = devm_kzalloc(dev, sizeof(*common->port), GFP_KERNEL);
+ common->dev = dev;
+ common->rpdev = rpdev;
+
+ return 0;
+}
+
+static void icve_rpmsg_remove(struct rpmsg_device *rpdev)
+{
+ dev_info(&rpdev->dev, "icve rpmsg client driver is removed\n");
+}
+
+static struct rpmsg_device_id icve_rpmsg_id_table[] = {
+ { .name = "ti.icve" },
+ {},
+};
+MODULE_DEVICE_TABLE(rpmsg, icve_rpmsg_id_table);
+
+static struct rpmsg_driver icve_rpmsg_client = {
+ .drv.name = KBUILD_MODNAME,
+ .id_table = icve_rpmsg_id_table,
+ .probe = icve_rpmsg_probe,
+ .callback = icve_rpmsg_cb,
+ .remove = icve_rpmsg_remove,
+};
+module_rpmsg_driver(icve_rpmsg_client);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Siddharth Vadapalli <s-vadapalli@ti.com>");
+MODULE_AUTHOR("Ravi Gunasekaran <r-gunasekaran@ti.com");
+MODULE_DESCRIPTION("TI Inter Core Virtual Ethernet driver");
diff --git a/drivers/net/ethernet/ti/inter_core_virt_eth.h b/drivers/net/ethernet/ti/inter_core_virt_eth.h
new file mode 100644
index 000000000000..91a3aba96996
--- /dev/null
+++ b/drivers/net/ethernet/ti/inter_core_virt_eth.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: GPL-2.0
+ * Texas Instruments K3 Inter Core Virtual Ethernet Driver
+ *
+ * Copyright (C) 2024 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+#ifndef __INTER_CORE_VIRT_ETH_H__
+#define __INTER_CORE_VIRT_ETH_H__
+
+#include <linux/etherdevice.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/netdevice.h>
+#include <linux/rpmsg.h>
+#include "icve_rpmsg_common.h"
+
+struct icve_port {
+ struct icve_common *common;
+} __packed;
+
+struct icve_common {
+ struct rpmsg_device *rpdev;
+ struct icve_port *port;
+ struct device *dev;
+} __packed;
+
+#endif /* __INTER_CORE_VIRT_ETH_H__ */
--
2.40.1> +struct request_message {
> + u32 type; /* Request Type */
> + u32 id; /* Request ID */
> +} __packed;
> +
> +struct response_message {
> + u32 type; /* Response Type */
> + u32 id; /* Response ID */
> +} __packed;
> +
> +struct notify_message {
> + u32 type; /* Notify Type */
> + u32 id; /* Notify ID */
> +} __packed;
These are basically identical.
The packed should not be needed, since these structures are naturally
aligned. The compiler will do the right thing without the
__packet. And there is a general dislike for __packed. It is better to
layout your structures correctly so they are not needed.
> +struct message_header {
> + u32 src_id;
> + u32 msg_type; /* Do not use enum type, as enum size is compiler dependent */
> +} __packed;
> +
> +struct message {
> + struct message_header msg_hdr;
> + union {
> + struct request_message req_msg;
> + struct response_message resp_msg;
> + struct notify_message notify_msg;
> + };
Since they are identical, why bother with a union? It could be argued
it allows future extensions, but i don't see any sort of protocol
version here so you can tell if extra fields have been added.
> +static int icve_rpmsg_cb(struct rpmsg_device *rpdev, void *data, int len,
> + void *priv, u32 src)
> +{
> + struct icve_common *common = dev_get_drvdata(&rpdev->dev);
> + struct message *msg = (struct message *)data;
> + u32 msg_type = msg->msg_hdr.msg_type;
> + u32 rpmsg_type;
> +
> + switch (msg_type) {
> + case ICVE_REQUEST_MSG:
> + rpmsg_type = msg->req_msg.type;
> + dev_dbg(common->dev, "Msg type = %d; RPMsg type = %d\n",
> + msg_type, rpmsg_type);
> + break;
> + case ICVE_RESPONSE_MSG:
> + rpmsg_type = msg->resp_msg.type;
> + dev_dbg(common->dev, "Msg type = %d; RPMsg type = %d\n",
> + msg_type, rpmsg_type);
> + break;
> + case ICVE_NOTIFY_MSG:
> + rpmsg_type = msg->notify_msg.type;
> + dev_dbg(common->dev, "Msg type = %d; RPMsg type = %d\n",
> + msg_type, rpmsg_type);
This can be flattened to:
> + case ICVE_REQUEST_MSG:
> + case ICVE_RESPONSE_MSG:
> + case ICVE_NOTIFY_MSG:
> + rpmsg_type = msg->notify_msg.type;
> + dev_dbg(common->dev, "Msg type = %d; RPMsg type = %d\n",
> + msg_type, rpmsg_type);
which makes me wounder about the value of this. Yes, later patches are
going to flesh this out, but what value is there in printing the
numerical value of msg_type, when you could easily have the text
"Request", "Response", and "Notify". And why not include src_id and id
in this debug output? If you are going to add debug output, please
make it complete, otherwise it is often not useful.
> + break;
> + default:
> + dev_err(common->dev, "Invalid msg type\n");
> + break;
That is a potential way for the other end to DoS you. It also makes
changes to the protocol difficult, since you cannot add new messages
without DoS a machine using the old protocol. It would be better to
just increment a counter and keep going.
> +static void icve_rpmsg_remove(struct rpmsg_device *rpdev)
> +{
> + dev_info(&rpdev->dev, "icve rpmsg client driver is removed\n");
Please don't spam the logs. dev_dbg(), or nothing at all.
Andrew
Hi Andrew,
On 6/2/24 21:51, Andrew Lunn wrote:
>> +struct request_message {
>> + u32 type; /* Request Type */
>> + u32 id; /* Request ID */
>> +} __packed;
>> +
>> +struct response_message {
>> + u32 type; /* Response Type */
>> + u32 id; /* Response ID */
>> +} __packed;
>> +
>> +struct notify_message {
>> + u32 type; /* Notify Type */
>> + u32 id; /* Notify ID */
>> +} __packed;
>
> These are basically identical.
>
The first patch introduces only the RPMsg-based driver.
The RPMsg driver is registered as a network device in the second patch.
struct icve_mac_addr mac_addr is added as a member to
struct request_message in the second patch. Similarly struct icve_shm shm_info
is added as a member to struct response_message in the second patch. From
second patch onward struct request_message and struct response_message are not
identical. These members are used for the network device driver. As this patch
introduces only RPMsg-based ethernet driver these members were not used in this
patch and hence not mentioned in this patch. I understand this has led to the
confusion of the structures looking similar in this patch. Kindly suggest if I
should add these members in this patch itself instead of introducing them in
the next patch.
> The packed should not be needed, since these structures are naturally
> aligned. The compiler will do the right thing without the
> __packet. And there is a general dislike for __packed. It is better to
> layout your structures correctly so they are not needed.
>
>> +struct message_header {
>> + u32 src_id;
>> + u32 msg_type; /* Do not use enum type, as enum size is compiler dependent */
>> +} __packed;
>> +
>> +struct message {
>> + struct message_header msg_hdr;
>> + union {
>> + struct request_message req_msg;
>> + struct response_message resp_msg;
>> + struct notify_message notify_msg;
>> + };
>
> Since they are identical, why bother with a union? It could be argued
> it allows future extensions, but i don't see any sort of protocol
> version here so you can tell if extra fields have been added.
>
struct icve_mac_addr mac_addr is added as a member to
struct request_message in the second patch. Similarly struct icve_shm shm_info
is added as a member to struct response_message in the second patch. So sizes
of the structures are different. Hence union is used. I had moved those newly
added members to second patch because they are not used in the first patch. I
understand this has led to the confusion of the structures looking identical in
this patch. If you suggest I will move the newly added members of the
structures from the second patch to the first patch and then the structures
will not look identical in this patch.
>> +static int icve_rpmsg_cb(struct rpmsg_device *rpdev, void *data, int len,
>> + void *priv, u32 src)
>> +{
>> + struct icve_common *common = dev_get_drvdata(&rpdev->dev);
>> + struct message *msg = (struct message *)data;
>> + u32 msg_type = msg->msg_hdr.msg_type;
>> + u32 rpmsg_type;
>> +
>> + switch (msg_type) {
>> + case ICVE_REQUEST_MSG:
>> + rpmsg_type = msg->req_msg.type;
>> + dev_dbg(common->dev, "Msg type = %d; RPMsg type = %d\n",
>> + msg_type, rpmsg_type);
>> + break;
>> + case ICVE_RESPONSE_MSG:
>> + rpmsg_type = msg->resp_msg.type;
>> + dev_dbg(common->dev, "Msg type = %d; RPMsg type = %d\n",
>> + msg_type, rpmsg_type);
>> + break;
>> + case ICVE_NOTIFY_MSG:
>> + rpmsg_type = msg->notify_msg.type;
>> + dev_dbg(common->dev, "Msg type = %d; RPMsg type = %d\n",
>> + msg_type, rpmsg_type);
>
> This can be flattened to:
>
>> + case ICVE_REQUEST_MSG:
>> + case ICVE_RESPONSE_MSG:
>> + case ICVE_NOTIFY_MSG:
>> + rpmsg_type = msg->notify_msg.type;
>> + dev_dbg(common->dev, "Msg type = %d; RPMsg type = %d\n",
>> + msg_type, rpmsg_type);
>
New switch case statements have been added in the second patch for rpmsg_type
under under the case ICVE_RESPONSE_MSG. This makes case ICVE_REQUEST_MSG, case
ICVE_RESPONSE_MSG and case ICVE_NOTIFY_MSG different in the second patch. I
have kept icve_rpmsg_cb simple in this patch as it is called by the .callback.
Do you suggest to flatten these switch cases only for this patch?
> which makes me wounder about the value of this. Yes, later patches are
> going to flesh this out, but what value is there in printing the
> numerical value of msg_type, when you could easily have the text
> "Request", "Response", and "Notify". And why not include src_id and id
> in this debug output? If you are going to add debug output, please
> make it complete, otherwise it is often not useful.
>
I will modify the debug output by including texts like "Request", "Response",
and "Notify" instead of the numerical value of msg_type. I will include src_id
and id and try to make this debug output complete and meaningful.
>> + break;
>> + default:
>> + dev_err(common->dev, "Invalid msg type\n");
>> + break;
> That is a potential way for the other end to DoS you. It also makes
> changes to the protocol difficult, since you cannot add new messages
> without DoS a machine using the old protocol. It would be better to
> just increment a counter and keep going.
>
I will modify default case to return -EINVAL.
>> +static void icve_rpmsg_remove(struct rpmsg_device *rpdev)
>> +{
>> + dev_info(&rpdev->dev, "icve rpmsg client driver is removed\n");
>
> Please don't spam the logs. dev_dbg(), or nothing at all.
>
> Andrew
I will remove the dev_info from icve_rpmsg_remove.
Thanks for your feedback.
On Mon, Jun 03, 2024 at 02:26:06PM +0530, Yojana Mallik wrote:
> Hi Andrew,
>
> On 6/2/24 21:51, Andrew Lunn wrote:
> >> +struct request_message {
> >> + u32 type; /* Request Type */
> >> + u32 id; /* Request ID */
> >> +} __packed;
> >> +
> >> +struct response_message {
> >> + u32 type; /* Response Type */
> >> + u32 id; /* Response ID */
> >> +} __packed;
> >> +
> >> +struct notify_message {
> >> + u32 type; /* Notify Type */
> >> + u32 id; /* Notify ID */
> >> +} __packed;
> >
> > These are basically identical.
> >
>
> The first patch introduces only the RPMsg-based driver.
> The RPMsg driver is registered as a network device in the second patch.
> struct icve_mac_addr mac_addr is added as a member to
> struct request_message in the second patch. Similarly struct icve_shm shm_info
> is added as a member to struct response_message in the second patch. From
> second patch onward struct request_message and struct response_message are not
> identical. These members are used for the network device driver. As this patch
> introduces only RPMsg-based ethernet driver these members were not used in this
> patch and hence not mentioned in this patch. I understand this has led to the
> confusion of the structures looking similar in this patch. Kindly suggest if I
> should add these members in this patch itself instead of introducing them in
> the next patch.
I think your first patch should add documentation of the whole
protocol. With a clear understanding of what the end goal is, it
becomes easier to understand the step by step implementation stages.
Andrew
On Fri, May 31, 2024 at 12:10:04PM +0530, Yojana Mallik wrote: > From: Ravi Gunasekaran <r-gunasekaran@ti.com> > > TI's K3 SoCs comprises heterogeneous processors (Cortex A, Cortex R). > When the ethernet controller is completely managed by a core (Cortex R) > running a flavor of RTOS, in a non virtualized environment, network traffic > tunnelling between heterogeneous processors can be realized by means of > RPMsg based shared memory ethernet driver. With the shared memory used > for the data plane and the RPMsg end point channel used for control plane. > > inter-core-virt-eth driver is modelled as a RPMsg based shared > memory ethernet driver for such an use case. > > As a first step, register the inter-core-virt-eth as a RPMsg driver. > And introduce basic control messages for querying and responding. > Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> My "Signed-off-by" tag was present in the RFC patch at: https://lore.kernel.org/r/20240130110944.26771-2-r-gunasekaran@ti.com/ Any reason for dropping it? Also, I was in the Cc list of the RFC series. Please ensure that you don't drop emails which were present in earlier versions of the series (unless the email is no longer valid), and also ensure that you Cc all individuals who have commented on the series when you post a new version of the series. > Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com> > Signed-off-by: Yojana Mallik <y-mallik@ti.com> > --- > drivers/net/ethernet/ti/Kconfig | 9 +++ > drivers/net/ethernet/ti/Makefile | 1 + > drivers/net/ethernet/ti/icve_rpmsg_common.h | 47 +++++++++++ > drivers/net/ethernet/ti/inter_core_virt_eth.c | 81 +++++++++++++++++++ [...] Regards, Siddharth.
On 6/2/24 12:31, Siddharth Vadapalli wrote: > On Fri, May 31, 2024 at 12:10:04PM +0530, Yojana Mallik wrote: >> From: Ravi Gunasekaran <r-gunasekaran@ti.com> >> >> TI's K3 SoCs comprises heterogeneous processors (Cortex A, Cortex R). >> When the ethernet controller is completely managed by a core (Cortex R) >> running a flavor of RTOS, in a non virtualized environment, network traffic >> tunnelling between heterogeneous processors can be realized by means of >> RPMsg based shared memory ethernet driver. With the shared memory used >> for the data plane and the RPMsg end point channel used for control plane. >> >> inter-core-virt-eth driver is modelled as a RPMsg based shared >> memory ethernet driver for such an use case. >> >> As a first step, register the inter-core-virt-eth as a RPMsg driver. >> And introduce basic control messages for querying and responding. >> > > Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> > > My "Signed-off-by" tag was present in the RFC patch at: > https://lore.kernel.org/r/20240130110944.26771-2-r-gunasekaran@ti.com/ > Sorry for the mistake. I will add it. > Any reason for dropping it? Also, I was in the Cc list of the RFC series. > Please ensure that you don't drop emails which were present in earlier > versions of the series (unless the email is no longer valid), and also > ensure that you Cc all individuals who have commented on the series when > you post a new version of the series. > Sorry for the mistake. I will ensure that I Cc all the necessary individuals. >> Signed-off-by: Ravi Gunasekaran <r-gunasekaran@ti.com> >> Signed-off-by: Yojana Mallik <y-mallik@ti.com> >> --- >> drivers/net/ethernet/ti/Kconfig | 9 +++ >> drivers/net/ethernet/ti/Makefile | 1 + >> drivers/net/ethernet/ti/icve_rpmsg_common.h | 47 +++++++++++ >> drivers/net/ethernet/ti/inter_core_virt_eth.c | 81 +++++++++++++++++++ > > [...] > > Regards, > Siddharth.
On 5/30/24 11:40 PM, Yojana Mallik wrote: > diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig > index 1729eb0e0b41..4f00cb8fe9f1 100644 > --- a/drivers/net/ethernet/ti/Kconfig > +++ b/drivers/net/ethernet/ti/Kconfig > @@ -145,6 +145,15 @@ config TI_AM65_CPSW_QOS > The EST scheduler runs on CPTS and the TAS/EST schedule is > updated in the Fetch RAM memory of the CPSW. > > +config TI_K3_INTERCORE_VIRT_ETH > + tristate "TI K3 Intercore Virtual Ethernet driver" > + help > + This driver provides intercore virtual ethernet driver > + capability.Intercore Virtual Ethernet driver is modelled as capability. Intercore > + a RPMsg based shared memory ethernet driver for network traffic a RPMsg-based > + tunnelling between heterogeneous processors Cortex A and Cortex R > + used in TI's K3 SoCs. OK, the darned British spellings can stay. ;) (the double-l words) -- #Randy https://people.kernel.org/tglx/notes-about-netiquette https://subspace.kernel.org/etiquette.html
On 5/31/24 21:00, Randy Dunlap wrote: > > > On 5/30/24 11:40 PM, Yojana Mallik wrote: >> diff --git a/drivers/net/ethernet/ti/Kconfig b/drivers/net/ethernet/ti/Kconfig >> index 1729eb0e0b41..4f00cb8fe9f1 100644 >> --- a/drivers/net/ethernet/ti/Kconfig >> +++ b/drivers/net/ethernet/ti/Kconfig >> @@ -145,6 +145,15 @@ config TI_AM65_CPSW_QOS >> The EST scheduler runs on CPTS and the TAS/EST schedule is >> updated in the Fetch RAM memory of the CPSW. >> >> +config TI_K3_INTERCORE_VIRT_ETH >> + tristate "TI K3 Intercore Virtual Ethernet driver" >> + help >> + This driver provides intercore virtual ethernet driver >> + capability.Intercore Virtual Ethernet driver is modelled as > > capability. Intercore I will fix this. > >> + a RPMsg based shared memory ethernet driver for network traffic > > a RPMsg-based > I will fix this. >> + tunnelling between heterogeneous processors Cortex A and Cortex R >> + used in TI's K3 SoCs. > > > OK, the darned British spellings can stay. ;) > (the double-l words) > I will fix this. Thankyou for pointing out the errors. Regards, Yojana Mallik
© 2016 - 2026 Red Hat, Inc.