Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

Morten Welinder <welinder@anemone.rentec.com>

Morten Welinder <welinder@darter.rentec.com>

Morten Welinder <welinder@troll.com>

Muhammad Usama Anjum <usama.anjum@arm.com> <usama.anjum@collabora.com>

Mukesh Ojha <quic_mojha@quicinc.com> <mojha@codeaurora.org>

Muna Sinada <quic_msinada@quicinc.com> <msinada@codeaurora.org>

Murali Nalajala <quic_mnalajal@quicinc.com> <mnalajal@codeaurora.org>

DMA_ATTR_MMIO will not perform any cache flushing. The address

provided must never be mapped cacheable into the CPU.

DMA_ATTR_CPU_CACHE_CLEAN

------------------------

This attribute indicates the CPU will not dirty any cacheline overlapping this

DMA_FROM_DEVICE/DMA_BIDIRECTIONAL buffer while it is mapped. This allows

multiple small buffers to safely share a cacheline without risk of data

corruption, suppressing DMA debug warnings about overlapping mappings.

All mappings sharing a cacheline should have this attribute.

DMA_ATTR_DEBUGGING_IGNORE_CACHELINES

------------------------------------

This attribute indicates that CPU cache lines may overlap for buffers mapped

with DMA_FROM_DEVICE or DMA_BIDIRECTIONAL.

Such overlap may occur when callers map multiple small buffers that reside

within the same cache line. In this case, callers must guarantee that the CPU

will not dirty these cache lines after the mappings are established. When this

condition is met, multiple buffers can safely share a cache line without risking

data corruption.

All mappings that share a cache line must set this attribute to suppress DMA

debug warnings about overlapping mappings.

DMA_ATTR_REQUIRE_COHERENT

-------------------------

DMA mapping requests with the DMA_ATTR_REQUIRE_COHERENT fail on any

system where SWIOTLB or cache management is required. This should only

be used to support uAPI designs that require continuous HW DMA

coherence with userspace processes, for example RDMA and DRM. At a

minimum the memory being mapped must be userspace memory from

pin_user_pages() or similar.

Drivers should consider using dma_mmap_pages() instead of this

interface when building their uAPIs, when possible.

It must never be used in an in-kernel driver that only works with

kernel memory.

  Flash sub nodes describe the memory range and optional per-flash

  properties.

allOf:

  - $ref: mtd.yaml#

properties:

  compatible:

    const: st,spear600-smi

    $ref: /schemas/types.yaml#/definitions/uint32

    description: Functional clock rate of the SMI controller in Hz.

patternProperties:

  "^flash@.*$":

    $ref: /schemas/mtd/mtd.yaml#

    properties:

      reg:

        maxItems: 1

      st,smi-fast-mode:

        type: boolean

        description: Indicates that the attached flash supports fast read mode.

    unevaluatedProperties: false

    required:

      - reg

required:

  - compatible

  - reg

  - clock-rate

  - "#address-cells"

  - "#size-cells"

unevaluatedProperties: false

        interrupts = <12>;

        clock-rate = <50000000>;  /* 50 MHz */

        flash@f8000000 {

        flash@fc000000 {

            reg = <0xfc000000 0x1000>;

            st,smi-fast-mode;

        };

      offset from voltage set to regulator.

  regulator-uv-protection-microvolt:

    description: Set over under voltage protection limit. This is a limit where

    description: Set under voltage protection limit. This is a limit where

      hardware performs emergency shutdown. Zero can be passed to disable

      protection and value '1' indicates that protection should be enabled but

      limit setting can be omitted. Limit is given as microvolt offset from

      is given as microvolt offset from voltage set to regulator.

  regulator-uv-warn-microvolt:

    description: Set over under voltage warning limit. This is a limit where

    description: Set under voltage warning limit. This is a limit where

      hardware is assumed still to be functional but approaching limit where

      it gets damaged. Recovery actions should be initiated. Zero can be passed

      to disable detection and value '1' indicates that detection should

When a driver is removed, the list of devices that it supports is

iterated over, and the driver's remove callback is called for each

one. The device is removed from that list and the symlinks removed.

Driver Override

~~~~~~~~~~~~~~~

Userspace may override the standard matching by writing a driver name to

a device's ``driver_override`` sysfs attribute.  When set, only a driver

whose name matches the override will be considered during binding.  This

bypasses all bus-specific matching (OF, ACPI, ID tables, etc.).

The override may be cleared by writing an empty string, which returns

the device to standard matching rules.  Writing to ``driver_override``

does not automatically unbind the device from its current driver or

make any attempt to load the specified driver.

Buses opt into this mechanism by setting the ``driver_override`` flag in

their ``struct bus_type``::

  const struct bus_type example_bus_type = {

      ...

      .driver_override = true,

  };

When the flag is set, the driver core automatically creates the

``driver_override`` sysfs attribute for every device on that bus.

The bus's ``match()`` callback should check the override before performing

its own matching, using ``device_match_driver_override()``::

  static int example_match(struct device *dev, const struct device_driver *drv)

  {

      int ret;

      ret = device_match_driver_override(dev, drv);

      if (ret >= 0)

          return ret;

      /* Fall through to bus-specific matching... */

  }

``device_match_driver_override()`` returns > 0 if the override matches

the given driver, 0 if the override is set but does not match, or < 0 if

no override is set at all.

Additional helpers are available:

- ``device_set_driver_override()`` - set or clear the override from kernel code.

- ``device_has_driver_override()`` - check whether an override is set.