+/*
+ * Static definition of an OCP device.
+ *
+ * @vendor: Vendor code. It is _STRONGLY_ discouraged to use
+ * the vendor code as a way to match a unique device,
+ * though I kept that possibility open, you should
+ * really define different function codes for different
+ * device types
+ * @function: This is the function code for this device.
+ * @index: This index is used for mapping the Nth function of a
+ * given core. This is typically used for cross-driver
+ * matching, like looking for a given MAL or ZMII from
+ * an EMAC or for getting to the proper set of DCRs.
+ * Indices are no longer magically calculated based on
+ * structure ordering, they have to be actually coded
+ * into the ocp_def to avoid any possible confusion
+ * I _STRONGLY_ (again ? wow !) encourage anybody relying
+ * on index mapping to encode the "target" index in an
+ * associated structure pointed to by "additions", see
+ * how it's done for the EMAC driver.
+ * @paddr: Device physical address (may not mean anything...)
+ * @irq: Interrupt line for this device (TODO: think about making
+ * an array with this)
+ * @pm: Currently, contains the bitmask in CPMFR DCR for the device
+ * @additions: Optionally points to a function specific structure
+ * providing additional informations for a given device
+ * instance. It's currently used by the EMAC driver for MAL
+ * channel & ZMII port mapping among others.
+ * @show: Optionally points to a function specific structure
+ * providing a sysfs show routine for additions fields.
+ */