[PATCH][2.4] VIO infrastructure update - review request

Hollis Blanchard hollisb at us.ibm.com
Fri Oct 31 02:12:40 EST 2003

On Wednesday, Oct 29, 2003, at 19:30 US/Central, Santiago Leon wrote:
> The attached patch is a reconstruction of the virtual I/O
> infrastructure, along with the proper changes to the Virtual Ethernet
> driver... The objective was to clean up the interface, structs, and
> functions... Some of the device initialization code was moved to each
> virtual driver (sort of what other buses like PCI do), making the
> drivers module-friendly and ready for hotplug...

This patch is important because the current VIO bus code in 2.4 has a
lot of PCI-specific features which don't make sense for virtual
devices. For example, it maintains separate global and per-bus lists of
devices (even though logically it's hard to see how we could end up
with multiple virtual busses), and it tries to emulate PCI's
vendor/device identifiers with hardcoded constants. That changes the
drivers' device tables like so:

>  static struct vio_device_id ibmveth_device_table[] __devinitdata= {
> -    { 0x1014, 0x0001, 0, 0, 0, 0, 0},
> +    { "network", "IBM,l-lan"},
>      { 0,}
>  };
All those 0's were unused, and the vendor/device IDs were completely
artificial. I think this patch is clearly better.

Also, there was some driver-specific code in vio.c, for example
knowledge about irq and dma properties between different types of

One change I'd like to see: instead of having each driver call
vio_get_irq(), rather have vio.c set the irq for it. Something like
this, unconditionally in vio_register_device():

	uint *intrs = (uint *)get_property(node, "interrupts", NULL);
	if (intrs) {
		vio_dev->interrupts = *intrs;
	} else {
		vio_dev->interrupts = -1;
In other words, if the OF node has an "interrupts" property, store the
value into struct vio_dev. If not, store -1 (or whatever). Same for
DMA, but not for things that really are device-specific, e.g. MAC

Also, Santi didn't mention in the mail that he's modified and tested
ibmveth.c and I believe VSCSI as well.

Hollis Blanchard
IBM Linux Technology Center

** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/

More information about the Linuxppc64-dev mailing list