Merge tag 'asoc-fix-v7.0-rc6' of...

Hans Verkuil <hverkuil@kernel.org> <hansverk@cisco.com>

Hao Ge <hao.ge@linux.dev> <gehao@kylinos.cn>

Harry Yoo <harry.yoo@oracle.com> <42.hyeyoo@gmail.com>

Harry Yoo <harry@kernel.org> <harry.yoo@oracle.com>

Heiko Carstens <hca@linux.ibm.com> <h.carstens@de.ibm.com>

Heiko Carstens <hca@linux.ibm.com> <heiko.carstens@de.ibm.com>

Heiko Stuebner <heiko@sntech.de> <heiko.stuebner@bqreaders.com>

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>

the error message to the Root Port. Please refer to PCIe specs for other

fields.

The 'TLP Header' is the prefix/header of the TLP that caused the error

in raw hex format. To decode the TLP Header into human-readable form

one may use tlp-tool:

https://github.com/mmpg-x86/tlp-tool

Example usage::

  curl -L https://git.kernel.org/linus/2ca1c94ce0b6 | rtlp-tool --aer

AER Ratelimits

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

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.

    mounted with "uuid=on".

Durability and copy up

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

The fsync(2) system call ensures that the data and metadata of a file

are safely written to the backing storage, which is expected to

guarantee the existence of the information post system crash.

Without an fsync(2) call, there is no guarantee that the observed

data after a system crash will be either the old or the new data, but

in practice, the observed data after crash is often the old or new data

or a mix of both.

When an overlayfs file is modified for the first time, copy up will

create a copy of the lower file and its parent directories in the upper

layer.  Since the Linux filesystem API does not enforce any particular

ordering on storing changes without explicit fsync(2) calls, in case

of a system crash, the upper file could end up with no data at all

(i.e. zeros), which would be an unusual outcome.  To avoid this

experience, overlayfs calls fsync(2) on the upper file before completing

data copy up with rename(2) or link(2) to make the copy up "atomic".

By default, overlayfs does not explicitly call fsync(2) on copied up

directories or on metadata-only copy up, so it provides no guarantee to

persist the user's modification unless the user calls fsync(2).

The fsync during copy up only guarantees that if a copy up is observed

after a crash, the observed data is not zeroes or intermediate values

from the copy up staging area.

On traditional local filesystems with a single journal (e.g. ext4, xfs),

fsync on a file also persists the parent directory changes, because they

are usually modified in the same transaction, so metadata durability during

data copy up effectively comes for free.  Overlayfs further limits risk by

disallowing network filesystems as upper layer.

Overlayfs can be tuned to prefer performance or durability when storing

to the underlying upper layer.  This is controlled by the "fsync" mount

option, which supports these values:

- "auto": (default)

    Call fsync(2) on upper file before completion of data copy up.

    No explicit fsync(2) on directory or metadata-only copy up.

- "strict":

    Call fsync(2) on upper file and directories before completion of any

    copy up.

- "volatile": [*]

    Prefer performance over durability (see `Volatile mount`_)

[*] The mount option "volatile" is an alias to "fsync=volatile".

Volatile mount

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

Sysfs entries

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

The following attributes are supported. Current maxim attribute

The following attributes are supported. Current maximum attribute

is read-write, all other attributes are read-only.

in0_input		Measured voltage in microvolts.

in0_input		Measured voltage in millivolts.

curr1_input		Measured current in microamperes.

curr1_max_alarm		Overcurrent alarm in microamperes.

curr1_input		Measured current in milliamperes.

curr1_max		Overcurrent shutdown threshold in milliamperes.