* Re: [PATCH v8 phy-next 15/31] drm/rockchip: dw_hdmi: avoid direct dereference of phy->dev.of_node
From: Heiko Stuebner @ 2026-05-20 14:21 UTC (permalink / raw)
To: linux-phy, Vladimir Oltean
Cc: Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-scsi,
linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
UNGLinuxDriver, Sandy Huang, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter
In-Reply-To: <20260505100523.1922388-16-vladimir.oltean@nxp.com>
Hi Vladimir,
Am Dienstag, 5. Mai 2026, 12:05:07 Mitteleuropäische Sommerzeit schrieb Vladimir Oltean:
> The dw_hdmi-rockchip driver validates pixel clock rates against the
> HDMI PHY's internal clock provider on certain SoCs like RK3328.
> This is currently achieved by dereferencing hdmi->phy->dev.of_node
> to obtain the provider node, which violates the Generic PHY API's
> encapsulation (the goal is for struct phy to be an opaque pointer
> with a hidden definition, to be interacted with only using API
> functions or NULL pointer checks, for the case where optional variants
> of phy_get() did not find a PHY).
>
> Refactor dw_hdmi_rockchip_bind() to perform a manual phandle lookup
> on the "hdmi" PHY index within the controller's DT node. This provides
> a parallel path to the clock provider's OF node without relying on the
> internal structure of the struct phy handle.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> Reviewed-by: Heiko Stueber <heiko@sntech.de>
there is now already more stuff depending on this change [0], and
the change itself also is sort of independent of the whole
phy-series. And somehow this series itself sadly hasn't gotten
much review yet.
So would you be ok with me just picking this one patch for the
drm-misc-tree?
Thanks
Heiko
[0] https://lore.kernel.org/dri-devel/20260518193748.2482823-1-jonas@kwiboo.se/
^ permalink raw reply
* Re: [PATCH v4 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
From: Jason Gunthorpe @ 2026-05-20 14:20 UTC (permalink / raw)
To: Nicolin Chen
Cc: Bjorn Helgaas, will, robin.murphy, bhelgaas, 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: <ag0IkpcWvhQUfzf7@Asurada-Nvidia>
On Tue, May 19, 2026 at 06:04:18PM -0700, Nicolin Chen wrote:
> > Yeah, that's fair, so let's rename it to
> >
> > pci_translated_required()
> >
> > ie the device requires translated requests to function. This is what
> > CXL.cache implies (IIRC I was told the spec specifically says this)
> >
> > Requiring translated requests implies you have to enable ATS in the
> > system.
>
> Perhaps we could let IOMMU drivers check:
> pci_cxl_is_cache_capable() || pci_dev_specific_is_pre_cxl()
> directly?
I'd rather have a single function.
Jason
^ permalink raw reply
* Re: [PATCH v2 10/18] KVM: arm64: vgic-v5: Add missing trap handing for NV triage
From: Joey Gouly @ 2026-05-20 13:54 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-11-maz@kernel.org>
On Wed, May 20, 2026 at 10:19:41AM +0100, Marc Zyngier wrote:
> From: Sascha Bischoff <sascha.bischoff@arm.com>
>
> As things stand, there is no support for Nested Virt with GICv5 guests
> yet. However, this is coming and therefore we need to be able to
> correctly triage the traps when running with NV.
>
> Add the missing fgtreg lookups required for that to
> triage_sysreg_trap(). These are specific to the FGT regs added as part
> of GICv5:
> * ICH_HFGRTR_EL2
> * ICH_HFGWTR_EL2
> * ICH_HFGITR_EL2
>
> Fixes: 9d6d9514c08f "(KVM: arm64: gic-v5: Support GICv5 FGTs & FGUs")
> Link: https://sashiko.dev/#/patchset/20260319154937.3619520-1-sascha.bischoff%40arm.com
> Signed-off-by: Sascha Bischoff <sascha.bischoff@arm.com>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
> ---
> arch/arm64/kvm/emulate-nested.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> index dba7ced74ca5e..a4eb36b4c4421 100644
> --- a/arch/arm64/kvm/emulate-nested.c
> +++ b/arch/arm64/kvm/emulate-nested.c
> @@ -2631,6 +2631,14 @@ bool triage_sysreg_trap(struct kvm_vcpu *vcpu, int *sr_index)
> fgtreg = HFGITR2_EL2;
> break;
>
> + case ICH_HFGRTR_GROUP:
> + fgtreg = is_read ? ICH_HFGRTR_EL2 : ICH_HFGWTR_EL2;
> + break;
> +
> + case ICH_HFGITR_GROUP:
> + fgtreg = ICH_HFGITR_EL2;
> + break;
> +
> default:
> /* Something is really wrong, bail out */
> WARN_ONCE(1, "Bad FGT group (encoding %08x, config %016llx)\n",
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH 2/2] ASoC: mt8173-max98090: use standard callback to set jack
From: Mark Brown @ 2026-05-20 13:42 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: lgirdwood, perex, tiwai, matthias.bgg, angelogioacchino.delregno,
sharq0406, kuninori.morimoto.gx, ckeepax, linux-sound,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260520132930.54333-3-srinivas.kandagatla@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 255 bytes --]
On Wed, May 20, 2026 at 01:29:30PM +0000, Srinivas Kandagatla wrote:
> use snd_soc_component_set_jack() instead of custom callback to
> max98090 codec.
This needs to be squashed into the first commit, otherwise the first
commit will cause a build break.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v4 04/13] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
From: Jason Gunthorpe @ 2026-05-20 13:40 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Mostafa Saleh, iommu, linux-arm-kernel, linux-kernel, linux-coco,
Robin Murphy, Marek Szyprowski, Will Deacon, Marc Zyngier,
Steven Price, Suzuki K Poulose, Catalin Marinas, Jiri Pirko,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <yq5a5x4ispg8.fsf@kernel.org>
On Wed, May 20, 2026 at 09:27:27AM +0530, Aneesh Kumar K.V wrote:
> Jason Gunthorpe <jgg@ziepe.ca> writes:
>
> > On Tue, May 19, 2026 at 09:35:30PM +0530, Aneesh Kumar K.V wrote:
> >> Yes, that also resulted in simpler and cleaner code.
> >>
> >> swiotlb_tbl_map_single
> >> /*
> >> * If the physical address is encrypted but the device requires
> >> * decrypted DMA, use a decrypted io_tlb_mem and update the
> >> * attributes so the caller knows that a decrypted io_tlb_mem
> >> * was used.
> >> */
> >> if (!(*attrs & DMA_ATTR_CC_SHARED) && force_dma_unencrypted(dev))
> >> *attrs |= DMA_ATTR_CC_SHARED;
> >>
> >> if (mem->unencrypted != !!(*attrs & DMA_ATTR_CC_SHARED))
> >> return (phys_addr_t)DMA_MAPPING_ERROR;
> >
> > Yeah, exactly that is so much clearer now that the mem->unecrypted is
> > tied directly.
> >
> > That logic is reversed though, the incoming ATTR_CC doesn't matter for
> > swiotlb, that is just the source of the memcpy.
> >
> > /* swiotlb pool is incorrect for this device */
> > if (mem->unencrypted != force_dma_unencrypted(dev))
> > return (phys_addr_t)DMA_MAPPING_ERROR;
> >
> > /* Force attrs to match the kind of memory in the pool */
> > if (mem->unencrypted)
> > *attrs |= DMA_ATTR_CC_SHARED;
> > else
> > *attrs &= ~DMA_ATTR_CC_SHARED;
> >
> >
> > Attrs should be forced to whatever memory swiotlb selected.
> >
>
> But that will not handle a T=1 device that wants to use swiotlb to
> bounce unencrypted memory. That is:
>
> force_dma_unencrypted(dev) == 0 /* T=1 device */
> attrs = DMA_ATTR_CC_SHARED;
>
> In that case, it should use an unencrypted io_tlb_mem:
> mem->unencrypted == 1
No! The DMA_ATTR_CC_SHARED only states the nature of the source
memory, the DMA transfer will always happen under T=1
It is perfectly fine to memcpy from shared to private and do a T=1 DMA
from the private memory if we have to bounce.
Jason
^ permalink raw reply
* Re: [PATCH v3 3/3] hwmon: raspberrypi: Fix delayed-work teardown race
From: Guenter Roeck @ 2026-05-20 13:39 UTC (permalink / raw)
To: Shubham Chakraborty
Cc: Florian Fainelli, Jonathan Corbet, Shuah Khan,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
linux-hwmon, linux-doc, linux-rpi-kernel, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260517080445.103962-4-chakrabortyshubham66@gmail.com>
On Sun, May 17, 2026 at 01:34:45PM +0530, Shubham Chakraborty wrote:
> The delayed polling work rearms itself from the work function, so use
> explicit delayed-work setup and cleanup instead of
> devm_delayed_work_autocancel().
>
> Initialize the delayed work with INIT_DELAYED_WORK() and register a
> devres cleanup action that calls disable_delayed_work_sync() during
> teardown.
>
> This addresses the concern raised during review about the polling work
> being able to requeue itself while the driver is being removed.
>
> Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
Applied.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v3 2/3] hwmon: raspberrypi: Add voltage input support
From: Guenter Roeck @ 2026-05-20 13:37 UTC (permalink / raw)
To: Shubham Chakraborty
Cc: Florian Fainelli, Jonathan Corbet, Shuah Khan,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
linux-hwmon, linux-doc, linux-rpi-kernel, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260517080445.103962-3-chakrabortyshubham66@gmail.com>
On Sun, May 17, 2026 at 01:34:44PM +0530, Shubham Chakraborty wrote:
> Extend the raspberrypi-hwmon driver to expose firmware-provided
> voltage measurements through the hwmon subsystem.
>
> The driver now exports the following voltage inputs:
>
> - in0_input (core)
> - in1_input (sdram_c)
> - in2_input (sdram_i)
> - in3_input (sdram_p)
>
> Voltage values returned by firmware are converted from microvolts
> to millivolts as expected by the hwmon subsystem.
>
> Update the documentation related to it.
>
> The existing undervoltage sticky alarm handling is preserved and
> associated with the first voltage channel.
>
> Tested in -
> - Raspberry Pi 3b+ (Linux raspberrypi 6.12.75+rpt-rpi-v8 #1 SMP PREEMPT
> Debian 1:6.12.75-1+rpt1 (2026-03-11) aarch64 GNU/Linux)
>
> Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
> Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Applied, after fixing:
WARNING: Missing a blank line after declarations
#207: FILE: drivers/hwmon/raspberrypi-hwmon.c:74:
+ int ret;
+ ret = rpi_firmware_property(data->fw, RPI_FIRMWARE_GET_VOLTAGE,
Please run checkpatch on your patches.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v3 1/3] soc: bcm2835: raspberrypi-firmware: Add voltage domain IDs
From: Guenter Roeck @ 2026-05-20 13:35 UTC (permalink / raw)
To: Shubham Chakraborty
Cc: Florian Fainelli, Jonathan Corbet, Shuah Khan,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
linux-hwmon, linux-doc, linux-rpi-kernel, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260517080445.103962-2-chakrabortyshubham66@gmail.com>
On Sun, May 17, 2026 at 01:34:43PM +0530, Shubham Chakraborty wrote:
> Add Raspberry Pi firmware voltage domain identifiers for the mailbox
> property interface.
>
> Also add the voltage request structure used with
> RPI_FIRMWARE_GET_VOLTAGE so firmware clients can share the common API
> definition from the firmware header.
>
> Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
> Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
Applied.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v02] mailbox: pcc: report errors for PCC clients
From: Sudeep Holla @ 2026-05-20 13:32 UTC (permalink / raw)
To: lihuisong (C)
Cc: Adam Young, Jassi Brar, linux-kernel, Sudeep Holla, linux-hwmon,
Rafael J . Wysocki, Len Brown, linux-acpi, Andi Shyti,
Guenter Roeck, MyungJoo Ham, Kyungmin Park, Chanwoo Choi,
linux-arm-kernel
In-Reply-To: <d719462f-3430-47c1-9b9d-1068b3c4e429@huawei.com>
On Wed, May 20, 2026 at 07:53:45PM +0800, lihuisong (C) wrote:
>
> On 5/20/2026 12:25 AM, Sudeep Holla wrote:
> > On Tue, May 19, 2026 at 09:54:47PM +0800, lihuisong (C) wrote:
[...]
> > > @Sudeep, I have always had doubts about the addition of this line of code in
> > > the
> > > commit 9c753f7c953c (mailbox: pcc: Mark Tx as complete in PCC IRQ handler).
> > > The patch seems to avoid the timeouts in the mailbox core according to its
> > > commit log.
> > > Regardless of whether the command succeeds or fails, each mbox client
> > > driver, like cppc_acpi/acpi_pcc，kunpeng_hccs and so on, is responsible to
> > > call mbox_chan_txdone() to tell mailbox core.
> > Few controller drivers do have mbox_chan_txdone(), so Tx complete is detected
> Which controller driver?
git grep mbox_chan_txdone drivers/mailbox/
> > by PCC, so not sure why you think this is not the right place to do. The irq
> Because many mbox client drivers call mbox_chan_txdone() after running
> rx_callback() in mbox_chan_received_data().
OK, but why can't the controller hide that for the clients ? What am I missing?
> These drivers doesn't set chan->cl->tx_block to true.
> It seems that the client driver having tx_block need to set
> chan->tx_complete in tx_tick().
> Do you add this code for them?
I don't quite follow you.
> > is to indicate the completion. I am confused as why you think otherwise.
> > It is defined in include/linux/mailbox_controller.h for the same reason.
> >
> > The client drivers can you mbox_client_txdone() if they wish to as defined
> > in include/linux/mailbox_client.h
> mbox_client_txdone() is used in the case that txdone_method is
> MBOX_TXDONE_BY_ACK.
Yes and agreed.
> And mbox clinte driver using IRQ method need to use mbox_chan_txdone().
Client doesn't handle IRQ its always controller driver and client must have
no business to do that IMO.
> It seems that all the current client drivers are used in this way.
> These interface internal would verify chan->txdone_method.
>
Yes, sounds wrong to me.
drivers/acpi/acpi_pcc.c
drivers/acpi/cppc_acpi.c
drivers/hwmon/xgene-hwmon.c
drivers/i2c/busses/i2c-xgene-slimpro.c
drivers/soc/hisilicon/kunpeng_hccs.c
It is very clear from the code in mailbox.c, mbox_client_txdone() is for
the client drivers and mbox_chan_txdone() is for the controller. We need
to fix the above list but I need to check if there is anything I am missing
to understand first. Please let me know.
> In addition, I find that you also modify the txdone_irq/poll in the commit
> 3349f800609e (mailbox: pcc: Set txdone_irq/txdone_poll based on PCCT flags).
> The txdone_method will change from MBOX_TXDONE_BY_ACK to MBOX_TXDONE_BY_POLL
> on the platform using poll mode.
> This may lead to the original mbox client driver printing exceptions in
> mbox_client_txdone.
> I haven't observed it based on the latest code yet, it's just code analysis.
Right, I do remember seeing something and wonder if I moved to
mbox_chan_txdone() in drivers/acpi/acpi_pcc.c for that reason. But if the
expectations I have mentioned are correct, then we need to fix the framework
to avoid throwing that warnings.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH 2/2] ASoC: mt8173-max98090: use standard callback to set jack
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>
use snd_soc_component_set_jack() instead of custom callback to
max98090 codec.
This will help other drivers using the standard callback to exercise
the standard path instead of custom callback.
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
---
sound/soc/mediatek/mt8173/mt8173-max98090.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/sound/soc/mediatek/mt8173/mt8173-max98090.c b/sound/soc/mediatek/mt8173/mt8173-max98090.c
index 49ebb67c818a..236e1f8df45a 100644
--- a/sound/soc/mediatek/mt8173/mt8173-max98090.c
+++ b/sound/soc/mediatek/mt8173/mt8173-max98090.c
@@ -9,7 +9,6 @@
#include <linux/module.h>
#include <sound/soc.h>
#include <sound/jack.h>
-#include "../../codecs/max98090.h"
static struct snd_soc_jack mt8173_max98090_jack;
@@ -78,7 +77,7 @@ static int mt8173_max98090_init(struct snd_soc_pcm_runtime *runtime)
return ret;
}
- return max98090_mic_detect(component, &mt8173_max98090_jack);
+ return snd_soc_component_set_jack(component, &mt8173_max98090_jack);
}
SND_SOC_DAILINK_DEFS(playback,
--
2.47.3
^ permalink raw reply related
* [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
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