diff options
Diffstat (limited to 'Documentation/driver-api')
| -rw-r--r-- | Documentation/driver-api/driver-model/devres.rst | 1 | ||||
| -rw-r--r-- | Documentation/driver-api/libata.rst | 25 | ||||
| -rw-r--r-- | Documentation/driver-api/pwm.rst | 13 | ||||
| -rw-r--r-- | Documentation/driver-api/thermal/intel_dptf.rst | 9 |
4 files changed, 34 insertions, 14 deletions
diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst index 3d56f94ac2ee..2b36ebde9cec 100644 --- a/Documentation/driver-api/driver-model/devres.rst +++ b/Documentation/driver-api/driver-model/devres.rst @@ -275,7 +275,6 @@ GPIO devm_gpiod_put() devm_gpiod_unhinge() devm_gpiochip_add_data() - devm_gpio_request() devm_gpio_request_one() I2C diff --git a/Documentation/driver-api/libata.rst b/Documentation/driver-api/libata.rst index 5da27a749246..93d97fe78e3f 100644 --- a/Documentation/driver-api/libata.rst +++ b/Documentation/driver-api/libata.rst @@ -283,18 +283,25 @@ interrupts, start DMA engine, etc. ``->error_handler()`` is a driver's hook into probe, hotplug, and recovery and other exceptional conditions. The primary responsibility of an -implementation is to call :c:func:`ata_do_eh` or :c:func:`ata_bmdma_drive_eh` -with a set of EH hooks as arguments: +implementation is to call :c:func:`ata_std_error_handler`. -'prereset' hook (may be NULL) is called during an EH reset, before any -other actions are taken. +:c:func:`ata_std_error_handler` will perform a standard error handling sequence +to resurect failed devices, detach lost devices and add new devices (if any). +This function will call the various reset operations for a port, as needed. +These operations are as follows. -'postreset' hook (may be NULL) is called after the EH reset is -performed. Based on existing conditions, severity of the problem, and -hardware capabilities, +* The 'prereset' operation (which may be NULL) is called during an EH reset, + before any other action is taken. -Either 'softreset' (may be NULL) or 'hardreset' (may be NULL) will be -called to perform the low-level EH reset. +* The 'postreset' hook (which may be NULL) is called after the EH reset is + performed. Based on existing conditions, severity of the problem, and hardware + capabilities, + +* Either the 'softreset' operation or the 'hardreset' operation will be called + to perform the low-level EH reset. If both operations are defined, + 'hardreset' is preferred and used. If both are not defined, no low-level reset + is performed and EH assumes that an ATA class device is connected through the + link. :: diff --git a/Documentation/driver-api/pwm.rst b/Documentation/driver-api/pwm.rst index b41b1c56477f..0d27a40f5818 100644 --- a/Documentation/driver-api/pwm.rst +++ b/Documentation/driver-api/pwm.rst @@ -173,10 +173,15 @@ Locking ------- The PWM core list manipulations are protected by a mutex, so pwm_get() -and pwm_put() may not be called from an atomic context. Currently the -PWM core does not enforce any locking to pwm_enable(), pwm_disable() and -pwm_config(), so the calling context is currently driver specific. This -is an issue derived from the former barebone API and should be fixed soon. +and pwm_put() may not be called from an atomic context. +Most functions in the PWM consumer API might sleep and so must not be called +from atomic context. The notable exception is pwm_apply_atomic() which has the +same semantics as pwm_apply_might_sleep() but can be called from atomic context. +(The price for that is that it doesn't work for all PWM devices, use +pwm_might_sleep() to check if a given PWM supports atomic operation. + +Locking in the PWM core ensures that callbacks related to a single chip are +serialized. Helpers ------- diff --git a/Documentation/driver-api/thermal/intel_dptf.rst b/Documentation/driver-api/thermal/intel_dptf.rst index ec5769accae0..c51ac793dc06 100644 --- a/Documentation/driver-api/thermal/intel_dptf.rst +++ b/Documentation/driver-api/thermal/intel_dptf.rst @@ -206,6 +206,15 @@ All these controls needs admin privilege to update. Update a new temperature target in milli degree celsius for hardware to use for the temperature control. +``thermal_tolerance`` (RW) + This attribute ranges from 0 to 7, where 0 represents + the most aggressive control to avoid any temperature overshoots, and + 7 represents a more graceful approach, favoring performance even at + the expense of temperature overshoots. + Note: This level may not scale linearly. For example, a value of 3 does + not necessarily imply a 50% improvement in performance compared to a + value of 0. + Given that this is platform temperature control, it is expected that a single user-level manager owns and manages the controls. If multiple user-level software applications attempt to write different targets, it |