Commit 2ee738e9 authored by Jakub Kicinski's avatar Jakub Kicinski
Browse files

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

Cross-merge networking fixes after downstream PR (net-6.13-rc8).

Conflicts:

drivers/net/ethernet/realtek/r8169_main.c
  1f691a1f ("r8169: remove redundant hwmon support")
  152d00a9 ("r8169: simplify setting hwmon attribute visibility")
https://lore.kernel.org/20250115122152.760b4e8d@canb.auug.org.au



Adjacent changes:

drivers/net/ethernet/broadcom/bnxt/bnxt.c
  152f4da0 ("bnxt_en: add support for rx-copybreak ethtool command")
  f0aa6a37 ("eth: bnxt: always recalculate features after XDP clearing, fix null-deref")

drivers/net/ethernet/intel/ice/ice_type.h
  50327223 ("ice: add lock to protect low latency interface")
  dc26548d ("ice: Fix quad registers read on E825")

Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
parents b44e27b4 ce69b401

.mailmap

+2 −0
Original line number Diff line number Diff line
@@ -121,6 +121,8 @@ Ben Widawsky <bwidawsk@kernel.org> <benjamin.widawsky@intel.com> 
Benjamin Poirier <benjamin.poirier@gmail.com> <bpoirier@suse.de>

Benjamin Tissoires <bentiss@kernel.org> <benjamin.tissoires@gmail.com>

Benjamin Tissoires <bentiss@kernel.org> <benjamin.tissoires@redhat.com>

Bingwu Zhang <xtex@aosc.io> <xtexchooser@duck.com>

Bingwu Zhang <xtex@aosc.io> <xtex@xtexx.eu.org>

Bjorn Andersson <andersson@kernel.org> <bjorn@kryo.se>

Bjorn Andersson <andersson@kernel.org> <bjorn.andersson@linaro.org>

Bjorn Andersson <andersson@kernel.org> <bjorn.andersson@sonymobile.com>

Documentation/admin-guide/pm/cpuidle.rst

+31 −41
Original line number Diff line number Diff line
@@ -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/devicetree/bindings/display/mediatek/mediatek,dp.yaml

+18 −1
Original line number Diff line number Diff line
@@ -42,6 +42,9 @@ properties: 
  interrupts:

    maxItems: 1



  '#sound-dai-cells':

    const: 0



  ports:

    $ref: /schemas/graph.yaml#/properties/ports

    properties:
@@ -85,7 +88,21 @@ required: 
  - ports

  - max-linkrate-mhz



additionalProperties: false

allOf:

  - $ref: /schemas/sound/dai-common.yaml#

  - if:

      not:

        properties:

          compatible:

            contains:

              enum:

                - mediatek,mt8188-dp-tx

                - mediatek,mt8195-dp-tx

    then:

      properties:

        '#sound-dai-cells': false



unevaluatedProperties: false



examples:

  - |

Documentation/devicetree/bindings/iio/st,st-sensors.yaml

+1 −0
Original line number Diff line number Diff line
@@ -65,6 +65,7 @@ properties: 
          - st,lsm9ds0-gyro

      - description: STMicroelectronics Magnetometers

        enum:

          - st,iis2mdc

          - st,lis2mdl

          - st,lis3mdl-magn

          - st,lsm303agr-magn

Documentation/sound/codecs/cs35l56.rst

0 → 100644
+292 −0
Original line number Diff line number Diff line 
.. SPDX-License-Identifier: GPL-2.0-only



=====================================================================

Audio drivers for Cirrus Logic CS35L54/56/57 Boosted Smart Amplifiers

=====================================================================

:Copyright: 2025 Cirrus Logic, Inc. and

                 Cirrus Logic International Semiconductor Ltd.



Contact: patches@opensource.cirrus.com



Summary

=======



The high-level summary of this document is:



**If you have a laptop that uses CS35L54/56/57 amplifiers but audio is not

working, DO NOT ATTEMPT TO USE FIRMWARE AND SETTINGS FROM ANOTHER LAPTOP,

EVEN IF THAT LAPTOP SEEMS SIMILAR.**



The CS35L54/56/57 amplifiers must be correctly configured for the power

supply voltage, speaker impedance, maximum speaker voltage/current, and

other external hardware connections.



The amplifiers feature advanced boost technology that increases the voltage

used to drive the speakers, while proprietary speaker protection algorithms

allow these boosted amplifiers to push the limits of the speakers without

causing damage. These **must** be configured correctly.



Supported Cirrus Logic amplifiers

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



The cs35l56 drivers support:



* CS35L54

* CS35L56

* CS35L57



There are two drivers in the kernel



*For systems using SoundWire*: sound/soc/codecs/cs35l56.c and associated files



*For systems using HDA*: sound/pci/hda/cs35l56_hda.c



Firmware

========



The amplifier is controlled and managed by firmware running on the internal

DSP. Firmware files are essential to enable the full capabilities of the

amplifier.



Firmware is distributed in the linux-firmware repository:

https://gitlab.com/kernel-firmware/linux-firmware.git



On most SoundWire systems the amplifier has a default minimum capability to

produce audio. However this will be



* at low volume, to protect the speakers, since the speaker specifications

  and power supply voltages are unknown.

* a mono mix of left and right channels.



On some SoundWire systems that have both CS42L43 and CS35L56/57 the CS35L56/57

receive their audio from the CS42L43 instead of directly from the host

SoundWire interface. These systems can be identified by the CS42L43 showing

in dmesg as a SoundWire device, but the CS35L56/57 as SPI. On these systems

the firmware is *mandatory* to enable receiving the audio from the CS42L43.



On HDA systems the firmware is *mandatory* to enable HDA bridge mode. There

will not be any audio from the amplifiers without firmware.



Cirrus Logic firmware files

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



Each amplifier requires two firmware files. One file has a .wmfw suffix, the

other has a .bin suffix.



The firmware is customized by the OEM to match the hardware of each laptop,

and the firmware is specific to that laptop. Because of this, there are many

firmware files in linux-firmware for these amplifiers. Firmware files are

**not interchangeable between laptops**.



Cirrus Logic submits files for known laptops to the upstream linux-firmware

repository. Providing Cirrus Logic is aware of a particular laptop and has

permission from the manufacturer to publish the firmware, it will be pushed

to linux-firmware. You may need to upgrade to a newer release of

linux-firmware to obtain the firmware for your laptop.



**Important:** the Makefile for linux-firmware creates symlinks that are listed

in the WHENCE file. These symlinks are required for the CS35L56 driver to be

able to load the firmware.



How do I know which firmware file I should have?

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

All firmware file names are qualified with a unique "system ID". On normal

x86 PCs with PCI audio this is the Vendor Subsystem ID (SSID) of the host

PCI audio interface.



The SSID can be viewed using the lspci tool::



  lspci -v -nn | grep -A2 -i audio

  0000:00:1f.3 Audio device [0403]: Intel Corporation Meteor Lake-P HD Audio Controller [8086:7e28]

  Subsystem: Dell Meteor Lake-P HD Audio Controller [1028:0c63]



In this example the SSID is 10280c63.



The format of the firmware file names is:



    cs35lxx-b0-dsp1-misc-SSID[-spkidX]-ampN



Where:



  * cs35lxx-b0 is the amplifier model and silicon revision. This information

    is logged by the driver during initialization.

  * SSID is the 8-digit hexadecimal SSID value.

  * ampN is the amplifier number (for example amp1). This is the same as

    the prefix on the ALSA control names except that it is always lower-case

    in the file name.

  * spkidX is an optional part, used for laptops that have firmware

    configurations for different makes and models of internal speakers.



Sound Open Firmware and ALSA topology files

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



All SoundWire systems will require a Sound Open Firmware (SOF) for the

host CPU audio DSP, together with an ALSA topology file (.tplg).



The SOF firmware will usually be provided by the manufacturer of the host

CPU (i.e. Intel or AMD). The .tplg file is normally part of the SOF firmware

release.



SOF binary builds are available from: https://github.com/thesofproject/sof-bin/releases



The main SOF source is here: https://github.com/thesofproject



ALSA-ucm configurations

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

Typically an appropriate ALSA-ucm configuration file is needed for

use-case managers and audio servers such as PipeWire.



Configuration files are available from the alsa-ucm-conf repository:

https://git.alsa-project.org/?p=alsa-ucm-conf.git



Kernel log messages

===================



SoundWire

---------

A successful initialization will look like this (this will be repeated for

each amplifier)::



  [ 7.568374] cs35l56 sdw:0:0:01fa:3556:01:0: supply VDD_P not found, using dummy regulator

  [ 7.605208] cs35l56 sdw:0:0:01fa:3556:01:0: supply VDD_IO not found, using dummy regulator

  [ 7.605313] cs35l56 sdw:0:0:01fa:3556:01:0: supply VDD_A not found, using dummy regulator

  [ 7.939279] cs35l56 sdw:0:0:01fa:3556:01:0: Cirrus Logic CS35L56 Rev B0 OTP3 fw:3.4.4 (patched=0)

  [ 7.947844] cs35l56 sdw:0:0:01fa:3556:01:0: Slave 4 state check1: UNATTACHED, status was 1

  [ 8.740280] cs35l56 sdw:0:0:01fa:3556:01:0: supply VDD_B not found, using dummy regulator

  [ 8.740552] cs35l56 sdw:0:0:01fa:3556:01:0: supply VDD_AMP not found, using dummy regulator

  [ 9.242164] cs35l56 sdw:0:0:01fa:3556:01:0: DSP1: cirrus/cs35l56-b0-dsp1-misc-xxxxxxxx.wmfw: format 3 timestamp 0x66b2b872

  [ 9.242173] cs35l56 sdw:0:0:01fa:3556:01:0: DSP1: cirrus/cs35l56-b0-dsp1-misc-xxxxxxxx.wmfw: Tue 05 Dec 2023 21:37:21 GMT Standard Time

  [ 9.991709] cs35l56 sdw:0:0:01fa:3556:01:0: DSP1: Firmware: 1a00d6 vendor: 0x2 v3.11.23, 41 algorithms

  [10.039098] cs35l56 sdw:0:0:01fa:3556:01:0: DSP1: cirrus/cs35l56-b0-dsp1-misc-xxxxxxxx-amp1.bin: v3.11.23

  [10.879235] cs35l56 sdw:0:0:01fa:3556:01:0: Slave 4 state check1: UNATTACHED, status was 1

  [11.401536] cs35l56 sdw:0:0:01fa:3556:01:0: Calibration applied



HDA

---

A successful initialization will look like this (this will be repeated for

each amplifier)::



  [ 6.306475] cs35l56-hda i2c-CSC3556:00-cs35l56-hda.0: Cirrus Logic CS35L56 Rev B0 OTP3 fw:3.4.4 (patched=0)

  [ 6.613892] cs35l56-hda i2c-CSC3556:00-cs35l56-hda.0: DSP system name: 'xxxxxxxx', amp name: 'AMP1'

  [ 8.266660] snd_hda_codec_cs8409 ehdaudio0D0: bound i2c-CSC3556:00-cs35l56-hda.0 (ops cs35l56_hda_comp_ops [snd_hda_scodec_cs35l56])

  [ 8.287525] cs35l56-hda i2c-CSC3556:00-cs35l56-hda.0: DSP1: cirrus/cs35l56-b0-dsp1-misc-xxxxxxxx.wmfw: format 3 timestamp 0x66b2b872

  [ 8.287528] cs35l56-hda i2c-CSC3556:00-cs35l56-hda.0: DSP1: cirrus/cs35l56-b0-dsp1-misc-xxxxxxxx.wmfw: Tue 05 Dec 2023 21:37:21 GMT Standard Time

  [ 9.984335] cs35l56-hda i2c-CSC3556:00-cs35l56-hda.0: DSP1: Firmware: 1a00d6 vendor: 0x2 v3.11.23, 41 algorithms

  [10.085797] cs35l56-hda i2c-CSC3556:00-cs35l56-hda.0: DSP1: cirrus/cs35l56-b0-dsp1-misc-xxxxxxxx-amp1.bin: v3.11.23

  [10.655237] cs35l56-hda i2c-CSC3556:00-cs35l56-hda.0: Calibration applied



Important messages

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

Cirrus Logic CS35L56 Rev B0 OTP3 fw:3.4.4 (patched=0)

  Shows that the driver has been able to read device ID registers from the

  amplifier.



    * The actual amplifier type and silicon revision (CS35L56 B0 in this

      example) is shown, as read from the amplifier identification registers.

    * (patched=0) is normal, and indicates that the amplifier has been hard

      reset and is running default ROM firmware.

    * (patched=1) means that something has previously downloaded firmware

      to the amplifier and the driver does not have control of the RESET

      signal to be able to replace this preloaded firmware. This is normal

      for systems where the BIOS downloads firmware to the amplifiers

      before OS boot.

      This status can also be seen if the cs35l56 kernel module is unloaded

      and reloaded on a system where the driver does not have control of

      RESET. SoundWire systems typically do not give the driver control of

      RESET and only a BIOS (re)boot can reset the amplifiers.



DSP1: cirrus/cs35l56-b0-dsp1-misc-xxxxxxxx.wmfw

  Shows that a .wmfw firmware file was found and downloaded.



DSP1: cirrus/cs35l56-b0-dsp1-misc-xxxxxxxx-amp1.bin

  Shows that a .bin firmware file was found and downloaded.



Calibration applied

  Factory calibration data in EFI was written to the amplifier.



Error messages

==============

This section explains some of the error messages that the driver can log.



Algorithm coefficient version %d.%d.%d but expected %d.%d.%d

  The version of the .bin file content does not match the loaded firmware.

  Caused by mismatched .wmfw and .bin file, or .bin file was found but

  .wmfw was not.



No %s for algorithm %x

  The version of the .bin file content does not match the loaded firmware.

  Caused by mismatched .wmfw and .bin file, or .bin file was found but

  .wmfw was not.



.bin file required but not found

  HDA driver did not find a .bin file that matches this hardware.



Calibration disabled due to missing firmware controls

  Driver was not able to write EFI calibration data to firmware registers.

  This typically means that either:



    * The driver did not find a suitable wmfw for this hardware, or

    * The amplifier has already been patched with firmware by something

      previously, and the driver does not have control of a hard RESET line

      to be able to reset the amplifier and download the firmware files it

      found. This situation is indicated by the device identification

      string in the kernel log shows "(patched=1)"



Failed to write calibration

  Same meaning and cause as "Calibration disabled due to missing firmware

  controls"



Failed to read calibration data from EFI

  Factory calibration data in EFI is missing, empty or corrupt.

  This is most likely to be cause by accidentally deleting the file from

  the EFI filesystem.



No calibration for silicon ID

  The factory calibration data in EFI does not match this hardware.

  The most likely cause is that an amplifier has been replaced on the

  motherboard without going through manufacturer calibration process to

  generate calibration data for the new amplifier.



Did not find any buses for CSCxxxx

  Only on HDA systems. The HDA codec driver found an ACPI entry for

  Cirrus Logic companion amps, but could not enumerate the ACPI entries for

  the I2C/SPI buses. The most likely cause of this is that:



    * The relevant bus driver (I2C or SPI) is not part of the kernel.

    * The HDA codec driver was built-in to the kernel but the I2C/SPI

      bus driver is a module and so the HDA codec driver cannot call the

      bus driver functions.



init_completion timed out

  The SoundWire bus controller (host end) did not enumerate the amplifier.

  In other words, the ACPI says there is an amplifier but for some reason

  it was not detected on the bus.



No AF01 node

  Indicates an error in ACPI. A SoundWire system should have a Device()

  node named "AF01" but it was not found.



Failed to get spk-id-gpios

  ACPI says that the driver should request a GPIO but the driver was not

  able to get that GPIO. The most likely cause is that the kernel does not

  include the correct GPIO or PINCTRL driver for this system.



Failed to read spk-id

  ACPI says that the driver should request a GPIO but the driver was not

  able to read that GPIO.



Unexpected spk-id element count

  AF01 contains more speaker ID GPIO entries than the driver supports



Overtemp error

  Amplifier overheat protection was triggered and the amplifier shut down

  to protect itself.



Amp short error

  Amplifier detected a short-circuit on the speaker output pins and shut

  down for protection. This would normally indicate a damaged speaker.



Hibernate wake failed

  The driver tried to wake the amplifier from its power-saving state but

  did not see the expected responses from the amplifier. This can be caused

  by using firmware that does not match the hardware.