summaryrefslogtreecommitdiffstats
path: root/drivers/staging/vme/vme_api.txt
diff options
context:
space:
mode:
authorManohar Vanga2011-09-26 11:27:16 +0200
committerGreg Kroah-Hartman2011-10-18 00:43:13 +0200
commit5d6abf379d73efe390488e8edba972af4e93cb1c (patch)
tree428bff86b71eeec6e24504221574092ab14c1cf1 /drivers/staging/vme/vme_api.txt
parentstaging: vme: add struct vme_dev for VME devices (diff)
downloadkernel-qcow2-linux-5d6abf379d73efe390488e8edba972af4e93cb1c.tar.gz
kernel-qcow2-linux-5d6abf379d73efe390488e8edba972af4e93cb1c.tar.xz
kernel-qcow2-linux-5d6abf379d73efe390488e8edba972af4e93cb1c.zip
staging: vme: make match() driver specific to improve non-VME64x support
For jumper based boards (non VME64x), there is no mechanism for detecting the card that is plugged into a specific slot. This leads to issues in non-autodiscovery crates/cards when a card is plugged into a slot that is "claimed" by a different driver. In reality, there is no problem, but the driver rejects such a configuration due to its dependence on the concept of slots. This patch makes the concept of slots less critical and pushes the driver match() to individual drivers (similar to what happens in the ISA bus in driver/base/isa.c). This allows drivers to register the number of devices that they expect without any restrictions. Devices in this new model are now formatted as $driver_name-$bus_id.$device_id (as compared to the earlier vme-$bus_id.$slot_number). This model also makes the device model more logical as devices are only registered when they actually exist whereas earlier, a set of devices were being created automatically regardless of them actually being there. Another change introduced in this patch is that devices are now created within the VME driver structure rather than in the VME bridge structure. This way, things don't go haywire if the bridge driver is removed while a driver is using it. Signed-off-by: Manohar Vanga <manohar.vanga@cern.ch> Cc: Martyn Welch <martyn.welch@ge.com> Reviewed-by: Emilio G. Cota <cota@braap.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'drivers/staging/vme/vme_api.txt')
-rw-r--r--drivers/staging/vme/vme_api.txt60
1 files changed, 30 insertions, 30 deletions
diff --git a/drivers/staging/vme/vme_api.txt b/drivers/staging/vme/vme_api.txt
index 03f481347067..53abf7e7cb4d 100644
--- a/drivers/staging/vme/vme_api.txt
+++ b/drivers/staging/vme/vme_api.txt
@@ -18,24 +18,37 @@ registration function. The structure is as follows:
struct vme_driver {
struct list_head node;
- char *name;
- const struct vme_device_id *bind_table;
- int (*probe) (struct vme_dev *);
- int (*remove) (struct vme_dev *);
- void (*shutdown) (void);
- struct device_driver driver;
+ const char *name;
+ int (*match)(struct vme_dev *);
+ int (*probe)(struct vme_dev *);
+ int (*remove)(struct vme_dev *);
+ void (*shutdown)(void);
+ struct device_driver driver;
+ struct list_head devices;
+ unsigned int ndev;
};
-At the minimum, the '.name', '.probe' and '.bind_table' elements of this
-structure should be correctly set. The '.name' element is a pointer to a string
-holding the device driver's name. The '.probe' element should contain a pointer
-to the probe routine.
+At the minimum, the '.name', '.match' and '.probe' elements of this structure
+should be correctly set. The '.name' element is a pointer to a string holding
+the device driver's name.
-The arguments of the probe routine are as follows:
+The '.match' function allows controlling the number of devices that need to
+be registered. The match function should return 1 if a device should be
+probed and 0 otherwise. This example match function (from vme_user.c) limits
+the number of devices probed to one:
- probe(struct vme_dev *dev);
+ #define USER_BUS_MAX 1
+ ...
+ static int vme_user_match(struct vme_dev *vdev)
+ {
+ if (vdev->id.num >= USER_BUS_MAX)
+ return 0;
+ return 1;
+ }
-The device structure looks like the following:
+The '.probe' element should contain a pointer to the probe routine. The
+probe routine is passed a 'struct vme_dev' pointer as an argument. The
+'struct vme_dev' structure looks like the following:
struct vme_dev {
struct vme_device_id id;
@@ -49,25 +62,12 @@ contains information useful for the probe function:
struct vme_device_id {
int bus;
int slot;
+ int num;
};
-'bus' is the number of the bus the device being probed is on. 'slot' refers
-to the specific slot on the VME bus.
-
-The '.bind_table' is a pointer to an array of type 'vme_device_id':
-
- struct vme_device_id {
- int bus;
- int slot;
- };
-
-Each structure in this array should provide a bus and slot number where the core
-should probe, using the driver's probe routine, for a device on the specified
-VME bus.
-
-The VME subsystem supports a single VME driver per 'slot'. There are considered
-to be 32 slots per bus, one for each slot-ID as defined in the ANSI/VITA 1-1994
-specification and are analogious to the physical slots on the VME backplane.
+Here, 'bus' is the number of the bus the device being probed is on. 'slot'
+refers to the specific slot on the VME bus. The 'num' field refers to the
+sequential device ID for this specific driver.
A function is also provided to unregister the driver from the VME core and is
usually called from the device driver's exit routine: