On 29/07/2025 11:46, MD Danish Anwar wrote: >>> >>> One idea I had was to create a new binding for this node, and use >>> compatible string to access the node in driver. But the device is >>> virtual and not physical so I thought that might not be the way to go so >>> I went with the current approach. >> >> virtual devices do not go to DTS anyway. How do you imagine this works? >> You add it to DTS but you do not add bindings and you expect checks to >> succeed? >> >> Provide details how you checked your DTS compliance. >> >> > > This is my device tree patch [1]. I ran these two commands before and > after applying the patch and checked the diff. > > make dt_binding_check > make dtbs_check > > I didn't see any new error / warning getting introduced due to the patch > > After applying the patch I also ran, > > make CHECK_DTBS=y ti/k3-am642-evm.dtb > > I still don't see any warnings / error. > > > If you look at the DT patch, you'll see I am adding a new node in the I see. This is so odd syntax... You have the phandle there, so you do not need to do any node name checking. I did not really expect you will be checking node name for reserved memory!!! Obviously this will be fine with dt bindings, because such ABI should never be constructed. > `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 will not. Best regards, Krzysztof
