On Thu, Feb 06, 2025 at 11:34:27PM +0800, Zijun Hu wrote:
> On 2/4/2025 7:09 PM, Greg Kroah-Hartman wrote:
> > +#define MAX_NAME_SIZE 256 /* Max size of a faux_device name */
> > +
> > +/*
> > + * Internal wrapper structure so we can hold the memory
> > + * for the driver and the name string of the faux device.
> > + */
> > +struct faux_object {
> > + struct faux_device faux_dev;
> > + const struct faux_driver_ops *faux_ops;
> > + char name[];
>
> Remove name since it is not used actually ?
Hm, we do copy it:
/* Save off the name of the object into local memory */
memcpy(faux_obj->name, name, name_size);
Ah, but then we do a dev_set_name() so we don't care anymore! When the
code was a two-step process we did care. Nice catch, let me go change
that and test it to be sure.
> > +};+ */
> > +void faux_device_destroy(struct faux_device *faux_dev)
> > +{
> > + struct device *dev = &faux_dev->dev;
> > +
> > + if (IS_ERR_OR_NULL(faux_dev))
> > + return;
> > +
>
> struct device *dev;
>
> //faux_device_create() does not return ERR_PTR().
> if (!faux_dev)
> return;
>
> // avoid NULL pointer dereference in case of above error
> dev = &faux_dev->dev;
Nope, that wouldn't have been a dereference error, you can set a pointer
to point to NULL just fine as long as you don't try to dereference it to
something else. Isn't C fun! :)
> > + device_del(dev);
> > +
> > + /* The final put_device() will clean up the driver we created for this device. */
> > + put_device(dev);
>
> use device_unregister() instead of above 2 statements?
Could be, both are the same.
> > +}
> > +EXPORT_SYMBOL_GPL(faux_device_destroy);
> > +
> > +int __init faux_bus_init(void)
> > +{
> > + int ret;
> > +
> > + ret = device_register(&faux_bus_root);
> > + if (ret) {
> > + put_device(&faux_bus_root);
>
> put_device() for static device may trigger below warning:
>
> drivers/base/core.c:device_release():
> WARN(1, KERN_ERR "Device '%s' does not have a release() function, it is
> broken and must be fixed. See Documentation/core-api/kobject.rst.\n",
> dev_name(dev));
Yes, but that will never trigger when you run the code as the final put
device never happens. So you will not ever see that.
And yes, I HATE static struct devices in the kernel a lot, but in the
driver core we use them for a few things like this, so either I fix all
of them, or just live with the few that we have.
thanks for the review!
greg k-h
