Merge tag 'net-next-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-nextgrafted

Pull networking updates from Jakub Kicinski:
 "Core:

   - Add dedicated kmem_cache for typical/small skb->head, avoid having
     to access struct page at kfree time, and improve memory use.

   - Introduce sysctl to set default RPS configuration for new netdevs.

   - Define Netlink protocol specification format which can be used to
     describe messages used by each family and auto-generate parsers.
     Add tools for generating kernel data structures and uAPI headers.

   - Expose all net/core sysctls inside netns.

   - Remove 4s sleep in netpoll if carrier is instantly detected on
     boot.

   - Add configurable limit of MDB entries per port, and port-vlan.

   - Continue populating drop reasons throughout the stack.

   - Retire a handful of legacy Qdiscs and classifiers.

  Protocols:

   - Support IPv4 big TCP (TSO frames larger than 64kB).

   - Add IP_LOCAL_PORT_RANGE socket option, to control local port range
     on socket by socket basis.

   - Track and report in procfs number of MPTCP sockets used.

   - Support mixing IPv4 and IPv6 flows in the in-kernel MPTCP path
     manager.

   - IPv6: don't check net.ipv6.route.max_size and rely on garbage
     collection to free memory (similarly to IPv4).

   - Support Penultimate Segment Pop (PSP) flavor in SRv6 (RFC8986).

   - ICMP: add per-rate limit counters.

   - Add support for user scanning requests in ieee802154.

   - Remove static WEP support.

   - Support minimal Wi-Fi 7 Extremely High Throughput (EHT) rate
     reporting.

   - WiFi 7 EHT channel puncturing support (client & AP).

  BPF:

   - Add a rbtree data structure following the "next-gen data structure"
     precedent set by recently added linked list, that is, by using
     kfunc + kptr instead of adding a new BPF map type.

   - Expose XDP hints via kfuncs with initial support for RX hash and
     timestamp metadata.

   - Add BPF_F_NO_TUNNEL_KEY extension to bpf_skb_set_tunnel_key to
     better support decap on GRE tunnel devices not operating in collect
     metadata.

   - Improve x86 JIT's codegen for PROBE_MEM runtime error checks.

   - Remove the need for trace_printk_lock for bpf_trace_printk and
     bpf_trace_vprintk helpers.

   - Extend libbpf's bpf_tracing.h support for tracing arguments of
     kprobes/uprobes and syscall as a special case.

   - Significantly reduce the search time for module symbols by
     livepatch and BPF.

   - Enable cpumasks to be used as kptrs, which is useful for tracing
     programs tracking which tasks end up running on which CPUs in
     different time intervals.

   - Add support for BPF trampoline on s390x and riscv64.

   - Add capability to export the XDP features supported by the NIC.

   - Add __bpf_kfunc tag for marking kernel functions as kfuncs.

   - Add cgroup.memory=nobpf kernel parameter option to disable BPF
     memory accounting for container environments.

  Netfilter:

   - Remove the CLUSTERIP target. It has been marked as obsolete for
     years, and we still have WARN splats wrt races of the out-of-band
     /proc interface installed by this target.

   - Add 'destroy' commands to nf_tables. They are identical to the
     existing 'delete' commands, but do not return an error if the
     referenced object (set, chain, rule...) did not exist.

  Driver API:

   - Improve cpumask_local_spread() locality to help NICs set the right
     IRQ affinity on AMD platforms.

   - Separate C22 and C45 MDIO bus transactions more clearly.

   - Introduce new DCB table to control DSCP rewrite on egress.

   - Support configuration of Physical Layer Collision Avoidance (PLCA)
     Reconciliation Sublayer (RS) (802.3cg-2019). Modern version of
     shared medium Ethernet.

   - Support for MAC Merge layer (IEEE 802.3-2018 clause 99). Allowing
     preemption of low priority frames by high priority frames.

   - Add support for controlling MACSec offload using netlink SET.

   - Rework devlink instance refcounts to allow registration and
     de-registration under the instance lock. Split the code into
     multiple files, drop some of the unnecessarily granular locks and
     factor out common parts of netlink operation handling.

   - Add TX frame aggregation parameters (for USB drivers).

   - Add a new attr TCA_EXT_WARN_MSG to report TC (offload) warning
     messages with notifications for debug.

   - Allow offloading of UDP NEW connections via act_ct.

   - Add support for per action HW stats in TC.

   - Support hardware miss to TC action (continue processing in SW from
     a specific point in the action chain).

   - Warn if old Wireless Extension user space interface is used with
     modern cfg80211/mac80211 drivers. Do not support Wireless
     Extensions for Wi-Fi 7 devices at all. Everyone should switch to
     using nl80211 interface instead.

   - Improve the CAN bit timing configuration. Use extack to return
     error messages directly to user space, update the SJW handling,
     including the definition of a new default value that will benefit
     CAN-FD controllers, by increasing their oscillator tolerance.

  New hardware / drivers:

   - Ethernet:
      - nVidia BlueField-3 support (control traffic driver)
      - Ethernet support for imx93 SoCs
      - Motorcomm yt8531 gigabit Ethernet PHY
      - onsemi NCN26000 10BASE-T1S PHY (with support for PLCA)
      - Microchip LAN8841 PHY (incl. cable diagnostics and PTP)
      - Amlogic gxl MDIO mux

   - WiFi:
      - RealTek RTL8188EU (rtl8xxxu)
      - Qualcomm Wi-Fi 7 devices (ath12k)

   - CAN:
      - Renesas R-Car V4H

  Drivers:

   - Bluetooth:
      - Set Per Platform Antenna Gain (PPAG) for Intel controllers.

   - Ethernet NICs:
      - Intel (1G, igc):
         - support TSN / Qbv / packet scheduling features of i226 model
      - Intel (100G, ice):
         - use GNSS subsystem instead of TTY
         - multi-buffer XDP support
         - extend support for GPIO pins to E823 devices
      - nVidia/Mellanox:
         - update the shared buffer configuration on PFC commands
         - implement PTP adjphase function for HW offset control
         - TC support for Geneve and GRE with VF tunnel offload
         - more efficient crypto key management method
         - multi-port eswitch support
      - Netronome/Corigine:
         - add DCB IEEE support
         - support IPsec offloading for NFP3800
      - Freescale/NXP (enetc):
         - support XDP_REDIRECT for XDP non-linear buffers
         - improve reconfig, avoid link flap and waiting for idle
         - support MAC Merge layer
      - Other NICs:
         - sfc/ef100: add basic devlink support for ef100
         - ionic: rx_push mode operation (writing descriptors via MMIO)
         - bnxt: use the auxiliary bus abstraction for RDMA
         - r8169: disable ASPM and reset bus in case of tx timeout
         - cpsw: support QSGMII mode for J721e CPSW9G
         - cpts: support pulse-per-second output
         - ngbe: add an mdio bus driver
         - usbnet: optimize usbnet_bh() by avoiding unnecessary queuing
         - r8152: handle devices with FW with NCM support
         - amd-xgbe: support 10Mbps, 2.5GbE speeds and rx-adaptation
         - virtio-net: support multi buffer XDP
         - virtio/vsock: replace virtio_vsock_pkt with sk_buff
         - tsnep: XDP support

   - Ethernet high-speed switches:
      - nVidia/Mellanox (mlxsw):
         - add support for latency TLV (in FW control messages)
      - Microchip (sparx5):
         - separate explicit and implicit traffic forwarding rules, make
           the implicit rules always active
         - add support for egress DSCP rewrite
         - IS0 VCAP support (Ingress Classification)
         - IS2 VCAP filters (protos, L3 addrs, L4 ports, flags, ToS
           etc.)
         - ES2 VCAP support (Egress Access Control)
         - support for Per-Stream Filtering and Policing (802.1Q,
           8.6.5.1)

   - Ethernet embedded switches:
      - Marvell (mv88e6xxx):
         - add MAB (port auth) offload support
         - enable PTP receive for mv88e6390
      - NXP (ocelot):
         - support MAC Merge layer
         - support for the the vsc7512 internal copper phys
      - Microchip:
         - lan9303: convert to PHYLINK
         - lan966x: support TC flower filter statistics
         - lan937x: PTP support for KSZ9563/KSZ8563 and LAN937x
         - lan937x: support Credit Based Shaper configuration
         - ksz9477: support Energy Efficient Ethernet
      - other:
         - qca8k: convert to regmap read/write API, use bulk operations
         - rswitch: Improve TX timestamp accuracy

   - Intel WiFi (iwlwifi):
      - EHT (Wi-Fi 7) rate reporting
      - STEP equalizer support: transfer some STEP (connection to radio
        on platforms with integrated wifi) related parameters from the
        BIOS to the firmware.

   - Qualcomm 802.11ax WiFi (ath11k):
      - IPQ5018 support
      - Fine Timing Measurement (FTM) responder role support
      - channel 177 support

   - MediaTek WiFi (mt76):
      - per-PHY LED support
      - mt7996: EHT (Wi-Fi 7) support
      - Wireless Ethernet Dispatch (WED) reset support
      - switch to using page pool allocator

   - RealTek WiFi (rtw89):
      - support new version of Bluetooth co-existance

   - Mobile:
      - rmnet: support TX aggregation"

* tag 'net-next-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next: (1872 commits)
  page_pool: add a comment explaining the fragment counter usage
  net: ethtool: fix __ethtool_dev_mm_supported() implementation
  ethtool: pse-pd: Fix double word in comments
  xsk: add linux/vmalloc.h to xsk.c
  sefltests: netdevsim: wait for devlink instance after netns removal
  selftest: fib_tests: Always cleanup before exit
  net/mlx5e: Align IPsec ASO result memory to be as required by hardware
  net/mlx5e: TC, Set CT miss to the specific ct action instance
  net/mlx5e: Rename CHAIN_TO_REG to MAPPED_OBJ_TO_REG
  net/mlx5: Refactor tc miss handling to a single function
  net/mlx5: Kconfig: Make tc offload depend on tc skb extension
  net/sched: flower: Support hardware miss to tc action
  net/sched: flower: Move filter handle initialization earlier
  net/sched: cls_api: Support hardware miss to tc action
  net/sched: Rename user cookie and act cookie
  sfc: fix builds without CONFIG_RTC_LIB
  sfc: clean up some inconsistent indentings
  net/mlx4_en: Introduce flexible array to silence overflow warning
  net: lan966x: Fix possible deadlock inside PTP
  net/ulp: Remove redundant ->clone() test in inet_clone_ulp().
  ...

1 files changed, 351 insertions, 0 deletions

diff --git a/Documentation/userspace-api/media/v4l/vidioc-g-fbuf.rst b/Documentation/userspace-api/media/v4l/vidioc-g-fbuf.rst
new file mode 100644
index 000000000..b6cc1a823
--- /dev/null
+++ b/Documentation/userspace-api/media/v4l/vidioc-g-fbuf.rst
@@ -0,0 +1,351 @@
+.. SPDX-License-Identifier: GFDL-1.1-no-invariants-or-later
+.. c:namespace:: V4L
+
+.. _VIDIOC_G_FBUF:
+
+**********************************
+ioctl VIDIOC_G_FBUF, VIDIOC_S_FBUF
+**********************************
+
+Name
+====
+
+VIDIOC_G_FBUF - VIDIOC_S_FBUF - Get or set frame buffer overlay parameters
+
+Synopsis
+========
+
+.. c:macro:: VIDIOC_G_FBUF
+
+``int ioctl(int fd, VIDIOC_G_FBUF, struct v4l2_framebuffer *argp)``
+
+.. c:macro:: VIDIOC_S_FBUF
+
+``int ioctl(int fd, VIDIOC_S_FBUF, const struct v4l2_framebuffer *argp)``
+
+Arguments
+=========
+
+``fd``
+    File descriptor returned by :c:func:`open()`.
+
+``argp``
+    Pointer to struct :c:type:`v4l2_framebuffer`.
+
+Description
+===========
+
+Applications can use the :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` and :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>` ioctl
+to get and set the framebuffer parameters for a
+:ref:`Video Overlay <overlay>` or :ref:`Video Output Overlay <osd>`
+(OSD). The type of overlay is implied by the device type (capture or
+output device) and can be determined with the
+:ref:`VIDIOC_QUERYCAP` ioctl. One ``/dev/videoN``
+device must not support both kinds of overlay.
+
+The V4L2 API distinguishes destructive and non-destructive overlays. A
+destructive overlay copies captured video images into the video memory
+of a graphics card. A non-destructive overlay blends video images into a
+VGA signal or graphics into a video signal. *Video Output Overlays* are
+always non-destructive.
+
+To get the current parameters applications call the :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>`
+ioctl with a pointer to a struct :c:type:`v4l2_framebuffer`
+structure. The driver fills all fields of the structure or returns an
+EINVAL error code when overlays are not supported.
+
+To set the parameters for a *Video Output Overlay*, applications must
+initialize the ``flags`` field of a struct
+:c:type:`v4l2_framebuffer`. Since the framebuffer is
+implemented on the TV card all other parameters are determined by the
+driver. When an application calls :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>` with a pointer to
+this structure, the driver prepares for the overlay and returns the
+framebuffer parameters as :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>` does, or it returns an error
+code.
+
+To set the parameters for a *non-destructive Video Overlay*,
+applications must initialize the ``flags`` field, the ``fmt``
+substructure, and call :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>`. Again the driver prepares for
+the overlay and returns the framebuffer parameters as :ref:`VIDIOC_G_FBUF <VIDIOC_G_FBUF>`
+does, or it returns an error code.
+
+For a *destructive Video Overlay* applications must additionally provide
+a ``base`` address. Setting up a DMA to a random memory location can
+jeopardize the system security, its stability or even damage the
+hardware, therefore only the superuser can set the parameters for a
+destructive video overlay.
+
+.. tabularcolumns:: |p{3.5cm}|p{3.5cm}|p{3.5cm}|p{6.6cm}|
+
+.. c:type:: v4l2_framebuffer
+
+.. cssclass:: longtable
+
+.. flat-table:: struct v4l2_framebuffer
+    :header-rows:  0
+    :stub-columns: 0
+    :widths:       1 1 1 2
+
+    * - __u32
+      - ``capability``
+      -
+      - Overlay capability flags set by the driver, see
+	:ref:`framebuffer-cap`.
+    * - __u32
+      - ``flags``
+      -
+      - Overlay control flags set by application and driver, see
+	:ref:`framebuffer-flags`
+    * - void *
+      - ``base``
+      -
+      - Physical base address of the framebuffer, that is the address of
+	the pixel in the top left corner of the framebuffer. [#f1]_
+    * -
+      -
+      -
+      - This field is irrelevant to *non-destructive Video Overlays*. For
+	*destructive Video Overlays* applications must provide a base
+	address. The driver may accept only base addresses which are a
+	multiple of two, four or eight bytes. For *Video Output Overlays*
+	the driver must return a valid base address, so applications can
+	find the corresponding Linux framebuffer device (see
+	:ref:`osd`).
+    * - struct
+      - ``fmt``
+      -
+      - Layout of the frame buffer.
+    * -
+      - __u32
+      - ``width``
+      - Width of the frame buffer in pixels.
+    * -
+      - __u32
+      - ``height``
+      - Height of the frame buffer in pixels.
+    * -
+      - __u32
+      - ``pixelformat``
+      - The pixel format of the framebuffer.
+    * -
+      -
+      -
+      - For *non-destructive Video Overlays* this field only defines a
+	format for the struct :c:type:`v4l2_window`
+	``chromakey`` field.
+    * -
+      -
+      -
+      - For *destructive Video Overlays* applications must initialize this
+	field. For *Video Output Overlays* the driver must return a valid
+	format.
+    * -
+      -
+      -
+      - Usually this is an RGB format (for example
+	:ref:`V4L2_PIX_FMT_RGB565 <V4L2-PIX-FMT-RGB565>`) but YUV
+	formats (only packed YUV formats when chroma keying is used, not
+	including ``V4L2_PIX_FMT_YUYV`` and ``V4L2_PIX_FMT_UYVY``) and the
+	``V4L2_PIX_FMT_PAL8`` format are also permitted. The behavior of
+	the driver when an application requests a compressed format is
+	undefined. See :ref:`pixfmt` for information on pixel formats.
+    * -
+      - enum :c:type:`v4l2_field`
+      - ``field``
+      - Drivers and applications shall ignore this field. If applicable,
+	the field order is selected with the
+	:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl, using the ``field``
+	field of struct :c:type:`v4l2_window`.
+    * -
+      - __u32
+      - ``bytesperline``
+      - Distance in bytes between the leftmost pixels in two adjacent
+	lines.
+    * - :cspan:`3`
+
+	This field is irrelevant to *non-destructive Video Overlays*.
+
+	For *destructive Video Overlays* both applications and drivers can
+	set this field to request padding bytes at the end of each line.
+	Drivers however may ignore the requested value, returning
+	``width`` times bytes-per-pixel or a larger value required by the
+	hardware. That implies applications can just set this field to
+	zero to get a reasonable default.
+
+	For *Video Output Overlays* the driver must return a valid value.
+
+	Video hardware may access padding bytes, therefore they must
+	reside in accessible memory. Consider for example the case where
+	padding bytes after the last line of an image cross a system page
+	boundary. Capture devices may write padding bytes, the value is
+	undefined. Output devices ignore the contents of padding bytes.
+
+	When the image format is planar the ``bytesperline`` value applies
+	to the first plane and is divided by the same factor as the
+	``width`` field for the other planes. For example the Cb and Cr
+	planes of a YUV 4:2:0 image have half as many padding bytes
+	following each line as the Y plane. To avoid ambiguities drivers
+	must return a ``bytesperline`` value rounded up to a multiple of
+	the scale factor.
+    * -
+      - __u32
+      - ``sizeimage``
+      - This field is irrelevant to *non-destructive Video Overlays*. For
+	*destructive Video Overlays* applications must initialize this
+	field. For *Video Output Overlays* the driver must return a valid
+	format.
+
+	Together with ``base`` it defines the framebuffer memory
+	accessible by the driver.
+    * -
+      - enum :c:type:`v4l2_colorspace`
+      - ``colorspace``
+      - This information supplements the ``pixelformat`` and must be set
+	by the driver, see :ref:`colorspaces`.
+    * -
+      - __u32
+      - ``priv``
+      - Reserved. Drivers and applications must set this field to zero.
+
+.. tabularcolumns:: |p{7.4cm}|p{1.6cm}|p{8.3cm}|
+
+.. _framebuffer-cap:
+
+.. flat-table:: Frame Buffer Capability Flags
+    :header-rows:  0
+    :stub-columns: 0
+    :widths:       3 1 4
+
+    * - ``V4L2_FBUF_CAP_EXTERNOVERLAY``
+      - 0x0001
+      - The device is capable of non-destructive overlays. When the driver
+	clears this flag, only destructive overlays are supported. There
+	are no drivers yet which support both destructive and
+	non-destructive overlays. Video Output Overlays are in practice
+	always non-destructive.
+    * - ``V4L2_FBUF_CAP_CHROMAKEY``
+      - 0x0002
+      - The device supports clipping by chroma-keying the images. That is,
+	image pixels replace pixels in the VGA or video signal only where
+	the latter assume a certain color. Chroma-keying makes no sense
+	for destructive overlays.
+    * - ``V4L2_FBUF_CAP_LIST_CLIPPING``
+      - 0x0004
+      - The device supports clipping using a list of clip rectangles.
+    * - ``V4L2_FBUF_CAP_BITMAP_CLIPPING``
+      - 0x0008
+      - The device supports clipping using a bit mask.
+    * - ``V4L2_FBUF_CAP_LOCAL_ALPHA``
+      - 0x0010
+      - The device supports clipping/blending using the alpha channel of
+	the framebuffer or VGA signal. Alpha blending makes no sense for
+	destructive overlays.
+    * - ``V4L2_FBUF_CAP_GLOBAL_ALPHA``
+      - 0x0020
+      - The device supports alpha blending using a global alpha value.
+	Alpha blending makes no sense for destructive overlays.
+    * - ``V4L2_FBUF_CAP_LOCAL_INV_ALPHA``
+      - 0x0040
+      - The device supports clipping/blending using the inverted alpha
+	channel of the framebuffer or VGA signal. Alpha blending makes no
+	sense for destructive overlays.
+    * - ``V4L2_FBUF_CAP_SRC_CHROMAKEY``
+      - 0x0080
+      - The device supports Source Chroma-keying. Video pixels with the
+	chroma-key colors are replaced by framebuffer pixels, which is
+	exactly opposite of ``V4L2_FBUF_CAP_CHROMAKEY``
+
+.. tabularcolumns:: |p{7.4cm}|p{1.6cm}|p{8.3cm}|
+
+.. _framebuffer-flags:
+
+.. cssclass:: longtable
+
+.. flat-table:: Frame Buffer Flags
+    :header-rows:  0
+    :stub-columns: 0
+    :widths:       3 1 4
+
+    * - ``V4L2_FBUF_FLAG_PRIMARY``
+      - 0x0001
+      - The framebuffer is the primary graphics surface. In other words,
+	the overlay is destructive. This flag is typically set by any
+	driver that doesn't have the ``V4L2_FBUF_CAP_EXTERNOVERLAY``
+	capability and it is cleared otherwise.
+    * - ``V4L2_FBUF_FLAG_OVERLAY``
+      - 0x0002
+      - If this flag is set for a video capture device, then the driver
+	will set the initial overlay size to cover the full framebuffer
+	size, otherwise the existing overlay size (as set by
+	:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`) will be used. Only one
+	video capture driver (bttv) supports this flag. The use of this
+	flag for capture devices is deprecated. There is no way to detect
+	which drivers support this flag, so the only reliable method of
+	setting the overlay size is through
+	:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`. If this flag is set for a
+	video output device, then the video output overlay window is
+	relative to the top-left corner of the framebuffer and restricted
+	to the size of the framebuffer. If it is cleared, then the video
+	output overlay window is relative to the video output display.
+    * - ``V4L2_FBUF_FLAG_CHROMAKEY``
+      - 0x0004
+      - Use chroma-keying. The chroma-key color is determined by the
+	``chromakey`` field of struct :c:type:`v4l2_window`
+	and negotiated with the :ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>`
+	ioctl, see :ref:`overlay` and :ref:`osd`.
+    * - :cspan:`2` There are no flags to enable clipping using a list of
+	clip rectangles or a bitmap. These methods are negotiated with the
+	:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl, see :ref:`overlay`
+	and :ref:`osd`.
+    * - ``V4L2_FBUF_FLAG_LOCAL_ALPHA``
+      - 0x0008
+      - Use the alpha channel of the framebuffer to clip or blend
+	framebuffer pixels with video images. The blend function is:
+	output = framebuffer pixel * alpha + video pixel * (1 - alpha).
+	The actual alpha depth depends on the framebuffer pixel format.
+    * - ``V4L2_FBUF_FLAG_GLOBAL_ALPHA``
+      - 0x0010
+      - Use a global alpha value to blend the framebuffer with video
+	images. The blend function is: output = (framebuffer pixel * alpha
+	+ video pixel * (255 - alpha)) / 255. The alpha value is
+	determined by the ``global_alpha`` field of struct
+	:c:type:`v4l2_window` and negotiated with the
+	:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl, see :ref:`overlay`
+	and :ref:`osd`.
+    * - ``V4L2_FBUF_FLAG_LOCAL_INV_ALPHA``
+      - 0x0020
+      - Like ``V4L2_FBUF_FLAG_LOCAL_ALPHA``, use the alpha channel of the
+	framebuffer to clip or blend framebuffer pixels with video images,
+	but with an inverted alpha value. The blend function is: output =
+	framebuffer pixel * (1 - alpha) + video pixel * alpha. The actual
+	alpha depth depends on the framebuffer pixel format.
+    * - ``V4L2_FBUF_FLAG_SRC_CHROMAKEY``
+      - 0x0040
+      - Use source chroma-keying. The source chroma-key color is
+	determined by the ``chromakey`` field of struct
+	:c:type:`v4l2_window` and negotiated with the
+	:ref:`VIDIOC_S_FMT <VIDIOC_G_FMT>` ioctl, see :ref:`overlay`
+	and :ref:`osd`. Both chroma-keying are mutual exclusive to each
+	other, so same ``chromakey`` field of struct
+	:c:type:`v4l2_window` is being used.
+
+Return Value
+============
+
+On success 0 is returned, on error -1 and the ``errno`` variable is set
+appropriately. The generic error codes are described at the
+:ref:`Generic Error Codes <gen-errors>` chapter.
+
+EPERM
+    :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>` can only be called by a privileged user to
+    negotiate the parameters for a destructive overlay.
+
+EINVAL
+    The :ref:`VIDIOC_S_FBUF <VIDIOC_G_FBUF>` parameters are unsuitable.
+
+.. [#f1]
+   A physical base address may not suit all platforms. GK notes in
+   theory we should pass something like PCI device + memory region +
+   offset instead. If you encounter problems please discuss on the
+   linux-media mailing list:
+   `https://linuxtv.org/lists.php <https://linuxtv.org/lists.php>`__.