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). Why does a userspace tool want to walk bus types? Shouldn't it just be iterating over the userspace class type instead? classes are how devices are exposed to userspace, not through a bus. That way if there is a new bus type tomorrow (like this one), code will just keep working. What does the tool actually do in the platform device's directory? thanks, greg k-h
