netdev - Re: [PATCH net-next 2/5] net: rpmsg-eth: Add basic rpmsg skeleton

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: <5f4e1f99-ff71-443f-ba34-39396946e5b4@ti.com>
Date: Mon, 28 Jul 2025 13:40:59 +0530
From: MD Danish Anwar <danishanwar@...com>
To: Krzysztof Kozlowski <krzk@...nel.org>,
        "David S. Miller"
	<davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
	<kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, Simon Horman
	<horms@...nel.org>,
        Jonathan Corbet <corbet@....net>, Andrew Lunn
	<andrew+netdev@...n.ch>,
        Mengyuan Lou <mengyuanlou@...-swift.com>,
        Michael
 Ellerman <mpe@...erman.id.au>,
        Madhavan Srinivasan <maddy@...ux.ibm.com>,
        Fan
 Gong <gongfan1@...wei.com>, Lee Trager <lee@...ger.us>,
        Lorenzo Bianconi
	<lorenzo@...nel.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Lukas
 Bulwahn <lukas.bulwahn@...hat.com>,
        Parthiban Veerasooran
	<Parthiban.Veerasooran@...rochip.com>
CC: <netdev@...r.kernel.org>, <linux-doc@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next 2/5] net: rpmsg-eth: Add basic rpmsg skeleton

Hi Krzysztof,

On 25/07/25 12:48 am, Krzysztof Kozlowski wrote:
> On 23/07/2025 10:03, MD Danish Anwar wrote:
>> This patch introduces a basic RPMSG Ethernet driver skeleton. It adds
> 
> Please do not use "This commit/patch/change", but imperative mood. See
> longer explanation here:
> https://elixir.bootlin.com/linux/v5.17.1/source/Documentation/process/submitting-patches.rst#L95
> 

Sure. I will fix this in v2.

>> support for creating virtual Ethernet devices over RPMSG channels,
>> allowing user-space programs to send and receive messages using a
>> standard Ethernet protocol. The driver includes message handling,
>> probe, and remove functions, along with necessary data structures.
>>
> 
> 
> ...
> 
>> +
>> +/**
>> + * rpmsg_eth_get_shm_info - Get shared memory info from device tree
>> + * @common: Pointer to rpmsg_eth_common structure
>> + *
>> + * Return: 0 on success, negative error code on failure
>> + */
>> +static int rpmsg_eth_get_shm_info(struct rpmsg_eth_common *common)
>> +{
>> +	struct device_node *peer;
>> +	const __be32 *reg;
>> +	u64 start_address;
>> +	int prop_size;
>> +	int reg_len;
>> +	u64 size;
>> +
>> +	peer = of_find_node_by_name(NULL, "virtual-eth-shm");
> 
> 
> This is new ABI and I do not see earlier patch documenting it.
> 
> You cannot add undocumented ABI... but even if you documented it, I am
> sorry, but I am pretty sure it is wrong. Why are you choosing random
> nodes just because their name by pure coincidence is "virtual-eth-shm"?
> I cannot name my ethernet like that?
> 

This series adds a new virtual ethernet driver. The tx / rx happens in a
shared memory block. I need to have a way for the driver to know what is
the address / size of this block. This driver can be used by any
vendors. The vendors can create a new node in their dt and specify the
base address / size of the shared memory block.

I wanted to keep the name of the node constant so that the driver can
just look for this name and then grab the address and size.

I can create a new binding file for this but I didn't create thinking
it's a virtual device not a physical and I wasn't sure if bindings can
be created for virtual devices.

In my use case, I am reserving this shared memory and during reserving I
named the node "virtual-eth-shm". The memory is reserved by the
ti_k3_r5_remoteproc.c driver. The DT change is not part of this series
but can be found
https://gist.github.com/danish-ti/cdd10525ad834fdb20871ab411ff94fb

The idea is any vendor who want to use this driver, should name their dt
node as "virtual-eth-shm" (if they also need to reserve the memory) so
that the driver can take the address from DT and use it for tx / rx.

If this is not the correct way, can you please let me know of some other
way to handle this.

One idea I had was to create a new binding for this node, and use
compatible string to access the node in driver. But the device is
virtual and not physical so I thought that might not be the way to go so
I went with the current approach.

> Best regards,
> Krzysztof

-- 
Thanks and Regards,
Danish