ppc64: VIO support, from Dave Boutcher, Hollis Blanchard and Santiago Leon
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 16 lines · Linux Kernel Mailing List
(quoted diff) +16
-0+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)
Review
Quoted 10 lines
(quoted diff) +10
-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
Quoted 5 lines · Greg KH
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 onCONFIG_HOTPLUG, as we now have different ways we can bind drivers to devices after they are loaded (see thenew_idstuff 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.
Quoted 9 lines · Christoph Hellwig
Quoted 5 lines · Greg KH
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 onCONFIG_HOTPLUG, as we now have different ways we can bind drivers to devices after they are loaded (see thenew_idstuff 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
Quoted 6 lines · Greg KH
Quoted 2 lines · Christoph Hellwig
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.
Signature · 2 lines
Hollis Blanchard IBM Linux Technology Center
Quoted 4 lines
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