Message-ID: <Z8CCPIoeNoG6m7FT@smile.fi.intel.com>
Date: Thu, 27 Feb 2025 17:18:20 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Louis Chauvet <louis.chauvet@...tlin.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	linux-kernel@...r.kernel.org, Lyude Paul <lyude@...hat.com>,
	"Rafael J. Wysocki" <rafael@...nel.org>,
	Danilo Krummrich <dakr@...nel.org>,
	Alexander Lobakin <aleksander.lobakin@...el.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Jonathan Cameron <Jonathan.Cameron@...wei.com>,
	Liam Girdwood <lgirdwood@...il.com>, Lukas Wunner <lukas@...ner.de>,
	Mark Brown <broonie@...nel.org>,
	Maíra Canal <mairacanal@...eup.net>,
	Robin Murphy <robin.murphy@....com>,
	Simona Vetter <simona.vetter@...ll.ch>,
	Zijun Hu <quic_zijuhu@...cinc.com>, linux-usb@...r.kernel.org,
	rust-for-linux@...r.kernel.org,
	José Expósito <jose.exposito89@...il.com>
Subject: Re: [PATCH v4 0/9] Driver core: Add faux bus devices

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

Powered by blists - more mailing lists