281 ddi_ufm_op_getcaps()
282 The ddi_ufm_op_getcaps() function is used to indicate
283 which DDI UFM capabilities are supported by this driver
284 instance. Currently there is only a single capability
285 (DDI_UFM_CAP_REPORT) which indicates that the driver is
286 capable of reporting UFM information for this instance.
287 Future UFM versions may add additional capabilities
288 such as the ability to obtain a raw dump of the
289 firmware image or to upgrade the firmware.
290
291 The driver should indicate the supported capabilities
292 by setting the value in the caps parameter. Once the
293 driver has populated caps with an appropriate value,
294 then the driver should return 0. Otherwise, the driver
295 should return the appropriate error number. For a full
296 list of error numbers, see Intro(2). Common values
297 are:
298
299 EIO An error occurred talking to
300 the device while trying to
301 discover firmware capabilties.
302
303 ENOMEM The driver was unable to
304 allocate memory.
305
306 Caching and Updates
307 The system will fetch firmware and slot information on an as-needed
308 basis. Once it obtains some information, it may end up caching this
309 information on behalf of the driver. Whenever the driver believes that
310 something could have changed -- it need know that it has -- then the
311 driver must call ddi_ufm_update(9F).
312
313 Locking
314 All UFM operations on a single UFM handle will always be run serially.
315 However, the device driver may still need to apply adequate locking to
316 its structure members as other may be accessing the same data structure
317 or trying to communicate with the device.
318
319 Unregistering from the UFM subsystem
320 When a device driver is detached, it should unregister from the UFM
321 subsystem. To do so, the driver should call ddi_ufm_fini(9F). By the
322 time this function returns, the driver is guaranteed that no UFM entry
323 points will be called. However, if there are outstanding UFM related
324 activity, the function will block until it is terminated.
325
326 ioctl Interface
327 Userland consumers can access UFM information via a set of ioctls that
328 are implemented by the ufm(7D) driver.
329
330 CONTEXT
331 The various UFM entry points that a device driver must implement will
332 always be called from kernel context.
333
334 SEE ALSO
335 Intro(2), ufd(7D), attach(9E), ddi_ufm_fini(9F), ddi_ufm_image(9F),
336 ddi_ufm_image_set_desc(9F), ddi_ufm_image_set_misc(9F),
337 ddi_ufm_image_set_nslots(9F), ddi_ufm_init(9F), ddi_ufm_slot(9F),
338 ddi_ufm_slot_set_attrs(9F), ddi_ufm_slot_set_misc(9F),
339 ddi_ufm_slot_set_version(9F), ddi_ufm_update(9F)
340
341 illumos April 30, 2019 illumos
|
281 ddi_ufm_op_getcaps()
282 The ddi_ufm_op_getcaps() function is used to indicate
283 which DDI UFM capabilities are supported by this driver
284 instance. Currently there is only a single capability
285 (DDI_UFM_CAP_REPORT) which indicates that the driver is
286 capable of reporting UFM information for this instance.
287 Future UFM versions may add additional capabilities
288 such as the ability to obtain a raw dump of the
289 firmware image or to upgrade the firmware.
290
291 The driver should indicate the supported capabilities
292 by setting the value in the caps parameter. Once the
293 driver has populated caps with an appropriate value,
294 then the driver should return 0. Otherwise, the driver
295 should return the appropriate error number. For a full
296 list of error numbers, see Intro(2). Common values
297 are:
298
299 EIO An error occurred talking to
300 the device while trying to
301 discover firmware capabilities.
302
303 ENOMEM The driver was unable to
304 allocate memory.
305
306 Caching and Updates
307 The system will fetch firmware and slot information on an as-needed
308 basis. Once it obtains some information, it may end up caching this
309 information on behalf of the driver. Whenever the driver believes that
310 something could have changed -- it need know that it has -- then the
311 driver must call ddi_ufm_update(9F).
312
313 Locking
314 All UFM operations on a single UFM handle will always be run serially.
315 However, the device driver may still need to apply adequate locking to
316 its structure members as other may be accessing the same data structure
317 or trying to communicate with the device.
318
319 Unregistering from the UFM subsystem
320 When a device driver is detached, it should unregister from the UFM
321 subsystem. To do so, the driver should call ddi_ufm_fini(9F). By the
322 time this function returns, the driver is guaranteed that no UFM entry
323 points will be called. However, if there are outstanding UFM related
324 activity, the function will block until it is terminated.
325
326 ioctl Interface
327 Userland consumers can access UFM information via a set of ioctls that
328 are implemented by the ufm(7D) driver.
329
330 CONTEXT
331 The various UFM entry points that a device driver must implement will
332 always be called from kernel context.
333
334 SEE ALSO
335 Intro(2), ufd(7D), attach(9E), ddi_ufm_fini(9F), ddi_ufm_image(9F),
336 ddi_ufm_image_set_desc(9F), ddi_ufm_image_set_misc(9F),
337 ddi_ufm_image_set_nslots(9F), ddi_ufm_init(9F), ddi_ufm_slot(9F),
338 ddi_ufm_slot_set_attrs(9F), ddi_ufm_slot_set_misc(9F),
339 ddi_ufm_slot_set_version(9F), ddi_ufm_update(9F)
340
341 illumos February 15, 2020 illumos
|