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/serial/driver.rst | 7 | ||||
| -rw-r--r-- | Documentation/driver-api/thermal/intel_dptf.rst | 9 | ||||
| -rw-r--r-- | Documentation/driver-api/tty/tty_port.rst | 5 | ||||
| -rw-r--r-- | Documentation/driver-api/usb/anchors.rst | 11 |
7 files changed, 40 insertions, 31 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/serial/driver.rst b/Documentation/driver-api/serial/driver.rst index fa1ebfcd4472..c1db6a1a67c4 100644 --- a/Documentation/driver-api/serial/driver.rst +++ b/Documentation/driver-api/serial/driver.rst @@ -24,9 +24,8 @@ console support. Console Support --------------- -The serial core provides a few helper functions. This includes identifying -the correct port structure (via uart_get_console()) and decoding command line -arguments (uart_parse_options()). +The serial core provides a few helper functions. This includes +decoding command line arguments (uart_parse_options()). There is also a helper function (uart_console_write()) which performs a character by character write, translating newlines to CRLF sequences. @@ -76,7 +75,7 @@ Other functions uart_add_one_port uart_remove_one_port uart_console_write uart_parse_earlycon uart_parse_options uart_set_options uart_get_lsr_info uart_handle_dcd_change uart_handle_cts_change - uart_try_toggle_sysrq uart_get_console + uart_try_toggle_sysrq .. kernel-doc:: include/linux/serial_core.h :identifiers: uart_port_tx_limited uart_port_tx 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 diff --git a/Documentation/driver-api/tty/tty_port.rst b/Documentation/driver-api/tty/tty_port.rst index 5cb90e954fcf..504a353f2682 100644 --- a/Documentation/driver-api/tty/tty_port.rst +++ b/Documentation/driver-api/tty/tty_port.rst @@ -42,9 +42,10 @@ TTY Refcounting TTY Helpers ----------- +.. kernel-doc:: include/linux/tty_port.h + :identifiers: tty_port_tty_hangup tty_port_tty_vhangup .. kernel-doc:: drivers/tty/tty_port.c - :identifiers: tty_port_tty_hangup tty_port_tty_wakeup - + :identifiers: tty_port_tty_wakeup Modem Signals ------------- diff --git a/Documentation/driver-api/usb/anchors.rst b/Documentation/driver-api/usb/anchors.rst index 4b248e691bd6..5a93d171e76c 100644 --- a/Documentation/driver-api/usb/anchors.rst +++ b/Documentation/driver-api/usb/anchors.rst @@ -45,17 +45,6 @@ This function kills all URBs associated with an anchor. The URBs are called in the reverse temporal order they were submitted. This way no data can be reordered. -:c:func:`usb_unlink_anchored_urbs` ----------------------------------- - - -This function unlinks all URBs associated with an anchor. The URBs -are processed in the reverse temporal order they were submitted. -This is similar to :c:func:`usb_kill_anchored_urbs`, but it will not sleep. -Therefore no guarantee is made that the URBs have been unlinked when -the call returns. They may be unlinked later but will be unlinked in -finite time. - :c:func:`usb_scuttle_anchored_urbs` ----------------------------------- |