Lines Matching refs:bus
15 at the bus driver layer. This was intentional, to minimize the
17 of bus drivers.
20 be embedded in larger, bus-specific objects. Fields in these generic
21 objects can replace fields in the bus-specific objects.
35 Step 1: Registering the bus driver.
38 - Define a struct bus_type for the bus driver.
45 - Register the bus type.
46 This should be done in the initialization function for the bus type,
57 The bus type may be unregistered (if the bus driver may be compiled
63 - Export the bus type for others to use.
65 Other code may wish to reference the bus type, so declare it in a
79 - This will cause the bus to show up in /sys/bus/pci/ with two
82 # tree -d /sys/bus/pci/
83 /sys/bus/pci/
95 - Embed a struct device in the bus-specific device type.
125 When devices are discovered or registered with the bus type, the
126 bus driver should initialize the generic device. The most important
127 things to initialize are the bus_id, parent, and bus fields.
130 the bus. The format of this string is bus-specific. This is
134 the bus driver sets this field correctly.
147 The device's bus field is a pointer to the bus type the device
151 Optionally, the bus driver may set the device's name and release
175 If a bus driver unregisters a device, it should not immediately free
177 device's release method, then free the bus-specific object.
206 Also, symlinks are created in the bus's 'devices' directory
209 /sys/bus/pci/devices/
232 - Embed a struct device_driver in the bus-specific driver.
244 When the driver registers with the bus (e.g. doing pci_register_driver()),
245 initialize the necessary fields of the driver: the name and bus
257 When the driver is unregistered from the bus, unregister it from the
268 Drivers are exported via sysfs in their bus's 'driver's directory.
271 /sys/bus/pci/drivers/
283 operations the bus already defines for drivers, but taking different
286 It would be difficult and tedious to force every driver on a bus to
288 bus driver should define single instances of the generic methods that
289 forward call to the bus-specific drivers. For instance:
311 drv->driver.bus = &pci_bus_type;
321 Ideally, the bus should only initialize the fields if they are not
329 registered with the bus at any time. When registration happens,
334 bus driver compares these IDs to the IDs of devices registered with it.
336 bus-specific, so the generic model does attempt to generalize them.
338 Instead, a bus may supply a method in struct bus_type that does the
346 When a device is registered, the bus's list of drivers is iterated
347 over. bus->match() is called for each one until a match is found.
349 When a driver is registered, the bus's list of devices is iterated
350 over. bus->match() is called for each device that is not already
358 /sys/bus/pci/drivers/
370 mechanism the bus currently uses.
386 A bus driver may also supply additional parameters for userspace to
387 consume. To do this, a bus must implement the 'hotplug' method in
396 Step 7: Cleaning up the bus driver.
398 The generic bus, device, and driver structures provide several fields
399 that can replace those defined privately to the bus driver.
403 struct bus_type contains a list of all devices registered with the bus
404 type. This includes all devices on all instances of that bus type.
405 An internal list that the bus uses may be removed, in favor of using
410 int bus_for_each_dev(struct bus_type * bus, struct device * start,
417 it. An internal list of drivers that the bus driver maintains may
422 int bus_for_each_drv(struct bus_type * bus, struct device_driver * start,
426 Please see drivers/base/bus.c for more information.
432 the device and driver lists. This can be used by the bus driver
434 lists the bus maintains.
440 fields in the bus-specific representations of these objects. Feel free
441 to remove the bus-specific ones and favor the generic ones. Note
443 reference the bus-specific fields (though those should all be 1-line