Skip to content

Commit

Permalink
Merge tag 'i2c-host-6.13-p1' of git://git.kernel.org/pub/scm/linux/ke…
Browse files Browse the repository at this point in the history 
…rnel/git/andi.shyti/linux into i2c/for-mergewindow

i2c-host updates for v6.13, part 1

Major Improvements and Refactoring:

 - All controllers using the 'remove_new' callback have been
   reverted to use the 'remove' callback.

 - Intel SCH controller underwent significant refactoring,
   this brings love and a modern look to the driver.

 - PIIX4 driver refactored to enable usage by other drivers
   (e.g., AMD ASF).

 - iMX/MXC improved message handling to reduce protocol overhead:
     Refactored DMA/non-DMA read/write and bus polling mechanisms
     to achieve this.

 - ACPI documentation for PIIX4.

New Features:

 - i2c-cadence added support for atomic transfers.
 - Qualcomm CII added support for a 32MHz serial engine clock.

Deprecated Features:

 - Dropped outdated support for AMD756 S4882 and NFORCE2 S4985. If
   somebody misses this, Jean will rewrite support using the proper
   i2c mux framework.

New Hardware Support:

 - Added support for:
   - Intel Panther Lake (new ID)
   - AMD ASF (new driver)
   - S32G2/S32G3 SoCs (new ID)
   - Realtek RTL I2C Controller (new driver)
   - HJMC01 DesignWare ACPI HID (new ID)
   - PIC64GX to Microchip Core (new ID)
   - Qualcomm SDM670 to Qualcomm CCI (new ID)
  • Loading branch information
Wolfram Sang committed Nov 18, 2024
2 parents 48730a9 + 1922bc2 commit 1b30732
Show file tree
Hide file tree
Showing 1,714 changed files with 23,083 additions and 15,080 deletions.
17 changes: 15 additions & 2 deletions .mailmap
View file
Original file line number Diff line number Diff line change
Expand Up @@ -73,6 +73,8 @@ Andrey Ryabinin <[email protected]> <[email protected]>
Andrzej Hajda <[email protected]> <[email protected]>
André Almeida <[email protected]> <[email protected]>
Andy Adamson <[email protected]>
Andy Chiu <[email protected]> <[email protected]>
Andy Chiu <[email protected]> <[email protected]>
Andy Shevchenko <[email protected]> <[email protected]>
Andy Shevchenko <[email protected]> <[email protected]>
Anilkumar Kolli <[email protected]> <[email protected]>
Expand Down Expand Up @@ -197,18 +199,23 @@ Elliot Berman <[email protected]> <[email protected]>
Enric Balletbo i Serra <[email protected]> <[email protected]>
Enric Balletbo i Serra <[email protected]> <[email protected]>
Erik Kaneda <[email protected]> <[email protected]>
Eugen Hristev <[email protected]> <[email protected]>
Eugen Hristev <[email protected]> <[email protected]>
Eugen Hristev <[email protected]> <[email protected]>
Evgeniy Polyakov <[email protected]>
Ezequiel Garcia <[email protected]> <[email protected]>
Faith Ekstrand <[email protected]> <[email protected]>
Faith Ekstrand <[email protected]> <[email protected]>
Faith Ekstrand <[email protected]> <[email protected]>
Fangrui Song <[email protected]> <[email protected]>
Felipe W Damasio <[email protected]>
Felix Kuhling <[email protected]>
Felix Moeller <[email protected]>
Fenglin Wu <[email protected]> <[email protected]>
Filipe Lautert <[email protected]>
Finn Thain <[email protected]> <[email protected]>
Fiona Behrens <[email protected]>
Fiona Behrens <[email protected]> <[email protected]>
Fiona Behrens <[email protected]> <[email protected]>
Franck Bui-Huu <[email protected]>
Frank Rowand <[email protected]> <[email protected]>
Frank Rowand <[email protected]> <[email protected]>
Expand Down Expand Up @@ -276,7 +283,7 @@ Jan Glauber <[email protected]> <[email protected]>
Jan Kuliga <[email protected]> <[email protected]>
Jarkko Sakkinen <[email protected]> <[email protected]>
Jarkko Sakkinen <[email protected]> <[email protected]>
Jarkko Sakkinen <[email protected]> <jarkko.sakkinen@tuni.fi>
Jarkko Sakkinen <[email protected]> <jarkko.sakkinen@parity.io>
Jason Gunthorpe <[email protected]> <[email protected]>
Jason Gunthorpe <[email protected]> <[email protected]>
Jason Gunthorpe <[email protected]> <[email protected]>
Expand All @@ -300,6 +307,11 @@ Jens Axboe <[email protected]> <[email protected]>
Jens Axboe <[email protected]> <[email protected]>
Jens Osterkamp <[email protected]>
Jernej Skrabec <[email protected]> <[email protected]>
Jesper Dangaard Brouer <[email protected]> <[email protected]>
Jesper Dangaard Brouer <[email protected]> <[email protected]>
Jesper Dangaard Brouer <[email protected]> <[email protected]>
Jesper Dangaard Brouer <[email protected]> <[email protected]>
Jesper Dangaard Brouer <[email protected]> <[email protected]>
Jessica Zhang <[email protected]> <[email protected]>
Jilai Wang <[email protected]> <[email protected]>
Jiri Kosina <[email protected]> <[email protected]>
Expand Down Expand Up @@ -653,6 +665,7 @@ Tomeu Vizoso <[email protected]> <[email protected]>
Thomas Graf <[email protected]>
Thomas Körper <[email protected]> <[email protected]>
Thomas Pedersen <[email protected]>
Thorsten Blum <[email protected]> <[email protected]>
Tiezhu Yang <[email protected]> <[email protected]>
Tingwei Zhang <[email protected]> <[email protected]>
Tirupathi Reddy <[email protected]> <[email protected]>
Expand Down
58 changes: 31 additions & 27 deletions CREDITS
View file
Original file line number Diff line number Diff line change
Expand Up @@ -1204,6 +1204,10 @@ S: Dreisbachstrasse 24
S: D-57250 Netphen
S: Germany

N: Florian Fainelli
E: [email protected]
D: DSA

N: Rik Faith
E: [email protected]
D: Future Domain TMC-16x0 SCSI driver (author)
Expand Down Expand Up @@ -1358,10 +1362,6 @@ D: Major kbuild rework during the 2.5 cycle
D: ISDN Maintainer
S: USA

N: Gerrit Renker
E: [email protected]
D: DCCP protocol support.

N: Philip Gladstone
E: [email protected]
D: Kernel / timekeeping stuff
Expand Down Expand Up @@ -1677,11 +1677,6 @@ W: http://www.carumba.com/
D: bug toaster (A1 sauce makes all the difference)
D: Random linux hacker

N: James Hogan
E: [email protected]
D: Metag architecture maintainer
D: TZ1090 SoC maintainer

N: Tim Hockin
E: [email protected]
W: http://www.hockin.org/~thockin
Expand All @@ -1697,6 +1692,11 @@ D: hwmon subsystem maintainer
D: i2c-sis96x and i2c-stub SMBus drivers
S: USA

N: James Hogan
E: [email protected]
D: Metag architecture maintainer
D: TZ1090 SoC maintainer

N: Dirk Hohndel
E: [email protected]
D: The XFree86[tm] Project
Expand Down Expand Up @@ -1872,6 +1872,10 @@ S: K osmidomkum 723
S: 160 00 Praha 6
S: Czech Republic

N: Seth Jennings
E: [email protected]
D: Creation and maintenance of zswap

N: Jeremy Kerr
D: Maintainer of SPU File System

Expand Down Expand Up @@ -2188,19 +2192,6 @@ N: Mike Kravetz
E: [email protected]
D: Maintenance and development of the hugetlb subsystem

N: Seth Jennings
E: [email protected]
D: Creation and maintenance of zswap

N: Dan Streetman
E: [email protected]
D: Maintenance and development of zswap
D: Creation and maintenance of the zpool API

N: Vitaly Wool
E: [email protected]
D: Maintenance and development of zswap

N: Andreas S. Krebs
E: [email protected]
D: CYPRESS CY82C693 chipset IDE, Digital's PC-Alpha 164SX boards
Expand Down Expand Up @@ -3191,6 +3182,11 @@ N: Ken Pizzini
E: [email protected]
D: CDROM driver "sonycd535" (Sony CDU-535/531)

N: Mathieu Poirier
E: [email protected]
D: CoreSight kernel subsystem, Maintainer 2014-2022
D: Perf tool support for CoreSight

N: Stelian Pop
E: [email protected]
P: 1024D/EDBB6147 7B36 0E07 04BC 11DC A7A0 D3F7 7185 9E7A EDBB 6147
Expand Down Expand Up @@ -3300,6 +3296,10 @@ S: Schlossbergring 9
S: 79098 Freiburg
S: Germany

N: Gerrit Renker
E: [email protected]
D: DCCP protocol support.

N: Thomas Renninger
E: [email protected]
D: cpupowerutils
Expand Down Expand Up @@ -3576,11 +3576,6 @@ D: several improvements to system programs
S: Oldenburg
S: Germany

N: Mathieu Poirier
E: [email protected]
D: CoreSight kernel subsystem, Maintainer 2014-2022
D: Perf tool support for CoreSight

N: Robert Schwebel
E: [email protected]
W: https://www.schwebel.de
Expand Down Expand Up @@ -3771,6 +3766,11 @@ S: Chr. Winthersvej 1 B, st.th.
S: DK-1860 Frederiksberg C
S: Denmark

N: Dan Streetman
E: [email protected]
D: Maintenance and development of zswap
D: Creation and maintenance of the zpool API

N: Drew Sullivan
E: [email protected]
W: http://www.ss.org/
Expand Down Expand Up @@ -4286,6 +4286,10 @@ S: Pipers Way
S: Swindon. SN3 1RJ
S: England

N: Vitaly Wool
E: [email protected]
D: Maintenance and development of zswap

N: Chris Wright
E: [email protected]
D: hacking on LSM framework and security modules.
Expand Down
7 changes: 5 additions & 2 deletions Documentation/admin-guide/LSM/ipe.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -223,7 +223,10 @@ are signed through the PKCS#7 message format to enforce some level of
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" \
Expand Down Expand Up @@ -266,7 +269,7 @@ in the kernel. This file is write-only and accepts a PKCS#7 signed
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.
Expand Down
2 changes: 1 addition & 1 deletion Documentation/admin-guide/kernel-parameters.txt
View file
Original file line number Diff line number Diff line change
Expand Up @@ -6688,7 +6688,7 @@
0: no polling (default)

thp_anon= [KNL]
Format: <size>,<size>[KMG]:<state>;<size>-<size>[KMG]:<state>
Format: <size>[KMG],<size>[KMG]:<state>;<size>[KMG]-<size>[KMG]:<state>
state is one of "always", "madvise", "never" or "inherit".
Control the default behavior of the system with respect
to anonymous transparent hugepages.
Expand Down
2 changes: 1 addition & 1 deletion Documentation/admin-guide/mm/transhuge.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -303,7 +303,7 @@ control by passing the parameter ``transparent_hugepage=always`` or
kernel command line.

Alternatively, each supported anonymous THP size can be controlled by
passing ``thp_anon=<size>,<size>[KMG]:<state>;<size>-<size>[KMG]:<state>``,
passing ``thp_anon=<size>[KMG],<size>[KMG]:<state>;<size>[KMG]-<size>[KMG]:<state>``,
where ``<size>`` is the THP size (must be a power of 2 of PAGE_SIZE and
supported anonymous THP) and ``<state>`` is one of ``always``, ``madvise``,
``never`` or ``inherit``.
Expand Down
20 changes: 10 additions & 10 deletions Documentation/admin-guide/pm/cpufreq.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -425,8 +425,8 @@ This governor exposes only one tunable:

``rate_limit_us``
Minimum time (in microseconds) that has to pass between two consecutive
runs of governor computations (default: 1000 times the scaling driver's
transition latency).
runs of governor computations (default: 1.5 times the scaling driver's
transition latency or the maximum 2ms).

The purpose of this tunable is to reduce the scheduler context overhead
of the governor which might be excessive without it.
Expand Down Expand Up @@ -474,17 +474,17 @@ This governor exposes the following tunables:
This is how often the governor's worker routine should run, in
microseconds.

Typically, it is set to values of the order of 10000 (10 ms). Its
default value is equal to the value of ``cpuinfo_transition_latency``
for each policy this governor is attached to (but since the unit here
is greater by 1000, this means that the time represented by
``sampling_rate`` is 1000 times greater than the transition latency by
default).
Typically, it is set to values of the order of 2000 (2 ms). Its
default value is to add a 50% breathing room
to ``cpuinfo_transition_latency`` on each policy this governor is
attached to. The minimum is typically the length of two scheduler
ticks.

If this tunable is per-policy, the following shell command sets the time
represented by it to be 750 times as high as the transition latency::
represented by it to be 1.5 times as high as the transition latency
(the default)::

# echo `$(($(cat cpuinfo_transition_latency) * 750 / 1000)) > ondemand/sampling_rate
# echo `$(($(cat cpuinfo_transition_latency) * 3 / 2)) > ondemand/sampling_rate

``up_threshold``
If the estimated CPU load is above this value (in percent), the governor
Expand Down
38 changes: 30 additions & 8 deletions Documentation/core-api/protection-keys.rst
View file
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,10 @@ Pkeys Userspace (PKU) is a feature which can be found on:
* 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.

Expand All @@ -28,6 +31,22 @@ register. The feature is only available in 64-bit mode, even though there is
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
========

Expand All @@ -38,11 +57,10 @@ There are 3 system calls which directly interact with pkeys::
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;
Expand All @@ -64,9 +82,9 @@ is no longer in use::
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
========
Expand Down Expand Up @@ -96,3 +114,7 @@ with a read()::
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().
54 changes: 54 additions & 0 deletions Documentation/devicetree/bindings/display/elgin,jg10309-01.yaml
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/elgin,jg10309-01.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#

title: Elgin JG10309-01 SPI-controlled display

maintainers:
- Fabio Estevam <[email protected]>

description: |
The Elgin JG10309-01 SPI-controlled display is used on the RV1108-Elgin-r1
board and is a custom display.
allOf:
- $ref: /schemas/spi/spi-peripheral-props.yaml#

properties:
compatible:
const: elgin,jg10309-01

reg:
maxItems: 1

spi-max-frequency:
maximum: 24000000

spi-cpha: true

spi-cpol: true

required:
- compatible
- reg
- spi-cpha
- spi-cpol

additionalProperties: false

examples:
- |
spi {
#address-cells = <1>;
#size-cells = <0>;
display@0 {
compatible = "elgin,jg10309-01";
reg = <0>;
spi-max-frequency = <24000000>;
spi-cpha;
spi-cpol;
};
};
Loading

0 comments on commit 1b30732

Please sign in to comment.