* [PATCH 1/2] ASoC: codecs: max98090: use component set_jack callback
From: Srinivas Kandagatla @ 2026-05-20 13:29 UTC (permalink / raw)
To: broonie
Cc: lgirdwood, perex, tiwai, matthias.bgg, angelogioacchino.delregno,
sharq0406, kuninori.morimoto.gx, ckeepax, srinivas.kandagatla,
linux-sound, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260520132930.54333-1-srinivas.kandagatla@oss.qualcomm.com>
The MAX98090 driver provides a custom max98090_mic_detect() helper for
machine drivers to register a jack.
This can be implemented using the standard component set_jack callback
instead. Doing so allows machine drivers to use
snd_soc_component_set_jack(), which is also the interface used by
machine drivers including Qualcomm ones.
Convert max98090_mic_detect() to a component set_jack callback and remove
the exported helper.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
---
sound/soc/codecs/max98090.c | 10 +++++-----
sound/soc/codecs/max98090.h | 3 ---
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c
index 13a15459040f..bd3bfa1d3402 100644
--- a/sound/soc/codecs/max98090.c
+++ b/sound/soc/codecs/max98090.c
@@ -2337,7 +2337,7 @@ static irqreturn_t max98090_interrupt(int irq, void *data)
}
/**
- * max98090_mic_detect - Enable microphone detection via the MAX98090 IRQ
+ * max98090_set_jack - Enable microphone detection via the MAX98090 IRQ
*
* @component: MAX98090 component
* @jack: jack to report detection events on
@@ -2349,12 +2349,12 @@ static irqreturn_t max98090_interrupt(int irq, void *data)
*
* If no jack is supplied detection will be disabled.
*/
-int max98090_mic_detect(struct snd_soc_component *component,
- struct snd_soc_jack *jack)
+static int max98090_set_jack(struct snd_soc_component *component,
+ struct snd_soc_jack *jack, void *data)
{
struct max98090_priv *max98090 = snd_soc_component_get_drvdata(component);
- dev_dbg(component->dev, "max98090_mic_detect\n");
+ dev_dbg(component->dev, "%s\n", __func__);
max98090->jack = jack;
if (jack) {
@@ -2377,7 +2377,6 @@ int max98090_mic_detect(struct snd_soc_component *component,
return 0;
}
-EXPORT_SYMBOL_GPL(max98090_mic_detect);
#define MAX98090_RATES SNDRV_PCM_RATE_8000_96000
#define MAX98090_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S24_LE)
@@ -2554,6 +2553,7 @@ static const struct snd_soc_component_driver soc_component_dev_max98090 = {
.remove = max98090_remove,
.seq_notifier = max98090_seq_notifier,
.set_bias_level = max98090_set_bias_level,
+ .set_jack = max98090_set_jack,
.idle_bias_on = 1,
.use_pmdown_time = 1,
.endianness = 1,
diff --git a/sound/soc/codecs/max98090.h b/sound/soc/codecs/max98090.h
index 6ce8dd176e48..048af4a1376f 100644
--- a/sound/soc/codecs/max98090.h
+++ b/sound/soc/codecs/max98090.h
@@ -1543,7 +1543,4 @@ struct max98090_priv {
bool shdn_pending;
};
-int max98090_mic_detect(struct snd_soc_component *component,
- struct snd_soc_jack *jack);
-
#endif
--
2.47.3
^ permalink raw reply related
* [PATCH 0/2] ASoC: codecs: max98090: switch to standard set_jack callback
From: Srinivas Kandagatla @ 2026-05-20 13:29 UTC (permalink / raw)
To: broonie
Cc: lgirdwood, perex, tiwai, matthias.bgg, angelogioacchino.delregno,
sharq0406, kuninori.morimoto.gx, ckeepax, srinivas.kandagatla,
linux-sound, linux-kernel, linux-arm-kernel, linux-mediatek
The MAX98090 codec driver currently exposes a custom
max98090_mic_detect() helper for machine drivers to register a headset
jack.
This series converts the driver to use the standard component
.set_jack callback and updates the mt8173-max98090 machine driver to use
snd_soc_component_set_jack() instead of the codec-specific helper.
Using the standard callback removes the need for a custom exported
symbol and allows machine drivers to use the common ASoC jack
registration interface. This also improves compatibility with machine
drivers, such as Qualcomm platforms, that already rely on
snd_soc_component_set_jack().
Srinivas Kandagatla (2):
ASoC: codecs: max98090: use component set_jack callback
ASoC: mt8173-max98090: use standard callback to set jack
sound/soc/codecs/max98090.c | 10 +++++-----
sound/soc/codecs/max98090.h | 3 ---
sound/soc/mediatek/mt8173/mt8173-max98090.c | 3 +--
3 files changed, 6 insertions(+), 10 deletions(-)
--
2.47.3
^ permalink raw reply
* Re: [PATCH] fbdev: Consistently define pci_device_ids using named initializers
From: Uwe Kleine-König (The Capable Hub) @ 2026-05-20 13:28 UTC (permalink / raw)
To: Helge Deller
Cc: Benjamin Herrenschmidt, Russell King, Andres Salomon,
Antonino Daplas, linux-fbdev, dri-devel, linux-kernel,
linux-arm-kernel, linux-geode, Markus Schneider-Pargmann
In-Reply-To: <6f1e1da5-a086-4261-aacb-f1117e22146b@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 803 bytes --]
On Wed, May 20, 2026 at 12:11:16PM +0200, Helge Deller wrote:
> On 5/20/26 10:46, Uwe Kleine-König (The Capable Hub) wrote:
> > Would you mind squashing that into the patch you already applied, maybe
> > adding:
> >
> > While touching all these arrays, unify usage of whitespace and
> > comma in a few drivers.
> >
> > to the commit log? I can also send a v2 of the patch with these changes
> > included if that's easier for you.
> >
> > Otherwise I will put sending these modifications separately on my todo
> > list.
>
> No need to resend anything. I'll clean it up manually during the next few hours....
Looking at commit bca0e1973086919ae2dcd7b72e4ef5ee48858df5 in your
branch, the result looks fine. Thanks for cleaning up after me, very
appreciated.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 03/18] KVM: arm64: vgic-v5: Remove use of __assign_bit() with a constant
From: Joey Gouly @ 2026-05-20 13:26 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, linux-arm-kernel, Steffen Eiden, Suzuki K Poulose,
Oliver Upton, Zenghui Yu, Sascha Bischoff
In-Reply-To: <20260520091949.542365-4-maz@kernel.org>
On Wed, May 20, 2026 at 10:19:34AM +0100, Marc Zyngier wrote:
> Using __assign_bit() is very useful when the value of the bit is
> not known at compile time. In all other cases, __set_bit() and
> __clear_bit() are the correct tool for the job.
>
> This also fixes an odd case of using VGIC_V5_NR_PRIVATE_IRQS as
> the bit value...
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
> ---
> arch/arm64/kvm/vgic/vgic-v5.c | 16 +++++++---------
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c
> index 7c146fccc9689..4d62b1c31fe8b 100644
> --- a/arch/arm64/kvm/vgic/vgic-v5.c
> +++ b/arch/arm64/kvm/vgic/vgic-v5.c
> @@ -25,13 +25,13 @@ static void vgic_v5_get_implemented_ppis(void)
> * If we have KVM, we have EL2, which means that we have support for the
> * EL1 and EL2 Physical & Virtual timers.
> */
> - __assign_bit(GICV5_ARCH_PPI_CNTHP, ppi_caps.impl_ppi_mask, 1);
> - __assign_bit(GICV5_ARCH_PPI_CNTV, ppi_caps.impl_ppi_mask, 1);
> - __assign_bit(GICV5_ARCH_PPI_CNTHV, ppi_caps.impl_ppi_mask, 1);
> - __assign_bit(GICV5_ARCH_PPI_CNTP, ppi_caps.impl_ppi_mask, 1);
> + __set_bit(GICV5_ARCH_PPI_CNTHP, ppi_caps.impl_ppi_mask);
> + __set_bit(GICV5_ARCH_PPI_CNTV, ppi_caps.impl_ppi_mask);
> + __set_bit(GICV5_ARCH_PPI_CNTHV, ppi_caps.impl_ppi_mask);
> + __set_bit(GICV5_ARCH_PPI_CNTP, ppi_caps.impl_ppi_mask);
>
> /* The SW_PPI should be available */
> - __assign_bit(GICV5_ARCH_PPI_SW_PPI, ppi_caps.impl_ppi_mask, 1);
> + __set_bit(GICV5_ARCH_PPI_SW_PPI, ppi_caps.impl_ppi_mask);
>
> /* The PMUIRQ is available if we have the PMU */
> __assign_bit(GICV5_ARCH_PPI_PMUIRQ, ppi_caps.impl_ppi_mask, system_supports_pmuv3());
> @@ -146,9 +146,7 @@ int vgic_v5_init(struct kvm *kvm)
> /* We only allow userspace to drive the SW_PPI, if it is implemented. */
> bitmap_zero(kvm->arch.vgic.gicv5_vm.userspace_ppis,
> VGIC_V5_NR_PRIVATE_IRQS);
> - __assign_bit(GICV5_ARCH_PPI_SW_PPI,
> - kvm->arch.vgic.gicv5_vm.userspace_ppis,
> - VGIC_V5_NR_PRIVATE_IRQS);
> + __set_bit(GICV5_ARCH_PPI_SW_PPI, kvm->arch.vgic.gicv5_vm.userspace_ppis);
> bitmap_and(kvm->arch.vgic.gicv5_vm.userspace_ppis,
> kvm->arch.vgic.gicv5_vm.userspace_ppis,
> ppi_caps.impl_ppi_mask, VGIC_V5_NR_PRIVATE_IRQS);
> @@ -197,7 +195,7 @@ int vgic_v5_finalize_ppi_state(struct kvm *kvm)
> /* Expose PPIs with an owner or the SW_PPI, only */
> scoped_guard(raw_spinlock_irqsave, &irq->irq_lock) {
> if (irq->owner || i == GICV5_ARCH_PPI_SW_PPI) {
> - __assign_bit(i, kvm->arch.vgic.gicv5_vm.vgic_ppi_mask, 1);
> + __set_bit(i, kvm->arch.vgic.gicv5_vm.vgic_ppi_mask);
> __assign_bit(i, kvm->arch.vgic.gicv5_vm.vgic_ppi_hmr,
> irq->config == VGIC_CONFIG_LEVEL);
> }
> --
> 2.47.3
>
^ permalink raw reply
* [PATCH net] net: airoha: Disable GDM2 forwarding before configuring GDM2 loopback
From: Lorenzo Bianconi @ 2026-05-20 13:12 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev, Madhur Agrawal,
Lorenzo Bianconi
Hw design requires to disable GDM2 forwarding before configuring GDM2
loopback in airoha_set_gdm2_loopback routine.
Fixes: 9cd451d414f6e ("net: airoha: Add loopback support for GDM2")
Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index d0c0c0ec8a80..cecd66251dba 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1793,11 +1793,8 @@ static int airoha_set_gdm2_loopback(struct airoha_gdm_port *port)
u32 val, pse_port, chan;
int i, src_port;
- /* Forward the traffic to the proper GDM port */
- pse_port = port->id == AIROHA_GDM3_IDX ? FE_PSE_PORT_GDM3
- : FE_PSE_PORT_GDM4;
airoha_set_gdm_port_fwd_cfg(eth, REG_GDM_FWD_CFG(AIROHA_GDM2_IDX),
- pse_port);
+ FE_PSE_PORT_DROP);
airoha_fe_clear(eth, REG_GDM_FWD_CFG(AIROHA_GDM2_IDX),
GDM_STRIP_CRC_MASK);
@@ -1815,6 +1812,11 @@ static int airoha_set_gdm2_loopback(struct airoha_gdm_port *port)
GDM_SHORT_LEN_MASK | GDM_LONG_LEN_MASK,
FIELD_PREP(GDM_SHORT_LEN_MASK, 60) |
FIELD_PREP(GDM_LONG_LEN_MASK, AIROHA_MAX_MTU));
+ /* Forward the traffic to the proper GDM port */
+ pse_port = port->id == AIROHA_GDM3_IDX ? FE_PSE_PORT_GDM3
+ : FE_PSE_PORT_GDM4;
+ airoha_set_gdm_port_fwd_cfg(eth, REG_GDM_FWD_CFG(AIROHA_GDM2_IDX),
+ pse_port);
/* Disable VIP and IFC for GDM2 */
airoha_fe_clear(eth, REG_FE_VIP_PORT_EN, BIT(AIROHA_GDM2_IDX));
---
base-commit: dc416e32baaeb620b9809e9e25fc7b30889686e9
change-id: 20260520-airoha-disable-gdm2-fwd-cdf18f7d4f1f
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH] ASoC: mediatek: mt2701: fix snprintf bounds
From: David Laight @ 2026-05-20 13:12 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-sound, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Matthias Brugger, AngeloGioacchino Del Regno,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
In-Reply-To: <20260519010440.629290-1-rosenp@gmail.com>
On Mon, 18 May 2026 18:04:40 -0700
Rosen Penev <rosenp@gmail.com> wrote:
> For whatever reason, GCC is unable to figure out that i2s_num is a
> single digit number, with MT2701_BASE_CLK_NUM being the maximum value it
> represents. Add a min() call to help it out and fix W=1 errors regarding
> snprintf bounds.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c b/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
> index 5a2bcf027b4f..43157f218409 100644
> --- a/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
> +++ b/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
> @@ -25,6 +25,7 @@ static const char *const base_clks[] = {
> int mt2701_init_clock(struct mtk_base_afe *afe)
> {
> struct mt2701_afe_private *afe_priv = afe->platform_priv;
> + int i2s_num;
> int i;
>
> for (i = 0; i < MT2701_BASE_CLK_NUM; i++) {
> @@ -35,8 +36,9 @@ int mt2701_init_clock(struct mtk_base_afe *afe)
> }
> }
>
> + i2s_num = min(MT2701_BASE_CLK_NUM, afe_priv->soc->i2s_num);
To me that is backwards, like an 'if' put the variable before the limit.
> /* Get I2S related clocks */
> - for (i = 0; i < afe_priv->soc->i2s_num; i++) {
> + for (i = 0; i < i2s_num; i++) {
Caching the limit also stops the compiler having to read it every iteration.
-- David
> struct mt2701_i2s_path *i2s_path = &afe_priv->i2s_path[i];
> struct clk *i2s_ck;
> char name[13];
^ permalink raw reply
* Re: [PATCH v4 2/3] PCI: Allow ATS to be always on for pre-CXL devices
From: Yi Liu @ 2026-05-20 13:12 UTC (permalink / raw)
To: Nicolin Chen, jgg, will, robin.murphy, bhelgaas
Cc: joro, praan, baolu.lu, kevin.tian, miko.lenczewski,
linux-arm-kernel, iommu, linux-kernel, linux-pci, dan.j.williams,
jonathan.cameron, vsethi, linux-cxl, nirmoyd
In-Reply-To: <1a8cf5e88051ab5c10417edb94df598ecbc810cf.1777269009.git.nicolinc@nvidia.com>
On 4/27/26 13:54, Nicolin Chen wrote:
> Some NVIDIA GPU/NIC devices, though they don't implement CXL config space,
> have many CXL-like properties. Call this kind "pre-CXL".
>
> Similar to CXL.cache capability, these pre-CXL devices also require the ATS
> function even when their RIDs are IOMMU bypassed, i.e. keep ATS "always on"
> v.s. "on demand" when a non-zero PASID line gets enabled in SVA use cases.
>
> Introduce pci_dev_specific_ats_always_on() quirk function to scan a list of
> IDs for these devices. Then, include it in pci_ats_always_on().
>
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Reviewed-by: Nirmoy Das <nirmoyd@nvidia.com>
> Tested-by: Nirmoy Das <nirmoyd@nvidia.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/pci/pci.h | 9 +++++++++
> drivers/pci/ats.c | 3 ++-
> drivers/pci/quirks.c | 38 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 49 insertions(+), 1 deletion(-)
Reviewed-by: Yi Liu <yi.l.liu@intel.com>
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index 4a14f88e543a2..4e0077478cd7a 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -1155,6 +1155,15 @@ static inline int pci_dev_specific_reset(struct pci_dev *dev, bool probe)
> }
> #endif
>
> +#if defined(CONFIG_PCI_QUIRKS) && defined(CONFIG_PCI_ATS)
> +bool pci_dev_specific_ats_always_on(struct pci_dev *dev);
> +#else
> +static inline bool pci_dev_specific_ats_always_on(struct pci_dev *dev)
> +{
> + return false;
> +}
> +#endif
> +
> #if defined(CONFIG_PCI_QUIRKS) && defined(CONFIG_ARM64)
> int acpi_get_rc_resources(struct device *dev, const char *hid, u16 segment,
> struct resource *res);
> diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
> index fc871858b65bc..3846447ea322f 100644
> --- a/drivers/pci/ats.c
> +++ b/drivers/pci/ats.c
> @@ -244,7 +244,8 @@ bool pci_ats_always_on(struct pci_dev *pdev)
> if (pdev->is_virtfn)
> pdev = pci_physfn(pdev);
>
> - return pci_cxl_ats_always_on(pdev);
> + return pci_cxl_ats_always_on(pdev) ||
> + pci_dev_specific_ats_always_on(pdev);
> }
> EXPORT_SYMBOL_GPL(pci_ats_always_on);
>
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index caaed1a01dc02..887babba97cc7 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -5715,6 +5715,44 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1457, quirk_intel_e2000_no_ats);
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x1459, quirk_intel_e2000_no_ats);
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x145a, quirk_intel_e2000_no_ats);
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x145c, quirk_intel_e2000_no_ats);
> +
> +static bool quirk_nvidia_gpu_ats_always_on(struct pci_dev *pdev)
> +{
> + switch (pdev->device) {
> + case 0x2e00 ... 0x2e3f: /* GB20B */
> + return true;
> + }
> + return false;
> +}
> +
> +static const struct pci_dev_ats_always_on {
> + u16 vendor;
> + u16 device;
> + bool (*ats_always_on)(struct pci_dev *dev);
> +} pci_dev_ats_always_on[] = {
> + /* NVIDIA GPUs */
> + { PCI_VENDOR_ID_NVIDIA, PCI_ANY_ID, quirk_nvidia_gpu_ats_always_on },
> + /* NVIDIA CX10 Family NVlink-C2C */
> + { PCI_VENDOR_ID_MELLANOX, 0x2101, NULL },
> + { 0 }
> +};
> +
> +/* Some pre-CXL devices require ATS when it is IOMMU-bypassed */
> +bool pci_dev_specific_ats_always_on(struct pci_dev *pdev)
> +{
> + const struct pci_dev_ats_always_on *i;
> +
> + for (i = pci_dev_ats_always_on; i->vendor; i++) {
> + if (i->vendor != pdev->vendor)
> + continue;
> + if (i->ats_always_on && i->ats_always_on(pdev))
> + return true;
> + if (!i->ats_always_on && i->device == pdev->device)
> + return true;
> + }
> +
> + return false;
> +}
> #endif /* CONFIG_PCI_ATS */
>
> /* Freescale PCIe doesn't support MSI in RC mode */
^ permalink raw reply
* Re: [PATCH v4 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
From: Yi Liu @ 2026-05-20 13:12 UTC (permalink / raw)
To: Nicolin Chen, jgg, will, robin.murphy, bhelgaas
Cc: joro, praan, baolu.lu, kevin.tian, miko.lenczewski,
linux-arm-kernel, iommu, linux-kernel, linux-pci, dan.j.williams,
jonathan.cameron, vsethi, linux-cxl, nirmoyd
In-Reply-To: <f6734b9dad0050138676f11ecd14e9db1cf6b697.1777269009.git.nicolinc@nvidia.com>
On 4/27/26 13:54, Nicolin Chen wrote:
> Controlled by the IOMMU driver, ATS is usually enabled "on demand" when a
> given PASID on a device is attached to an I/O page table. This is working
> even when a device has no translation on its RID (i.e., the RID is IOMMU
> bypassed).
nit: this description seems not accurate. Intel iommu driver enables ATS
in the probe_device() phase. mind tweak a bit to avoid misleading
message. :)
> However, certain PCIe devices require non-PASID ATS on their RID even when
> the RID is IOMMU bypassed. Call this "always on".
>
> For example, CXL spec r4.0 notes in sec 3.2.5.13 Memory Type on CXL.cache:
> "To source requests on CXL.cache, devices need to get the Host Physical
> Address (HPA) from the Host by means of an ATS request on CXL.io."
>
> In other words, the CXL.cache capability requires ATS; otherwise, it can't
> access host physical memory.
>
> Introduce a new pci_ats_always_on() helper for the IOMMU driver to scan a
> PCI device and shift ATS policies between "on demand" and "always on".
>
> Add the support for CXL.cache devices first. Pre-CXL devices will be added
> in quirks.c file.
>
> Note that pci_ats_always_on() validates against pci_ats_supported(), so we
> ensure that untrusted devices (e.g. external ports) will not be always on.
> This maintains the existing ATS security policy regarding potential side-
> channel attacks via ATS.
>
Reviewed-by: Yi Liu <yi.l.liu@intel.com>
> Cc: linux-cxl@vger.kernel.org
> Suggested-by: Vikram Sethi <vsethi@nvidia.com>
> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> Reviewed-by: Kevin Tian <kevin.tian@intel.com>
> Tested-by: Nirmoy Das <nirmoyd@nvidia.com>
> Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> include/linux/pci-ats.h | 3 +++
> include/uapi/linux/pci_regs.h | 1 +
> drivers/pci/ats.c | 43 +++++++++++++++++++++++++++++++++++
> 3 files changed, 47 insertions(+)
>
> diff --git a/include/linux/pci-ats.h b/include/linux/pci-ats.h
> index 75c6c86cf09dc..d14ba727d38b3 100644
> --- a/include/linux/pci-ats.h
> +++ b/include/linux/pci-ats.h
> @@ -12,6 +12,7 @@ int pci_prepare_ats(struct pci_dev *dev, int ps);
> void pci_disable_ats(struct pci_dev *dev);
> int pci_ats_queue_depth(struct pci_dev *dev);
> int pci_ats_page_aligned(struct pci_dev *dev);
> +bool pci_ats_always_on(struct pci_dev *dev);
> #else /* CONFIG_PCI_ATS */
> static inline bool pci_ats_supported(struct pci_dev *d)
> { return false; }
> @@ -24,6 +25,8 @@ static inline int pci_ats_queue_depth(struct pci_dev *d)
> { return -ENODEV; }
> static inline int pci_ats_page_aligned(struct pci_dev *dev)
> { return 0; }
> +static inline bool pci_ats_always_on(struct pci_dev *dev)
> +{ return false; }
> #endif /* CONFIG_PCI_ATS */
>
> #ifdef CONFIG_PCI_PRI
> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> index 14f634ab9350d..6ac45be1008b8 100644
> --- a/include/uapi/linux/pci_regs.h
> +++ b/include/uapi/linux/pci_regs.h
> @@ -1349,6 +1349,7 @@
> /* CXL r4.0, 8.1.3: PCIe DVSEC for CXL Device */
> #define PCI_DVSEC_CXL_DEVICE 0
> #define PCI_DVSEC_CXL_CAP 0xA
> +#define PCI_DVSEC_CXL_CACHE_CAPABLE _BITUL(0)
> #define PCI_DVSEC_CXL_MEM_CAPABLE _BITUL(2)
> #define PCI_DVSEC_CXL_HDM_COUNT __GENMASK(5, 4)
> #define PCI_DVSEC_CXL_CTRL 0xC
> diff --git a/drivers/pci/ats.c b/drivers/pci/ats.c
> index ec6c8dbdc5e9c..fc871858b65bc 100644
> --- a/drivers/pci/ats.c
> +++ b/drivers/pci/ats.c
> @@ -205,6 +205,49 @@ int pci_ats_page_aligned(struct pci_dev *pdev)
> return 0;
> }
>
> +/*
> + * CXL r4.0, sec 3.2.5.13 Memory Type on CXL.cache notes: to source requests on
> + * CXL.cache, devices need to get the Host Physical Address (HPA) from the Host
> + * by means of an ATS request on CXL.io.
> + *
> + * In other words, CXL.cache devices cannot access host physical memory without
> + * ATS.
> + */
> +static bool pci_cxl_ats_always_on(struct pci_dev *pdev)
> +{
> + int offset;
> + u16 cap;
> +
> + offset = pci_find_dvsec_capability(pdev, PCI_VENDOR_ID_CXL,
> + PCI_DVSEC_CXL_DEVICE);
> + if (!offset)
> + return false;
> +
> + if (pci_read_config_word(pdev, offset + PCI_DVSEC_CXL_CAP, &cap))
> + return false;
> +
> + return cap & PCI_DVSEC_CXL_CACHE_CAPABLE;
> +}
> +
> +/**
> + * pci_ats_always_on - Whether the PCI device requires ATS to be always enabled
> + * @pdev: the PCI device
> + *
> + * Returns true, if the PCI device requires ATS for basic functional operation.
> + */
> +bool pci_ats_always_on(struct pci_dev *pdev)
> +{
> + if (pci_ats_disabled() || !pci_ats_supported(pdev))
> + return false;
> +
> + /* A VF inherits its PF's requirement for ATS function */
> + if (pdev->is_virtfn)
> + pdev = pci_physfn(pdev);
> +
> + return pci_cxl_ats_always_on(pdev);
> +}
> +EXPORT_SYMBOL_GPL(pci_ats_always_on);
> +
> #ifdef CONFIG_PCI_PRI
> void pci_pri_init(struct pci_dev *pdev)
> {
^ permalink raw reply
* Re: [PATCH v2 2/2] KVM: arm64: nv: Don't save/restore FP register during a nested ERET or exception
From: Mark Rutland @ 2026-05-20 13:02 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, linux-arm-kernel, kvm, Steffen Eiden, Joey Gouly,
Suzuki K Poulose, Oliver Upton, Zenghui Yu, Will Deacon,
Fuad Tabba
In-Reply-To: <20260520085036.541666-3-maz@kernel.org>
On Wed, May 20, 2026 at 09:50:36AM +0100, Marc Zyngier wrote:
> When switching between L1 and L2, we save the old state using
> kvm_arch_vcpu_put(), mutate the state in memory, then load the new
> state using kvm_arch_vcpu_load(). Any live FPSIMD/SVE state is saved
> and unbound, such that it can be lazily restored on a subsequent trap.
>
> The FPSIMD/SVE state is shared by exception levels, and only a handful
> of related control registers need to be changed when transitioning
> between L1 and L2. The save/restore of the common state is needless
> overhead, especially as trapping becomes exponentially more expensive
> with nesting.
>
> Avoid this overhead by leaving the common FPSIMD/SVE state live on the
> CPU, and only switching the state that is distinct for L1 and L2:
>
> - the trap controls: the effective values are recomputed on each entry
> into the guest to take the EL into account and merge the L0 and L1
> configuration if in a nested context, or directly use the L0 configuration
> in non-nested context (see __activate_traps()).
>
> - the VL settings: the effective values are are also recomputed on each
> entry into the guest (see fpsimd_lazy_switch_to_guest()).
>
> Since we appear to cover all bases, use the vcpu flags indicating the
> handling of a nested ERET or exception delivery to avoid the whole FP
> save/restore shenanigans. SME will have to be similarly dealt with when
> it eventually gets supported.
>
> For an EL1 L3 guest where L1 and L2 have this optimisation, this
> results in at least a 10% wall clock reduction when running an I/O
> heavy workload, generating a high rate of nested exceptions.
There's on additional thing that's important, but I forgot to mention
last time: in the window between kvm_arch_vcpu_put() and
kvm_arch_vcpu_load(), it's possible to take an interrupt, and for a
softirq handler to try to use kernel mode NEON.
Due to that, kvm_arch_vcpu_put() must leave the L1 guest's maximum VL
configured in the host's ZCR_ELx, such that the guest's state can be
saved.
That value is configured by fpsimd_lazy_switch_to_host(), so we just
need to make sure that kvm_arch_vcpu_put() doesn't clobber it. I *think*
that's fine today, but maybe that warrants a comment somewhere.
Other than that, this all looks good to me:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm64/kvm/fpsimd.c | 23 +++++++++++++++++++++++
> 1 file changed, 23 insertions(+)
>
> diff --git a/arch/arm64/kvm/fpsimd.c b/arch/arm64/kvm/fpsimd.c
> index 15e17aca1dec0..aca98752a6e42 100644
> --- a/arch/arm64/kvm/fpsimd.c
> +++ b/arch/arm64/kvm/fpsimd.c
> @@ -28,6 +28,20 @@ void kvm_arch_vcpu_load_fp(struct kvm_vcpu *vcpu)
> if (!system_supports_fpsimd())
> return;
>
> + /*
> + * Avoid needless save/restore of the guest's common
> + * FPSIMD/SVE/SME regs during transitions between L1/L2.
> + *
> + * These transitions only happens in a non-preemptible context
> + * where the host regs have already been saved and unbound. The
> + * live registers are either free or owned by the guest.
> + */
> + if (vcpu_get_flag(vcpu, IN_NESTED_ERET) ||
> + vcpu_get_flag(vcpu, IN_NESTED_EXCEPTION)) {
> + WARN_ON_ONCE(host_owns_fp_regs());
> + return;
> + }
> +
> /*
> * Ensure that any host FPSIMD/SVE/SME state is saved and unbound such
> * that the host kernel is responsible for restoring this state upon
> @@ -102,6 +116,15 @@ void kvm_arch_vcpu_put_fp(struct kvm_vcpu *vcpu)
> {
> unsigned long flags;
>
> + /*
> + * See comment in kvm_arch_vcpu_load_fp().
> + */
> + if (vcpu_get_flag(vcpu, IN_NESTED_ERET) ||
> + vcpu_get_flag(vcpu, IN_NESTED_EXCEPTION)) {
> + WARN_ON_ONCE(host_owns_fp_regs());
> + return;
> + }
> +
> local_irq_save(flags);
>
> if (guest_owns_fp_regs()) {
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Lorenzo Stoakes @ 2026-05-20 12:55 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Suren Baghdasaryan, Barry Song, Matthew Wilcox, akpm, linux-mm,
liam, vbabka, rppt, mhocko, jack, pfalcato, wanglian, chentao,
lianux.mm, kunwu.chan, liyangouwen1, chrisl, kasong, shikemeng,
nphamcs, bhe, youngjun.park, linux-arm-kernel, linux-kernel,
loongarch, linuxppc-dev, linux-riscv, linux-s390, Nanzhe Zhao
In-Reply-To: <e6d1017a-e4c5-493e-bfca-932c6d64eaac@kernel.org>
On Wed, May 20, 2026 at 12:33:56PM +0200, David Hildenbrand (Arm) wrote:
> On 5/19/26 14:53, Lorenzo Stoakes wrote:
> > On Mon, May 18, 2026 at 12:56:59PM -0700, Suren Baghdasaryan wrote:
> >
> >>>
> >>> I think we either need to fix `fork()`, or keep the current
> >>> behavior of dropping the VMA lock before performing I/O.
> >>
> >> I see. So, this problem arises from the fact that we are changing the
> >> pagefaults requiring I/O operation to hold VMA lock...
> >> And you want to lock VMA on fork only if vma_is_anonymous(vma) ||
> >> is_cow_mapping(vma->vm_flags). So, we will be blocking page faults for
> >> anonymous and COW VMAs only while holding mmap_write_lock, preventing
> >> any VMA modification. On the surface, that looks ok to me but I might
> >> be missing some corner cases. If nobody sees any obvious issues, I
> >> think it's worth a try.
> >
> > Not sure if you noticed but I did raise concerns ;)
> >
> > I wonder if you've confused the fault path and fork here, as I think Barry has
> > been a little unclear on that.
> >
> > What's being suggested in this thread is to fundamentally change fork behaviour
> > so it's different from the entire history of the kernel (or - presumably - at
> > least recent history :)
> I don't want fork() to become different in that regard.
>
> There is already a slight difference with vs. without per-VMA locks, because
> there is a window in-between us taking the write mmap_lock and all the per-VMA
> locks. I raised that previously [1] and assumed that it is probably fine.
>
> I also raised in the past why I think we must not allow concurrent page faults,
> at least as soon as anonymous memory is involved [2].
>
> ... and I raised that this is pretty much slower by design right now: "Well, the
> design decision that CONFIG_PER_VMA_LOCK made for now to make page faults fast
> and to make blocking any page faults from happening to be slower ..." [3]
Thanks for the background will read through! :)
But yeah I think the transition from !vma->anon_vma -> vma->anon_vma being a bit
slow is kinda ok most page faults will of course have anon_vma populated.
Be interesting with CoW context, because we won't need to mmap read lock there
at all :)
>
> [1] https://lore.kernel.org/all/970295ab-e85d-7af3-76e6-df53a5c52f8b@redhat.com/
> [2] https://lore.kernel.org/all/7e3f35cc-59b9-bf12-b8b1-4ed78223844a@redhat.com/
> [3] https://lore.kernel.org/all/2efa2c89-3765-721d-2c3c-00590054aa5b@redhat.com/
>
> --
> Cheers,
>
> David
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmtk: remove extra copy in cmd array init
From: Luiz Augusto von Dentz @ 2026-05-20 12:55 UTC (permalink / raw)
To: Jiajia Liu
Cc: Marcel Holtmann, Matthias Brugger, AngeloGioacchino Del Regno,
linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260520021500.13504-1-liujiajia@kylinos.cn>
Hi Jiajia,
On Tue, May 19, 2026 at 10:15 PM Jiajia Liu <liujiajia@kylinos.cn> wrote:
>
> In btmtk_setup_firmware_79xx, the data length indicated by wmt_params.dlen
> in the cmd buffer is MTK_SEC_MAP_NEED_SEND_SIZE + 1. Except for the first
> byte, the remaining length is MTK_SEC_MAP_NEED_SEND_SIZE. memcpy copied one
> more byte to cmd + 1 than the remaining length. Align the length passed to
> memcpy to avoid exceeding current section map.
>
> Signed-off-by: Jiajia Liu <liujiajia@kylinos.cn>
> ---
> drivers/bluetooth/btmtk.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
> index ea7a031000cd..53cba71cb07f 100644
> --- a/drivers/bluetooth/btmtk.c
> +++ b/drivers/bluetooth/btmtk.c
> @@ -188,7 +188,7 @@ int btmtk_setup_firmware_79xx(struct hci_dev *hdev, const char *fwname,
> MTK_FW_ROM_PATCH_GD_SIZE +
> MTK_FW_ROM_PATCH_SEC_MAP_SIZE * i +
> MTK_SEC_MAP_COMMON_SIZE,
> - MTK_SEC_MAP_NEED_SEND_SIZE + 1);
> + MTK_SEC_MAP_NEED_SEND_SIZE);
>
> wmt_params.op = BTMTK_WMT_PATCH_DWNLD;
> wmt_params.status = &status;
> --
> 2.53.0
>
Have you tested this on the actual hardware? If not we need a Tested-by.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH net-next v3 5/6] net: phy: Introduce Airoha AN8801/R Gigabit Ethernet PHY driver
From: Louis-Alexis Eyraud @ 2026-05-20 12:46 UTC (permalink / raw)
To: Maxime Chevallier, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, AngeloGioacchino Del Regno, Andrew Lunn,
Heiner Kallweit, Russell King
Cc: kevin-kw.huang, macpaul.lin, matthias.bgg, kernel, netdev,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <e77b4028-c201-4dd4-9214-721bdf67e976@bootlin.com>
Hi Maxime,
On Tue, 2026-05-12 at 12:06 +0200, Maxime Chevallier wrote:
> Hi :)
>
> This looks good, I just have very minimal comments
>
> On 5/12/26 06:33, Louis-Alexis Eyraud wrote:
> > From: AngeloGioacchino Del Regno
> > <angelogioacchino.delregno@collabora.com>
> >
> > Introduce a driver for the Airoha AN8801R Series Gigabit Ethernet
> > PHY; this currently supports setting up PHY LEDs, 10/100M, 1000M
> > speeds, and Wake on LAN and PHY interrupts.
> >
> > Signed-off-by: AngeloGioacchino Del Regno
> > <angelogioacchino.delregno@collabora.com>
> > Signed-off-by: Louis-Alexis Eyraud
> > <louisalexis.eyraud@collabora.com>
>
> [...]
>
> > +static u32 an8801r_led_blink_ms_to_hw(unsigned long req_ms)
> > +{
> > + u32 req_ns, regval;
> > +
> > + if (req_ms > AN8801_MAX_PERIOD_MS)
> > + req_ms = AN8801_MAX_PERIOD_MS;
> > +
> > + req_ns = req_ms * 1000000;
>
> Use NSEC_PER_MSEC :)
I'll fix this in the next version.
>
> > +
> > + /* Round to the nearest period unit... */
> > + regval = req_ns + (AN8801_PERIOD_UNIT / 2);
> > +
> > + /* ...and now divide by the full period */
> > + regval >>= AN8801_PERIOD_SHIFT;
> > +
> > + return regval;
> > +}
> > +
>
> [...]
>
> > +static int an8801r_led_hw_control_set(struct phy_device *phydev,
> > u8 index,
> > + unsigned long rules)
> > +{
> > + u16 on = 0, blink = 0;
> > + int ret;
> > +
> > + if (index >= AN8801R_NUM_LEDS)
> > + return -EINVAL;
> > +
> > + ret = an8801r_led_trig_to_hw(rules, &on, &blink);
> > + if (ret)
> > + return ret;
> > +
> > + ret = phy_modify_mmd(phydev, MDIO_MMD_VEND2,
> > LED_ON_CTRL(index),
> > + LED_ON_EVT_MASK, on);
> > + if (ret)
> > + return ret;
> > +
> > + ret = phy_modify_mmd(phydev, MDIO_MMD_VEND2,
> > LED_BLINK_CTRL(index),
> > + LED_BLINK_EVT_MASK, blink);
> > +
> > + if (ret)
> > + return ret;
>
> Extra newline before the if()
I'll fix this in the next version too.
>
> > +
> > + return phy_modify_mmd(phydev, MDIO_MMD_VEND2,
> > LED_ON_CTRL(index),
> > + LED_ON_EN, on | blink ? LED_ON_EN :
> > 0);
> > +}
> > +
>
> [...]
>
> > +static int an8801r_rgmii_rxdelay(struct phy_device *phydev, bool
> > enable,
> > + u16 delay_steps)
> > +{
> > + u32 reg_val;
> > +
> > + if (delay_steps > RGMII_DELAY_STEP_MASK)
> > + return -EINVAL;
> > +
> > + if (enable) {
> > + reg_val = delay_steps & RGMII_DELAY_STEP_MASK;
> > +
> > + /* Set align bit to add extra offset for RX delay
> > */
> > + reg_val |= RGMII_RXDELAY_ALIGN;
> > +
> > + /* Set force mode bit to enable RX delay
> > insertion */
> > + reg_val |= RGMII_RXDELAY_FORCE_MODE;
> > + } else {
> > + reg_val = 0;
> > + }
> > +
> > + return an8801_buckpbus_reg_write(phydev,
> > AN8801_BPBUS_REG_RXDLY_STEP,
> > + reg_val);
> > +}
> > +
> > +static int an8801r_rgmii_txdelay(struct phy_device *phydev, bool
> > enable,
> > + u16 delay_steps)
> > +{
> > + u32 reg_val;
> > +
> > + if (delay_steps > RGMII_DELAY_STEP_MASK)
> > + return -EINVAL;
> > +
> > + if (enable) {
> > + reg_val = delay_steps & RGMII_DELAY_STEP_MASK;
>
> Is this bitwise and needed, as you have the check above ?
Indeed, it is not needed, so I'll remove this masking operation here
and in an8801r_rgmii_rxdelay too.
>
> > +
> > + /* Set force mode bit to enable TX delay
> > insertion */
> > + reg_val |= RGMII_TXDELAY_FORCE_MODE;
> > + } else {
> > + reg_val = 0;
> > + }
> > +
> > + return an8801_buckpbus_reg_write(phydev,
> > AN8801_BPBUS_REG_TXDLY_STEP,
> > + reg_val);
> > +}
> > +
> > +static int an8801r_rgmii_delay_config(struct phy_device *phydev)
> > +{
> > + bool enable_delay;
> > + u16 delay_step;
> > + int ret;
> > +
> > + if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
> > + phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID) {
> > + enable_delay = true;
> > + delay_step = AN8801_RGMII_TXDELAY_DEFAULT;
> > + } else {
> > + enable_delay = false;
> > + delay_step = RGMII_DELAY_NO_STEP;
> > + }
> > +
> > + ret = an8801r_rgmii_txdelay(phydev, enable_delay,
> > delay_step);
> > + if (ret)
> > + return ret;
> > +
> > + if (phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
> > + phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID) {
> > + enable_delay = true;
> > + delay_step = AN8801_RGMII_RXDELAY_DEFAULT;
>
> Is it correct that AN8801_RGMII_RXDELAY_DEFAULT expands to
> RGMII_DELAY_NO_STEP ? feels strange, but it may simply be how the HW
> is
> made :)
As I replied in an earlier comment ([1]), for the inserted RX delay,
when the RGMII_RXDELAY_ALIGN bit is set, the "no step" value is then
the closest setting to the 2ns value.
I'll improve the AN8801_RGMII_RXDELAY_DEFAULT comment to say that it
corresponds to the 1.992ns delay value when the align bit is set and -
0.008ns otherwise.
[1]:https://lore.kernel.org/linux-mediatek/199e674cfdbccad104db761964611b1d6352f9f3.camel@collabora.com/
Best regards,
Louis-Alexis
>
> Thanks,
>
> Maxime
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm-smmu: qcom: Constrain clocks for Hawi SoC
From: Mukesh Ojha @ 2026-05-20 12:37 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Will Deacon, Joerg Roedel, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robin Murphy, linux-arm-kernel, iommu, devicetree,
linux-kernel
In-Reply-To: <20260520-evasive-harrier-of-honeydew-06ba84@quoll>
On Wed, May 20, 2026 at 12:57:13PM +0200, Krzysztof Kozlowski wrote:
> On Wed, May 20, 2026 at 01:04:47PM +0530, Mukesh Ojha wrote:
> > The Hawi SoC has two SMMU instances with different clock requirements.
> > The Adreno GPU SMMU uses the qcom,adreno-smmu fallback and requires a
> > single HLOS vote clock, matching the pattern already established for
> > Glymur and SM8750. The Application Processor SMMU (APSS) uses the
> > qcom,smmu-500 fallback and has no controllable clocks.
> >
> > Add qcom,hawi-smmu-500 to the single-clock constraint block for the
> > Adreno GPU SMMU and to the no-clocks constraint block for the APSS SMMU,
> > following the pattern how it is done for other SoCs.
>
> If you decided to make a competitive simultaneous work, you could at
> least tell me that.
Well, I covered for one SoC, while you covered for others. I am fine with either one getting picked.
>
> Best regards,
> Krzysztof
>
>
--
-Mukesh Ojha
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] net: ti: icssg: Add HSR and LRE PA statistics
From: Felix Maurer @ 2026-05-20 12:31 UTC (permalink / raw)
To: Luka Gejak
Cc: Jakub Kicinski, MD Danish Anwar, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Jonathan Corbet, Shuah Khan,
Roger Quadros, Andrew Lunn, Meghana Malladi, Jacob Keller,
David Carlier, Vadim Fedorenko, Kevin Hao, netdev, linux-doc,
linux-kernel, linux-arm-kernel, Vladimir Oltean
In-Reply-To: <E30AAC96-01D2-4A23-B562-126087DEB7FA@linux.dev>
Hi everyone,
On Tue, May 19, 2026 at 07:55:55AM +0200, Luka Gejak wrote:
> On May 19, 2026 3:45:06 AM GMT+02:00, Jakub Kicinski <kuba@kernel.org> wrote:
> >On Thu, 14 May 2026 13:26:05 +0530 MD Danish Anwar wrote:
> >> Add new firmware PA statistics counters for HSR and LRE to the ethtool
> >> statistics exposed by the ICSSG driver.
> >>
> >> New statistics added:
> >> - FW_HSR_FWD_CHECK_FAIL_DROP: Packets dropped on the HSR forwarding path
> >> - FW_HSR_HE_CHECK_FAIL_DROP: Packets dropped on the HSR host egress path
> >> - FW_HSR_SKIP_HOST_DUP_DISCARD_FRAMES: Frames with duplicate discard
> >> skipped
> >> - FW_LRE_CNT_UNIQUE/DUPLICATE/MULTIPLE_RX: LRE duplicate detection
> >> counters
> >> - FW_LRE_CNT_RX/TX: LRE per-port frame counters
> >> - FW_LRE_CNT_OWN_RX: Own HSR tagged frames received
> >> - FW_LRE_CNT_ERRWRONGLAN: Frames with wrong LAN identifier (PRP)
> >>
> >> Document the new HSR/LRE statistics in icssg_prueth.rst.
> >
> >To an untrained eye these stats look like stuff that could
> >be standardized across drivers.
> >
> >Luka, Felix, others on CC, do you think we should expose these
> >from HSR over netlink as "standard" offload stats different drivers
> >can plug into or not worth it?
>
> Hi Jakub,
> I think there is a case for standardizing part of this, but I would
> not standardize the whole set as-is.
>
> The LRE counters look generic enough to me, especially:
> - unique rx
> - duplicate rx
> - multiple rx
> - rx / tx
> - own rx
> - wrong LAN, PRP only
I'm very much in favor of having standardized stats for hsr hardware
offloads that the drivers can supply. The list above looks about right,
I'd add "frames with errors" and "(proxy) node table entry count" as
well and that "own rx" is HSR only.
In general, I don't think we need to standardize this ourselves but can
adapt to the counters that the SNMP MIB for IEC 62439-3 [1] already has.
It's part of the standard and IMHO we should gather these counters from
offloads (and later supply the same set from our sw implementation, but
the current netlink interface for hsr is quite messy). For reference,
the list in the MIB is (no need to fully adopt this naming):
- lreCntTx{A,B,C}: Sent frames per-port (for A,B only tagged frames)
- lreCntRx{A,B,C}: Received frames per-port (for A,B only tagged frames)
- lreCntErrWrongLan{A,B}: Received frames per-port with wrong LAN ID
(only for PRP)
- lreCntErrWrongLanC: Received frames on interlink port of HSR-PRP
RedBox with wrong LAN ID
- lreCntErrors{A,B,C}: Received frames with errors per-port
- lreCnt{,Proxy}Nodes: Nodes in the (proxy) node table
- lreCntUnique{A,B,C}: Frames only received once, per-port
- lreCntDuplicate{A,B,C}: Frames received with exactly one duplicate,
per-port
- lreCntMulti{A,B,C}: Frames received with more than one duplicate,
per-port
- lreCntOwnRx{A,B}: Frames received per-port (A,B) that originated from
this node, only for HSR rings
Note that we can not currently completely distinguish
Unique/Duplicate/Multi in the kernel implementation and their meaning is
not entirely clear to me from the MIB.
The explanations in the MIB in [1] are otherwise quite explicit for each
of the counters but we may want to adapt the meaning of "port C" to the
counters. For example, there is lreCntRx{A,B,C} for received HSR/PRP
tagged frames (by the LRE). Port A and B are clear, but for port C the
meaning is "number of frames received from the application interface of
a DANP or DANH or the number of number of frames received on the
interlink of a RedBox". IMHO, we should consider separating "application
interface" (what the kernel calls master) and the interlink port because
these two are not mutually exclusive in the kernel (nor in the NICs that
support hardware offload).
Thanks,
Felix
[1]: you can find it for example here: https://mibbrowser.online/mibdb_search.php?mib=IEC-62439-3-MIB
^ permalink raw reply
* Re: [PATCH v2 0/7] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
From: Wen Jiang @ 2026-05-20 12:29 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, urezki, baohua,
Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, Wen Jiang
In-Reply-To: <20260519131738.11a78ba88e1be28ba5cb26eb@linux-foundation.org>
Hi Andrew,
I've reviewed all the Sashiko findings:
- Patch 2 (fls() truncation risk): Will fix. Replace fls() with
__fls() to accept unsigned long directly.
- Patch 4 (nr overflow risk): Pre-existing type choice.
- Patch 4 (missing NULL check before page_to_phys): Will fix.
Add defensive checks consistent with vmap_pages_pte_range().
- Patch 5 (flush_cache_vmap with empty range): Valid point. Will
save the original start address and use it for the final flush.
- Patch 5 (virtual address alignment not checked): Addressed by
Patch 6 in this series.
- Patch 6 (caller tracking loss and while(1) loop): Valid point.
Will pass caller as a parameter and restructure per Uladzislau's
suggestion to replace while(1) with explicit sequential attempts.
- Patch 7 (partial cache flush on early break): Same root cause as
the Patch 5 flush issue.
Will resend V3 shortly.
Thanks,
Wen
On Wed, 20 May 2026 at 04:17, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Thu, 14 May 2026 17:41:01 +0800 Wen Jiang <jiangwenxiaomi@gmail.com> wrote:
>
> > This patchset accelerates ioremap, vmalloc, and vmap when the memory
> > is physically fully or partially contiguous.
> >
> > ...
> >
> > On the RK3588 8-core ARM64 SoC, with tasks pinned to a little core and
> > the performance CPUfreq policy enabled, benchmark results:
> >
> > * ioremap(1 MB): 1.35× faster (3407 ns -> 2526 ns)
> > * vmalloc(1 MB) mapping time (excluding allocation) with
> > VM_ALLOW_HUGE_VMAP: 1.42× faster (5.00 us -> 3.53us)
> > * vmap(100MB) with order-8 pages: 8.3× faster (1235 us -> 149 us)
>
> Nice.
>
> AI review found a bunch of things to ask about:
> https://sashiko.dev/#/patchset/20260514094108.2016201-1-jiangwen6@xiaomi.com
>
> It doesn't appear that you'll be getting any more review on this
> series, so please check the above questions and resend?
>
^ permalink raw reply
* [PATCH v8 next 01/10] fs/resctrl: Fix MPAM Partid parsing errors by preserving CDP state during umount
From: Zeng Heng @ 2026-05-20 12:28 UTC (permalink / raw)
To: James Morse, ben.horgan, Dave.Martin, tan.shaopeng,
reinette.chatre, fenghuay, tglx, will, hpa, bp, babu.moger,
dave.hansen, mingo, tony.luck, gshan, catalin.marinas
Cc: linux-arm-kernel, x86, linux-kernel, wangkefeng.wang
In-Reply-To: <c6b77292-4ac4-189f-66f6-300e03440788@huawei.com>
Hi James,
On 2026/5/15 1:06, James Morse wrote:
> Hi Zeng,
>
> I think this should be a separate patch as its fixing a problem not adding a feature. It's
> not actually relevant to the rest of the series.
>
The intention behind this fix is that reqPARTID would end up the same as
the original PARTID, because the conversion between RMID and reqPARTID
relies on the `cdp_enabled` variable. Hence, I attempted to also
resolve this existing problem with the patch.
> On 13/04/2026 09:53, Zeng Heng wrote:
>> This patch fixes a pre-existing issue in the resctrl filesystem teardown
>> sequence where premature clearing of cdp_enabled could lead to MPAM Partid
>> parsing errors.
>
> resctrl changes need to go via tip, which has a bunch of rules about commit messages,
> see Documentation/process/maintainer-tip.rst
>
> You end up with a structure describing the current state, e.g:
> | When resctrl is umounted it disables CDP,
>
> what the problem is, e.g:
> | CLOSID remain in the limbo list, and the mbm monitors continue to be read
> | after umount. MPAM changes the meaning of CLOSID when CDP is enabled/disabled,
> | resulting in out of bounds accesses.
>
> Then, what you do about it, here you are:
> | Throwing away the limbo list on umount.
>
> (I don't suggest you take this wording - its just an example)
>
> "this patch" is a phrase to avoid, acronyms like CLOSID need capitalising, etc.
>
Thanks for the details, I'll rework the commit to follow these
guidelines.
>
>> The closid to partid conversion logic inherently depends on the global
>> cdp_enabled state. However, rdt_disable_ctx() clears this flag early in
>> the umount path, while free_rmid() operations will reference after that.
>> This creates a window where partid parsing operates with inconsistent CDP
>> state, potentially makes monitor reads with wrong partid mapping.
>>
>> Additionally, rmid_entry remaining in limbo between mount sessions may
>> trigger potential partid out-of-range errors, leading to MPAM fault
>> interrupts and subsequent MPAM disablement.
>
> Can you give more details on this. I assume its going from CDP-disable to
> enabled, means MPAM doubles the CLOSID from the stale limbo list, making it
> out of range.
>
Get it, I would explain that.
>
>> Reorder rdt_kill_sb() to delay rdt_disable_ctx() until after
>> rmdir_all_sub() and resctrl_fs_teardown() complete. This ensures
>> all rmid-related operations finish with correct CDP state.
>
>
>> Introduce rdt_flush_limbo() to flush and cancel limbo work before the
>> filesystem teardown completes.
>
> So, discard the state in the hope we don't need it again.
> What happens if the filesystem is mounted again quickly afterwards?
> Surely we get noisy bandwidth results for ~minutes afterwards?
>
>
>> An alternative approach would be to cancel limbo work on umount
>
> Sounds like a move in the right direction - having bits of resctrl still
> taking CPU time when its not in use is surprising.
>
> I'd love to eventually remove the limbo worker and have the RMID alloc code
> search the limbo list for a clean RMID when a control/monitor group is created.
> By deferring the work as late as possible, we do less work overall.
>
>
>> and restart it on remount with remaked bitmap.
>> However, this would require substantial changes in the resctrl layer to
>> handle CDP state transitions across mount sessions,
>
> This would be necessary if the limbo timer was stopped on umount too.
> It also covers cases where you kexec and re-mount resctrl.
>
> I think this is a good idea. I agree its more work.
>
>
>> which is beyond the
>> scope of the reqpartid feature work this patchset focuses on.
>
> Was it a mistake to include it in this series then?
>
>
>> The current
>> fix addresses the immediate correctness issue with minimal churn.
>
> I'm not a fan of papering over problems in resctrl. Could we do it properly
> by rebuilding the limbo list at mount time as you suggested above?
>
>
I discussed this with Ben earlier, and the remake bitmap approach was
actually his proposal:
https://lore.kernel.org/all/b95077d7-c036-4a8f-8e42-8f1dc0288075@arm.com/
Best regards,
Zeng Heng
^ permalink raw reply
* Re: [PATCH RESEND v3 1/6] drm/connector: report IRQ_HPD events to drm_connector_oob_hotplug_event()
From: Dmitry Baryshkov @ 2026-05-20 12:26 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Heikki Krogerus, Greg Kroah-Hartman, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Adrien Grassein, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Tomi Valkeinen,
Bjorn Andersson, Konrad Dybcio, Pengyu Luo, Nikita Travkin,
Yongxing Mou
Cc: dri-devel, linux-kernel, linux-usb, intel-gfx, intel-xe,
linux-amlogic, linux-arm-kernel, linux-arm-msm, freedreno
In-Reply-To: <20260513-hpd-irq-events-v3-1-086857017f16@oss.qualcomm.com>
On Wed, May 13, 2026 at 09:23:21PM +0300, Dmitry Baryshkov wrote:
> The DisplayPort standard defines a special kind of events called IRQ.
> These events are used to notify DP Source about the events on the Sink
> side. It is extremely important for DP MST handling, where the MST
> events are reported through this IRQ.
>
> In case of the USB-C DP AltMode there is no actual HPD pulse, but the
> events are ported through the bits in the AltMode VDOs.
>
> Extend the drm_connector_oob_hotplug_event() interface and report IRQ
> events to the DisplayPort Sink drivers.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> drivers/gpu/drm/drm_connector.c | 5 ++++-
> drivers/usb/typec/altmodes/displayport.c | 15 +++++++++++----
> include/drm/drm_connector.h | 19 ++++++++++++++++++-
> 3 files changed, 33 insertions(+), 6 deletions(-)
Greg, Heikki, would you please ack merging this through the drm tree?
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 47dc53c4a738..edee9daccd51 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -3510,6 +3510,8 @@ struct drm_connector *drm_connector_find_by_fwnode(struct fwnode_handle *fwnode)
> * drm_connector_oob_hotplug_event - Report out-of-band hotplug event to connector
> * @connector_fwnode: fwnode_handle to report the event on
> * @status: hot plug detect logical state
> + * @extra_status: additional information provided by the sink without changing
> + * the HPD state (or in addition to such a change).
> *
> * On some hardware a hotplug event notification may come from outside the display
> * driver / device. An example of this is some USB Type-C setups where the hardware
> @@ -3520,7 +3522,8 @@ struct drm_connector *drm_connector_find_by_fwnode(struct fwnode_handle *fwnode)
> * a drm_connector reference through calling drm_connector_find_by_fwnode().
> */
> void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
> - enum drm_connector_status status)
> + enum drm_connector_status status,
> + enum drm_connector_status_extra extra_status)
> {
> struct drm_connector *connector;
>
> diff --git a/drivers/usb/typec/altmodes/displayport.c b/drivers/usb/typec/altmodes/displayport.c
> index 35d9c3086990..7182a8e2e710 100644
> --- a/drivers/usb/typec/altmodes/displayport.c
> +++ b/drivers/usb/typec/altmodes/displayport.c
> @@ -189,7 +189,9 @@ static int dp_altmode_status_update(struct dp_altmode *dp)
> } else {
> drm_connector_oob_hotplug_event(dp->connector_fwnode,
> hpd ? connector_status_connected :
> - connector_status_disconnected);
> + connector_status_disconnected,
> + (hpd && irq_hpd) ? DRM_CONNECTOR_DP_IRQ_HPD :
> + DRM_CONNECTOR_NO_EXTRA_STATUS);
> dp->hpd = hpd;
> sysfs_notify(&dp->alt->dev.kobj, "displayport", "hpd");
> if (hpd && irq_hpd) {
> @@ -212,7 +214,10 @@ static int dp_altmode_configured(struct dp_altmode *dp)
> */
> if (dp->pending_hpd) {
> drm_connector_oob_hotplug_event(dp->connector_fwnode,
> - connector_status_connected);
> + connector_status_connected,
> + dp->pending_irq_hpd ?
> + DRM_CONNECTOR_DP_IRQ_HPD :
> + DRM_CONNECTOR_NO_EXTRA_STATUS);
> sysfs_notify(&dp->alt->dev.kobj, "displayport", "hpd");
> dp->pending_hpd = false;
> if (dp->pending_irq_hpd) {
> @@ -397,7 +402,8 @@ static int dp_altmode_vdm(struct typec_altmode *alt,
> dp->data.conf = 0;
> if (dp->hpd) {
> drm_connector_oob_hotplug_event(dp->connector_fwnode,
> - connector_status_disconnected);
> + connector_status_disconnected,
> + DRM_CONNECTOR_NO_EXTRA_STATUS);
> dp->hpd = false;
> sysfs_notify(&dp->alt->dev.kobj, "displayport", "hpd");
> }
> @@ -827,7 +833,8 @@ void dp_altmode_remove(struct typec_altmode *alt)
>
> if (dp->connector_fwnode) {
> drm_connector_oob_hotplug_event(dp->connector_fwnode,
> - connector_status_disconnected);
> + connector_status_disconnected,
> + DRM_CONNECTOR_NO_EXTRA_STATUS);
>
> fwnode_handle_put(dp->connector_fwnode);
> }
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index f83f28cae207..e05197e970d3 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -91,6 +91,22 @@ enum drm_connector_status {
> connector_status_unknown = 3,
> };
>
> +/**
> + * enum drm_connector_status_extra - additional events sent by the sink /
> + * display together or in replacement of the HPD status changes.
> + */
> +enum drm_connector_status_extra {
> + /**
> + * @DRM_CONNECTOR_NO_EXTRA_STATUS: No additional status reported.
> + */
> + DRM_CONNECTOR_NO_EXTRA_STATUS,
> + /**
> + * @DRM_CONNECTOR_DP_IRQ_HPD: DisplayPort Sink has sent the
> + * IRQ_HPD (either by the HPD short pulse or via the AltMode event).
> + */
> + DRM_CONNECTOR_DP_IRQ_HPD,
> +};
> +
> /**
> * enum drm_connector_registration_state - userspace registration status for
> * a &drm_connector
> @@ -2521,7 +2537,8 @@ drm_connector_is_unregistered(struct drm_connector *connector)
> }
>
> void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
> - enum drm_connector_status status);
> + enum drm_connector_status status,
> + enum drm_connector_status_extra extra_status);
> const char *drm_get_connector_type_name(unsigned int connector_type);
> const char *drm_get_connector_status_name(enum drm_connector_status status);
> const char *drm_get_subpixel_order_name(enum subpixel_order order);
>
> --
> 2.47.3
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v8 next 01/10] fs/resctrl: Fix MPAM Partid parsing errors by preserving CDP state during umount
From: Zeng Heng @ 2026-05-20 12:16 UTC (permalink / raw)
To: James Morse, ben.horgan, Dave.Martin, tan.shaopeng,
reinette.chatre, fenghuay, tglx, will, hpa, bp, babu.moger,
dave.hansen, mingo, tony.luck, gshan, catalin.marinas
Cc: linux-arm-kernel, x86, linux-kernel, wangkefeng.wang
In-Reply-To: <0efe369b-8a01-45b1-bd0f-4fdd4ebbb18a@arm.com>
Hi James,
On 2026/5/15 1:06, James Morse wrote:
> Hi Zeng,
>
> I think this should be a separate patch as its fixing a problem not adding a feature. It's
> not actually relevant to the rest of the series.
>
The intention behind this fix is that reqPARTID would end up the same as
the original PARTID, because the conversion between RMID and reqPARTID
relies on the `cdp_enabled` variable. Hence, I attempted to also
resolve this existing problem with the patch.
> On 13/04/2026 09:53, Zeng Heng wrote:
>> This patch fixes a pre-existing issue in the resctrl filesystem teardown
>> sequence where premature clearing of cdp_enabled could lead to MPAM Partid
>> parsing errors.
>
> resctrl changes need to go via tip, which has a bunch of rules about commit messages,
> see Documentation/process/maintainer-tip.rst
>
> You end up with a structure describing the current state, e.g:
> | When resctrl is umounted it disables CDP,
>
> what the problem is, e.g:
> | CLOSID remain in the limbo list, and the mbm monitors continue to be read
> | after umount. MPAM changes the meaning of CLOSID when CDP is enabled/disabled,
> | resulting in out of bounds accesses.
>
> Then, what you do about it, here you are:
> | Throwing away the limbo list on umount.
>
> (I don't suggest you take this wording - its just an example)
>
> "this patch" is a phrase to avoid, acronyms like CLOSID need capitalising, etc.
>
Thanks for the details, I'll rework the commit to follow these
guidelines.
>
>> The closid to partid conversion logic inherently depends on the global
>> cdp_enabled state. However, rdt_disable_ctx() clears this flag early in
>> the umount path, while free_rmid() operations will reference after that.
>> This creates a window where partid parsing operates with inconsistent CDP
>> state, potentially makes monitor reads with wrong partid mapping.
>>
>> Additionally, rmid_entry remaining in limbo between mount sessions may
>> trigger potential partid out-of-range errors, leading to MPAM fault
>> interrupts and subsequent MPAM disablement.
>
> Can you give more details on this. I assume its going from CDP-disable to
> enabled, means MPAM doubles the CLOSID from the stale limbo list, making it
> out of range.
>
Get it, I would explain that.
>
>> Reorder rdt_kill_sb() to delay rdt_disable_ctx() until after
>> rmdir_all_sub() and resctrl_fs_teardown() complete. This ensures
>> all rmid-related operations finish with correct CDP state.
>
>
>> Introduce rdt_flush_limbo() to flush and cancel limbo work before the
>> filesystem teardown completes.
>
> So, discard the state in the hope we don't need it again.
> What happens if the filesystem is mounted again quickly afterwards?
> Surely we get noisy bandwidth results for ~minutes afterwards?
>
>
>> An alternative approach would be to cancel limbo work on umount
>
> Sounds like a move in the right direction - having bits of resctrl still
> taking CPU time when its not in use is surprising.
>
> I'd love to eventually remove the limbo worker and have the RMID alloc code
> search the limbo list for a clean RMID when a control/monitor group is created.
> By deferring the work as late as possible, we do less work overall.
>
>
>> and restart it on remount with remaked bitmap.
>> However, this would require substantial changes in the resctrl layer to
>> handle CDP state transitions across mount sessions,
>
> This would be necessary if the limbo timer was stopped on umount too.
> It also covers cases where you kexec and re-mount resctrl.
>
> I think this is a good idea. I agree its more work.
>
>
>> which is beyond the
>> scope of the reqpartid feature work this patchset focuses on.
>
> Was it a mistake to include it in this series then?
>
>
>> The current
>> fix addresses the immediate correctness issue with minimal churn.
>
> I'm not a fan of papering over problems in resctrl. Could we do it properly
> by rebuilding the limbo list at mount time as you suggested above?
>
>
I discussed this with Ben earlier, and the remake bitmap approach was
actually his proposal:
https://lore.kernel.org/all/b95077d7-c036-4a8f-8e42-8f1dc0288075@arm.com/
Best regards,
Zeng Heng
^ permalink raw reply
* Re: [PATCH v2] ARM: PCI: merge pci_common_init_dev() into pci_common_init()
From: Andrew Lunn @ 2026-05-20 12:03 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: linux-arm-kernel, linux-kernel, Russell King, Bjorn Helgaas,
Ilpo Järvinen, Kuninori Morimoto
In-Reply-To: <20260520041343.23040-1-enelsonmoore@gmail.com>
On Tue, May 19, 2026 at 09:13:38PM -0700, Ethan Nelson-Moore wrote:
> pci_common_init() is a compatibility wrapper that simply calls
> pci_common_init_dev() with an additional NULL argument. The comment
> above it implies that it should be replaced by pci_common_init_dev(),
> but that has never happened - there are no callers of
> pci_common_init_dev() in the kernel. Make the PCI code more
> straightforward by getting rid of the wrapper function and instead
> removing the device argument from pci_common_init_dev() and renaming it
> to pci_common_init().
>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH PARTIAL-RESEND v12 0/5] Add support MT6316/6363/MT6373 PMICs regulators and MFD
From: AngeloGioacchino Del Regno @ 2026-05-20 12:00 UTC (permalink / raw)
To: Mark Brown
Cc: linux-mediatek, lee, robh, krzk+dt, conor+dt, matthias.bgg,
lgirdwood, devicetree, linux-kernel, linux-arm-kernel, kernel,
wenst
In-Reply-To: <agKBkUBVM81Y6MUk@sirena.co.uk>
On 5/12/26 03:25, Mark Brown wrote:
> On Mon, May 11, 2026 at 12:13:50PM +0200, AngeloGioacchino Del Regno wrote:
>> Changes in v12:
>> - This is a partial resend. MT6373 regulators and MFD patches were not picked.
>> - Rebased over next-20260508
>
> Is there a reason why this is a single patch series, are there any
> interdependencies here?
Just showing the full picture. Nothing else.
Btw, seen your feedback on the other patches, will fix as soon as I can - thanks!
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH PARTIAL-RESEND v12 0/5] Add support MT6316/6363/MT6373 PMICs regulators and MFD
From: AngeloGioacchino Del Regno @ 2026-05-20 12:00 UTC (permalink / raw)
To: Mark Brown
Cc: linux-mediatek, lee, robh, krzk+dt, conor+dt, matthias.bgg,
lgirdwood, devicetree, linux-kernel, linux-arm-kernel, kernel,
wenst
In-Reply-To: <agKBkUBVM81Y6MUk@sirena.co.uk>
On 5/12/26 03:25, Mark Brown wrote:
> On Mon, May 11, 2026 at 12:13:50PM +0200, AngeloGioacchino Del Regno wrote:
>> Changes in v12:
>> - This is a partial resend. MT6373 regulators and MFD patches were not picked.
>> - Rebased over next-20260508
>
> Is there a reason why this is a single patch series, are there any
> interdependencies here?
Just showing the full picture. Nothing else.
Btw, seen your feedback on the other patches, will fix as soon as I can - thanks!
Cheers,
Angelo
^ permalink raw reply
* [PATCH v5 0/2] Enable audio support for J721S2 EVM
From: Moteen Shah @ 2026-05-20 11:56 UTC (permalink / raw)
To: krzk+dt, robh, conor+dt, nm, vigneshr, kristo
Cc: devicetree, linux-arm-kernel, linux-kernel, u-kumar1,
gehariprasath, y-abhilashchandra, m-shah
Earlier version of the patchset sent upstream[0] was rejected as
its dependency[1], which resolves the DTBS check errors introduced
by [0] also got rejected on the grounds of ABI breakage.
Another solution to fix the DTBS check errors introduced by [0] is
to modify the ti,j721e-system-controller.yaml binding to allow
audio-refclk as clock-controller child. This is done in the first
patch of this series.
Changes sinve v4:
Link to v4: https://lore.kernel.org/all/20260519142341.2531948-1-m-shah@ti.com/
- Explicitly diasble main_mcan3 and Main_mcan5 as thy will silently break mcasp audio routing
Link to v3: https://lore.kernel.org/all/20260330094459.128648-1-m-shah@ti.com/
Link to v2: https://lore.kernel.org/all/20260205130707.2033197-1-m-shah@ti.com/
Link to v1: https://lore.kernel.org/all/20260112104536.83309-1-m-shah@ti.com/
Bootlogs: https://gist.github.com/Jamm02/f586087dad227450abe8637e8a688c68
Jayesh Choudhary (1):
arm64: dts: ti: Add audio overlay for k3-j721s2-evm
Moteen Shah (1):
dt-bindings: ti: Update audio-refclk binding and j721e system
controller
.../bindings/clock/ti,am62-audio-refclk.yaml | 8 +-
.../soc/ti/ti,j721e-system-controller.yaml | 6 +-
arch/arm64/boot/dts/ti/Makefile | 4 +
.../boot/dts/ti/k3-j721s2-evm-audio.dtso | 171 ++++++++++++++++++
4 files changed, 185 insertions(+), 4 deletions(-)
create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
--
2.34.1
^ permalink raw reply
* [PATCH v5 2/2] arm64: dts: ti: Add audio overlay for k3-j721s2-evm
From: Moteen Shah @ 2026-05-20 11:56 UTC (permalink / raw)
To: krzk+dt, robh, conor+dt, nm, vigneshr, kristo
Cc: devicetree, linux-arm-kernel, linux-kernel, u-kumar1,
gehariprasath, y-abhilashchandra, m-shah
In-Reply-To: <20260520115603.2662930-1-m-shah@ti.com>
From: Jayesh Choudhary <j-choudhary@ti.com>
Add device tree overlay to enable analog audio support on J721S2-EVM
using PCM3168A codec connected to McASP4 serializers.
- Add nodes for sound-card, audio codec, I2C3 and McASP4
- Add pinmux for I2C3, McASP4, AUDIO_EXT_REFCLK1 and WKUP_GPIO_0
- Add GPIO expander (TCA6408) for codec control
- Add GPIO hogs to route I2C3 lines and McASP serializers
- Set idle-state to 0 in mux0 and mux1 for McASP signal routing
- Disable main_mcan3 and main_mcan5 as they conflict with McASP4 signal routing via mux0 and mux1
Reviewed-by: Hari Prasath Gujulan Elango <gehariprasath@ti.com>
Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Co-developed-by: Moteen Shah <m-shah@ti.com>
Signed-off-by: Moteen Shah <m-shah@ti.com>
---
arch/arm64/boot/dts/ti/Makefile | 4 +
.../boot/dts/ti/k3-j721s2-evm-audio.dtso | 171 ++++++++++++++++++
2 files changed, 175 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index ba01a929e06f..17048f2f5043 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -138,6 +138,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j721s2-common-proc-board.dtb
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-gesi-exp-board.dtbo
k3-j721s2-evm-dtbs := k3-j721s2-common-proc-board.dtb k3-j721s2-evm-gesi-exp-board.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm.dtb
+dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-audio.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-pcie1-ep.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-usb0-type-a.dtbo
@@ -264,6 +265,8 @@ k3-j721e-evm-pcie1-ep-dtbs := k3-j721e-common-proc-board.dtb \
k3-j721e-evm-pcie1-ep.dtbo
k3-j721e-sk-csi2-dual-imx219-dtbs := k3-j721e-sk.dtb \
k3-j721e-sk-csi2-dual-imx219.dtbo
+k3-j721s2-evm-audio-dtbs := k3-j721s2-common-proc-board.dtb \
+ k3-j721s2-evm-audio.dtbo
k3-j721s2-evm-pcie1-ep-dtbs := k3-j721s2-common-proc-board.dtb \
k3-j721s2-evm-pcie1-ep.dtbo
k3-j721s2-evm-usb0-type-a-dtbs := k3-j721s2-common-proc-board.dtb \
@@ -328,6 +331,7 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-j721e-evm-pcie0-ep.dtb \
k3-j721e-evm-pcie1-ep.dtb \
k3-j721e-sk-csi2-dual-imx219.dtb \
+ k3-j721s2-evm-audio.dtb \
k3-j721s2-evm-pcie1-ep.dtb \
k3-j721s2-evm-usb0-type-a.dtb \
k3-j722s-evm-csi2-quad-rpi-cam-imx219.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso b/arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
new file mode 100644
index 000000000000..c467aa9ce647
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-evm-audio.dtso
@@ -0,0 +1,171 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * Device Tree Overlay for J721S2 Audio Support
+ *
+ * Copyright (C) 2026 Texas Instruments Incorporated - https://www.ti.com/
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+#include "k3-pinctrl.h"
+
+&{/} {
+ codec_audio: sound {
+ compatible = "ti,j7200-cpb-audio";
+ model = "j721s2-cpb";
+
+ ti,cpb-mcasp = <&mcasp4>;
+ ti,cpb-codec = <&pcm3168a_1>;
+
+ clocks = <&k3_clks 213 0>, <&k3_clks 213 1>,
+ <&k3_clks 157 299>, <&k3_clks 157 328>;
+ clock-names = "cpb-mcasp-auxclk", "cpb-mcasp-auxclk-48000",
+ "cpb-codec-scki", "cpb-codec-scki-48000";
+ };
+
+ i2c_mux: mux-controller-2 {
+ compatible = "gpio-mux";
+ #mux-state-cells = <1>;
+ mux-gpios = <&wkup_gpio0 54 GPIO_ACTIVE_HIGH>;
+ idle-state = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c3_mux_pins_default>;
+ };
+};
+
+&main_pmx0 {
+ mcasp4_pins_default: mcasp4-default-pins {
+ pinctrl-single,pins = <
+ J721S2_IOPAD(0x0c8, PIN_OUTPUT_PULLDOWN, 1) /* (AD28) MCASP4_ACLKX */
+ J721S2_IOPAD(0x06c, PIN_OUTPUT_PULLDOWN, 1) /* (V26) MCASP4_AFSX */
+ J721S2_IOPAD(0x068, PIN_INPUT_PULLDOWN, 1) /* (U28) MCASP4_AXR1 */
+ J721S2_IOPAD(0x0c4, PIN_OUTPUT_PULLDOWN, 1) /* (AB26) MCASP4_AXR2 */
+ J721S2_IOPAD(0x070, PIN_OUTPUT_PULLDOWN, 1) /* (R27) MCASP4_AXR3 */
+ >;
+ };
+
+ audio_ext_refclk1_pins_default: audio-ext-refclk1-default-pins {
+ pinctrl-single,pins = <
+ J721S2_IOPAD(0x078, PIN_OUTPUT, 1) /* (Y25) MCAN2_RX.AUDIO_EXT_REFCLK1 */
+ >;
+ };
+};
+
+&wkup_pmx2 {
+ main_i2c3_mux_pins_default: main-i2c3-mux-default-pins {
+ pinctrl-single,pins = <
+ J721S2_WKUP_IOPAD(0x038, PIN_OUTPUT, 7) /* (B27) WKUP_GPIO0_54 */
+ >;
+ };
+};
+
+&exp2 {
+ p09-hog {
+ /* P09 - MCASP/TRACE_MUX_S0 */
+ gpio-hog;
+ gpios = <9 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "MCASP/TRACE_MUX_S0";
+ };
+
+ p10-hog {
+ /* P10 - MCASP/TRACE_MUX_S1 */
+ gpio-hog;
+ gpios = <10 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "MCASP/TRACE_MUX_S1";
+ };
+};
+
+&mux0 {
+ idle-state = <0>;
+};
+
+&mux1 {
+ idle-state = <0>;
+};
+
+&main_mcan3 {
+ /* Conflicts with McASP4 signal routing via mux0 */
+ status = "disabled";
+};
+
+&main_mcan5 {
+ /* Conflicts with McASP4 signal routing via mux1 */
+ status = "disabled";
+};
+
+&scm_conf {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ audio_refclk1: clock-controller@42e4 {
+ compatible = "ti,j721s2-audio-refclk", "ti,am62-audio-refclk";
+ reg = <0x42e4 0x4>;
+ clocks = <&k3_clks 157 299>;
+ assigned-clocks = <&k3_clks 157 299>;
+ assigned-clock-parents = <&k3_clks 157 328>;
+ #clock-cells = <0>;
+ };
+};
+
+&k3_clks {
+ /* Configure AUDIO_EXT_REFCLK1 pin as output */
+ pinctrl-names = "default";
+ pinctrl-0 = <&audio_ext_refclk1_pins_default>;
+};
+
+&main_i2c3 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_i2c3_pins_default>;
+ clock-frequency = <400000>;
+ mux-states = <&i2c_mux 1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ exp3: gpio@20 {
+ compatible = "ti,tca6408";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-line-names = "CODEC_RSTZ", "CODEC_SPARE1",
+ "UB926_RESETN", "UB926_LOCK",
+ "UB926_PWR_SW_CNTRL", "UB926_TUNER_RESET",
+ "UB926_GPIO_SPARE";
+ };
+
+ pcm3168a_1: audio-codec@44 {
+ compatible = "ti,pcm3168a";
+ reg = <0x44>;
+ #sound-dai-cells = <1>;
+ reset-gpios = <&exp3 0 GPIO_ACTIVE_LOW>;
+ clocks = <&audio_refclk1>;
+ clock-names = "scki";
+ VDD1-supply = <&vsys_3v3>;
+ VDD2-supply = <&vsys_3v3>;
+ VCCAD1-supply = <&vsys_5v0>;
+ VCCAD2-supply = <&vsys_5v0>;
+ VCCDA1-supply = <&vsys_5v0>;
+ VCCDA2-supply = <&vsys_5v0>;
+ };
+};
+
+&mcasp4 {
+ status = "okay";
+ #sound-dai-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcasp4_pins_default>;
+ op-mode = <0>; /* MCASP_IIS_MODE */
+ tdm-slots = <2>;
+ auxclk-fs-ratio = <256>;
+ serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
+ 0 2 1 1
+ 0 0 0 0
+ 0 0 0 0
+ 0 0 0 0
+ >;
+};
--
2.34.1
^ permalink raw reply related
* [PATCH v5 1/2] dt-bindings: ti: Update audio-refclk binding and j721e system controller
From: Moteen Shah @ 2026-05-20 11:56 UTC (permalink / raw)
To: krzk+dt, robh, conor+dt, nm, vigneshr, kristo
Cc: devicetree, linux-arm-kernel, linux-kernel, u-kumar1,
gehariprasath, y-abhilashchandra, m-shah
In-Reply-To: <20260520115603.2662930-1-m-shah@ti.com>
Add ti,j721s2-audio-refclk as a supported compatible string in the
ti,am62-audio-refclk binding. J721S2 uses the same audio reference
clock IP block first introduced on AM62. Per writing-bindings
guidelines, the J721S2-specific compatible is added as the primary
string with ti,am62-audio-refclk as the fallback.
Also extend the ti,j721e-system-controller clock-controller@ child
pattern to accept audio-refclk schemas alongside ehrpwm-tbclk via a
oneOf constraint.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Moteen Shah <m-shah@ti.com>
---
.../devicetree/bindings/clock/ti,am62-audio-refclk.yaml | 8 ++++++--
.../bindings/soc/ti/ti,j721e-system-controller.yaml | 6 ++++--
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/ti,am62-audio-refclk.yaml b/Documentation/devicetree/bindings/clock/ti,am62-audio-refclk.yaml
index b2e40bd39a3a..6c8fb0793070 100644
--- a/Documentation/devicetree/bindings/clock/ti,am62-audio-refclk.yaml
+++ b/Documentation/devicetree/bindings/clock/ti,am62-audio-refclk.yaml
@@ -11,8 +11,12 @@ maintainers:
properties:
compatible:
- items:
- - const: ti,am62-audio-refclk
+ oneOf:
+ - items:
+ - const: ti,am62-audio-refclk
+ - items:
+ - const: ti,j721s2-audio-refclk
+ - const: ti,am62-audio-refclk
reg:
maxItems: 1
diff --git a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
index f3bd0be3b279..364be49f8c7c 100644
--- a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
+++ b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
@@ -53,9 +53,11 @@ patternProperties:
"^clock-controller@[0-9a-f]+$":
type: object
- $ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml#
+ oneOf:
+ - $ref: /schemas/clock/ti,am62-audio-refclk.yaml#
+ - $ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml#
description:
- Clock provider for TI EHRPWM nodes.
+ Clock provider for TI EHRPWM or Audio Reference Clock nodes.
"phy@[0-9a-f]+$":
type: object
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 1/4] dt-bindings: usb: dwc3-xilinx: Add MMI USB support on Versal Gen2 platform
From: Pandey, Radhey Shyam @ 2026-05-20 11:55 UTC (permalink / raw)
To: Krzysztof Kozlowski, Radhey Shyam Pandey
Cc: gregkh, robh, krzk+dt, conor+dt, michal.simek, Thinh.Nguyen,
p.zabel, linux-usb, devicetree, linux-arm-kernel, linux-kernel,
git
In-Reply-To: <a51d0e53-3134-475d-a19f-67d7d0695cfe@kernel.org>
On 5/14/2026 9:30 PM, Krzysztof Kozlowski wrote:
> On 07/05/2026 21:01, Pandey, Radhey Shyam wrote:
>>> On Wed, Apr 29, 2026 at 11:00:47PM +0530, Radhey Shyam Pandey wrote:
>>>> additionalProperties: false
>>>>
>>>> examples:
>>>> @@ -156,3 +193,30 @@ examples:
>>>> };
>>>> };
>>>> };
>>>> + - |
>>>> + #include <dt-bindings/power/xlnx-zynqmp-power.h>
>>>> + #include <dt-bindings/reset/xlnx-zynqmp-resets.h>
>>>> + #include <dt-bindings/phy/phy.h>
>>>> + usb {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <1>;
>>> Please follow DTS coding style.
>> Thanks for the review. will fix it in next version.
>>>> + compatible = "xlnx,versal2-mmi-dwc3";
>>> I really doubt that DWC3 block comes without addressing space
>>> (registers), so either you just misrepresented things, like created a
>>> fake block and syscon, or forgot to combine DWC3 with the wrapper.
>>>
>>> And if you built with W=1 your DTS you would see errors. How do you see
>>> it now? Where do you place it? Wrapper must be outside of soc, but DWC3
>>> child must be inside. Did you read submitting patches and writing
>>> bindings documents?
>> Apologies for missing the DTS sanity check earlier. I am summarizing the
>> problem statement and possible solution. Please review.
>>
>> For MMI USB in current implementation it need a parent/child
>> representation. However, the parent IP is shared across DP, USB,
>> and HDCP, so it cannot have a USB-dedicated parent reg space.
>>
>> 1. Versal platform
>> - Parent: USB wrapper IP → has its own I/O space
>> - Child: USB DWC3
>>
>> 2. Versal Gen2 platform - MMI USB
>> - Parent subsystem combines DP, USB, and HDCP in a single I/O space
>> - Children:
>> - USB DWC3
>> - DP
>> - HDCP
>>
>> To model the Versal Gen2 MMI USB parent register space, I introduced
>> xlnx,usb-syscon, allowing the DWC3 driver to access parent registers
>> via a syscon handle, addressing the v1 review comment.
>
> Syscon phandle is not to express such relationsship.
>
>>
>> However, making reg optional satisfies schema validation but fails
>> DTB checks.
>>
>> versal2.dtsi:1: Warning (simple_bus_reg):
>> /axi/mmi-usb: missing or empty reg/ranges property
>
> Yep, exactly.
>
>>
>> To fix it i think we can switch from parent/child representation to
>> flat DT representation for the Versal Gen2 platform, similar to
>> existing implementations in qcom,snps-dwc3 and Google Tensor G5 DWC3
>> bindings[1].
>>
>> The Google Tensor DWC3 binding uses a syscon phandle to access USB
>> configuration registers, which aligns well with the Versal Gen2 MMI
>
> Not true. Just read the binding. If you refer to Tensor, then to access
> A FEW configuration registers. If you refer to LGA, then it has address
> space.
>
>> USB IP, where wrapper subsystem shares a common register space for
>> USB along with other IPs.
>
>
>
>>
>> If this approach looks fine , will create binding for MMI USB using
>> this flat representation and send out next version.
>>
>> usb@fe200000 {
>> compatible = "xlnx,versal2-mmi-dwc3";
>> reg = <0xfe200000 0x40000>;
>> xlnx,usb-syscon = <&udh_slcr 0x005c 0x0070 0x00c4 0x00f8>;
>> <snip>
>> };
>
> So I am confused. We ask, since long time, to have unified child.
> Several platforms were already converted. What are you discussing with
> in such case?
>
> Are you going to have unified node or not?
>
Yes, in next version will switch to a unified node representation for
Versal Gen2 MMI USB.
Based on your feedback:
-the fake wrapper hierarchy will be removed.
-parent node without reg will be dropped.
-syscon will not be used to model hierarchy.
Instead, I will introduce a separate unified-node binding for Versal
Gen2 MMI USB where: the USB controller register space is described
directly in the USB node, auxiliary USB configuration registers in
UDH SLCR are accessed through a syscon phandle only for sideband
configuration access.
New DT representation using single unified node.
usb@0xedec0000 {
compatible = "xlnx,versal2-mmi-dwc3", "snps,dwc3";
reg = <...>;
xlnx,usb-syscon = <&udh_slcr>;
<snip>
};
Thanks,
Radhey
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox