On Mon, Jan 19, 2004 at 06:21:43PM +0000, Linux Kernel Mailing List wrote:
> +static inline int vio_module_init(struct vio_driver *drv)
> +{
> + int rc = vio_register_driver (drv);
> +
> + if (rc > 0)
> + return 0;
> +
> + /* iff CONFIG_HOTPLUG and built into kernel, we should
> + * leave the driver around for future hotplug events.
> + * For the module case, a hotplug daemon of some sort
> + * should load a module in response to an insert event. */
> +#if defined(CONFIG_HOTPLUG) && !defined(MODULE)
> + if (rc == 0)
> + return 0;
> +#else
> + if (rc == 0)
> + rc = -ENODEV;
> +#endif
> +
> + /* if we get here, we need to clean up vio driver instance
> + * and return some sort of error */
> +
> + return rc;
> +}
> +
> +#endif /* _PHYP_H */
Ick ick ick. I thought you all were not going to add this function, but
just use vio_register_driver() on it's own? Loading a driver should not
depend on CONFIG_HOTPLUG, as we now have different ways we can bind
drivers to devices after they are loaded (see the new_id stuff for pci
devices as an example.)
In fact I have a patch in my queue to clean this logic up for PCI
drivers from rmk that I need to apply soon...
thanks,
greg k-h
On Mon, Jan 19, 2004 at 02:32:30PM -0800, Greg KH wrote:
> Ick ick ick. I thought you all were not going to add this function, but
> just use vio_register_driver() on it's own? Loading a driver should not
> depend on CONFIG_HOTPLUG, as we now have different ways we can bind
> drivers to devices after they are loaded (see the new_id stuff for pci
> devices as an example.)
I wonder why this code got merged at all. Half of it could easily be
scrapped by using the driver model properly.
On Mon, Jan 19, 2004 at 10:49:53PM +0000, Christoph Hellwig wrote:
> On Mon, Jan 19, 2004 at 02:32:30PM -0800, Greg KH wrote:
> > Ick ick ick. I thought you all were not going to add this function, but
> > just use vio_register_driver() on it's own? Loading a driver should not
> > depend on CONFIG_HOTPLUG, as we now have different ways we can bind
> > drivers to devices after they are loaded (see the new_id stuff for pci
> > devices as an example.)
>
> I wonder why this code got merged at all. Half of it could easily be
> scrapped by using the driver model properly.
Which is another point. I thought I saw a port of this code to the
driver model for 2.6 on the ppc mailing list. Why this old code?
thanks,
greg k-h
On Jan 19, 2004, at 5:03 PM, Greg KH wrote:
> On Mon, Jan 19, 2004 at 10:49:53PM +0000, Christoph Hellwig wrote:
>> I wonder why this code got merged at all. Half of it could easily be
>> scrapped by using the driver model properly.
>
> Which is another point. I thought I saw a port of this code to the
> driver model for 2.6 on the ppc mailing list. Why this old code?
The driver model code is present in the ppc64 tree, pushed Friday. It
seems this version had been promoted into -mm though, and now into
mainline.
--
Hollis Blanchard
IBM Linux Technology Center
> The driver model code is present in the ppc64 tree, pushed Friday. It
> seems this version had been promoted into -mm though, and now into
> mainline.
Sorry, my fault. I was too busy watching Linus get dunked to see the
updates from Hollis go in. We'll get the updates to Andrew and Linus.
Anton