linux-kernel - Re: [PATCH 1/3] driver core: add a faux bus for use when a simple device/bus is needed

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <2025020405-granddad-husband-65ee@gregkh>
Date: Tue, 4 Feb 2025 11:49:44 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Thomas Weißschuh <linux@...ssschuh.net>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>,
	Danilo Krummrich <dakr@...nel.org>, Lyude Paul <lyude@...hat.com>,
	Alexander Lobakin <aleksander.lobakin@...el.com>,
	Andy Shevchenko <andriy.shevchenko@...ux.intel.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-kernel@...r.kernel.org,
	linux-usb@...r.kernel.org, rust-for-linux@...r.kernel.org
Subject: Re: [PATCH 1/3] driver core: add a faux bus for use when a simple
 device/bus is needed

On Tue, Feb 04, 2025 at 11:44:41AM +0100, Thomas Weißschuh wrote:
> On 2025-02-04 11:20:43+0100, Greg Kroah-Hartman wrote:
> > On Tue, Feb 04, 2025 at 11:08:11AM +0100, Thomas Weißschuh wrote:
> > > On 2025-02-03 15:25:17+0100, Greg Kroah-Hartman wrote:
> > > > +static void faux_remove(struct device *dev)
> > > > +{
> > > > +	struct faux_object *faux_obj = to_faux_object(dev);
> > > > +	struct faux_device *faux_dev = &faux_obj->faux_dev;
> > > > +	const struct faux_driver_ops *faux_ops = faux_obj->faux_ops;
> > > > +
> > > > +	if (faux_ops && faux_ops->remove)
> > > > +		faux_ops->remove(faux_dev);
> > > > +}
> > > > +
> > > > +static const struct bus_type faux_bus_type = {
> > > > +	.name		= "faux_bus",
> > > 
> > > Is the _bus suffix intentional?
> > 
> > It was intentional.
> > 
> > > Other busses don't have it.
> > 
> > True.  Naming is hard.  I guess /sys/bus/faux/ makes sense, I will go
> > rename it.
> > 
> > But for the "root" device, does /sys/devices/faux_bus/ make sense, or
> > should it be /sys/devices/faux/ as well?  I'm now leaning toward the
> > latter...
> 
> I'm leaning slightly towards the former.
> But my naming skills are beyond limited.
> 
> > > > +	.match		= faux_match,
> > > > +	.probe		= faux_probe,
> > > > +	.remove		= faux_remove,
> > > > +};
> > > > +
> > > > +static void faux_device_release(struct device *dev)
> > > > +{
> > > > +	struct faux_object *faux_obj = to_faux_object(dev);
> > > > +	struct device_driver *drv = &faux_obj->driver;
> > > > +
> > > > +	/*
> > > > +	 * Now that the device is going away, it has been unbound from the
> > > > +	 * driver we created for it, so it is safe to unregister the driver from
> > > > +	 * the system.
> > > > +	 */
> > > > +	driver_unregister(drv);
> > > > +
> > > > +	kfree(faux_obj);
> > > > +}
> > > > +
> > > > +/**
> > > > + * __faux_device_create - create and register a faux device and driver
> > > > + * @name: name of the device and driver we are adding
> > > > + * @faux_ops: struct faux_driver_ops that the new device will call back into, can be NULL
> > > > + * @owner: module owner of the device/driver
> > > > + *
> > > > + * Create a new faux device and driver, both with the same name, and register
> > > > + * them in the driver core properly.  The probe() callback of @faux_ops will be
> > > > + * called with the new device that is created for the caller to do something
> > > > + * with.
> > > > + */
> > > > +struct faux_device *__faux_device_create(const char *name,
> > > > +					       struct faux_driver_ops *faux_ops,
> > > 
> > > const
> > > 
> > > > +					       struct module *owner)
> > > 
> > > What about attributes?
> > 
> > What in-kernel user of this wants an attribute for such a device?
> 
> It was mostly a guess.
> However drivers/video/fbdev/gbefb.c seems to be an example.

As that driver is allocateing io memory and the like, it really looks
like a "real" platform driver/device to me.  Do you think it should not
be one?

Also, that driver should be converted to use an attribute group instead
of manually adding those sysfs files, if you wanted to touch it in the
future :)

thanks,

greg k-h