summaryrefslogtreecommitdiff
path: root/Documentation/driver-api
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/driver-api')
-rw-r--r--Documentation/driver-api/crypto/iaa/iaa-crypto.rst2
-rw-r--r--Documentation/driver-api/dpll.rst18
-rw-r--r--Documentation/driver-api/early-userspace/buffer-format.rst5
-rw-r--r--Documentation/driver-api/gpio/board.rst65
-rw-r--r--Documentation/driver-api/gpio/index.rst1
-rw-r--r--Documentation/driver-api/gpio/legacy-boards.rst298
-rw-r--r--Documentation/driver-api/media/camera-sensor.rst24
-rw-r--r--Documentation/driver-api/media/maintainer-entry-profile.rst4
-rw-r--r--Documentation/driver-api/media/v4l2-fh.rst59
-rw-r--r--Documentation/driver-api/pin-control.rst4
10 files changed, 434 insertions, 46 deletions
diff --git a/Documentation/driver-api/crypto/iaa/iaa-crypto.rst b/Documentation/driver-api/crypto/iaa/iaa-crypto.rst
index 8e50b900d51c..f815d4fd8372 100644
--- a/Documentation/driver-api/crypto/iaa/iaa-crypto.rst
+++ b/Documentation/driver-api/crypto/iaa/iaa-crypto.rst
@@ -476,7 +476,6 @@ Use the following commands to enable zswap::
# echo 0 > /sys/module/zswap/parameters/enabled
# echo 50 > /sys/module/zswap/parameters/max_pool_percent
# echo deflate-iaa > /sys/module/zswap/parameters/compressor
- # echo zsmalloc > /sys/module/zswap/parameters/zpool
# echo 1 > /sys/module/zswap/parameters/enabled
# echo 100 > /proc/sys/vm/swappiness
# echo never > /sys/kernel/mm/transparent_hugepage/enabled
@@ -625,7 +624,6 @@ the 'fixed' compression mode::
echo 0 > /sys/module/zswap/parameters/enabled
echo 50 > /sys/module/zswap/parameters/max_pool_percent
echo deflate-iaa > /sys/module/zswap/parameters/compressor
- echo zsmalloc > /sys/module/zswap/parameters/zpool
echo 1 > /sys/module/zswap/parameters/enabled
echo 100 > /proc/sys/vm/swappiness
diff --git a/Documentation/driver-api/dpll.rst b/Documentation/driver-api/dpll.rst
index eca72d9b9ed8..be1fc643b645 100644
--- a/Documentation/driver-api/dpll.rst
+++ b/Documentation/driver-api/dpll.rst
@@ -179,7 +179,23 @@ Phase offset measurement and adjustment
Device may provide ability to measure a phase difference between signals
on a pin and its parent dpll device. If pin-dpll phase offset measurement
is supported, it shall be provided with ``DPLL_A_PIN_PHASE_OFFSET``
-attribute for each parent dpll device.
+attribute for each parent dpll device. The reported phase offset may be
+computed as the average of prior values and the current measurement, using
+the following formula:
+
+.. math::
+ curr\_avg = prev\_avg * \frac{2^N-1}{2^N} + new\_val * \frac{1}{2^N}
+
+where `curr_avg` is the current reported phase offset, `prev_avg` is the
+previously reported value, `new_val` is the current measurement, and `N` is
+the averaging factor. Configured averaging factor value is provided with
+``DPLL_A_PHASE_OFFSET_AVG_FACTOR`` attribute of a device and value change can
+be requested with the same attribute with ``DPLL_CMD_DEVICE_SET`` command.
+
+ ================================== ======================================
+ ``DPLL_A_PHASE_OFFSET_AVG_FACTOR`` attr configured value of phase offset
+ averaging factor
+ ================================== ======================================
Device may also provide ability to adjust a signal phase on a pin.
If pin phase adjustment is supported, minimal and maximal values that pin
diff --git a/Documentation/driver-api/early-userspace/buffer-format.rst b/Documentation/driver-api/early-userspace/buffer-format.rst
index 726bfa2fe70d..4597a91100b7 100644
--- a/Documentation/driver-api/early-userspace/buffer-format.rst
+++ b/Documentation/driver-api/early-userspace/buffer-format.rst
@@ -86,6 +86,11 @@ c_mtime is ignored unless CONFIG_INITRAMFS_PRESERVE_MTIME=y is set.
The c_filesize should be zero for any file which is not a regular file
or symlink.
+c_namesize may account for more than one trailing '\0', as long as the
+value doesn't exceed PATH_MAX. This can be useful for ensuring that a
+subsequent file data segment is aligned, e.g. to a filesystem block
+boundary.
+
The c_chksum field contains a simple 32-bit unsigned sum of all the
bytes in the data field. cpio(1) refers to this as "crc", which is
clearly incorrect (a cyclic redundancy check is a different and
diff --git a/Documentation/driver-api/gpio/board.rst b/Documentation/driver-api/gpio/board.rst
index 4fd1cbd8296e..069b54d8591b 100644
--- a/Documentation/driver-api/gpio/board.rst
+++ b/Documentation/driver-api/gpio/board.rst
@@ -94,6 +94,71 @@ with the help of _DSD (Device Specific Data), introduced in ACPI 5.1::
For more information about the ACPI GPIO bindings see
Documentation/firmware-guide/acpi/gpio-properties.rst.
+Software Nodes
+--------------
+
+Software nodes allow board-specific code to construct an in-memory,
+device-tree-like structure using struct software_node and struct
+property_entry. This structure can then be associated with a platform device,
+allowing drivers to use the standard device properties API to query
+configuration, just as they would on an ACPI or device tree system.
+
+Software-node-backed GPIOs are described using the ``PROPERTY_ENTRY_GPIO()``
+macro, which ties a software node representing the GPIO controller with
+consumer device. It allows consumers to use regular gpiolib APIs, such as
+gpiod_get(), gpiod_get_optional().
+
+The software node representing a GPIO controller need not be attached to the
+GPIO controller device. The only requirement is that the node must be
+registered and its name must match the GPIO controller's label.
+
+For example, here is how to describe a single GPIO-connected LED. This is an
+alternative to using platform_data on legacy systems.
+
+.. code-block:: c
+
+ #include <linux/property.h>
+ #include <linux/gpio/machine.h>
+ #include <linux/gpio/property.h>
+
+ /*
+ * 1. Define a node for the GPIO controller. Its .name must match the
+ * controller's label.
+ */
+ static const struct software_node gpio_controller_node = {
+ .name = "gpio-foo",
+ };
+
+ /* 2. Define the properties for the LED device. */
+ static const struct property_entry led_device_props[] = {
+ PROPERTY_ENTRY_STRING("label", "myboard:green:status"),
+ PROPERTY_ENTRY_STRING("linux,default-trigger", "heartbeat"),
+ PROPERTY_ENTRY_GPIO("gpios", &gpio_controller_node, 42, GPIO_ACTIVE_HIGH),
+ { }
+ };
+
+ /* 3. Define the software node for the LED device. */
+ static const struct software_node led_device_swnode = {
+ .name = "status-led",
+ .properties = led_device_props,
+ };
+
+ /*
+ * 4. Register the software nodes and the platform device.
+ */
+ const struct software_node *swnodes[] = {
+ &gpio_controller_node,
+ &led_device_swnode,
+ NULL
+ };
+ software_node_register_node_group(swnodes);
+
+ // Then register a platform_device for "leds-gpio" and associate
+ // it with &led_device_swnode via .fwnode.
+
+For a complete guide on converting board files to use software nodes, see
+Documentation/driver-api/gpio/legacy-boards.rst.
+
Platform Data
-------------
Finally, GPIOs can be bound to devices and functions using platform data. Board
diff --git a/Documentation/driver-api/gpio/index.rst b/Documentation/driver-api/gpio/index.rst
index 43f6a3afe10b..87929840e85a 100644
--- a/Documentation/driver-api/gpio/index.rst
+++ b/Documentation/driver-api/gpio/index.rst
@@ -12,6 +12,7 @@ Contents:
driver
consumer
board
+ legacy-boards
drivers-on-gpio
bt8xxgpio
diff --git a/Documentation/driver-api/gpio/legacy-boards.rst b/Documentation/driver-api/gpio/legacy-boards.rst
new file mode 100644
index 000000000000..46e3a26dba77
--- /dev/null
+++ b/Documentation/driver-api/gpio/legacy-boards.rst
@@ -0,0 +1,298 @@
+Supporting Legacy Boards
+========================
+
+Many drivers in the kernel, such as ``leds-gpio`` and ``gpio-keys``, are
+migrating away from using board-specific ``platform_data`` to a unified device
+properties interface. This interface allows drivers to be simpler and more
+generic, as they can query properties in a standardized way.
+
+On modern systems, these properties are provided via device tree. However, some
+older platforms have not been converted to device tree and instead rely on
+board files to describe their hardware configuration. To bridge this gap and
+allow these legacy boards to work with modern, generic drivers, the kernel
+provides a mechanism called **software nodes**.
+
+This document provides a guide on how to convert a legacy board file from using
+``platform_data`` and ``gpiod_lookup_table`` to the modern software node
+approach for describing GPIO-connected devices.
+
+The Core Idea: Software Nodes
+-----------------------------
+
+Software nodes allow board-specific code to construct an in-memory,
+device-tree-like structure using struct software_node and struct
+property_entry. This structure can then be associated with a platform device,
+allowing drivers to use the standard device properties API (e.g.,
+device_property_read_u32(), device_property_read_string()) to query
+configuration, just as they would on an ACPI or device tree system.
+
+The gpiolib code has support for handling software nodes, so that if GPIO is
+described properly, as detailed in the section below, then regular gpiolib APIs,
+such as gpiod_get(), gpiod_get_optional(), and others will work.
+
+Requirements for GPIO Properties
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+When using software nodes to describe GPIO connections, the following
+requirements must be met for the GPIO core to correctly resolve the reference:
+
+1. **The GPIO controller's software node "name" must match the controller's
+ "label".** The gpiolib core uses this name to find the corresponding
+ struct gpio_chip at runtime.
+ This software node has to be registered, but need not be attached to the
+ device representing the GPIO controller that is providing the GPIO in
+ question. It may be left as a "free floating" node.
+
+2. **The GPIO property must be a reference.** The ``PROPERTY_ENTRY_GPIO()``
+ macro handles this as it is an alias for ``PROPERTY_ENTRY_REF()``.
+
+3. **The reference must have exactly two arguments:**
+
+ - The first argument is the GPIO offset within the controller.
+ - The second argument is the flags for the GPIO line (e.g.,
+ GPIO_ACTIVE_HIGH, GPIO_ACTIVE_LOW).
+
+The ``PROPERTY_ENTRY_GPIO()`` macro is the preferred way of defining GPIO
+properties in software nodes.
+
+Conversion Example
+------------------
+
+Let's walk through an example of converting a board file that defines a GPIO-
+connected LED and a button.
+
+Before: Using Platform Data
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+A typical legacy board file might look like this:
+
+.. code-block:: c
+
+ #include <linux/platform_device.h>
+ #include <linux/leds.h>
+ #include <linux/gpio_keys.h>
+ #include <linux/gpio/machine.h>
+
+ #define MYBOARD_GPIO_CONTROLLER "gpio-foo"
+
+ /* LED setup */
+ static const struct gpio_led myboard_leds[] = {
+ {
+ .name = "myboard:green:status",
+ .default_trigger = "heartbeat",
+ },
+ };
+
+ static const struct gpio_led_platform_data myboard_leds_pdata = {
+ .num_leds = ARRAY_SIZE(myboard_leds),
+ .leds = myboard_leds,
+ };
+
+ static struct gpiod_lookup_table myboard_leds_gpios = {
+ .dev_id = "leds-gpio",
+ .table = {
+ GPIO_LOOKUP_IDX(MYBOARD_GPIO_CONTROLLER, 42, NULL, 0, GPIO_ACTIVE_HIGH),
+ { },
+ },
+ };
+
+ /* Button setup */
+ static struct gpio_keys_button myboard_buttons[] = {
+ {
+ .code = KEY_WPS_BUTTON,
+ .desc = "WPS Button",
+ .active_low = 1,
+ },
+ };
+
+ static const struct gpio_keys_platform_data myboard_buttons_pdata = {
+ .buttons = myboard_buttons,
+ .nbuttons = ARRAY_SIZE(myboard_buttons),
+ };
+
+ static struct gpiod_lookup_table myboard_buttons_gpios = {
+ .dev_id = "gpio-keys",
+ .table = {
+ GPIO_LOOKUP_IDX(MYBOARD_GPIO_CONTROLLER, 15, NULL, 0, GPIO_ACTIVE_LOW),
+ { },
+ },
+ };
+
+ /* Device registration */
+ static int __init myboard_init(void)
+ {
+ gpiod_add_lookup_table(&myboard_leds_gpios);
+ gpiod_add_lookup_table(&myboard_buttons_gpios);
+
+ platform_device_register_data(NULL, "leds-gpio", -1,
+ &myboard_leds_pdata, sizeof(myboard_leds_pdata));
+ platform_device_register_data(NULL, "gpio-keys", -1,
+ &myboard_buttons_pdata, sizeof(myboard_buttons_pdata));
+
+ return 0;
+ }
+
+After: Using Software Nodes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Here is how the same configuration can be expressed using software nodes.
+
+Step 1: Define the GPIO Controller Node
+***************************************
+
+First, define a software node that represents the GPIO controller that the
+LEDs and buttons are connected to. The ``name`` of this node must match the
+name of the driver for the GPIO controller (e.g., "gpio-foo").
+
+.. code-block:: c
+
+ #include <linux/property.h>
+ #include <linux/gpio/property.h>
+
+ #define MYBOARD_GPIO_CONTROLLER "gpio-foo"
+
+ static const struct software_node myboard_gpio_controller_node = {
+ .name = MYBOARD_GPIO_CONTROLLER,
+ };
+
+Step 2: Define Consumer Device Nodes and Properties
+***************************************************
+
+Next, define the software nodes for the consumer devices (the LEDs and buttons).
+This involves creating a parent node for each device type and child nodes for
+each individual LED or button.
+
+.. code-block:: c
+
+ /* LED setup */
+ static const struct software_node myboard_leds_node = {
+ .name = "myboard-leds",
+ };
+
+ static const struct property_entry myboard_status_led_props[] = {
+ PROPERTY_ENTRY_STRING("label", "myboard:green:status"),
+ PROPERTY_ENTRY_STRING("linux,default-trigger", "heartbeat"),
+ PROPERTY_ENTRY_GPIO("gpios", &myboard_gpio_controller_node, 42, GPIO_ACTIVE_HIGH),
+ { }
+ };
+
+ static const struct software_node myboard_status_led_swnode = {
+ .name = "status-led",
+ .parent = &myboard_leds_node,
+ .properties = myboard_status_led_props,
+ };
+
+ /* Button setup */
+ static const struct software_node myboard_keys_node = {
+ .name = "myboard-keys",
+ };
+
+ static const struct property_entry myboard_wps_button_props[] = {
+ PROPERTY_ENTRY_STRING("label", "WPS Button"),
+ PROPERTY_ENTRY_U32("linux,code", KEY_WPS_BUTTON),
+ PROPERTY_ENTRY_GPIO("gpios", &myboard_gpio_controller_node, 15, GPIO_ACTIVE_LOW),
+ { }
+ };
+
+ static const struct software_node myboard_wps_button_swnode = {
+ .name = "wps-button",
+ .parent = &myboard_keys_node,
+ .properties = myboard_wps_button_props,
+ };
+
+
+
+Step 3: Group and Register the Nodes
+************************************
+
+For maintainability, it is often beneficial to group all software nodes into a
+single array and register them with one call.
+
+.. code-block:: c
+
+ static const struct software_node * const myboard_swnodes[] = {
+ &myboard_gpio_controller_node,
+ &myboard_leds_node,
+ &myboard_status_led_swnode,
+ &myboard_keys_node,
+ &myboard_wps_button_swnode,
+ NULL
+ };
+
+ static int __init myboard_init(void)
+ {
+ int error;
+
+ error = software_node_register_node_group(myboard_swnodes);
+ if (error) {
+ pr_err("Failed to register software nodes: %d\n", error);
+ return error;
+ }
+
+ // ... platform device registration follows
+ }
+
+.. note::
+ When splitting registration of nodes by devices that they represent, it is
+ essential that the software node representing the GPIO controller itself
+ is registered first, before any of the nodes that reference it.
+
+Step 4: Register Platform Devices with Software Nodes
+*****************************************************
+
+Finally, register the platform devices and associate them with their respective
+software nodes using the ``fwnode`` field in struct platform_device_info.
+
+.. code-block:: c
+
+ static struct platform_device *leds_pdev;
+ static struct platform_device *keys_pdev;
+
+ static int __init myboard_init(void)
+ {
+ struct platform_device_info pdev_info;
+ int error;
+
+ error = software_node_register_node_group(myboard_swnodes);
+ if (error)
+ return error;
+
+ memset(&pdev_info, 0, sizeof(pdev_info));
+ pdev_info.name = "leds-gpio";
+ pdev_info.id = PLATFORM_DEVID_NONE;
+ pdev_info.fwnode = software_node_fwnode(&myboard_leds_node);
+ leds_pdev = platform_device_register_full(&pdev_info);
+ if (IS_ERR(leds_pdev)) {
+ error = PTR_ERR(leds_pdev);
+ goto err_unregister_nodes;
+ }
+
+ memset(&pdev_info, 0, sizeof(pdev_info));
+ pdev_info.name = "gpio-keys";
+ pdev_info.id = PLATFORM_DEVID_NONE;
+ pdev_info.fwnode = software_node_fwnode(&myboard_keys_node);
+ keys_pdev = platform_device_register_full(&pdev_info);
+ if (IS_ERR(keys_pdev)) {
+ error = PTR_ERR(keys_pdev);
+ platform_device_unregister(leds_pdev);
+ goto err_unregister_nodes;
+ }
+
+ return 0;
+
+ err_unregister_nodes:
+ software_node_unregister_node_group(myboard_swnodes);
+ return error;
+ }
+
+ static void __exit myboard_exit(void)
+ {
+ platform_device_unregister(keys_pdev);
+ platform_device_unregister(leds_pdev);
+ software_node_unregister_node_group(myboard_swnodes);
+ }
+
+With these changes, the generic ``leds-gpio`` and ``gpio-keys`` drivers will
+be able to probe successfully and get their configuration from the properties
+defined in the software nodes, removing the need for board-specific platform
+data.
diff --git a/Documentation/driver-api/media/camera-sensor.rst b/Documentation/driver-api/media/camera-sensor.rst
index c290833165e6..94bd1dae82d5 100644
--- a/Documentation/driver-api/media/camera-sensor.rst
+++ b/Documentation/driver-api/media/camera-sensor.rst
@@ -29,21 +29,31 @@ used in the system. Using another frequency may cause harmful effects
elsewhere. Therefore only the pre-determined frequencies are configurable by the
user.
+The external clock frequency shall be retrieved by obtaining the external clock
+using the ``devm_v4l2_sensor_clk_get()`` helper function, and then getting its
+frequency with ``clk_get_rate()``. Usage of the helper function guarantees
+correct behaviour regardless of whether the sensor is integrated in a DT-based
+or ACPI-based system.
+
ACPI
~~~~
-Read the ``clock-frequency`` _DSD property to denote the frequency. The driver
-can rely on this frequency being used.
+ACPI-based systems typically don't register the sensor external clock with the
+kernel, but specify the external clock frequency in the ``clock-frequency``
+_DSD property. The ``devm_v4l2_sensor_clk_get()`` helper creates and returns a
+fixed clock set at that rate.
Devicetree
~~~~~~~~~~
-The preferred way to achieve this is using ``assigned-clocks``,
-``assigned-clock-parents`` and ``assigned-clock-rates`` properties. See the
-`clock device tree bindings
+Devicetree-based systems declare the sensor external clock in the device tree
+and reference it from the sensor node. The preferred way to select the external
+clock frequency is to use the ``assigned-clocks``, ``assigned-clock-parents``
+and ``assigned-clock-rates`` properties in the sensor node to set the clock
+rate. See the `clock device tree bindings
<https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/clock/clock.yaml>`_
-for more information. The driver then gets the frequency using
-``clk_get_rate()``.
+for more information. The ``devm_v4l2_sensor_clk_get()`` helper retrieves and
+returns that clock.
This approach has the drawback that there's no guarantee that the frequency
hasn't been modified directly or indirectly by another driver, or supported by
diff --git a/Documentation/driver-api/media/maintainer-entry-profile.rst b/Documentation/driver-api/media/maintainer-entry-profile.rst
index ad96a89ee916..2127e5b15e8f 100644
--- a/Documentation/driver-api/media/maintainer-entry-profile.rst
+++ b/Documentation/driver-api/media/maintainer-entry-profile.rst
@@ -75,7 +75,7 @@ The media maintainers that work on specific areas of the subsystem are:
Sean Young <sean@mess.org>
- HDMI CEC:
- Hans Verkuil <hverkuil@xs4all.nl>
+ Hans Verkuil <hverkuil@kernel.org>
- Media controller drivers:
Laurent Pinchart <laurent.pinchart@ideasonboard.com>
@@ -84,7 +84,7 @@ The media maintainers that work on specific areas of the subsystem are:
Sakari Ailus <sakari.ailus@linux.intel.com>
- V4L2 drivers and core V4L2 frameworks:
- Hans Verkuil <hverkuil@xs4all.nl>
+ Hans Verkuil <hverkuil@kernel.org>
The subsystem maintainer is:
Mauro Carvalho Chehab <mchehab@kernel.org>
diff --git a/Documentation/driver-api/media/v4l2-fh.rst b/Documentation/driver-api/media/v4l2-fh.rst
index 3eeaa8da0c9e..a934caa483a4 100644
--- a/Documentation/driver-api/media/v4l2-fh.rst
+++ b/Documentation/driver-api/media/v4l2-fh.rst
@@ -1,33 +1,27 @@
.. SPDX-License-Identifier: GPL-2.0
-V4L2 File handlers
-------------------
+V4L2 File handles
+-----------------
-struct v4l2_fh provides a way to easily keep file handle specific
-data that is used by the V4L2 framework.
+struct v4l2_fh provides a way to easily keep file handle specific data that is
+used by the V4L2 framework. Its usage is mandatory in all drivers.
-.. attention::
- New drivers must use struct v4l2_fh
- since it is also used to implement priority handling
- (:ref:`VIDIOC_G_PRIORITY`).
+struct v4l2_fh is allocated in the driver's ``open()`` file operation handler.
+It is typically embedded in a larger driver-specific structure. The
+:c:type:`v4l2_fh` must be initialized with a call to :c:func:`v4l2_fh_init`,
+and added to the video device with :c:func:`v4l2_fh_add`. This associates the
+:c:type:`v4l2_fh` with the :c:type:`file` by setting ``file->private_data`` to
+point to the :c:type:`v4l2_fh`.
-The users of :c:type:`v4l2_fh` (in the V4L2 framework, not the driver) know
-whether a driver uses :c:type:`v4l2_fh` as its ``file->private_data`` pointer
-by testing the ``V4L2_FL_USES_V4L2_FH`` bit in :c:type:`video_device`->flags.
-This bit is set whenever :c:func:`v4l2_fh_init` is called.
+Similarly, the struct v4l2_fh is freed in the driver's ``release()`` file
+operation handler. It must be removed from the video device with
+:c:func:`v4l2_fh_del` and cleaned up with :c:func:`v4l2_fh_exit` before being
+freed.
-struct v4l2_fh is allocated as a part of the driver's own file handle
-structure and ``file->private_data`` is set to it in the driver's ``open()``
-function by the driver.
-
-In many cases the struct v4l2_fh will be embedded in a larger
-structure. In that case you should call:
-
-#) :c:func:`v4l2_fh_init` and :c:func:`v4l2_fh_add` in ``open()``
-#) :c:func:`v4l2_fh_del` and :c:func:`v4l2_fh_exit` in ``release()``
-
-Drivers can extract their own file handle structure by using the container_of
-macro.
+Drivers must not access ``file->private_data`` directly. They can retrieve the
+:c:type:`v4l2_fh` associated with a :c:type:`file` by calling
+:c:func:`file_to_v4l2_fh`. Drivers can extract their own file handle structure
+by using the container_of macro.
Example:
@@ -56,18 +50,17 @@ Example:
...
- file->private_data = &my_fh->fh;
- v4l2_fh_add(&my_fh->fh);
+ v4l2_fh_add(&my_fh->fh, file);
return 0;
}
int my_release(struct file *file)
{
- struct v4l2_fh *fh = file->private_data;
+ struct v4l2_fh *fh = file_to_v4l2_fh(file);
struct my_fh *my_fh = container_of(fh, struct my_fh, fh);
...
- v4l2_fh_del(&my_fh->fh);
+ v4l2_fh_del(&my_fh->fh, file);
v4l2_fh_exit(&my_fh->fh);
kfree(my_fh);
return 0;
@@ -78,19 +71,17 @@ Below is a short description of the :c:type:`v4l2_fh` functions used:
:c:func:`v4l2_fh_init <v4l2_fh_init>`
(:c:type:`fh <v4l2_fh>`, :c:type:`vdev <video_device>`)
-
- Initialise the file handle. This **MUST** be performed in the driver's
:c:type:`v4l2_file_operations`->open() handler.
-
:c:func:`v4l2_fh_add <v4l2_fh_add>`
-(:c:type:`fh <v4l2_fh>`)
+(:c:type:`fh <v4l2_fh>`, struct file \*filp)
- Add a :c:type:`v4l2_fh` to :c:type:`video_device` file handle list.
Must be called once the file handle is completely initialized.
:c:func:`v4l2_fh_del <v4l2_fh_del>`
-(:c:type:`fh <v4l2_fh>`)
+(:c:type:`fh <v4l2_fh>`, struct file \*filp)
- Unassociate the file handle from :c:type:`video_device`. The file handle
exit function may now be called.
@@ -101,6 +92,10 @@ Below is a short description of the :c:type:`v4l2_fh` functions used:
- Uninitialise the file handle. After uninitialisation the :c:type:`v4l2_fh`
memory can be freed.
+:c:func:`file_to_v4l2_fh <file_to_v4l2_fh>`
+(struct file \*filp)
+
+- Retrieve the :c:type:`v4l2_fh` instance associated with a :c:type:`file`.
If struct v4l2_fh is not embedded, then you can use these helper functions:
diff --git a/Documentation/driver-api/pin-control.rst b/Documentation/driver-api/pin-control.rst
index 27ea1236307e..8208924e513e 100644
--- a/Documentation/driver-api/pin-control.rst
+++ b/Documentation/driver-api/pin-control.rst
@@ -863,7 +863,7 @@ has to be handled by the ``<linux/gpio/consumer.h>`` interface. Instead view thi
a certain pin config setting. Look in e.g. ``<linux/pinctrl/pinconf-generic.h>``
and you find this in the documentation:
- PIN_CONFIG_OUTPUT:
+ PIN_CONFIG_LEVEL:
this will configure the pin in output, use argument
1 to indicate high level, argument 0 to indicate low level.
@@ -897,7 +897,7 @@ And your machine configuration may look like this:
};
static unsigned long uart_sleep_mode[] = {
- PIN_CONF_PACKED(PIN_CONFIG_OUTPUT, 0),
+ PIN_CONF_PACKED(PIN_CONFIG_LEVEL, 0),
};
static struct pinctrl_map pinmap[] __initdata = {