linux-kernel - Re: [PATCH net-next v2 2/3] net: ethernet: ti: Register the RPMsg driver as network device

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: <efff16aa-33d9-45eb-ac42-86f3411abfc9@lunn.ch>
Date: Sun, 16 Jun 2024 18:19:18 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Yojana Mallik <y-mallik@...com>
Cc: schnelle@...ux.ibm.com, wsa+renesas@...g-engineering.com,
	diogo.ivo@...mens.com, rdunlap@...radead.org, horms@...nel.org,
	vigneshr@...com, rogerq@...com, danishanwar@...com,
	pabeni@...hat.com, kuba@...nel.org, edumazet@...gle.com,
	davem@...emloft.net, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, srk@...com, rogerq@...nel.org,
	Siddharth Vadapalli <s-vadapalli@...com>
Subject: Re: [PATCH net-next v2 2/3] net: ethernet: ti: Register the RPMsg
 driver as network device

> The Linux Remoteproc driver which initializes remote processor cores carves out
> a section from DDR memory as reserved memory for each remote processor on the
> SOC. This memory region has been reserved in the Linux device tree file as
> reserved-memory. Out of this reserved memory for R5 core some memory is
> reserved for shared memory.

I don't know much about rpmsg, so i read the documentation:

https://docs.kernel.org/staging/rpmsg.html

There is no mention of carving out a region of DDR memory. It says
nothing about memory reserved in DT.

The API is pretty much: Please send these bytes to the peer. Call this
callback when bytes have been received from a peer.

> The shared memory is divided into two distinct regions:
> one for the A53 -> R5 data path (Tx buffer for Linux), and other for R5 -> A53
> data path (Rx buffer for Linux).

As i said in my previous message. Forget about the A54->R5. Think
about a generic architecture. You have an RPMSG facility using the API
described in the documentation. You have a block of shared
memory. That memory could be VRAM, it could be a dual port SRAM, a PCI
BAR region, or some DDR which both CPU have mapped into their address
space. Design a protocol around that. This might mean you need to
modify your firmware. It might mean you need to throw away your
firmware and start again. But for mainline, we want something generic
which any vendor can use with a wide range of hardware, with as few
assumptions as possible.

	Andrew