Message-ID: <dab8033d-e7d7-4522-b832-eaf58efaad68@ti.com>
Date: Thu, 28 Aug 2025 12:37:14 +0530
From: MD Danish Anwar <danishanwar@...com>
To: "Anwar, Md Danish" <a0501179@...com>,
        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, Andrew,

On 30/07/25 8:41 pm, Anwar, Md Danish wrote:
> 
> 
> On 7/30/2025 11:43 AM, Krzysztof Kozlowski wrote:
>> On 30/07/2025 08:01, MD Danish Anwar wrote:
>>>>
>>>>> `reserved-memory`. I am not creating a completely new undocumented node.
>>>>> Instead I am creating a new node under reserved-memory as the shared
>>>>> memory used by rpmsg-eth driver needs to be reserved first. This memory
>>>>> is reserved by the ti_k3_r5_remoteproc driver by k3_reserved_mem_init().
>>>>>
>>>>> It's just that I am naming this node as "virtual-eth-shm@...00000" and
>>>>> then using the same name in driver to get the base_address and size
>>>>> mentioned in this node.
>>>>
>>>> And how your driver will work with:
>>>>
>>>> s/virtual-eth-shm@...00000/whatever@...00000/
>>>>
>>>
>>>
>>> It won't. The driver imposes a restriction with the node name. The node
>>> name should always be "virtual-eth-shm"
>>
>> Drivers cannot impose the restriction. I don't think you understand the
>> problem. What stops me from renaming the node? Nothing.
>>
>> You keep explaining this broken code, but sorry, this is a no-go. Shall
>> I NAK it to make it obvious?
>>
> 
> Krzysztof, I understand this can't be accepted. This wasn't my first
> approach. The first approach was that the firmware running on the
> remotecore will share the base-address using rpmsg. But that was
> discouraged by Andrew.
> 
> So I came up with this DT approach to read the base-address from linux only.
> 
> Andrew, Since rpmsg-eth is a virtual device and we can't have DT node
> for it. Using the reserved memory node and then search the same using
> node name in the driver is also not acceptable as per Krzysztof. What do
> you suggest should be done here?
> 
> Can we revisit the first approach (firmware sharing the address)? Can we
> use module params to pass the base-address? or Do you have any other
> ideas on how to handle this?
> 
> Please let me know.
> 

This is what I came up with after few discussions offline with Andrew. I
will post v2 soon with the below changes

1. Similar to qcom,glink-edge.yaml and google,cros-ec.yaml - I will
create a new binding named ti,rpmsg-eth.yaml this binding will describe
the rpmsg eth node. This node will have a memory region.
2. The rpmsg-eth node will be a child node of the rproc device. In this
case `r5f@...00000`. I will modify the rproc binding
`ti,k3-r5f-rproc.yaml` to describe the same.
3. Other vendors who wish to use RPMSG_ETH, can create a rpmsg-eth node
as a child of their rproc device.

This approach is very similar to what's done by qcom,glink-edge.yaml
/google,cros-ec.yaml and their users.

-- 
Thanks and Regards,
Danish

Powered by blists - more mailing lists