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@a0400000" 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@a0400000/whatever@a0400000/ >>>> >>> >>> >>> 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@78000000`. 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
