On 12/3/25 1:35 PM, Michael S. Tsirkin wrote:
On Wed, Dec 03, 2025 at 12:12:46PM -0600, Tanmay Shah wrote:
Hello,
Thanks for your reviews. Please find the response below.
On 11/22/25 6:05 AM, Zhongqiu Han wrote:
On 11/15/2025 2:46 AM, Tanmay Shah wrote:
From: Xiang Xiao <[email protected]>
[...]
Thanks, that's a good question. I keept id 2 unmodified from the original
series. I don't know why ID 2 was chosen in the original series. I will have
to discuss this with the linux remoteproc/rpmsg maintainers and choose the
correct ID.
I don't see any problem choosing ID 1, but for some reason if ID 1 was
assigned and deprecated (I don't think that is the case) then only we should
use ID 2.
Arnaud, Mathieu, Bjorn any input here?
+
+struct virtio_rpmsg_config {
+ /* The tx/rx individual buffer size(if VIRTIO_RPMSG_F_BUFSZ) */
+ __u32 txbuf_size;
+ __u32 rxbuf_size;
+ __u32 reserved[14]; /* Reserve for the future use */
Should we use __virtio32 instead of __u32 to avoid endianness issues?
Sure, if that is the standard in other virtio headers I will modify it.
Thanks,
Tanmay
rpmsg is still not standardized, sadly. It's really time it was.
Modern virtio devices use __le32.
Accordingly, accessed with virtio_cread_le
__virtioXX and virtio_cread are for legacy compatible parts of config space.
As of now, I am using virtio_cread so I think it is legacy compatible.
Does rpmsg want to be modern or keep using legacy? I donnu.
I don't know either. This we have to discuss with the maintainers and
other vendors.
Ideally it should finally be documented and at that point we
definitely will want to switch to __le32.
For now, run sparse to make sure you don't introduce new endian-ness
issues.
Ack.
+ /* Put the customize config here */
+} __attribute__((packed));
+
+#endif /* _LINUX_VIRTIO_RPMSG_H */
