Lines Matching +full:hardware +full:- +full:bound

42 model because the bus they belong to has a bus-specific structure with
43 bus-specific fields that cannot be generalized.
48 completely bus-specific. Defining them as bus-specific entities would
49 sacrifice type-safety, so we keep bus-specific structures around.
51 Bus-specific drivers should include a generic struct device_driver in
52 the definition of the bus-specific driver. Like this::
59 A definition that included bus-specific fields would look like
85 no bus-specific fields (i.e. don't have a bus-specific driver
89 Most drivers, however, will have a bus-specific structure and will
105 define generic callbacks that forward the call to the bus-specific
123 The devices field is a list of all the devices that have been bound to
152 and the driver partially bound to the device.  Drivers commonly use
153 container_of() to convert "dev" to a bus-specific type, both in probe()
156 addition to dev->platform_data to initialize the driver.
158 This callback holds the driver-specific logic to bind the driver to a
161 be allocated and initialized, and that any hardware can be initialized.
163 When the driver has successfully bound itself to that device, then probe()
171 Optionally, probe() may return -EPROBE_DEFER if the driver depends on
175 must defer, it should return -EPROBE_DEFER as early as possible to
180       -EPROBE_DEFER must not be returned if probe() has already created
182       in a cleanup path. If -EPROBE_DEFER is returned after a child
212 and at a particular hardware configuration by the bootloader, the device's
215 probed, the device's driver can synchronize the hardware state of the device to
243 it into a supported low-power state.