linux-kernel - Re: [PATCH net-next v2 2/8] dt-bindings: remoteproc: k3-r5f: Add rpmsg-eth subnode

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: <38c054a3-1835-4f91-9f89-fbe90ddba4a9@ti.com>
Date: Wed, 3 Sep 2025 19:02:56 +0530
From: "Anwar, Md Danish" <a0501179@...com>
To: Krzysztof Kozlowski <krzk@...nel.org>,
        MD Danish Anwar
	<danishanwar@...com>
CC: Andrew Lunn <andrew+netdev@...n.ch>,
        "David S. Miller"
	<davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
	<kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, Rob Herring
	<robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley
	<conor+dt@...nel.org>,
        Bjorn Andersson <andersson@...nel.org>,
        Mathieu
 Poirier <mathieu.poirier@...aro.org>,
        Simon Horman <horms@...nel.org>, Jonathan Corbet <corbet@....net>,
        Nishanth Menon <nm@...com>, Vignesh
 Raghavendra <vigneshr@...com>,
        Mengyuan Lou <mengyuanlou@...-swift.com>,
        Xin
 Guo <guoxin09@...wei.com>, Lei Wei <quic_leiwei@...cinc.com>,
        Lee Trager
	<lee@...ger.us>, Michael Ellerman <mpe@...erman.id.au>,
        Fan Gong
	<gongfan1@...wei.com>, Lorenzo Bianconi <lorenzo@...nel.org>,
        Geert
 Uytterhoeven <geert+renesas@...der.be>,
        Lukas Bulwahn
	<lukas.bulwahn@...hat.com>,
        Parthiban Veerasooran
	<Parthiban.Veerasooran@...rochip.com>,
        Suman Anna <s-anna@...com>, Tero
 Kristo <kristo@...nel.org>,
        <netdev@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-remoteproc@...r.kernel.org>,
        <linux-doc@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
        <srk@...com>, Roger Quadros
	<rogerq@...nel.org>
Subject: Re: [PATCH net-next v2 2/8] dt-bindings: remoteproc: k3-r5f: Add
 rpmsg-eth subnode



On 9/3/2025 6:24 PM, Krzysztof Kozlowski wrote:
> On 03/09/2025 09:57, MD Danish Anwar wrote:
>>>> Signed-off-by: MD Danish Anwar <danishanwar@...com>
>>>> ---
>>>>  .../devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml     | 6 ++++++
>>>>  1 file changed, 6 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml
>>>> index a492f74a8608..4dbd708ec8ee 100644
>>>> --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml
>>>> +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml
>>>> @@ -210,6 +210,12 @@ patternProperties:
>>>>            should be defined as per the generic bindings in,
>>>>            Documentation/devicetree/bindings/sram/sram.yaml
>>>>  
>>>> +      rpmsg-eth:
>>>> +        $ref: /schemas/net/ti,rpmsg-eth.yaml
>>>
>>> No, not a separate device. Please read slides from my DT for beginners
>>
>> I had synced with Andrew and we came to the conclusion that including
>> rpmsg-eth this way will follow the DT guidelines and should be okay.
> 
> ... and did you check the guidelines? Instead of repeating something not
> related to my comment rather bring argument matching the comment.
> 
> 
> ...
> 
>> @@ -768,6 +774,7 @@ &main_r5fss0_core0 {
>>  	mboxes = <&mailbox0_cluster2 &mbox_main_r5fss0_core0>;
>>  	memory-region = <&main_r5fss0_core0_dma_memory_region>,
>>  			<&main_r5fss0_core0_memory_region>;
>> +	rpmsg-eth-region = <&main_r5fss0_core0_memory_region_shm>;
> 
> You already have here memory-region, so use that one.
> 

There is a problem with using memory-region. If I add
`main_r5fss0_core0_memory_region_shm` to memory region, to get this
phandle from driver I would have to use
	
	of_parse_phandle(np, "memory-region", 2)

Where 2 is the index for this region. But the problem is how would the
driver know this index. This index can vary for different vendors and
their rproc device.

If some other vendor tries to use this driver but their memory-region
has 3 existing entries. so this this entry will be the 4th one.

But the driver code won't work for this. We need to have a way to know
which index to look for in existing memory-region which can defer from
vendor to vendor.

So to avoid this, I thought of using a new memory region. Which will
have only 1 entry specifically for this case, and the driver can always

	of_parse_phandle(np, "rpmsg-eth-region", 0)

to get the memory region.

>>  };
>>
>>  &main_r5fss0_core1 {
>>
>>
>> In this approach I am creating a new phandle to a memory region that
>> will be used by my device.
> 
> 
> 
> Best regards,
> Krzysztof

-- 
Thanks and Regards,
Md Danish Anwar