On Tue, Jun 24, 2025 at 04:27:21PM +0300, Dmitry Baryshkov wrote: > On Thu, Jun 19, 2025 at 10:40:26AM +0530, Ekansh Gupta wrote: > > During rpmsg_probe, fastrpc device nodes are created first, then > > channel specific resources are initialized, followed by > > of_platform_populate, which triggers context bank probing. This > > sequence can cause issues as applications might open the device > > node before channel resources are initialized or the session is > > available, leading to problems. For example, spin_lock is initialized > > after the device node creation, but it is used in device_open, > > potentially before initialization. Move device registration after > > channel resource initialization in fastrpc_rpmsg_probe. > > You've moved device init, however there is still a possibility for the > context devices to be created, but not bound to the driver (because all > the probings are async). I think instead we should drop the extra > platform driver layer and create and set up corresponding devices > manually. For example, see how it is handled in > host1x_memory_context_list_init(). That function uses iommu-maps, but we > can use OF nodes and iommus instead.
Is this a real platform device? If so, why do you need a second platform driver, what makes this so unique? If this isn't a platform device, then why not just use the faux bus instead? It seems that "number of sessions" is a DT property, is that something that is really defined by the hardware? Or is it just a virtual thing that people are abusing in the DT? And if you really have all these sessions, why not make them real devices, wouldn't that make things simpler? thanks, greg k-h
