On Thu, Feb 27, 2025 at 02:06:21PM +0100, Louis Chauvet wrote: > Le 10/02/2025 à 13:30, Greg Kroah-Hartman a écrit : > > For years/decades now, I've been complaining when I see people use > > platform devices for things that are obviously NOT platform devices. > > To finally fix this up, here is a "faux bus" that should be used instead > > of a platform device for these tiny and "fake" devices that people > > create all over the place. > > > > The api is even simpler than the normal platform device api, just two > > functions, one to create a device and one to remove it. When a device > > is created, if a probe/release callback is offered, they will be called > > at the proper time in the device's lifecycle. When finished with the > > device, just destroy it and all should be good. > > > > This simple api should also hopefully provide for a simple rust binding > > to it given the simple rules and lifecycle of the pointer passed back > > from the creation function (i.e. it is alive and valid for as long as > > you have not called destroy on it.) > > > > I've also converted four different examples of platform device abuse, the > > dummy regulator driver, the USB phy code, the x86 microcode dvice, and > > the "regulator" device that wifi uses to load the firmware tables, to > > use this api. In all cases, the logic either was identical, or became > > simpler, than before, a good sign (side note, a bug was fixed in the usb > > phy code that no one ever noticed before). > > > > Note, unless there are major objections, I'm leaning toward getting > > patch 1 and 2 of this series merged during this -rc cycle so that all of > > the individual driver subsystem cleanups can go through those subsystems > > as needed, as well as allowing the rust developers to create a binding > > and get that merged easier. Having patch 1 merged on its own isn't > > going to cause any changes if no one uses it, so that should be fine. > > Hi all, > > I have a maybe dumb question regarding the patches 3..9: do they break the > UAPI? > > With a platform device, the drivers appear under /sys/bus/platform, but with > faux device, they appear under /sys/bus/faux. > > I ask because I found out that one (see my reply to [2]) of the main drm > library expects to find all the devices under pci, usb, platform, virtio and > host1x buses [1], so at least for the vgem and vkms driver, this library > will be broken (it will not crash, but previously detected devices will > suddenly disappear). > > I don't know what are the rules for /sys/bus, but changing a device from one > bus to another seems to break userspace programs. How should we handle this > situation? Should we fix the existing drivers? Or only new drivers should > use it? > > +CC: José Expósito My 2 cents is that. The library should be prepared for the change. AFAIU the concept of sys/bus the user space is supposed to check all as the same device theoretically may float from one bus to another. -- With Best Regards, Andy Shevchenko
