Merge drm/drm-fixes into drm-misc-fixes

Andrzej Hajda <andrzej.hajda@intel.com> <a.hajda@samsung.com>

André Almeida <andrealmeid@igalia.com> <andrealmeid@collabora.com>

Andy Adamson <andros@citi.umich.edu>

Andy Chiu <andybnac@gmail.com> <andy.chiu@sifive.com>

Andy Chiu <andybnac@gmail.com> <taochiu@synology.com>

Andy Shevchenko <andy@kernel.org> <andy@smile.org.ua>

Andy Shevchenko <andy@kernel.org> <ext-andriy.shevchenko@nokia.com>

Anilkumar Kolli <quic_akolli@quicinc.com> <akolli@codeaurora.org>

authorization of the policies (prohibiting an attacker from gaining

unconstrained root, and deploying an "allow all" policy). These

policies must be signed by a certificate that chains to the

``SYSTEM_TRUSTED_KEYRING``. With openssl, the policy can be signed by::

``SYSTEM_TRUSTED_KEYRING``, or to the secondary and/or platform keyrings if

``CONFIG_IPE_POLICY_SIG_SECONDARY_KEYRING`` and/or

``CONFIG_IPE_POLICY_SIG_PLATFORM_KEYRING`` are enabled, respectively.

With openssl, the policy can be signed by::

   openssl smime -sign \

      -in "$MY_POLICY" \

policy. Two checks will always be performed on this policy: First, the

``policy_names`` must match with the updated version and the existing

version. Second the updated policy must have a policy version greater than

or equal to the currently-running version. This is to prevent rollback attacks.

the currently-running version. This is to prevent rollback attacks.

The ``delete`` file is used to remove a policy that is no longer needed.

This file is write-only and accepts a value of ``1`` to delete the policy.

        * Intel server CPUs, Skylake and later

        * Intel client CPUs, Tiger Lake (11th Gen Core) and later

        * Future AMD CPUs

        * arm64 CPUs implementing the Permission Overlay Extension (FEAT_S1POE)

x86_64

======

Pkeys work by dedicating 4 previously Reserved bits in each page table entry to

a "protection key", giving 16 possible keys.

theoretically space in the PAE PTEs.  These permissions are enforced on data

access only and have no effect on instruction fetches.

arm64

=====

Pkeys use 3 bits in each page table entry, to encode a "protection key index",

giving 8 possible keys.

Protections for each key are defined with a per-CPU user-writable system

register (POR_EL0).  This is a 64-bit register encoding read, write and execute

overlay permissions for each protection key index.

Being a CPU register, POR_EL0 is inherently thread-local, potentially giving

each thread a different set of protections from every other thread.

Unlike x86_64, the protection key permissions also apply to instruction

fetches.

Syscalls

========

	int pkey_mprotect(unsigned long start, size_t len,

			  unsigned long prot, int pkey);

Before a pkey can be used, it must first be allocated with

pkey_alloc().  An application calls the WRPKRU instruction

directly in order to change access permissions to memory covered

with a key.  In this example WRPKRU is wrapped by a C function

called pkey_set().

Before a pkey can be used, it must first be allocated with pkey_alloc().  An

application writes to the architecture specific CPU register directly in order

to change access permissions to memory covered with a key.  In this example

this is wrapped by a C function called pkey_set().

::

	int real_prot = PROT_READ|PROT_WRITE;

	munmap(ptr, PAGE_SIZE);

	pkey_free(pkey);

.. note:: pkey_set() is a wrapper for the RDPKRU and WRPKRU instructions.

          An example implementation can be found in

          tools/testing/selftests/x86/protection_keys.c.

.. note:: pkey_set() is a wrapper around writing to the CPU register.

          Example implementations can be found in

          tools/testing/selftests/mm/pkey-{arm64,powerpc,x86}.h

Behavior

========

The kernel will send a SIGSEGV in both cases, but si_code will be set

to SEGV_PKERR when violating protection keys versus SEGV_ACCERR when

the plain mprotect() permissions are violated.

Note that kernel accesses from a kthread (such as io_uring) will use a default

value for the protection key register and so will not be consistent with

userspace's value of the register or mprotect().

$id: http://devicetree.org/schemas/iio/dac/adi,ad5686.yaml#

$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Analog Devices AD5360 and similar DACs

title: Analog Devices AD5360 and similar SPI DACs

maintainers:

  - Michael Hennerich <michael.hennerich@analog.com>

properties:

  compatible:

    oneOf:

      - description: SPI devices

    enum:

      - adi,ad5310r

      - adi,ad5672r

      - adi,ad5685r

      - adi,ad5686

      - adi,ad5686r

      - description: I2C devices

        enum:

          - adi,ad5311r

          - adi,ad5337r

          - adi,ad5338r

          - adi,ad5671r

          - adi,ad5675r

          - adi,ad5691r

          - adi,ad5692r

          - adi,ad5693

          - adi,ad5693r

          - adi,ad5694

          - adi,ad5694r

          - adi,ad5695r

          - adi,ad5696

          - adi,ad5696r

  reg:

    maxItems: 1

$id: http://devicetree.org/schemas/iio/dac/adi,ad5696.yaml#

$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Analog Devices AD5696 and similar multi-channel DACs

title: Analog Devices AD5696 and similar I2C multi-channel DACs

maintainers:

  - Michael Auchter <michael.auchter@ni.com>

  compatible:

    enum:

      - adi,ad5311r

      - adi,ad5337r

      - adi,ad5338r

      - adi,ad5671r

      - adi,ad5675r