Merge branch 'net-next-2025-01-21--06-00' into HEAD

.mailmap

@@ -83,6 +83,13 @@ Anirudh Ghayal <[email protected]> <[email protected]>
 Antoine Tenart <[email protected]> <[email protected]>
 Antoine Tenart <[email protected]> <[email protected]>
 Antonio Ospite <[email protected]> <[email protected]>
+Antonio Quartulli <[email protected]> <[email protected]>
+Antonio Quartulli <[email protected]> <[email protected]>
+Antonio Quartulli <[email protected]> <[email protected]>
+Antonio Quartulli <[email protected]> <[email protected]>
+Antonio Quartulli <[email protected]> <[email protected]>
+Antonio Quartulli <[email protected]> <[email protected]>
+Antonio Quartulli <[email protected]> <[email protected]>
 Anup Patel <[email protected]> <[email protected]>
 Archit Taneja <[email protected]>
 Ard Biesheuvel <[email protected]> <[email protected]>
@@ -121,6 +128,8 @@ Ben Widawsky <[email protected]> <[email protected]>
 Benjamin Poirier <[email protected]> <[email protected]>
 Benjamin Tissoires <[email protected]> <[email protected]>
 Benjamin Tissoires <[email protected]> <[email protected]>
+Bingwu Zhang <[email protected]> <[email protected]>
+Bingwu Zhang <[email protected]> <[email protected]>
 Bjorn Andersson <[email protected]> <[email protected]>
 Bjorn Andersson <[email protected]> <[email protected]>
 Bjorn Andersson <[email protected]> <[email protected]>
@@ -427,6 +436,8 @@ Marcin Nowakowski <[email protected]> <[email protected]>
 Marc Zyngier <[email protected]> <[email protected]>
 Marek Behún <[email protected]> <[email protected]>
 Marek Behún <[email protected]> Marek Behun <[email protected]>
+Marek Lindner <[email protected]> <[email protected]>
+Marek Lindner <[email protected]> <[email protected]>
 Mark Brown <[email protected]>
 Mark Starovoytov <[email protected]> <[email protected]>
 Markus Schneider-Pargmann <[email protected]> <[email protected]>
@@ -435,7 +446,7 @@ Martin Kepplinger <[email protected]> <[email protected]>
 Martin Kepplinger <[email protected]> <[email protected]>
 Martin Kepplinger <[email protected]> <[email protected]>
 Martyna Szapar-Mudlaw <[email protected]> <[email protected]>
-Mathieu Othacehe <m.othacehe@gmail.com> <othacehe@gnu.org>
+Mathieu Othacehe <othacehe@gnu.org> <m.othacehe@gmail.com>
 Mat Martineau <[email protected]> <[email protected]>
 Mat Martineau <[email protected]> <[email protected]>
 Matthew Wilcox <[email protected]> <[email protected]>
@@ -529,6 +540,8 @@ Oleksij Rempel <[email protected]> <[email protected]>
 Oleksij Rempel <[email protected]> <[email protected]>
 Oleksij Rempel <[email protected]>
 Oleksij Rempel <[email protected]> <[email protected]>
+Oliver Hartkopp <[email protected]> <[email protected]>
+Oliver Hartkopp <[email protected]> <[email protected]>
 Oliver Upton <[email protected]> <[email protected]>
 Ondřej Jirman <[email protected]> <[email protected]>
 Oza Pawandeep <[email protected]> <[email protected]>
@@ -640,6 +653,11 @@ Simona Vetter <[email protected]> <[email protected]>
 Simon Horman <[email protected]> <[email protected]>
 Simon Horman <[email protected]> <[email protected]>
 Simon Kelley <[email protected]>
+Simon Wunderlich <[email protected]> <[email protected]>
+Simon Wunderlich <[email protected]> <[email protected]>
+Simon Wunderlich <[email protected]> <[email protected]>
+Simon Wunderlich <[email protected]> <[email protected]>
+Simon Wunderlich <[email protected]> <[email protected]>
 Sricharan Ramabadhran <[email protected]> <[email protected]>
 Srinivas Ramana <[email protected]> <[email protected]>
 Sriram R <[email protected]> <[email protected]>
@@ -660,6 +678,11 @@ Sudarshan Rajagopalan <[email protected]> <[email protected]>
 Sudeep Holla <[email protected]> Sudeep KarkadaNagesha <[email protected]>
 Sumit Semwal <[email protected]>
 Surabhi Vishnoi <[email protected]> <[email protected]>
+Sven Eckelmann <[email protected]> <[email protected]>
+Sven Eckelmann <[email protected]> <[email protected]>
+Sven Eckelmann <[email protected]> <[email protected]>
+Sven Eckelmann <[email protected]> <[email protected]>
+Sven Eckelmann <[email protected]> <[email protected]>
 Takashi YOSHII <[email protected]>
 Tamizh Chelvam Raja <[email protected]> <[email protected]>
 Taniya Das <[email protected]> <[email protected]>
@@ -735,6 +758,7 @@ Wolfram Sang <[email protected]> <[email protected]>
 Wolfram Sang <[email protected]> <[email protected]>
 Yakir Yang <[email protected]> <[email protected]>
 Yanteng Si <[email protected]> <[email protected]>
+Ying Huang <[email protected]> <[email protected]>
 Yusuke Goda <[email protected]>
 Zack Rusin <[email protected]> <[email protected]>
 Zhu Yanjun <[email protected]> <[email protected]>

CREDITS

@@ -20,6 +20,10 @@ N: Thomas Abraham
 E: [email protected]
 D: Samsung pin controller driver
 
+N: Jose Abreu
+E: [email protected]
+D: Synopsys DesignWare XPCS MDIO/PCS driver.
+
 N: Dragos Acostachioaie
 E: [email protected]
 W: http://www.arbornet.org/~dragos
@@ -1428,6 +1432,10 @@ S: 8124 Constitution Apt. 7
 S: Sterling Heights, Michigan 48313
 S: USA
 
+N: Andy Gospodarek
+E: [email protected]
+D: Maintenance and contributions to the network interface bonding driver.
+
 N: Wolfgang Grandegger
 E: [email protected]
 D: Controller Area Network (device drivers)
@@ -1812,6 +1820,10 @@ D: Author/maintainer of most DRM drivers (especially ATI, MGA)
 D: Core DRM templates, general DRM and 3D-related hacking
 S: No fixed address
 
+N: Woojung Huh
+E: [email protected]
+D: Microchip LAN78XX USB Ethernet driver
+
 N: Kenn Humborg
 E: [email protected]
 D: Mods to loop device to support sparse backing files

Documentation/Makefile

@@ -104,7 +104,7 @@ quiet_cmd_sphinx = SPHINX  $@ --> file://$(abspath $(BUILDDIR)/$3/$4)
 YNL_INDEX:=$(srctree)/Documentation/networking/netlink_spec/index.rst
 YNL_RST_DIR:=$(srctree)/Documentation/networking/netlink_spec
 YNL_YAML_DIR:=$(srctree)/Documentation/netlink/specs
-YNL_TOOL:=$(srctree)/tools/net/ynl/ynl-gen-rst.py
+YNL_TOOL:=$(srctree)/tools/net/ynl/pyynl/ynl_gen_rst.py
 
 YNL_RST_FILES_TMP := $(patsubst %.yaml,%.rst,$(wildcard $(YNL_YAML_DIR)/*.yaml))
 YNL_RST_FILES := $(patsubst $(YNL_YAML_DIR)%,$(YNL_RST_DIR)%, $(YNL_RST_FILES_TMP))

Documentation/admin-guide/laptops/thinkpad-acpi.rst

@@ -445,8 +445,10 @@ event	code	Key		Notes
 0x1008	0x07	FN+F8		IBM: toggle screen expand
 				Lenovo: configure UltraNav,
 				or toggle screen expand.
-				On newer platforms (2024+)
-				replaced by 0x131f (see below)
+				On 2024 platforms replaced by
+				0x131f (see below) and on newer
+				platforms (2025 +) keycode is
+				replaced by 0x1401 (see below).
 
 0x1009	0x08	FN+F9		-
 
@@ -506,9 +508,11 @@ event	code	Key		Notes
 
 0x1019	0x18	unknown
 
-0x131f	...	FN+F8	        Platform Mode change.
+0x131f	...	FN+F8		Platform Mode change (2024 systems).
 				Implemented in driver.
 
+0x1401	...	FN+F8		Platform Mode change (2025 + systems).
+				Implemented in driver.
 ...	...	...
 
 0x1020	0x1F	unknown

Documentation/admin-guide/mm/transhuge.rst

@@ -436,7 +436,7 @@ AnonHugePmdMapped).
 The number of file transparent huge pages mapped to userspace is available
 by reading ShmemPmdMapped and ShmemHugePages fields in ``/proc/meminfo``.
 To identify what applications are mapping file transparent huge pages, it
-is necessary to read ``/proc/PID/smaps`` and count the FileHugeMapped fields
+is necessary to read ``/proc/PID/smaps`` and count the FilePmdMapped fields
 for each mapping.
 
 Note that reading the smaps file is expensive and reading it

Documentation/admin-guide/pm/amd-pstate.rst

@@ -251,9 +251,7 @@ performance supported in `AMD CPPC Performance Capability <perf_cap_>`_).
 In some ASICs, the highest CPPC performance is not the one in the ``_CPC``
 table, so we need to expose it to sysfs. If boost is not active, but
 still supported, this maximum frequency will be larger than the one in
-``cpuinfo``. On systems that support preferred core, the driver will have
-different values for some cores than others and this will reflect the values
-advertised by the platform at bootup.
+``cpuinfo``.
 This attribute is read-only.
 
 ``amd_pstate_lowest_nonlinear_freq``

Documentation/admin-guide/pm/cpuidle.rst

@@ -269,27 +269,7 @@ Namely, when invoked to select an idle state for a CPU (i.e. an idle state that
 the CPU will ask the processor hardware to enter), it attempts to predict the
 idle duration and uses the predicted value for idle state selection.
 
-It first obtains the time until the closest timer event with the assumption
-that the scheduler tick will be stopped.  That time, referred to as the *sleep
-length* in what follows, is the upper bound on the time before the next CPU
-wakeup.  It is used to determine the sleep length range, which in turn is needed
-to get the sleep length correction factor.
-
-The ``menu`` governor maintains two arrays of sleep length correction factors.
-One of them is used when tasks previously running on the given CPU are waiting
-for some I/O operations to complete and the other one is used when that is not
-the case.  Each array contains several correction factor values that correspond
-to different sleep length ranges organized so that each range represented in the
-array is approximately 10 times wider than the previous one.
-
-The correction factor for the given sleep length range (determined before
-selecting the idle state for the CPU) is updated after the CPU has been woken
-up and the closer the sleep length is to the observed idle duration, the closer
-to 1 the correction factor becomes (it must fall between 0 and 1 inclusive).
-The sleep length is multiplied by the correction factor for the range that it
-falls into to obtain the first approximation of the predicted idle duration.
-
-Next, the governor uses a simple pattern recognition algorithm to refine its
+It first uses a simple pattern recognition algorithm to obtain a preliminary
 idle duration prediction.  Namely, it saves the last 8 observed idle duration
 values and, when predicting the idle duration next time, it computes the average
 and variance of them.  If the variance is small (smaller than 400 square
@@ -301,29 +281,39 @@ Again, if the variance of them is small (in the above sense), the average is
 taken as the "typical interval" value and so on, until either the "typical
 interval" is determined or too many data points are disregarded, in which case
 the "typical interval" is assumed to equal "infinity" (the maximum unsigned
-integer value).  The "typical interval" computed this way is compared with the
-sleep length multiplied by the correction factor and the minimum of the two is
-taken as the predicted idle duration.
-
-Then, the governor computes an extra latency limit to help "interactive"
-workloads.  It uses the observation that if the exit latency of the selected
-idle state is comparable with the predicted idle duration, the total time spent
-in that state probably will be very short and the amount of energy to save by
-entering it will be relatively small, so likely it is better to avoid the
-overhead related to entering that state and exiting it.  Thus selecting a
-shallower state is likely to be a better option then.   The first approximation
-of the extra latency limit is the predicted idle duration itself which
-additionally is divided by a value depending on the number of tasks that
-previously ran on the given CPU and now they are waiting for I/O operations to
-complete.  The result of that division is compared with the latency limit coming
-from the power management quality of service, or `PM QoS <cpu-pm-qos_>`_,
-framework and the minimum of the two is taken as the limit for the idle states'
-exit latency.
+integer value).
+
+If the "typical interval" computed this way is long enough, the governor obtains
+the time until the closest timer event with the assumption that the scheduler
+tick will be stopped.  That time, referred to as the *sleep length* in what follows,
+is the upper bound on the time before the next CPU wakeup.  It is used to determine
+the sleep length range, which in turn is needed to get the sleep length correction
+factor.
+
+The ``menu`` governor maintains an array containing several correction factor
+values that correspond to different sleep length ranges organized so that each
+range represented in the array is approximately 10 times wider than the previous
+one.
+
+The correction factor for the given sleep length range (determined before
+selecting the idle state for the CPU) is updated after the CPU has been woken
+up and the closer the sleep length is to the observed idle duration, the closer
+to 1 the correction factor becomes (it must fall between 0 and 1 inclusive).
+The sleep length is multiplied by the correction factor for the range that it
+falls into to obtain an approximation of the predicted idle duration that is
+compared to the "typical interval" determined previously and the minimum of
+the two is taken as the idle duration prediction.
+
+If the "typical interval" value is small, which means that the CPU is likely
+to be woken up soon enough, the sleep length computation is skipped as it may
+be costly and the idle duration is simply predicted to equal the "typical
+interval" value.
 
 Now, the governor is ready to walk the list of idle states and choose one of
 them.  For this purpose, it compares the target residency of each state with
-the predicted idle duration and the exit latency of it with the computed latency
-limit.  It selects the state with the target residency closest to the predicted
+the predicted idle duration and the exit latency of it with the with the latency
+limit coming from the power management quality of service, or `PM QoS <cpu-pm-qos_>`_,
+framework.  It selects the state with the target residency closest to the predicted
 idle duration, but still below it, and exit latency that does not exceed the
 limit.
 

Documentation/core-api/packing.rst

@@ -227,11 +227,119 @@ Intended use
 
 Drivers that opt to use this API first need to identify which of the above 3
 quirk combinations (for a total of 8) match what the hardware documentation
-describes. Then they should wrap the packing() function, creating a new
-xxx_packing() that calls it using the proper QUIRK_* one-hot bits set.
+describes.
+
+There are 3 supported usage patterns, detailed below.
+
+packing()
+^^^^^^^^^
+
+This API function is deprecated.
 
 The packing() function returns an int-encoded error code, which protects the
 programmer against incorrect API use.  The errors are not expected to occur
-during runtime, therefore it is reasonable for xxx_packing() to return void
-and simply swallow those errors. Optionally it can dump stack or print the
-error description.
+during runtime, therefore it is reasonable to wrap packing() into a custom
+function which returns void and swallows those errors. Optionally it can
+dump stack or print the error description.
+
+.. code-block:: c
+
+  void my_packing(void *buf, u64 *val, int startbit, int endbit,
+                  size_t len, enum packing_op op)
+  {
+          int err;
+
+          /* Adjust quirks accordingly */
+          err = packing(buf, val, startbit, endbit, len, op, QUIRK_LSW32_IS_FIRST);
+          if (likely(!err))
+                  return;
+
+          if (err == -EINVAL) {
+                  pr_err("Start bit (%d) expected to be larger than end (%d)\n",
+                         startbit, endbit);
+          } else if (err == -ERANGE) {
+                  if ((startbit - endbit + 1) > 64)
+                          pr_err("Field %d-%d too large for 64 bits!\n",
+                                 startbit, endbit);
+                  else
+                          pr_err("Cannot store %llx inside bits %d-%d (would truncate)\n",
+                                 *val, startbit, endbit);
+          }
+          dump_stack();
+  }
+
+pack() and unpack()
+^^^^^^^^^^^^^^^^^^^
+
+These are const-correct variants of packing(), and eliminate the last "enum
+packing_op op" argument.
+
+Calling pack(...) is equivalent, and preferred, to calling packing(..., PACK).
+
+Calling unpack(...) is equivalent, and preferred, to calling packing(..., UNPACK).
+
+pack_fields() and unpack_fields()
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The library exposes optimized functions for the scenario where there are many
+fields represented in a buffer, and it encourages consumer drivers to avoid
+repetitive calls to pack() and unpack() for each field, but instead use
+pack_fields() and unpack_fields(), which reduces the code footprint.
+
+These APIs use field definitions in arrays of ``struct packed_field_u8`` or
+``struct packed_field_u16``, allowing consumer drivers to minimize the size
+of these arrays according to their custom requirements.
+
+The pack_fields() and unpack_fields() API functions are actually macros which
+automatically select the appropriate function at compile time, based on the
+type of the fields array passed in.
+
+An additional benefit over pack() and unpack() is that sanity checks on the
+field definitions are handled at compile time with ``BUILD_BUG_ON`` rather
+than only when the offending code is executed. These functions return void and
+wrapping them to handle unexpected errors is not necessary.
+
+It is recommended, but not required, that you wrap your packed buffer into a
+structured type with a fixed size. This generally makes it easier for the
+compiler to enforce that the correct size buffer is used.
+
+Here is an example of how to use the fields APIs:
+
+.. code-block:: c
+
+   /* Ordering inside the unpacked structure is flexible and can be different
+    * from the packed buffer. Here, it is optimized to reduce padding.
+    */
+   struct data {
+        u64 field3;
+        u32 field4;
+        u16 field1;
+        u8 field2;
+   };
+
+   #define SIZE 13
+
+   typdef struct __packed { u8 buf[SIZE]; } packed_buf_t;
+
+   static const struct packed_field_u8 fields[] = {
+           PACKED_FIELD(100, 90, struct data, field1),
+           PACKED_FIELD(90, 87, struct data, field2),
+           PACKED_FIELD(86, 30, struct data, field3),
+           PACKED_FIELD(29, 0, struct data, field4),
+   };
+
+   void unpack_your_data(const packed_buf_t *buf, struct data *unpacked)
+   {
+           BUILD_BUG_ON(sizeof(*buf) != SIZE;
+
+           unpack_fields(buf, sizeof(*buf), unpacked, fields,
+                         QUIRK_LITTLE_ENDIAN);
+   }
+
+   void pack_your_data(const struct data *unpacked, packed_buf_t *buf)
+   {
+           BUILD_BUG_ON(sizeof(*buf) != SIZE;
+
+           pack_fields(buf, sizeof(*buf), unpacked, fields,
+                       QUIRK_LITTLE_ENDIAN);
+   }