summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-01-14ASoC: intel: convert to snd_soc_dapm_xxx()Kuninori Morimoto
This patch uses snd_soc_card_to_dapm() to get dapm from card Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Link: https://patch.msgid.link/87tswv1t9c.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14ASoC: SDCA: Add lock to serialise the Function initialisationCharles Keepax
To avoid issues on some devices serialise the boot of each SDCA Function from the others. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20260109145206.3456151-5-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14ASoC: SDCA: Device boot into the system suspend processCharles Keepax
When system suspending the device may be powered off, this means all state will be lost and the firmware may need to be re-downloaded. Add the necessary calls to bring the device back up. This also requires that that the FDL (firmware download) IRQ handler is modified to allow it to run before runtime PM has been fully restored. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20260109145206.3456151-4-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14ASoC: SDCA: Add basic system suspend supportCharles Keepax
Add basic system suspend support. Disable the IRQs and force runtime suspend, during system suspend, because the device will likely fully power down during suspend. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20260109145206.3456151-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14ASoC: SDCA: Add SDCA IRQ enable/disable helpersCharles Keepax
Add helpers to enable and disable the SDCA IRQs by Function. These are useful to sequence the powering down and up around system suspend. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Link: https://patch.msgid.link/20260109145206.3456151-2-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14ASoC: codecs: aw88261: use dvdd-supply regulatorBharadwaj Raju
The AW88261 needs the DVDD pin to be powered on to start up. Get and enable the dvdd-supply regulator. Signed-off-by: Bharadwaj Raju <bharadwaj.raju@machinesoul.in> Link: https://patch.msgid.link/20260114-aw88261-dvdd-v2-2-ef485b82a7a7@machinesoul.in Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14ASoC: dt-bindings: document dvdd-supply property for awinic,aw88261Bharadwaj Raju
Add (and require) the dvdd-supply property for awinic,aw88261 in the awinic,aw88395.yaml binding. The chip needs DVDD to power on, and currently there are no users of this compatible in the kernel device trees, so we should be fine to change the ABI in this case. Signed-off-by: Bharadwaj Raju <bharadwaj.raju@machinesoul.in> Link: https://patch.msgid.link/20260114-aw88261-dvdd-v2-1-ef485b82a7a7@machinesoul.in Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14ASoC: tlv320adcx140: add channel sum controlEmil Svendsen
Add control for channel summation. 3 modes are supported: 1. "Disabled": Normal operation 2. "2 Channel": Every two channels are summed and divided by 2 Out 1 <- (CH1 + CH2) / 2 Out 2 <- (CH1 + CH2) / 2 Out 3 <- (CH3 + CH4) / 2 Out 4 <- (CH3 + CH4) / 2 3. "4 Channel": Every four channels are summed and divided by 4 Out 1 <- (CH1 + CH2 + CH3 + CH4) / 4 Out 2 <- (CH1 + CH2 + CH3 + CH4) / 4 Out 3 <- (CH1 + CH2 + CH3 + CH4) / 4 Out 4 <- (CH1 + CH2 + CH3 + CH4) / 4 Signed-off-by: Emil Svendsen <emas@bang-olufsen.dk> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://patch.msgid.link/20260113-sound-soc-codecs-tvl320adcx140-v4-10-8f7ecec525c8@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14ASoC: tlv320adcx140: add kcontrol for num biquadsEmil-Juhl
The tlv320adcx140 chips have a configurable amount of biquad filters enabled per input channel. Currently this number is always left at the default value of 2 biquads per channel. This commit adds a kcontrol to allow runtime configuration of the amount of biquads per channel. The configuration is controlled by bits [5-6] in the DSP_CFG1 register. Signed-off-by: Emil-Juhl <juhl.emildahl@gmail.com> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://patch.msgid.link/20260113-sound-soc-codecs-tvl320adcx140-v4-9-8f7ecec525c8@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14ASoC: dt-bindings: add avdd and iovdd supplySascha Hauer
Add bindings for the avdd-supply and iovdd-supply which are named after the corresponding pins on the tlv320adcx140 chips. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://patch.msgid.link/20260113-sound-soc-codecs-tvl320adcx140-v4-8-8f7ecec525c8@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14ASoC: dt-bindings: clarify areg-supply documentationEmil-Juhl
The documentation for areg-supply could cause confusion mainly in terms of the relationship between AREG and AVDD. According to the datasheet[1] the AREG can be one of two cases: 1) an external 1.8V supply 2) generated by an internal regulator (hence a 1.8V output) [1] https://www.ti.com/lit/ds/symlink/tlv320adc5140.pdf Signed-off-by: Emil-Juhl <juhl.emildahl@gmail.com> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260113-sound-soc-codecs-tvl320adcx140-v4-7-8f7ecec525c8@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14ASoC: tlv320adcx140: add avdd and iovdd supplyEmil-Juhl
The datasheet, under "10 Power Supply Recommendations" section, specifies that both the AVDD and IOVDD supplies must be up and stable for at least 100us before the SHDNZ can be released. After that, the chip is ready to receive commands after another 2ms. Currently the driver doesn't contain any options to bind AVDD and IOVDD supplies to the tlv320adcx140. This commit adds bindings for AVDD and IOVDD supplies which the driver will enable when used. Signed-off-by: Emil-Juhl <juhl.emildahl@gmail.com> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://patch.msgid.link/20260113-sound-soc-codecs-tvl320adcx140-v4-6-8f7ecec525c8@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14ASoC: tlv320adcx140: power on/off the device on demandEmil-Juhl
The tlv320adcx140 can be connected to controllable AVDD/IOVDD regulators which when disabled will reset the registers to their default. In preparation for that switch to register writes to cache only when powered off and sync the cached values to the registers when powered back on. Signed-off-by: Emil-Juhl <juhl.emildahl@gmail.com> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://patch.msgid.link/20260113-sound-soc-codecs-tvl320adcx140-v4-5-8f7ecec525c8@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14ASoC: tlv320adcx140: fix word lengthEmil Svendsen
The word length is the physical width of the channel slots. So the hw_params would misconfigure when format width and physical width doesn't match. Like S24_LE which has data width of 24 bits but physical width of 32 bits. So if using asymmetric formats you will get a lot of noise. Fixes: 689c7655b50c5 ("ASoC: tlv320adcx140: Add the tlv320adcx140 codec driver family") Signed-off-by: Emil Svendsen <emas@bang-olufsen.dk> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://patch.msgid.link/20260113-sound-soc-codecs-tvl320adcx140-v4-4-8f7ecec525c8@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14ASoC: tlv320adcx140: Propagate error codes during probeDimitrios Katsaros
When scanning for the reset pin, we could get an -EPROBE_DEFER. The driver would assume that no reset pin had been defined, which would mean that the chip would never be powered. Now we both respect any error we get from devm_gpiod_get_optional. We also now properly report the missing GPIO definition when 'gpio_reset' is NULL. Signed-off-by: Dimitrios Katsaros <patcherwork@gmail.com> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://patch.msgid.link/20260113-sound-soc-codecs-tvl320adcx140-v4-3-8f7ecec525c8@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14ASoC: tlv320adcx140: fix null pointerEmil Svendsen
The "snd_soc_component" in "adcx140_priv" was only used once but never set. It was only used for reaching "dev" which is already present in "adcx140_priv". Fixes: 4e82971f7b55 ("ASoC: tlv320adcx140: Add a new kcontrol") Signed-off-by: Emil Svendsen <emas@bang-olufsen.dk> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://patch.msgid.link/20260113-sound-soc-codecs-tvl320adcx140-v4-2-8f7ecec525c8@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14ASoC: tlv320adcx140: invert DRE_ENABLEEmil Svendsen
Looking at section 8.6.1.1.69 in datasheets for both 5140 and 6140 (3140 doesn't support DRE). REG ADCX140_DSP_CFG1 BIT 3 field "DRE_AGC_SEL" it select either DRE or AGC. It states: * 0 = DRE * 1 = AGC The control is called "DRE_ENABLE" and for it to be true it has to be active low. This commit will invert the control so "DRE_ENABLE" is active low. Signed-off-by: Emil Svendsen <emas@bang-olufsen.dk> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Link: https://patch.msgid.link/20260113-sound-soc-codecs-tvl320adcx140-v4-1-8f7ecec525c8@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14ASoC: sdw_utils: cs42l43: Enable Headphone pin for LINEOUT jack typeCole Leavitt
The CS42L43 codec's load detection can return different impedance values that map to either HEADPHONE or LINEOUT jack types. However, the soc_jack_pins array only maps SND_JACK_HEADPHONE to the "Headphone" DAPM pin, not SND_JACK_LINEOUT. When headphones are detected with an impedance that maps to LINEOUT (such as impedance value 0x2), the driver reports SND_JACK_LINEOUT. Since this doesn't match the jack pin mask, the "Headphone" DAPM pin is not activated, and no audio is routed to the headphone outputs. Fix by adding SND_JACK_LINEOUT to the Headphone pin mask, so that both headphone and line-out detection properly enable the headphone output path. This fixes no audio output on devices like the Lenovo ThinkPad P16 Gen 3 where headphones are detected with LINEOUT impedance. Fixes: d74bad3b7452 ("ASoC: intel: sof_sdw_cs42l43: Create separate jacks for hp and mic") Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Cole Leavitt <cole@unwrap.rs> Link: https://patch.msgid.link/20260114025518.28519-1-cole@unwrap.rs Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14ASoC: sdw_utils: Call init callbacks on the correct codec DAIRichard Fitzgerald
asoc_sdw_rtd_init() needs to call the rtd_init() callbacks for each codec in a dailink. It was finding the codecs by looking for the matching DAI name in codec_info_list[] but this isn't correct, because the DAI name isn't guaranteed to be unique. Parts using the same codec driver (so the same DAI names) might require different machine driver setup. Instead, get the struct sdw_slave and extract the SoundWire part ID. Use this to lookup the entry in codec_info_list[]. This is the same identity info that was used to find the entry when the machine driver created the dailink. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: e377c9477317 ("ASoC: intel/sdw_utils: move soundwire codec_info_list structure") Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260112140758.215799-3-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14soundwire: Add missing EXPORT for sdw_slave_typeRichard Fitzgerald
include/sdw_type.h provides the function is_sdw_slave() which requires sdw_slave_type. But sdw_slave_type was not exported. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Acked-by: Vinod Koul <vkoul@kernel.org> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260112140758.215799-2-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-01-14wifi: mac80211: Check for MLE before appending in Authentication frameKavita Kavita
Currently, in MLO connections, userspace constructs most of the Authentication frame body, excluding the Multi-Link element (MLE), which mac80211 appends later in ieee80211_send_auth(). At present, mac80211 always adds the MLE itself, since userspace (e.g. wpa_supplicant) does not yet include it. However, for new authentication protocols such as Enhanced Privacy Protection Key Exchange (EPPKE), as specified in "IEEE P802.11bi/D3.0 section 12.16.9", the MLE must be included in userspace so that the Message Integrity Code (MIC) can be computed correctly over the complete frame body. Table 9-71 specifies that the MIC is mandatory. If mac80211 appends the MLE again, the Authentication frame becomes invalid. Add a check in ieee80211_send_auth() to detect whether the MLE is already present in the Authentication frame body before appending. Skip the append if the MLE exists, otherwise add it as before. Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com> Link: https://patch.msgid.link/20260114111900.2196941-7-kavita.kavita@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-14wifi: mac80211: allow key installation before associationKavita Kavita
Currently, mac80211 allows key installation only after association completes. However, Enhanced Privacy Protection Key Exchange (EPPKE) requires key installation before association to enable encryption and decryption of (Re)Association Request and Response frames. Add support to install keys prior to association when the peer is an Enhanced Privacy Protection (EPP) peer that requires encryption and decryption of (Re)Association Request and Response frames. Introduce a new boolean parameter "epp_peer" in the "ieee80211_sta" profile to indicate that the peer supports the Enhanced Privacy Protection Key Exchange (EPPKE) protocol. For non-AP STA mode, it is set when the authentication algorithm is WLAN_AUTH_EPPKE during station profile initialization. For AP mode, it is set during NL80211_CMD_NEW_STA and NL80211_CMD_ADD_LINK_STA. When "epp_peer" parameter is set, mac80211 now accepts keys before association and enables encryption of the (Re)Association Request/Response frames. Co-developed-by: Sai Pratyusha Magam <sai.magam@oss.qualcomm.com> Signed-off-by: Sai Pratyusha Magam <sai.magam@oss.qualcomm.com> Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com> Link: https://patch.msgid.link/20260114111900.2196941-6-kavita.kavita@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-14wifi: nl80211: Add support for EPP peer indicationSai Pratyusha Magam
Introduce a new netlink attribute NL80211_ATTR_EPP_PEER to be used with NL80211_CMD_NEW_STA and NL80211_CMD_ADD_LINK_STA for the userspace to indicate that a non-AP STA is an Enhanced Privacy Protection (EPP) peer. Co-developed-by: Rohan Dutta <quic_drohan@quicinc.com> Signed-off-by: Rohan Dutta <quic_drohan@quicinc.com> Signed-off-by: Sai Pratyusha Magam <sai.magam@oss.qualcomm.com> Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com> Link: https://patch.msgid.link/20260114111900.2196941-5-kavita.kavita@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-14wifi: cfg80211: add support for key configuration before associationKavita Kavita
Currently, cfg80211 does not allow key installation, removal, or modification prior to association in non-AP STA mode. However, Enhanced Privacy Protection Key Exchange (EPPKE) requires encryption keys to be managed before association. Add support to manage keys before association in non-AP STA mode when the NL80211_EXT_FEATURE_ASSOC_FRAME_ENCRYPTION feature flag is set. If the flag is not set, reject the encryption keys. Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com> Link: https://patch.msgid.link/20260114111900.2196941-4-kavita.kavita@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-14wifi: cfg80211: add feature flag for (re)association frame encryptionAiny Kumari
Introduce an extended feature flag that allows drivers to signal support for encryption of (Re)Association Request and Response frames in both non-AP STA and AP mode, as specified in specification "IEEE P802.11bi/D3.0, 12.16.6". Signed-off-by: Ainy Kumari <ainy.kumari@oss.qualcomm.com> Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com> Link: https://patch.msgid.link/20260114111900.2196941-3-kavita.kavita@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-14wifi: cfg80211: add support for EPPKE Authentication ProtocolAiny Kumari
Add an extended feature flag NL80211_EXT_FEATURE_EPPKE to allow a driver to indicate support for the Enhanced Privacy Protection Key Exchange (EPPKE) authentication protocol in non-AP STA mode, as defined in "IEEE P802.11bi/D3.0, 12.16.9". In case of SME in userspace, the Authentication frame body is prepared in userspace while the driver finalizes the Authentication frame once it receives the required fields and elements. The driver indicates support for EPPKE using the extended feature flag so that userspace can initiate EPPKE authentication. When the feature flag is set, process EPPKE Authentication frames from userspace in non-AP STA mode. If the flag is not set, reject EPPKE Authentication frames. Define a new authentication type NL80211_AUTHTYPE_EPPKE for EPPKE. Signed-off-by: Ainy Kumari <ainy.kumari@oss.qualcomm.com> Co-developed-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com> Signed-off-by: Kavita Kavita <kavita.kavita@oss.qualcomm.com> Link: https://patch.msgid.link/20260114111900.2196941-2-kavita.kavita@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-01-14kconfig: fix static linking of nconfArkadiusz Kozdra
When running make nconfig with a static linking host toolchain, the libraries are linked in an incorrect order, resulting in errors similar to the following: $ MAKEFLAGS='HOSTCC=cc\ -static' make nconfig /usr/bin/ld: /usr/lib64/gcc/x86_64-unknown-linux-gnu/14.2.1/../../../../lib64/libpanel.a(p_new.o): in function `new_panel': (.text+0x13): undefined reference to `_nc_panelhook_sp' /usr/bin/ld: (.text+0x6c): undefined reference to `_nc_panelhook_sp' Fixes: 1c5af5cf9308 ("kconfig: refactor ncurses package checks for building mconf and nconf") Signed-off-by: Arusekk <floss@arusekk.pl> Link: https://patch.msgid.link/20260110114808.22595-1-floss@arusekk.pl [nsc: Added comment about library order] Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-01-14Merge tag 'phy_common_properties' into nextVinod Koul
phy common properties Vladimir Oltean <vladimir.oltean@nxp.com> wrote: Introduce "rx-polarity" and "tx-polarity" device tree properties with Kunit tests
2026-01-14kbuild: prefer ${NM} in check-function-names.shCarlos Llamas
The check-function-names.sh scripts invokes 'nm' directly and this can be problematic during cross-compilation when the toolchain is different from the system's default (e.g. LLVM=1). scripts/check-function-names.sh: nm: not found Let's prefer the ${NM} variable which is already set by kbuild. However, still fallback to plain 'nm' to ensure the script is still usable when called directly. Fixes: 93863f3f859a ("kbuild: Check for functions with ambiguous -ffunction-sections section names") Signed-off-by: Carlos Llamas <cmllamas@google.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20251218175824.3122690-1-cmllamas@google.com Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-01-14phy: add phy_get_rx_polarity() and phy_get_tx_polarity()Vladimir Oltean
Add helpers in the generic PHY folder which can be used using 'select PHY_COMMON_PROPS' from Kconfig, without otherwise needing to enable GENERIC_PHY. These helpers need to deal with the slight messiness of the fact that the polarity properties are arrays per protocol, and with the fact that there is no default value mandated by the standard properties, all default values depend on driver and protocol (PHY_POL_NORMAL may be a good default for SGMII, whereas PHY_POL_AUTO may be a good default for PCIe). Push the supported mask of polarities to these helpers, to simplify drivers such that they don't need to validate what's in the device tree (or other firmware description). Add a KUnit test suite to make sure that the API produces the expected results. The fact that we use fwnode structures means we can validate with software nodes, and as opposed to the device_property API, we can bypass the need to have a device structure. Co-developed-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20260111093940.975359-6-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14dt-bindings: phy-common-props: RX and TX lane polarity inversionVladimir Oltean
Differential signaling is a technique for high-speed protocols to be more resilient to noise. At the transmit side we have a positive and a negative signal which are mirror images of each other. At the receiver, if we subtract the negative signal (say of amplitude -A) from the positive signal (say +A), we recover the original single-ended signal at twice its original amplitude. But any noise, like one coming from EMI from outside sources, is supposed to have an almost equal impact upon the positive (A + E, E being for "error") and negative signal (-A + E). So (A + E) - (-A + E) eliminates this noise, and this is what makes differential signaling useful. Except that in order to work, there must be strict requirements observed during PCB design and layout, like the signal traces needing to have the same length and be physically close to each other, and many others. Sometimes it is not easy to fulfill all these requirements, a simple case to understand is when on chip A's pins, the positive pin is on the left and the negative is on the right, but on the chip B's pins (with which A tries to communicate), positive is on the right and negative on the left. The signals would need to cross, using vias and other ugly stuff that affects signal integrity (introduces impedance discontinuities which cause reflections, etc). So sometimes, board designers intentionally connect differential lanes the wrong way, and expect somebody else to invert that signal to recover useful data. This is where RX and TX polarity inversion comes in as a generic concept that applies to any high-speed serial protocol as long as it uses differential signaling. I've stopped two attempts to introduce more vendor-specific descriptions of this only in the past month: https://lore.kernel.org/linux-phy/20251110110536.2596490-1-horatiu.vultur@microchip.com/ https://lore.kernel.org/netdev/20251028000959.3kiac5kwo5pcl4ft@skbuf/ and in the kernel we already have merged: - "st,px_rx_pol_inv" - "st,pcie-tx-pol-inv" - "st,sata-tx-pol-inv" - "mediatek,pnswap" - "airoha,pnswap-rx" - "airoha,pnswap-tx" and maybe more. So it is pretty general. One additional element of complexity is introduced by the fact that for some protocols, receivers can automatically detect and correct for an inverted lane polarity (example: the PCIe LTSSM does this in the Polling.Configuration state; the USB 3.1 Link Layer Test Specification says that the detection and correction of the lane polarity inversion in SuperSpeed operation shall be enabled in Polling.RxEQ.). Whereas for other protocols (SGMII, SATA, 10GBase-R, etc etc), the polarity is all manual and there is no detection mechanism mandated by their respective standards. So why would one even describe rx-polarity and tx-polarity for protocols like PCIe, if it had to always be PHY_POL_AUTO? Related question: why would we define the polarity as an array per protocol? Isn't the physical PCB layout protocol-agnostic, and aren't we describing the same physical reality from the lens of different protocols? The answer to both questions is because multi-protocol PHYs exist (supporting e.g. USB2 and USB3, or SATA and PCIe, or PCIe and Ethernet over the same lane), one would need to manually set the polarity for SATA/Ethernet, while leaving it at auto for PCIe/USB 3.0+. I also investigated from another angle: what if polarity inversion in the PHY is one layer, and then the PCIe/USB3 LTSSM polarity detection is another layer on top? Then rx-polarity = <PHY_POL_AUTO> doesn't make sense, it can still be rx-polarity = <PHY_POL_NORMAL> or <PHY_POL_INVERT>, and the link training state machine figures things out on top of that. This would radically simplify the design, as the elimination of PHY_POL_AUTO inherently means that the need for a property array per protocol also goes away. I don't know how things are in the general case, but at least in the 10G and 28G Lynx SerDes blocks from NXP Layerscape devices, this isn't the case, and there's only a single level of RX polarity inversion: in the SerDes lane. In the case of PCIe, the controller is in charge of driving the RDAT_INV bit autonomously, and it is read-only to software. So the existence of this kind of SerDes lane proves the need for PHY_POL_AUTO to be a third state. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260111093940.975359-5-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14dt-bindings: phy-common-props: ensure protocol-names are uniqueVladimir Oltean
Rob Herring points out that "The default for .*-names is the entries don't have to be unique.": https://lore.kernel.org/linux-phy/20251204155219.GA1533839-robh@kernel.org/ Let's use uniqueItems: true to make sure the schema enforces this. It doesn't make sense in this case to have duplicate properties for the same SerDes protocol. Note that this can only be done with the $defs + $ref pattern as established by the previous commit. When the tx-p2p-microvolt-names constraints were expressed directly under "properties", it would have been validated by the string-array meta-schema, which does not support the 'uniqueItems' keyword as can be seen below. properties:tx-p2p-microvolt-names: Additional properties are not allowed ('uniqueItems' was unexpected) from schema $id: http://devicetree.org/meta-schemas/string-array.yaml Suggested-by: Rob Herring <robh@kernel.org> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260111093940.975359-4-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14dt-bindings: phy-common-props: create a reusable "protocol-names" definitionVladimir Oltean
Other properties also need to be defined per protocol than just tx-p2p-microvolt-names. Create a common definition to avoid copying a 55 line property. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260111093940.975359-3-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14dt-bindings: phy: rename transmit-amplitude.yaml to phy-common-props.yamlVladimir Oltean
I would like to add more properties similar to tx-p2p-microvolt, and I don't think it makes sense to create one schema for each such property (transmit-amplitude.yaml, lane-polarity.yaml, transmit-equalization.yaml etc). Instead, let's rename to phy-common-props.yaml, which makes it a more adequate host schema for all the above properties. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20260111093940.975359-2-vladimir.oltean@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2026-01-14dm: clear cloned request bio pointer when last clone bio completesMichael Liang
Stale rq->bio values have been observed to cause double-initialization of cloned bios in request-based device-mapper targets, leading to use-after-free and double-free scenarios. One such case occurs when using dm-multipath on top of a PCIe NVMe namespace, where cloned request bios are freed during blk_complete_request(), but rq->bio is left intact. Subsequent clone teardown then attempts to free the same bios again via blk_rq_unprep_clone(). The resulting double-free path looks like: nvme_pci_complete_batch() nvme_complete_batch() blk_mq_end_request_batch() blk_complete_request() // called on a DM clone request bio_endio() // first free of all clone bios ... rq->end_io() // end_clone_request() dm_complete_request(tio->orig) dm_softirq_done() dm_done() dm_end_request() blk_rq_unprep_clone() // second free of clone bios Fix this by clearing the clone request's bio pointer when the last cloned bio completes, ensuring that later teardown paths do not attempt to free already-released bios. Signed-off-by: Michael Liang <mliang@purestorage.com> Reviewed-by: Mohamed Khalfella <mkhalfella@purestorage.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org
2026-01-14dm-verity: fix up various workqueue-related commentsEric Biggers
Replace obsolete mentions of "tasklets" with "softirq context", and "workqueue" with "kworker". This reflects the fact that the implementation of the "try_verify_in_tasklet" dm-verity option now accesses softirq context using either the BH workqueue API or inline execution, not the tasklet API. The old names conflated the API with the intended execution context, so they became outdated when the APIs changed. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-01-14dm-verity: switch to bio_advance_iter_single()Eric Biggers
dm-verity doesn't support data blocks that span pages, and it sets dma_alignment accordingly. As such, instead of using bio_advance_iter(), it can use the more lightweight function bio_advance_iter_single() to get the same result. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-01-14dm-verity: consolidate the BH and normal work structsEric Biggers
Since each dm_verity_io is never on both the BH and normal workqueues at the same time, there's no need for two different work_structs. Replace the 'bh_work' and 'work' fields with just 'work'. Note: this is correct even though it means 'work' may be reused while verity_bh_work() is running. The workqueue API allows work functions to reuse or free their work_struct, and many workqueue users rely on that. Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-01-14dm: add WQ_PERCPU to alloc_workqueue usersMarco Crivellari
This continues the effort to refactor workqueue APIs, which began with the introduction of new workqueues and a new alloc_workqueue flag in: commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq") commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag") The refactoring is going to alter the default behavior of alloc_workqueue() to be unbound by default. With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND), any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND must now use WQ_PERCPU. For more details see the Link tag below. In order to keep alloc_workqueue() behavior identical, explicitly request WQ_PERCPU. Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/ Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-01-14dm-integrity: fix a typo in the code for write/discard raceMikulas Patocka
If we send a write followed by a discard, it may be possible that the discarded data end up being overwritten by the previous write from the journal. The code tries to prevent that, but there was a typo in this logic that made it not being activated as it should be. Note that if we end up here the second time (when discard_retried is true), it means that the write bio is actually racing with the discard bio, and in this situation it is not specified which of them should win. Cc: stable@vger.kernel.org Fixes: 31843edab7cb ("dm integrity: improve discard in journal mode") Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
2026-01-14dm: use READ_ONCE in dm_blk_report_zonesMikulas Patocka
The functon dm_blk_report_zones reads md->zone_revalidate_map, however it may change while the function is running. Use READ_ONCE. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: 37f53a2c60d0 ("dm: fix dm_blk_report_zones") Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>
2026-01-14dm: fix unlocked test for dm_suspended_mdMikulas Patocka
The function dm_blk_report_zones tests if the device is suspended with the "dm_suspended_md" call. However, this function is called without holding any locks, so the device may be suspended just after it. Move the call to dm_suspended_md after dm_get_live_table, so that the device can't be suspended after the suspended state was tested. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: 37f53a2c60d0 ("dm: fix dm_blk_report_zones") Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>
2026-01-14arm64: dts: amlogic: s4: fix mmc clock assignmentJerome Brunet
MMC A and C are mis-represented as having their "clkin0" input connected to xtal while it is actually connected to the MMC clock, probably in an attempt to provide 24MHz to the device on this input. Fix this and assign the clock to 24MHz to actually provide the required rate. Fixes: 3ab9d54b5d84 ("arm64: dts: amlogic: enable some device nodes for S4") Tested-by: Nick Xie <nick@khadas.com> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260114-amlogic-s4-mmc-fixup-v3-2-a4d3e136b3f2@baylibre.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2026-01-14arm64: dts: amlogic: s4: assign mmc b clock to 24MHzJerome Brunet
The amlogic MMC driver operate with the assumption that MMC clock is configured to provide 24MHz. It uses this path for low rates such as 400kHz. This assumption did hold true until but it now, but it is apparently not the case with s4. The clock has been reported to provide 1GHz instead. This is most likely due to how the bootloader is using the MMC clock on this platform. Regardless of why the MMC clock rate is 1GHz, if the MMC driver expects 24MHz, the clock should be properly assigned, so assign it. Reported-by: Nick Xie <nick@khadas.com> Closes: https://lore.kernel.org/linux-amlogic/20260113011931.40424-1-nick@khadas.com/ Fixes: 3ab9d54b5d84 ("arm64: dts: amlogic: enable some device nodes for S4") Tested-by: Nick Xie <nick@khadas.com> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260114-amlogic-s4-mmc-fixup-v3-1-a4d3e136b3f2@baylibre.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2026-01-14arm64: dts: amlogic: drop useless assigned-clock-parentsJerome Brunet
Amlogic sound card assigned-clock-parents only have <0> and are useless. Remove them. Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260114-amlogic-parent-clock-cleanup-v1-1-31078b1e4a2c@baylibre.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
2026-01-14i2c: imx-lpi2c: change to PIO mode in system-wide suspend/resume progressCarlos Song
EDMA resumes early and suspends late in the system power transition sequence, while LPI2C enters the NOIRQ stage for both suspend and resume. This means LPI2C resources become available before EDMA is fully resumed. Once IRQs are enabled, a slave device may immediately trigger an LPI2C transfer. If the transfer length meets DMA requirements, the driver will attempt to use EDMA even though EDMA may still be unavailable. This timing gap can lead to transfer failures. To prevent this, force LPI2C to use PIO mode during system-wide suspend and resume transitions. This reduces dependency on EDMA and avoids using an unready DMA resource. Fixes: a09c8b3f9047 ("i2c: imx-lpi2c: add eDMA mode support for LPI2C") Signed-off-by: Carlos Song <carlos.song@nxp.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2026-01-14i2c: qcom-geni: make sure I2C hub controllers can't use SE DMANeil Armstrong
The I2C Hub controller is a simpler GENI I2C variant that doesn't support DMA at all, add a no_dma flag to make sure it nevers selects the SE DMA mode with mappable 32bytes long transfers. Fixes: cacd9643eca7 ("i2c: qcom-geni: add support for I2C Master Hub variant") Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Mukesh Kumar Savaliya <mukesh.savaliya@oss.qualcomm.com>> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
2026-01-14Merge tag 'counter-updates-for-6.20' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/wbg/counter into char-misc-next William writes: Counter updates for 6.20 Update MAINTAINERS file to reflect new Intel Quadrature Encoder Peripheral counter driver maintainer. * tag 'counter-updates-for-6.20' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/wbg/counter: MAINTAINERS: Update Intel Quadrature Encoder Peripheral maintainer
2026-01-14Merge tag 'iio-fixes-for-6.19a' of ↵Greg Kroah-Hartman
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio into char-misc-linus Jonathan writes: IIO: 1st set of fixes for the 6.19 cycle The usual mixed bag of fixes for ancient problems plus some more recent ones. adi,ad7280a - Check for errors from spi_setup(). adi,ad3552r - Fix potential buffer overflow when setting to use the internal ramp. adi,ax5695r - Fill in the data for this device in the chip info table. adi,ad7606 - Don't store a negative error in an unsigned int. adi,ad9467 - Fix incorrect register mask value. adi,adxl380 - Fix inverted condition for whether INT1 interrupt present in dt. atmel,at91-sama5d2 - Cancel work on remove to avoid a potential use-after-free invensense,icm45600 - Fix temperature scaling. samsung,eynos_adc - Use of_platform_depolulate() to correctly clear up such that child devices are created correctly if the driver is rebound. sensiron,scd4x - Fix incorrect endianness reported to user-space. st,accel - Fix gain reported for the iis329dq. st,lsm6dsx - Hide event related interfaces on parts that don't support events. ti,pac1934 - Ensure output of clamp() is used rather than unclamped value. * tag 'iio-fixes-for-6.19a' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/jic23/iio: iio: dac: ad3552r-hs: fix out-of-bound write in ad3552r_hs_write_data_source iio: accel: iis328dq: fix gain values iio: core: add separate lockdep class for info_exist_lock iio: chemical: scd4x: fix reported channel endianness iio: imu: inv_icm45600: fix temperature offset reporting iio: adc: exynos_adc: fix OF populate on driver rebind iio: dac: ad5686: add AD5695R to ad5686_chip_info_tbl iio: accel: adxl380: fix handling of unavailable "INT1" interrupt iio: imu: st_lsm6dsx: fix iio_chan_spec for sensors without event detection iio: adc: pac1934: Fix clamped value in pac1934_reg_snapshot iio: adc: ad9467: fix ad9434 vref mask iio: adc: ad7606: Fix incorrect type for error return variable iio: adc: ad7280a: handle spi_setup() errors in probe() iio: adc: at91-sama5d2_adc: Fix potential use-after-free in sama5d2_adc driver
2026-01-14KVM: arm64: Fix missing <asm/stackpage/nvhe.h> includeBen Dooks
Include <asm/stackpage/nvhe.h> for kvm_arm_hyp_stack_base declaration which fixes the following sparse warning: arch/arm64/kvm/arm.c:63:1: warning: symbol 'kvm_arm_hyp_stack_base' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Link: https://patch.msgid.link/20260112160413.603493-1-ben.dooks@codethink.co.uk Signed-off-by: Marc Zyngier <maz@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-10-02 17:45:02 +0000