[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <fab2a856-e3b0-4d25-9ce4-72f1f57e3115@ti.com>
Date: Wed, 30 Jul 2025 20:41:13 +0530
From: "Anwar, Md Danish" <a0501179@...com>
To: Krzysztof Kozlowski <krzk@...nel.org>,
MD Danish Anwar
<danishanwar@...com>,
"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
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.
>
> Best regards,
> Krzysztof
--
Thanks and Regards,
Md Danish Anwar
Powered by blists - more mailing lists