* Re: [PATCH v2] KVM: arm64: Don't populate TPIDR_EL2 in finalise_el2()
From: Marc Zyngier @ 2026-05-18 15:39 UTC (permalink / raw)
To: Will Deacon
Cc: kvmarm, linux-arm-kernel, Oliver Upton, Catalin Marinas,
Mark Rutland
In-Reply-To: <20260518153127.6078-1-will@kernel.org>
On Mon, 18 May 2026 16:31:26 +0100,
Will Deacon <will@kernel.org> wrote:
>
> Currently, it is not necessary for __finalise_el2() to configure
> TPIDR_EL2:
>
> * The hyp stub code does not consume the value of TPIDR_EL2.
>
> * On the boot cpu, TPIDR_EL1 is used for the percpu offset until the
> ARM64_HAS_VIRT_HOST_EXTN cpucap is detected and boot alternatives
> are patched. Before boot alternatives are patched,
> cpu_copy_el2regs() will copy TPIDR_EL1 into TPIDR_EL2. It is not
> necessary for __finalise_el2() to initialise TPIDR_EL2 before this.
>
> * Secondary CPUs are brought up after boot alternatives have been
> patched, and __secondary_switched() will initialize TPIDR_EL2 in
> 'init_cpu_task', after finalise_el2() calls __finalise_el2()
>
> * KVM hyp code which may consume TPIDR_EL2 is brought up after all
> secondaries have been booted, once TPIDR_El2 has been configured on
> all CPUs.
>
> Remove the redundant initialisation from __finalise_el2().
>
> Cc: Oliver Upton <oupton@kernel.org>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Will Deacon <will@kernel.org>
Reviewed-by: Marc Zyngier <maz@kernel.org>
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v2] KVM: arm64: Don't populate TPIDR_EL2 in finalise_el2()
From: Marc Zyngier @ 2026-05-18 15:41 UTC (permalink / raw)
To: Will Deacon
Cc: kvmarm, linux-arm-kernel, Oliver Upton, Catalin Marinas,
Mark Rutland
In-Reply-To: <86y0hgwwul.wl-maz@kernel.org>
On Mon, 18 May 2026 16:39:30 +0100,
Marc Zyngier <maz@kernel.org> wrote:
>
> On Mon, 18 May 2026 16:31:26 +0100,
> Will Deacon <will@kernel.org> wrote:
> >
> > Currently, it is not necessary for __finalise_el2() to configure
> > TPIDR_EL2:
> >
> > * The hyp stub code does not consume the value of TPIDR_EL2.
> >
> > * On the boot cpu, TPIDR_EL1 is used for the percpu offset until the
> > ARM64_HAS_VIRT_HOST_EXTN cpucap is detected and boot alternatives
> > are patched. Before boot alternatives are patched,
> > cpu_copy_el2regs() will copy TPIDR_EL1 into TPIDR_EL2. It is not
> > necessary for __finalise_el2() to initialise TPIDR_EL2 before this.
> >
> > * Secondary CPUs are brought up after boot alternatives have been
> > patched, and __secondary_switched() will initialize TPIDR_EL2 in
> > 'init_cpu_task', after finalise_el2() calls __finalise_el2()
> >
> > * KVM hyp code which may consume TPIDR_EL2 is brought up after all
> > secondaries have been booted, once TPIDR_El2 has been configured on
> > all CPUs.
> >
> > Remove the redundant initialisation from __finalise_el2().
> >
> > Cc: Oliver Upton <oupton@kernel.org>
> > Cc: Marc Zyngier <maz@kernel.org>
> > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> > Signed-off-by: Will Deacon <will@kernel.org>
>
> Reviewed-by: Marc Zyngier <maz@kernel.org>
Ah, realised too late you intended for this to go via the KVM tree.
I'll queue that for 7.2.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH 0/8] iio: timestamp declaration cleanup
From: Jonathan Cameron @ 2026-05-18 15:44 UTC (permalink / raw)
To: David Lechner
Cc: Andy Shevchenko, Jyoti Bhayana, Nuno Sá, Andy Shevchenko,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea, Maxime Coquelin,
Alexandre Torgue, Benson Leung, Guenter Roeck, linux-iio,
linux-kernel, linux-arm-kernel, linux-stm32, chrome-platform
In-Reply-To: <41c0317d-2ce8-412c-818a-4a84201fce29@baylibre.com>
On Mon, 18 May 2026 09:34:48 -0500
David Lechner <dlechner@baylibre.com> wrote:
> On 5/18/26 2:14 AM, Andy Shevchenko wrote:
> > On Mon, May 18, 2026 at 10:09:48AM +0300, Andy Shevchenko wrote:
> >> On Sun, May 17, 2026 at 01:17:17PM -0500, David Lechner wrote:
> >>> While looking around the code, I noticed that there are a lot of places
> >>> were we are manually filling all of the fields of an IIO timestamp.
> >>>
> >>> This is error-prone (as seen in the first patch) and more verbose than
> >>> it needs to be.
> >>>
> >>> I went with the approach of using the existing IIO_CHAN_SOFT_TIMESTAMP()
> >>> macro for doing a struct assignment. This does require a cast, which
> >>
> >> No, it's *not* a cast. It's a compound literal. And instead of doing this in
> >> every driver, add it to the macro (in a separate patch). Oh, let me just cook
> >> it for you (I added that to several cases in the past).
> >
> > 20260518071349.469748-1-andriy.shevchenko@linux.intel.com
>
> Nice, thanks. I agree this will be the cleanest solution.
With that the series looks good to me.
J
>
> >
> >>> makes it a bit more verbose, but we were already doing that in to
> >>> drivers, so I went with it anyway.
> >>
> >>> If we want to consider alternatives, we could make a iio helper function
> >>> or macro like the first and second patches did.
> >
>
^ permalink raw reply
* Re: [PATCH 2/5] arm/pci: Use official API to iterate over PCI buses
From: Gerd Bayer @ 2026-05-18 15:45 UTC (permalink / raw)
To: Russell King
Cc: Yinghai Lu, linux-alpha, linux-kernel, linux-arm-kernel,
linuxppc-dev, linux-pci, Richard Henderson, Matt Turner,
Magnus Lindholm, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Bjorn Helgaas,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Gerd Bayer
In-Reply-To: <20260515-priv_root_buses-v1-2-f8e393c57390@linux.ibm.com>
On Fri, 2026-05-15 at 16:22 +0200, Gerd Bayer wrote:
> Replace iterating over pci_root_buses with the official
> pci_find_next_bus() call provided by PCI core. This allows to make
> pci_root_buses private to PCI core.
>
> Signed-off-by: Gerd Bayer <gbayer@linux.ibm.com>
> ---
> arch/arm/kernel/bios32.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
> index ac0e890510da..35642c9ba054 100644
> --- a/arch/arm/kernel/bios32.c
> +++ b/arch/arm/kernel/bios32.c
> @@ -59,9 +59,9 @@ static void pcibios_bus_report_status(struct pci_bus *bus, u_int status_mask, in
>
> void pcibios_report_status(u_int status_mask, int warn)
> {
> - struct pci_bus *bus;
> + struct pci_bus *bus = NULL;
>
> - list_for_each_entry(bus, &pci_root_buses, node)
> + while ((bus = pci_find_next_bus(bus)) != NULL)
> pcibios_bus_report_status(bus, status_mask, warn);
> }
>
Hi Russell,
Sashiko
https://sashiko.dev/#/message/20260515145940.E85AAC2BCB0%40smtp.kernel.org
reported:
> Since pci_find_next_bus() unconditionally acquires the pci_bus_sem read-write
> semaphore using down_read(), this introduces a blocking operation into that
> atomic path:
>
> dc21285_abort_irq() [hardirq context]
> pcibios_report_status()
> pci_find_next_bus()
> down_read(&pci_bus_sem) [sleeps]
>
> Does this path need an alternative approach to safely iterate over the buses
> without taking a sleeping lock?
IMHO, it looks like this entire pcibios_report_status() iterating over
all PCI buses and all their devices would be better off if moved
outside of the hardirq context?
Or could pcibios_report_status() be converted to use
for_each_pci_device()?
Any suggestions welcome...
Gerd
^ permalink raw reply
* Re: [PATCH 0/3] iommu: Add PCI vendor:device ID to IOMMU fault logs
From: Robin Murphy @ 2026-05-18 15:52 UTC (permalink / raw)
To: Oguz, Yigit, joro@8bytes.org, will@kernel.org,
baolu.lu@linux.intel.com, dwmw2@infradead.org,
suravee.suthikulpanit@amd.com
Cc: jgg@ziepe.ca, nicolinc@nvidia.com, iommu@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <C1C278E8-E5F6-4701-9127-DCDBC64636E1@amazon.de>
On 18/05/2026 4:19 pm, Oguz, Yigit wrote:
> On 2026-05-08, Robin Murphy wrote:
>> Sorry, but why are unexpected DMA faults happening "at scale" in the
>> first place? If you have so many broken drivers that disambiguating them
>> needs help from the kernel, something seems fundamentally wrong with
>> that picture. Conversely if these are devices assigned to userspace then
>> we should perhaps reconsider their ability to spam up the host kernel
>> log at will anyway.
>
> The use case is VFIO passthrough environments where translation faults
> show up during device lifecycle operations, mainly around device reset.
> When mappings are torn down and a device still has DMA in flight or
> issues DMA during/after FLR, the IOMMU blocks it and logs the fault.
> This series doesn't change when or whether events get logged, it just
> makes the existing lines more useful for triage when they do fire.
>
>> I'm not saying I necessarily have anything against this change in
>> particular, but it has a strong smell of effort being spent on the wrong
>> thing...
>
> Fair point. Whether the faults themselves should be addressed is a
> separate question, but since the kernel already logs them unconditionally,
> making the output more immediately useful seemed like low-hanging fruit.
TBH I think the more appropriate solution would be to have vfio-pci
register its own fault handler, wherein it can properly deal with
rate-limiting and/or entirely suppressing fault reports from misbehaving
userspace, and if and when it does want to log something it is then free
to do that in whatever format it wants, independent of the underlying
IOMMU driver.
Thanks,
Robin.
>> (And even then AFAICS it only really helps in the specific scenario of
>> having only one of each type of device, otherwise you're back to still
>> needing per-system knowledge of how BDFs map to physical instances to
>> know what's what.)
>
> The vendor:device ID answers the first question in triage: "what kind of
> device is this?" Even with multiple instances of the same type, narrowing
> by type cuts down the search space when correlating faults with device
> lifecycle events.
>
> Thanks,
> Yigit
>
>
> On 2026-05-06 4:05 pm, Yigit Oguz wrote:
>> IOMMU fault and event logs currently identify devices using only their
>> PCI segment/bus/device/function (SSSS:BB:DD.F). While mapping a single
>> BDF to a device type is straightforward, doing so at scale across many
>> hosts and thousands of fault events requires additional tooling and
>> manual cross-referencing. Including the vendor:device ID directly in
>> the log line makes each event self-contained and immediately actionable
>> without any post-processing.
>
>
> Sorry, but why are unexpected DMA faults happening "at scale" in the
> first place? If you have so many broken drivers that disambiguating them
> needs help from the kernel, something seems fundamentally wrong with
> that picture. Conversely if these are devices assigned to userspace then
> we should perhaps reconsider their ability to spam up the host kernel
> log at will anyway.
>
>
> I'm not saying I necessarily have anything against this change in
> particular, but it has a strong smell of effort being spent on the wrong
> thing...
>
>
> (And even then AFAICS it only really helps in the specific scenario of
> having only one of each type of device, otherwise you're back to still
> needing per-system knowledge of how BDFs map to physical instances to
> know what's what.)
>
>
> Thanks,
> Robin.
>
>
>> This series adds vendor:device ID (VVVV:DDDD) to IOMMU event logs for
>> ARM SMMUv3, Intel VT-d and AMD IOMMU.
>>
>> Before:
>> arm-smmu-v3 arm-smmu-v3.0.auto: event: F_TRANSLATION client: 0000:2b:11.6
>> sid: 0x158e ssid: 0x0 iova: 0x280000000000 ipa: 0x0
>> DMAR: [DMA Write NO_PASID] Request device [86:00.0] fault addr 0xe0000000
>> [fault reason 0x05] PTE Write access is not set
>> AMD-Vi: Event logged [IO_PAGE_FAULT device=0000:41:00.0 domain=0x000a
>> address=0xe0000000 flags=0x0020]
>>
>> After:
>> arm-smmu-v3 arm-smmu-v3.0.auto: event: F_TRANSLATION client: 0000:2b:11.6 [8086:1533]
>> sid: 0x158e ssid: 0x0 iova: 0x280000000000 ipa: 0x0
>> DMAR: [DMA Write NO_PASID] Request device [0000:86:00.0 8086:1533] fault addr 0xe0000000
>> [fault reason 0x05] PTE Write access is not set
>> AMD-Vi: Event logged [IO_PAGE_FAULT device=0000:41:00.0 8086:1533 domain=0x000a
>> address=0xe0000000 flags=0x0020]
>>
>> Patch 1 adds vendor:device ID to ARM SMMUv3 translation fault logs.
>> Patch 2 adds PCI segment and vendor:device ID to Intel VT-d DMAR
>> fault logs.
>> Patch 3 adds a devid_str helper and vendor:device ID to all AMD IOMMU
>> event log paths.
>>
>> Testing:
>> Build-tested against mainline Linux (torvalds/master).
>>
>> Runtime-tested on a custom downstream branch on ARM SMMUv3, Intel VT-d and
>> AMD IOMMU hosts. Translation faults were induced in a virtualized setup
>> by removing DMA mappings for an in-use region, causing the assigned device's
>> subsequent DMA transactions to hit unmapped IOVAs and produce
>> translation fault events. The resulting log lines were verified to
>> contain the PCI vendor:device ID on all three platforms.
>>
>> Lilit Janpoladyan (1):
>> iommu/arm-smmu-v3: Print PCI vendor:device ID in SMMU translation
>> fault logs
>>
>> Yigit Oguz (2):
>> iommu/vt-d: Add PCI segment and vendor:device ID to DMAR fault logs
>> iommu/amd: Add vendor:device ID to AMD IOMMU event logs
>>
>> drivers/iommu/amd/iommu.c | 94 +++++++++++++--------
>> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 29 ++++++-
>> drivers/iommu/intel/dmar.c | 33 +++++---
>> 3 files changed, 104 insertions(+), 52 deletions(-)
>>
>
>
>
>
>
>
>
>
> Amazon Web Services Development Center Germany GmbH
> Tamara-Danz-Str. 13
> 10243 Berlin
> Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
> Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
> Sitz: Berlin
> Ust-ID: DE 365 538 597
^ permalink raw reply
* Re: [RFC PATCH v4 00/14] coco/TSM: Host-side Arm CCA IDE setup via connect/disconnect callbacks
From: Aneesh Kumar K.V @ 2026-05-18 15:53 UTC (permalink / raw)
To: Will Deacon
Cc: linux-coco, kvmarm, linux-arm-kernel, linux-kernel,
Alexey Kardashevskiy, Catalin Marinas, Dan Williams,
Jason Gunthorpe, Jonathan Cameron, Marc Zyngier, Samuel Ortiz,
Steven Price, Suzuki K Poulose, Xu Yilun
In-Reply-To: <agsNO9cc7H-b0H8L@willie-the-truck>
Will Deacon <will@kernel.org> writes:
> On Mon, Apr 27, 2026 at 12:21:07PM +0530, Aneesh Kumar K.V (Arm) wrote:
>> arch/arm64/include/asm/rmi_cmds.h | 85 +++
>> arch/arm64/include/asm/rmi_smc.h | 168 +++++
>
> Curious, but why does this stuff have to live in the arch code? Wouldn't
> it be better off somewhere like drivers/firmware/ or
> include/linux/arm-rmi.h?
>
Those headers are used to collect all RMI-related helpers and #defines.
They were introduced by the Realm KVM/host support patch series, and I
am continuing to use the same headers to add more helpers.
We can consider moving the RMI helpers used by virt/coco/arm-caa-guest/,
virt/coco/arm-cca-host/, and
drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-realm.c into a more generic
header such as include/linux/arm-rmi.h. However, that would either
require moving all the helpers currently used by KVM there as well,
otherwise we would end up with two separate headers carrying RMI
helpers.
Additionally, there are also arch/arm64/include/asm/rsi_cmds.h and
arch/arm64/include/asm/rsi_smc.h to consider.
-aneesh
^ permalink raw reply
* Re: [PATCH v3 2/2] mailbox: exynos: Add support for Exynos850 mailbox
From: Alexey Klimov @ 2026-05-18 15:53 UTC (permalink / raw)
To: Tudor Ambarus, Krzysztof Kozlowski, Sam Protsenko, Rob Herring,
Conor Dooley, Jassi Brar, Alim Akhtar
Cc: Krzysztof Kozlowski, Peter Griffin, linux-samsung-soc,
linux-arm-kernel, devicetree, linux-kernel, Krzysztof Kozlowski,
Juan Yescas
In-Reply-To: <9b6fce56-6a94-44fe-ab55-5394ec6065e4@linaro.org>
On Thu Apr 30, 2026 at 12:01 PM BST, Tudor Ambarus wrote:
> Hi, Alexey,
Hi Tudor,
> The abstraction is clean. Few comments below.
>
> On 4/29/26 10:00 PM, Alexey Klimov wrote:
>> Exynos850-based platforms support ACPM and has similar workflow
>> of communicating with ACPM via mailbox, however mailbox controller
>> registers are located at different offsets and writes/reads could be
>> different. To distinguish between such different behaviours,
>> the registers offsets for Exynos850 and the platform-specific data
>> structs are introduced and configuration is described in such structs
>> for gs101 and exynos850 based SoCs. Probe routine now selects the
>> corresponding platform-specific data via device_get_match_data().
>>
>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
>> ---
>> drivers/mailbox/exynos-mailbox.c | 59 ++++++++++++++++++++++++++++++++++++++--
>> 1 file changed, 56 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/mailbox/exynos-mailbox.c b/drivers/mailbox/exynos-mailbox.c
>> index d2355b128ba4..11657dd475c0 100644
>> --- a/drivers/mailbox/exynos-mailbox.c
>> +++ b/drivers/mailbox/exynos-mailbox.c
>> @@ -31,14 +31,52 @@
>>
>> #define EXYNOS_MBOX_CHAN_COUNT HWEIGHT32(EXYNOS_MBOX_INTGR1_MASK)
>>
>> +#define EXYNOS850_MBOX_INTGR0 0x8 /* Interrupt Generation Register 0 */
>> +#define EXYNOS850_MBOX_INTMR1 0x24 /* Interrupt Mask Register 1 */
>> +
>> +#define EXYNOS850_MBOX_INTMR1_MASK GENMASK(15, 0)
>> +
>> +/**
>> + * struct exynos_mbox_driver_data - platform-specific mailbox configuration.
>> + * @intgr: offset to the IRQ generation register, doorbell
>> + * to APM co-processor.
>> + * @intgr_shift: shift to apply to the value written to IRQ generation
>> + * register.
>> + * @intmr: offset to the IRQ mask register.
>> + * @intmr_mask: value to write to the mask register to mask out all
>> + * interrupts.
>> + */
>> +struct exynos_mbox_driver_data {
>> + u16 intgr;
>> + u16 intgr_shift;
>> + u16 intmr;
>> + u16 intmr_mask;
>> +};
>
> using u16 for intmr_mask is slightly problematic. Down in the probe
> function, you pass it to writel():
> writel(data->intmr_mask, exynos_mbox->regs + data->intmr);
>
> writel() explicitly expects a 32-bit (u32) value. While the compiler will
> implicitly promote the u16 to a 32-bit integer, memory-mapped I/O masks
> should generally match the width of the register being written to. If a
> future SoC requires a 32-bit mask (e.g., GENMASK(31, 0)), the u16 will
> silently truncate it.
>
> u32 for all fields is generally preferred in kernel platform data structs
> for padding/alignment reasons.
Sure. Thanks. I can switch it to u32.
>> /**
>> * struct exynos_mbox - driver's private data.
>> * @regs: mailbox registers base address.
>> * @mbox: pointer to the mailbox controller.
>> + * @data: pointer to driver platform-specific data.
>> */
>> struct exynos_mbox {
>> void __iomem *regs;
>> struct mbox_controller *mbox;
>> + const struct exynos_mbox_driver_data *data;
>> +};
>> +
>> +static const struct exynos_mbox_driver_data exynos850_mbox_data = {
>> + .intgr = EXYNOS850_MBOX_INTGR0,
>> + .intgr_shift = 16,
>> + .intmr = EXYNOS850_MBOX_INTMR1,
>> + .intmr_mask = EXYNOS850_MBOX_INTMR1_MASK,
>> +};
>> +
>> +static const struct exynos_mbox_driver_data exynos_gs101_mbox_data = {
>> + .intgr = EXYNOS_MBOX_INTGR1,
>> + .intgr_shift = 0,
>> + .intmr = EXYNOS_MBOX_INTMR0,
>> + .intmr_mask = EXYNOS_MBOX_INTMR0_MASK,
>> };
>>
>> static int exynos_mbox_send_data(struct mbox_chan *chan, void *data)
>> @@ -57,7 +95,9 @@ static int exynos_mbox_send_data(struct mbox_chan *chan, void *data)
>> return -EINVAL;
>> }
>>
>> - writel(BIT(msg->chan_id), exynos_mbox->regs + EXYNOS_MBOX_INTGR1);
>> + /* Ring the doorbell */
>> + writel(BIT(msg->chan_id) << exynos_mbox->data->intgr_shift,
>> + exynos_mbox->regs + exynos_mbox->data->intgr);
>>
>> return 0;
>> }
>> @@ -87,13 +127,21 @@ static struct mbox_chan *exynos_mbox_of_xlate(struct mbox_controller *mbox,
>> }
>>
>> static const struct of_device_id exynos_mbox_match[] = {
>> - { .compatible = "google,gs101-mbox" },
>> + {
>> + .compatible = "google,gs101-mbox",
>> + .data = &exynos_gs101_mbox_data
>> + },
>> + {
>> + .compatible = "samsung,exynos850-mbox",
>> + .data = &exynos850_mbox_data
>> + },
>> {},
>> };
>> MODULE_DEVICE_TABLE(of, exynos_mbox_match);
>>
>> static int exynos_mbox_probe(struct platform_device *pdev)
>> {
>> + const struct exynos_mbox_driver_data *data;
>> struct device *dev = &pdev->dev;
>> struct exynos_mbox *exynos_mbox;
>> struct mbox_controller *mbox;
>> @@ -122,6 +170,11 @@ static int exynos_mbox_probe(struct platform_device *pdev)
>> return dev_err_probe(dev, PTR_ERR(pclk),
>> "Failed to enable clock.\n");
>>
>> + data = device_get_match_data(&pdev->dev);
>> + if (!data)
>> + return -ENODEV;
>
> you shall move this first thing in probe() to avoid doing allocations
> gratuitously on null match data.
Ack.
>> +
>> + exynos_mbox->data = data;
>> mbox->num_chans = EXYNOS_MBOX_CHAN_COUNT;
>
> EXYNOS_MBOX_CHAN_COUNT is globally defined as:
> #define EXYNOS_MBOX_CHAN_COUNT HWEIGHT32(EXYNOS_MBOX_INTGR1_MASK)
>
> Does the Exynos850 have the exact same number of channels as the GS101?
>
> You may move num_chans into struct exynos_mbox_driver_data alongside the
> register offsets so each SoC explicitly declares its channel capacity.
Here:
=> md 2040000 <--- sram_base + initdata_base
02040000: 000063bc 00000007 0000650c 00000013 .c.......e......
02040010: 00000000 00000007 0000000b 0000000e ................
^^^^
02040020: 00000000 00000000 00000013 00000009 ................
02040030: 00008000 00008008 0000800c 00008010 ................
02040040: 00000010 0000017f 00007800 00000080 .........x......
02040050: 0001f800 00004000 00000300 00000010 .....@..........
02040060: 66633931 20613261 65766164 00383130 19cfa2a dave018.
02040070: 00000000 00000000 3a393000 353a3133 .........09:31:5
02040080: 65462034 31312062 32303220 00000030 4 Feb 11 2020...
02040090: 00000000 0000001b 00000002 00ff00df ................
So it looks like the ipc_ap_max field is equal to 0xb.
[ 12.972113] exynos-acpm-protocol firmware:power-management: calling acpm_channels_init
[ 12.972216] acpm_channels_init: acpm->num_chans=b.
[ 12.975541] exynos-acpm-protocol firmware:power-management: ID = 0 poll = 1, mlen = 16, qlen = 15
[ 12.976522] exynos-acpm-protocol firmware:power-management: calling acpm_channels_init
[ 12.979336] acpm_channels_init: acpm->num_chans=b.
[ 12.984133] exynos-acpm-protocol firmware:power-management: ID = 0 poll = 1, mlen = 16, qlen = 15
[ 12.993849] exynos-acpm-protocol firmware:power-management: ID = 1 poll = 1, mlen = 16, qlen = 3
[ 13.001756] exynos-acpm-protocol firmware:power-management: ID = 2 poll = 1, mlen = 16, qlen = 5
[ 13.010519] exynos-acpm-protocol firmware:power-management: ID = 3 poll = 0, mlen = 16, qlen = 1
[ 13.019317] exynos-acpm-protocol firmware:power-management: ID = 4 poll = 1, mlen = 16, qlen = 3
[ 13.028073] exynos-acpm-protocol firmware:power-management: ID = 5 poll = 0, mlen = 16, qlen = 1
[ 13.036805] exynos-acpm-protocol firmware:power-management: ID = 6 poll = 0, mlen = 16, qlen = 1
[ 13.050945] exynos-acpm-protocol firmware:power-management: ID = 7 poll = 1, mlen = 2, qlen = 1
[ 13.065791] exynos-acpm-protocol firmware:power-management: ID = 8 poll = 1, mlen = 2, qlen = 1
[ 13.079592] exynos-acpm-protocol firmware:power-management: ID = 9 poll = 1, mlen = 16, qlen = 7
[ 13.088398] exynos-acpm-protocol firmware:power-management: ID = 10 poll = 1, mlen = 8, qlen = 1
That's what sram + initdata provides but I guess these are implemented
number of channels of ACPM firmware (when APM communicates with AP CPU).
The mailbox hardware register though can process or consume 16 bits or
in other words HWEIGHT32(GENMASK(15, 0)). I guess this field should
indicate hardware capability of mbox hardware like max number of
possible channels? I'll change the code to use HWEIGHT32(mask) of
corresponding register then.
Or should there be a call to acpm firmware driver to query the number
of channels? Or should we get it from device tree?
Does gs101 have less than 16 number of ACPM ap channels?
Best regards,
Alexey
^ permalink raw reply
* Re: [PATCH v2] KVM: arm64: Don't populate TPIDR_EL2 in finalise_el2()
From: Will Deacon @ 2026-05-18 15:55 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, linux-arm-kernel, Oliver Upton, Catalin Marinas,
Mark Rutland
In-Reply-To: <86wlx0wwro.wl-maz@kernel.org>
On Mon, May 18, 2026 at 04:41:15PM +0100, Marc Zyngier wrote:
> On Mon, 18 May 2026 16:39:30 +0100,
> Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Mon, 18 May 2026 16:31:26 +0100,
> > Will Deacon <will@kernel.org> wrote:
> > >
> > > Currently, it is not necessary for __finalise_el2() to configure
> > > TPIDR_EL2:
> > >
> > > * The hyp stub code does not consume the value of TPIDR_EL2.
> > >
> > > * On the boot cpu, TPIDR_EL1 is used for the percpu offset until the
> > > ARM64_HAS_VIRT_HOST_EXTN cpucap is detected and boot alternatives
> > > are patched. Before boot alternatives are patched,
> > > cpu_copy_el2regs() will copy TPIDR_EL1 into TPIDR_EL2. It is not
> > > necessary for __finalise_el2() to initialise TPIDR_EL2 before this.
> > >
> > > * Secondary CPUs are brought up after boot alternatives have been
> > > patched, and __secondary_switched() will initialize TPIDR_EL2 in
> > > 'init_cpu_task', after finalise_el2() calls __finalise_el2()
> > >
> > > * KVM hyp code which may consume TPIDR_EL2 is brought up after all
> > > secondaries have been booted, once TPIDR_El2 has been configured on
> > > all CPUs.
> > >
> > > Remove the redundant initialisation from __finalise_el2().
> > >
> > > Cc: Oliver Upton <oupton@kernel.org>
> > > Cc: Marc Zyngier <maz@kernel.org>
> > > Cc: Catalin Marinas <catalin.marinas@arm.com>
> > > Reviewed-by: Mark Rutland <mark.rutland@arm.com>
> > > Signed-off-by: Will Deacon <will@kernel.org>
> >
> > Reviewed-by: Marc Zyngier <maz@kernel.org>
>
> Ah, realised too late you intended for this to go via the KVM tree.
>
> I'll queue that for 7.2.
Thanks, Marc!
Will
^ permalink raw reply
* [PATCH v9 0/2] arm64/sve: Performance improvements with SVE state saving
From: Mark Brown @ 2026-05-18 16:11 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Rutland, Ryan Roberts, linux-arm-kernel, linux-kernel,
Mark Brown
This series aims to improve our handling of SVE access traps and state
clearing. As SVE deployment progresses both hardware and software
actively using SVE is becoming more common. When a task is using SVE it
faces additional costs, the floating point state we must track is larger
and our syscall ABI requires that the extra state is cleared on every
syscall. Users have measured these overheads and raised concerns about
them.
We can avoid these costs by reenabling SVE access traps and falling back
to FPSIMD only mode but if we do this too often for tasks that are
actively using SVE the cost of the access traps becomes prohibitive.
Currently we attempt to balance the tradeoffs here by starting tasks
with SVE disabled, enabling it on first use and then turning it off if
we need to load state from memory while the task is in a syscall. This
means that CPU bound tasks that do not regularly do blocking syscalls
will rarely drop SVE while tasks that use a lot of SVE but do block in
syscalls (eg, due to network or user interaction) will be much more
likely to do and hence incur SVE access traps.
I did some instrumentation which counted the number of SVE access traps
and the number of times we loaded FPSIMD only register state for each task.
Testing with Debian Bookworm this showed that during boot the overwhelming
majority of tasks triggered another SVE access trap more than 50% of the
time after loading FPSIMD only state with a substantial number near 100%,
though some programs had a very small number of SVE accesses most likely
from the dynamic linker. There were few tasks in the range 5-45%, most
tasks either used SVE frequently or used it only a tiny proportion of
times. As expected older distributions which do not have the SVE
performance work available showed no SVE usage in general applications.
For tasks with minimal SVE usage benchmarking with fp-pidbench on a
system with 128 bit SVE shows an approximately 6% overhead on syscalls
from having used SVE in the task, the overhead should be greater on a
system with 256 bit SVE since the Z registers must be flushed as well as
the P and FFR registers.
The two patches here move to using a time based heuristic to decide when
to reenable the SVE access trap, doing so after a second. This means
that tasks actively using SVE which block in syscalls should see reduced
or similar numbers of access traps, while CPU bound tasks that rarely
use SVE will see the SVE syscall overhead removed after running for
approximately a second, confirmed via fp-pidbench.
The benchmarking here is all very much microbenchmarks so there are
obviously some concerns on the system level impacts in actual use.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
Changes in v9:
- Rebase onto v7.1-rc3.
- Link to v8: https://patch.msgid.link/20260320-arm64-sve-trap-mitigation-v8-0-8bf116c8e360@kernel.org
Changes in v8:
- Rebase onto v7.0-rc3.
- Add some benchmarking info from physical systems.
- Add second patch that helps processes that stay on the CPU drop
TIF_SVE.
- Link to v7: https://lore.kernel.org/r/20240730-arm64-sve-trap-mitigation-v7-1-755e7e31bdd7@kernel.org
Changes in v7:
- Rebase onto v6.11-rc1.
- Only flush the predicate registers when loading FPSIMD state, Z will
be flushed by loading the V registers.
- Link to v6: https://lore.kernel.org/r/20240529-arm64-sve-trap-mitigation-v6-1-c2037be6aced@kernel.org
Changes in v6:
- Rebase onto v6.10-rc1.
- Link to v5: https://lore.kernel.org/r/20240405-arm64-sve-trap-mitigation-v5-1-126fe2515ef1@kernel.org
Changes in v5:
- Rebase onto v6.9-rc1.
- Use a timeout rather than number of state loads to decide when to
reenable traps.
- Link to v4: https://lore.kernel.org/r/20240122-arm64-sve-trap-mitigation-v4-1-54e0d78a3ae9@kernel.org
Changes in v4:
- Rebase onto v6.8-rc1.
- Link to v3: https://lore.kernel.org/r/20231113-arm64-sve-trap-mitigation-v3-1-4779c9382483@kernel.org
Changes in v3:
- Rebase onto v6.7-rc1.
- Link to v2: https://lore.kernel.org/r/20230913-arm64-sve-trap-mitigation-v2-1-1bdeff382171@kernel.org
Changes in v2:
- Rebase onto v6.6-rc1.
- Link to v1: https://lore.kernel.org/r/20230807-arm64-sve-trap-mitigation-v1-1-d92eed1d2855@kernel.org
---
Mark Brown (2):
arm64/fpsimd: Suppress SVE access traps when loading FPSIMD state
arm64/sve: Disable TIF_SVE on syscall once per second
arch/arm64/include/asm/fpsimd.h | 1 +
arch/arm64/include/asm/processor.h | 1 +
arch/arm64/kernel/entry-common.c | 14 ++++++++++--
arch/arm64/kernel/entry-fpsimd.S | 15 +++++++++++++
arch/arm64/kernel/fpsimd.c | 46 +++++++++++++++++++++++++++++++++-----
5 files changed, 70 insertions(+), 7 deletions(-)
---
base-commit: 5d6919055dec134de3c40167a490f33c74c12581
change-id: 20230807-arm64-sve-trap-mitigation-2e7e2663c849
Best regards,
--
Mark Brown <broonie@kernel.org>
^ permalink raw reply
* [PATCH v9 1/2] arm64/fpsimd: Suppress SVE access traps when loading FPSIMD state
From: Mark Brown @ 2026-05-18 16:11 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Rutland, Ryan Roberts, linux-arm-kernel, linux-kernel,
Mark Brown
In-Reply-To: <20260518-arm64-sve-trap-mitigation-v9-0-9cc8fcd002fd@kernel.org>
When we are in a syscall we take the opportunity to discard the SVE state,
saving only the FPSIMD subset of the register state. If we have to
reload the floating point state from memory then we reenable SVE access
traps, stopping tracking SVE until the task uses SVE again at which
point it will take another SVE access trap. This means that for a task
which is actively using SVE and also doing many blocking system calls
will have the additional overhead of SVE access traps.
The use of SVE for applications like memcpy() means that frequent SVE
usage is common with modern distributions, even with tasks that do not
obviously use floating point. I did some instrumentation which counted
the number of SVE access traps and the number of times we loaded FPSIMD
only register state for each task. Testing with Debian Bookworm this
showed that during boot the overwhelming majority of tasks triggered
another SVE access trap more than 50% of the time after loading FPSIMD
only state with a substantial number near 100%, though some programs had
a very small number of SVE accesses most likely from startup. There were
few tasks in the range 5-45%, most tasks either used SVE frequently or
used it only a tiny proportion of times. As expected older distributions
which do not have the SVE performance work available showed no SVE usage
in general applications.
This indicates that there should be some benefit from reducing the
number of SVE access traps for blocking system calls like we did for non
blocking system calls in commit 8c845e273104 ("arm64/sve: Leave SVE
enabled on syscall if we don't context switch"). Let's do this with a
timeout, when we take a SVE access trap record a jiffies after which
we'll reeanble SVE traps and then check this whenever we load a FPSIMD
only floating point state from memory. If the time has passed then we
reenable traps, otherwise we leave traps disabled and flush the
non-shared register state like we would on trap.
The timeout is currently set to a second, I pulled this number out of thin
air so there is doubtless some room for tuning. This means that for a
task which is actively using SVE the number of SVE access traps will be
equivalent or reduced but applications which use SVE only very
infrequently will avoid the overheads associated with tracking SVE state
after a second. The extra cost from additional tracking of SVE state
only occurs when a task is preempted so short running tasks should be
minimally affected.
As would be expected fp-pidbench shows minimal change from this patch,
it does not block and on a quiet system is unlikely to see it's state
reloaded from memory.
There should be no functional change resulting from this, it is purely a
performance optimisation.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/arm64/include/asm/fpsimd.h | 1 +
arch/arm64/include/asm/processor.h | 1 +
arch/arm64/kernel/entry-fpsimd.S | 15 +++++++++++++
arch/arm64/kernel/fpsimd.c | 46 +++++++++++++++++++++++++++++++++-----
4 files changed, 58 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
index d9d00b45ab11..b3ba8803b1d3 100644
--- a/arch/arm64/include/asm/fpsimd.h
+++ b/arch/arm64/include/asm/fpsimd.h
@@ -144,6 +144,7 @@ static inline void *thread_zt_state(struct thread_struct *thread)
extern void sve_save_state(void *state, u32 *pfpsr, int save_ffr);
extern void sve_load_state(void const *state, u32 const *pfpsr,
int restore_ffr);
+extern void sve_flush_p(bool flush_ffr);
extern void sve_flush_live(bool flush_ffr, unsigned long vq_minus_1);
extern unsigned int sve_get_vl(void);
extern void sve_set_vq(unsigned long vq_minus_1);
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index e30c4c8e3a7a..a174864eca5f 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -166,6 +166,7 @@ struct thread_struct {
unsigned int fpsimd_cpu;
void *sve_state; /* SVE registers, if any */
void *sme_state; /* ZA and ZT state, if any */
+ unsigned long sve_timeout; /* jiffies to drop TIF_SVE */
unsigned int vl[ARM64_VEC_MAX]; /* vector length */
unsigned int vl_onexec[ARM64_VEC_MAX]; /* vl after next exec */
unsigned long fault_address; /* fault info */
diff --git a/arch/arm64/kernel/entry-fpsimd.S b/arch/arm64/kernel/entry-fpsimd.S
index 6325db1a2179..617dd70cafd7 100644
--- a/arch/arm64/kernel/entry-fpsimd.S
+++ b/arch/arm64/kernel/entry-fpsimd.S
@@ -85,6 +85,21 @@ SYM_FUNC_START(sve_flush_live)
2: ret
SYM_FUNC_END(sve_flush_live)
+/*
+ * Zero the predicate registers
+ *
+ * VQ must already be configured by caller, any further updates of VQ
+ * will need to ensure that the register state remains valid.
+ *
+ * x0 = include FFR?
+ */
+SYM_FUNC_START(sve_flush_p)
+ sve_flush_p
+ tbz x0, #0, 1f
+ sve_flush_ffr
+1: ret
+SYM_FUNC_END(sve_flush_p)
+
#endif /* CONFIG_ARM64_SVE */
#ifdef CONFIG_ARM64_SME
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 60a45d600b46..9c3def8ddea7 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -362,6 +362,7 @@ static void task_fpsimd_load(void)
{
bool restore_sve_regs = false;
bool restore_ffr;
+ unsigned long sve_vq_minus_one;
WARN_ON(!system_supports_fpsimd());
WARN_ON(preemptible());
@@ -370,16 +371,11 @@ static void task_fpsimd_load(void)
if (system_supports_sve() || system_supports_sme()) {
switch (current->thread.fp_type) {
case FP_STATE_FPSIMD:
- /* Stop tracking SVE for this task until next use. */
- clear_thread_flag(TIF_SVE);
break;
case FP_STATE_SVE:
if (!thread_sm_enabled(¤t->thread))
WARN_ON_ONCE(!test_and_set_thread_flag(TIF_SVE));
- if (test_thread_flag(TIF_SVE))
- sve_set_vq(sve_vq_from_vl(task_get_sve_vl(current)) - 1);
-
restore_sve_regs = true;
restore_ffr = true;
break;
@@ -398,6 +394,15 @@ static void task_fpsimd_load(void)
}
}
+ /*
+ * If SVE has been enabled we may keep it enabled even if
+ * loading only FPSIMD state, so always set the VL.
+ */
+ if (system_supports_sve() && test_thread_flag(TIF_SVE)) {
+ sve_vq_minus_one = sve_vq_from_vl(task_get_sve_vl(current)) - 1;
+ sve_set_vq(sve_vq_minus_one);
+ }
+
/* Restore SME, override SVE register configuration if needed */
if (system_supports_sme()) {
unsigned long sme_vl = task_get_sme_vl(current);
@@ -427,6 +432,30 @@ static void task_fpsimd_load(void)
} else {
WARN_ON_ONCE(current->thread.fp_type != FP_STATE_FPSIMD);
fpsimd_load_state(¤t->thread.uw.fpsimd_state);
+
+ /*
+ * If the task had been using SVE we keep it enabled
+ * when loading FPSIMD only state for a period to
+ * minimise overhead for tasks actively using SVE,
+ * disabling it periodicaly to ensure that tasks that
+ * use SVE intermittently do eventually avoid the
+ * overhead of carrying SVE state. The timeout is
+ * initialised when we take a SVE trap in do_sve_acc().
+ */
+ if (system_supports_sve() && test_thread_flag(TIF_SVE)) {
+ if (time_after(jiffies, current->thread.sve_timeout)) {
+ clear_thread_flag(TIF_SVE);
+ sve_user_disable();
+ } else {
+ /*
+ * Loading V will have flushed the
+ * rest of the Z register, SVE is
+ * enabled at EL1 and VL was set
+ * above.
+ */
+ sve_flush_p(true);
+ }
+ }
}
}
@@ -1345,6 +1374,13 @@ void do_sve_acc(unsigned long esr, struct pt_regs *regs)
get_cpu_fpsimd_context();
+ /*
+ * We will keep SVE enabled when loading FPSIMD only state for
+ * the next second to minimise traps when userspace is
+ * actively using SVE.
+ */
+ current->thread.sve_timeout = jiffies + HZ;
+
if (test_and_set_thread_flag(TIF_SVE))
WARN_ON(1); /* SVE access shouldn't have trapped */
--
2.47.3
^ permalink raw reply related
* [PATCH v9 2/2] arm64/sve: Disable TIF_SVE on syscall once per second
From: Mark Brown @ 2026-05-18 16:11 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Mark Rutland, Ryan Roberts, linux-arm-kernel, linux-kernel,
Mark Brown
In-Reply-To: <20260518-arm64-sve-trap-mitigation-v9-0-9cc8fcd002fd@kernel.org>
Our syscall ABI requires that when performing a syscall the portions of
the Z registers not shared with the V registers, the P and FFR registers
are reset to 0. Since we have no way of monitoring EL0 SVE usage this
is implemented by changing the in register values on every syscall for
tasks which have SVE enabled, for systems with 128 bit SVE vector
lengths this has been benchmarked as a 6% overhead.
We currently support disabling SVE for userspace tasks when loading the
floating point state from memory during a syscall, allowing tasks that
use SVE infrequently to avoid this overhead, but this may not help CPU
bound tasks if they are not fortunate enough to block or be scheduled
during a syscall. This is done whenever the state is loaded from a
second after the last time the task generate a SVE access trap.
Extend this mechanism to also apply during syscall entry, disabling SVE
instead of flushing the live registers when we perform a syscall a
second after the last time a SVE access trap was taken. This adds an
additional memory access and branch for tasks using SVE and means that
CPU bound tasks actively using SVE will take extra SVE access traps (at
most one per second) but will allows CPU bound tasks that infrequently
use SVE to avoid the overhead of flushing the registers on syscall.
On a system with 128 bit SVE vectors fp-pidbench shows a roughly 4.5%
improvement compared to baseline after having used SVE, for a roughly
0.4% overhead when SVE is used between each syscall. Obviously this is
very much a microbenchmark.
This is purely a performance optimisation, there should be no functional
change.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/arm64/kernel/entry-common.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
index cb54335465f6..e02e2c1013e3 100644
--- a/arch/arm64/kernel/entry-common.c
+++ b/arch/arm64/kernel/entry-common.c
@@ -240,8 +240,18 @@ static inline void fpsimd_syscall_enter(void)
if (test_thread_flag(TIF_SVE)) {
unsigned int sve_vq_minus_one;
- sve_vq_minus_one = sve_vq_from_vl(task_get_sve_vl(current)) - 1;
- sve_flush_live(true, sve_vq_minus_one);
+ /*
+ * Ensure that tasks that don't block in a syscall
+ * also get a chance to drop TIF_SVE.
+ */
+ if (unlikely(time_after(jiffies,
+ current->thread.sve_timeout))) {
+ clear_thread_flag(TIF_SVE);
+ sve_user_disable();
+ } else {
+ sve_vq_minus_one = sve_vq_from_vl(task_get_sve_vl(current)) - 1;
+ sve_flush_live(true, sve_vq_minus_one);
+ }
}
/*
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Matthew Wilcox @ 2026-05-18 16:17 UTC (permalink / raw)
To: Barry Song
Cc: Lorenzo Stoakes, surenb, akpm, linux-mm, david, 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: <CAGsJ_4zqLfdWoTH9s7FFaqWWj0mESfikYgr7=GcV64qcuXrPxA@mail.gmail.com>
On Mon, May 18, 2026 at 07:25:54PM +0800, Barry Song wrote:
> We have clearly observed that the `fork()` operations of many
> popular Android apps, such as iQiyi, Baidu Tieba, and 10086,
> end up waiting on page-fault (PF) I/O when the VMA lock is
> held during I/O operations. This has already become a
> practical issue. I also believe this can lead to chained
> waiting, since the global `mmap_lock` blocks all threads that
> need to acquire it.
It's always been a terrible idea to call fork() from a multithreaded
application. For example, this question:
https://stackoverflow.com/questions/53601200/calling-fork-on-a-multithreaded-process
or this lwn thread: https://lwn.net/Articles/674660/
Do we have any insight into why these applications are doing this
horrible thing?
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: aspeed: Add Meta Rainiera6 board
From: Conor Dooley @ 2026-05-18 16:28 UTC (permalink / raw)
To: Neil Cheng
Cc: robh, krzk+dt, conor+dt, joel, andrew, geert+renesas, magnus.damm,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-renesas-soc
In-Reply-To: <4f7aee0a2dfc44770347ccc82e54820e7b35317c.1779088499.git.neilcheng0417@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v1 1/3] dt-bindings: display: rockchip: analogix-dp: Expose inherited properties
From: Conor Dooley @ 2026-05-18 16:31 UTC (permalink / raw)
To: Damon Ding
Cc: Conor Dooley, hjc, heiko, andy.yan, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, robh, krzk+dt, conor+dt,
andrzej.hajda, neil.armstrong, rfoss, Laurent.pinchart, jonas,
jernej.skrabec, nicolas.frattaroli, cristian.ciocaltea,
sebastian.reichel, dmitry.baryshkov, luca.ceresoli, dianders,
m.szyprowski, dri-devel, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <a7ab01f6-78a4-405f-8160-8af31a8ef99c@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 3963 bytes --]
On Mon, May 18, 2026 at 10:44:29AM +0800, Damon Ding wrote:
> Hi Conor,
>
> On 5/15/2026 5:04 PM, Conor Dooley wrote:
> > On Fri, May 15, 2026 at 11:57:58AM +0800, Damon Ding wrote:
> > > Hi Conor,
> > >
> > > On 5/15/2026 2:16 AM, Conor Dooley wrote:
> > > > On Thu, May 14, 2026 at 03:01:31PM +0800, Damon Ding wrote:
> > > > > Expose the inherited properties from the base analogix-dp schema
> > > > > to satisfy unevaluatedProperties constraints.
> > > > >
> > > > > Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
> > > >
> > > > Given it's unevaluatedProperties, not addtionalProperties, this patch
> > > > shouldn't be needed?
> > > >
> > >
> > > When I remove both the top-level data-lanes property and those explicit
> > > "xxx: true" property entries and run the dtbs check with:
> > >
> > > make CHECK_DTBS=y CROSS_COMPILE=aarch64-linux-gnu- LT0=none LLVM=1
> > > LLVM_IAS=1 ARCH=arm64 rockchip/rk3588-evb1-v10.dtb
> > > rockchip/rk3588s-evb1-v10.dtb rockchip/rk3399-sapphire-excavator.dtb
> > > rockchip/rk3576-evb1-v10.dtb -j4
> > >
> > > It results in validation errors like these:
> > >
> > > /home/ding/drm-misc/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dtb:
> > > edp@27dc0000: ports:port@1:endpoint: Unevaluated properties are not allowed
> > > ('data-lanes' was unexpected)
> > > from schema $id:
> > > http://devicetree.org/schemas/display/rockchip/rockchip,analogix-dp.yaml#
> > > /home/ding/drm-misc/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dtb:
> > > edp@27dc0000: Unevaluated properties are not allowed ('force-hpd',
> > > 'interrupts', 'phy-names', 'phys', 'ports', 'reg' were unexpected)
> > > from schema $id:
> > > http://devicetree.org/schemas/display/rockchip/rockchip,analogix-dp.yaml#
> > >
> > > I suspect that the properties defined in the child binding are
> > > overriding/masking all the inherited properties from the parent Analogix DP
> > > schema.
> > >
> > > Is there a better way to fix this issue without explicitly listing all
> > > inherited properties as true?
> >
> > The example in this file uses most of the properties that you mention
> > above:
> > dp@ff970000 {
> > compatible = "rockchip,rk3288-dp";
> > reg = <0xff970000 0x4000>;
> > interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
> > clocks = <&cru SCLK_EDP>, <&cru PCLK_EDP_CTRL>;
> > clock-names = "dp", "pclk";
> > phys = <&dp_phy>;
> > phy-names = "dp";
> > resets = <&cru 111>;
> > reset-names = "dp";
> > rockchip,grf = <&grf>;
> > pinctrl-0 = <&edp_hpd>;
> > pinctrl-names = "default";
> >
> > dt_binding_check reports no problems with this node, so I think the
> > problem might lie elsewhere?
> > There's no edp node in the dts you mention above, so this looks like an
> > interaction with something that's not yet upstream.
>
> Ah, I see.
>
> I did add extra changes to the edp node on my local rk3576-evb1 board DTS,
> which indeed caused this 'asymmetric information' issue and made the
> validation fail incorrectly.
>
> I will try adding the data-lanes property to the example in the binding
> document to ensure dt_binding_check passes cleanly.
>
> >
> > If this is required for the rk3576 edp, then you should include this
> > patch in the rk3576 edp support series rather than this one anyway where
> > it can actually be evaluated alongside the node it apparently causes
> > problems with.
>
> The data-lanes property is actually applicable and useful for all Rockchip
> eDP platforms, not just rk3576.
>
> In the next version, I will modify the series to better separate this common
> data-lanes change from the rk3576 specific eDP support patches.
To be clear, I wasn't talking about data-lanes here, I was talking about
this patch that addressed the properties inherited from the common
analogix-dp.yaml.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v22 08/13] mfd: core: Add firmware-node support to MFD cells
From: Shivendra Pratap @ 2026-05-18 16:41 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: linux-pm, linux-kernel, linux-arm-msm, linux-arm-kernel,
devicetree, Florian Fainelli, Krzysztof Kozlowski,
Dmitry Baryshkov, Mukesh Ojha, Andre Draszik, Greg Kroah-Hartman,
Kathiravan Thirumoorthy, Srinivas Kandagatla, Bartosz Golaszewski,
Sebastian Reichel, Mark Rutland, Lorenzo Pieralisi,
Rafael J. Wysocki, Daniel Lezcano, Christian Loehle, Ulf Hansson,
Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio, Arnd Bergmann, Souvik Chakravarty,
Andy Yan, Matthias Brugger, John Stultz, Moritz Fischer,
Sudeep Holla
In-Reply-To: <CAMRc=Mde7Y3CQ3yi=U+999JyHTNacebiK8jJhHuYBGaqn59yYg@mail.gmail.com>
On 18-05-2026 14:27, Bartosz Golaszewski wrote:
> On Thu, 14 May 2026 16:25:49 +0200, Shivendra Pratap
> <shivendra.pratap@oss.qualcomm.com> said:
>> MFD core has no way to register a child device using an explicit firmware
>> node. This prevents drivers from registering child nodes when those nodes
>> do not define a compatible string. One such example is the PSCI
>> "reboot-mode" node, which omits a compatible string as it describes
>> boot-states provided by the underlying firmware.
>>
>> Extend struct mfd_cell with a callback that allows drivers to provide an
>> explicit firmware node. The node is added to the MFD child device during
>> registration when none is assigned by device tree, ACPI, or software
>> matching.
>>
>> Suggested-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
>> ---
>> drivers/mfd/mfd-core.c | 30 ++++++++++++++++++++++++++++++
>> include/linux/mfd/core.h | 14 ++++++++++++++
>> 2 files changed, 44 insertions(+)
>>
>> diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
>> index 7aa32b90cf1eb7fa0a05bf3dc506e60a262c9850..cc2a2a924d6d3044e29a9f864b536ee325ed797b 100644
>> --- a/drivers/mfd/mfd-core.c
>> +++ b/drivers/mfd/mfd-core.c
>> @@ -10,6 +10,7 @@
>> #include <linux/kernel.h>
>> #include <linux/platform_device.h>
>> #include <linux/acpi.h>
>> +#include <linux/fwnode.h>
>> #include <linux/list.h>
>> #include <linux/property.h>
>> #include <linux/mfd/core.h>
>> @@ -148,6 +149,11 @@ static int mfd_match_of_node_to_dev(struct platform_device *pdev,
>> return 0;
>> }
>>
>> +static void mfd_child_fwnode_put(void *data)
>> +{
>> + fwnode_handle_put(data);
>> +}
>
> Ah, this seems to answer my previous question, but...
>
>> +
>> static int mfd_add_device(struct device *parent, int id,
>> const struct mfd_cell *cell,
>> struct resource *mem_base,
>> @@ -156,6 +162,7 @@ static int mfd_add_device(struct device *parent, int id,
>> struct resource *res;
>> struct platform_device *pdev;
>> struct mfd_of_node_entry *of_entry, *tmp;
>> + struct fwnode_handle *fwnode;
>> bool disabled = false;
>> int ret = -ENOMEM;
>> int platform_id;
>> @@ -224,6 +231,29 @@ static int mfd_add_device(struct device *parent, int id,
>>
>> mfd_acpi_add_device(cell, pdev);
>>
>> + if (!pdev->dev.fwnode && cell->get_child_fwnode) {
>> + fwnode = cell->get_child_fwnode(parent);
>> + if (fwnode) {
>> + device_set_node(&pdev->dev, fwnode);
>> +
>> + /*
>> + * platform_device_release() drops only of_node refs.
>
> Which is a separate problem we're discussing elsewhere. It should probably drop
> the fwnode reference it holds, not the one of of_node.
>
>> + * Track non-OF fwnodes explicitly so they are put on
>> + * all teardown paths.
>> + */
>> + if (!to_of_node(fwnode)) {
>> + ret = devm_add_action(&pdev->dev,
>> + mfd_child_fwnode_put,
>> + fwnode);
>
> What if the device never gets bound to the driver? The release will never be
> called, this is why it's wrong to schedule devres actions for unbound devices
> and one of the reasons for patch 1 in this series.
>
> What I suggest for now is: in tear-down path: see if the cell has the
> get_child_fwnode() callback and - if so - drop the reference. Add a big, fat
> comment saying that this must be removed if we decide to switch to dropping the
> device's fwnode reference in platform driver core which may happen soon.
Ack. sure. lets me work it out.
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH 01/15] dt-bindings: arm: stm32: support Engicam MicroGEA-STM32MP257-RMM board
From: Conor Dooley @ 2026-05-18 16:44 UTC (permalink / raw)
To: Dario Binacchi
Cc: linux-kernel, linux-amarula, domenico.acri, francesco.utel,
Alexandre Torgue, Christophe Parant, Conor Dooley,
Himanshu Bhavani, Krzysztof Kozlowski, Maxime Coquelin,
Rob Herring, devicetree, linux-arm-kernel, linux-stm32
In-Reply-To: <20260518143150.3138712-2-dario.binacchi@amarulasolutions.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v22 07/13] power: reset: Add psci-reboot-mode driver
From: Shivendra Pratap @ 2026-05-18 16:45 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: linux-pm, linux-kernel, linux-arm-msm, linux-arm-kernel,
devicetree, Florian Fainelli, Krzysztof Kozlowski,
Dmitry Baryshkov, Mukesh Ojha, Andre Draszik, Greg Kroah-Hartman,
Kathiravan Thirumoorthy, Srinivas Kandagatla, Sebastian Reichel,
Mark Rutland, Lorenzo Pieralisi, Rafael J. Wysocki,
Daniel Lezcano, Christian Loehle, Ulf Hansson, Lee Jones,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Arnd Bergmann, Souvik Chakravarty, Andy Yan,
Matthias Brugger, John Stultz, Moritz Fischer, Sudeep Holla
In-Reply-To: <CAMRc=MdNVBKH_4Ps_QSG_YzW3=BgsMo0bDk6vuJuH7VheY9PmQ@mail.gmail.com>
On 18-05-2026 14:28, Bartosz Golaszewski wrote:
> On Thu, 14 May 2026 16:25:48 +0200, Shivendra Pratap
> <shivendra.pratap@oss.qualcomm.com> said:
>> PSCI supports different types of resets like SYSTEM_RESET, SYSTEM_RESET2
>> ARCH WARM reset and SYSTEM_RESET2 vendor-specific resets. Currently
>> there is no common driver that handles all supported psci resets at one
>> place. Additionally, there is no common mechanism to issue the supported
>> psci resets from userspace.
>>
>> Add a psci-reboot-mode driver, and define two types of PSCI resets,
>> predefined-resets and vendor-specific resets. Predefined-resets are
>> defined by psci driver and vendor-specific resets are defined by SoC
>> vendors, under the psci:reboot-mode node of SoC device tree.
>>
>> Register the driver with the reboot-mode framework to interface these
>> resets to userspace. When userspace initiates a supported command, pass
>> the reset arguments to the PSCI driver to enable command-based reset.
>>
>> This change allows userspace to issue supported PSCI reset commands
>> using the standard reboot system calls while enabling SoC vendors to
>> define their specific resets for PSCI.
>>
>> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
>> ---
>> MAINTAINERS | 1 +
>> drivers/power/reset/Kconfig | 10 +++++
>> drivers/power/reset/Makefile | 1 +
>> drivers/power/reset/psci-reboot-mode.c | 72 ++++++++++++++++++++++++++++++++++
>> 4 files changed, 84 insertions(+)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 36ba42209c0b332813a296880cd55798a5592d2a..4b0815c31679550f5ab719de4a5852990c7cc643 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -21342,6 +21342,7 @@ S: Maintained
>> F: Documentation/devicetree/bindings/arm/psci.yaml
>> F: drivers/firmware/psci/
>> F: drivers/mfd/psci-mfd.c
>> +F: drivers/power/reset/psci-reboot-mode.c
>> F: include/linux/psci.h
>> F: include/uapi/linux/psci.h
>>
>> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
>> index 124afb99febe92450b6ae322aeed3b63fa2070df..d9d1f768b8691abc3b32f2675519f2ddbaf19b84 100644
>> --- a/drivers/power/reset/Kconfig
>> +++ b/drivers/power/reset/Kconfig
>> @@ -348,6 +348,16 @@ config NVMEM_REBOOT_MODE
>> then the bootloader can read it and take different
>> action according to the mode.
>>
>> +config PSCI_REBOOT_MODE
>> + bool "PSCI reboot mode driver"
>> + depends on OF && ARM_PSCI_FW
>
> Can you add COMPILE_TEST coverage here too please?
Ack. thanks.
>
>> + select REBOOT_MODE
>> + help
>> + Say y here will enable PSCI reboot mode driver. This gets
>> + the PSCI reboot mode arguments and passes them to psci
>> + driver. psci driver uses these arguments for issuing
>> + device reset into different boot states.
>> +
>> config POWER_MLXBF
>> tristate "Mellanox BlueField power handling driver"
>> depends on (GPIO_MLXBF2 || GPIO_MLXBF3) && ACPI
[SNIP..]
>> +static struct platform_driver psci_reboot_mode_driver = {
>> + .probe = psci_reboot_mode_probe,
>> + .driver = {
>> + .name = "psci-reboot-mode",
>> + },
>> +};
>> +
>
> You can drop the newline here.
Ack.
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu: pass smmu->dev to report_iommu_fault
From: Robin Murphy @ 2026-05-18 17:00 UTC (permalink / raw)
To: Shyam Saini, iommu
Cc: linux-arm-kernel, linux-arm-msm, robin.clark, will, joro, stable
In-Reply-To: <20260517005052.3783378-1-shyamsaini@linux.microsoft.com>
On 17/05/2026 1:50 am, Shyam Saini wrote:
> report_iommu_fault() passes the dev argument to trace_io_page_fault(),
> which dereferences it via dev_name() and dev_driver_string(). Passing
> NULL causes a kernel crash when the io_page_fault tracepoint is
> enabled.
>
> In arm-smmu.c, 'commit f8f934c180f6 ("iommu/arm-smmu: Add support for driver IOMMU fault handlers")'
> replaced a dev_err_ratelimited() call that correctly used smmu->dev with
I'm not sure it was really correct - it's pretty clear that "dev" is
intended to be the client device that _caused_ the fault, since why
would it make any sense to pass the IOMMU device to some other
driver/subsystem's fault handler? (Yes, other IOMMU drivers already do
that; I would consider them just as wrong too).
IMO it would seem more robust to just fix the tracepoint to handle a
NULL "dev" in the case that one can't (easily) be identified.
Thanks,
Robin.
> report_iommu_fault() but passed NULL instead.
> In arm-smmu-qcom-debug.c, 'commit d374555ef993 ("iommu/arm-smmu-qcom: Use a custom context fault handler for sdm845")'
> introduced two report_iommu_fault() calls also with NULL.
>
> Pass smmu->dev to all three call sites.
>
> Fixes: f8f934c180f629bb ("iommu/arm-smmu: Add support for driver IOMMU fault handlers")
> Fixes: d374555ef993433f ("iommu/arm-smmu-qcom: Use a custom context fault handler for sdm845")
> Cc: stable@vger.kernel.org
> Assisted-by: GitHub_Copilot:claude-opus-4.6
> Signed-off-by: Shyam Saini <shyamsaini@linux.microsoft.com>
> ---
> drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c | 4 ++--
> drivers/iommu/arm/arm-smmu/arm-smmu.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
> index 65e0ef6539fe7..8eb9f7831de07 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom-debug.c
> @@ -399,7 +399,7 @@ irqreturn_t qcom_smmu_context_fault(int irq, void *dev)
> return IRQ_NONE;
>
> if (list_empty(&tbu_list)) {
> - ret = report_iommu_fault(&smmu_domain->domain, NULL, cfi.iova,
> + ret = report_iommu_fault(&smmu_domain->domain, smmu->dev, cfi.iova,
> cfi.fsynr & ARM_SMMU_CB_FSYNR0_WNR ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ);
>
> if (ret == -ENOSYS)
> @@ -417,7 +417,7 @@ irqreturn_t qcom_smmu_context_fault(int irq, void *dev)
>
> phys_soft = ops->iova_to_phys(ops, cfi.iova);
>
> - tmp = report_iommu_fault(&smmu_domain->domain, NULL, cfi.iova,
> + tmp = report_iommu_fault(&smmu_domain->domain, smmu->dev, cfi.iova,
> cfi.fsynr & ARM_SMMU_CB_FSYNR0_WNR ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ);
> if (!tmp || tmp == -EBUSY) {
> ret = IRQ_HANDLED;
> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> index 0bd21d206eb3e..92d8fa2100adb 100644
> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
> @@ -467,7 +467,7 @@ static irqreturn_t arm_smmu_context_fault(int irq, void *dev)
> if (!(cfi.fsr & ARM_SMMU_CB_FSR_FAULT))
> return IRQ_NONE;
>
> - ret = report_iommu_fault(&smmu_domain->domain, NULL, cfi.iova,
> + ret = report_iommu_fault(&smmu_domain->domain, smmu->dev, cfi.iova,
> cfi.fsynr & ARM_SMMU_CB_FSYNR0_WNR ? IOMMU_FAULT_WRITE : IOMMU_FAULT_READ);
>
> if (ret == -ENOSYS && __ratelimit(&rs))
^ permalink raw reply
* [PATCH 1/2] PCI: dwc: Guard RAS DES debugfs deinit
From: Shuvam Pandey @ 2026-05-18 16:59 UTC (permalink / raw)
To: Jingoo Han, Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Bjorn Helgaas, Yue Wang,
Neil Armstrong
Cc: Rob Herring, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Fan Ni, Shradha Todi, Hanjie Lin, linux-pci, linux-amlogic,
linux-arm-kernel, linux-kernel
dwc_pcie_rasdes_debugfs_init() returns success when the controller has
no RAS DES capability, leaving pci->debugfs->rasdes_info unset. The
common debugfs teardown path still calls
dwc_pcie_rasdes_debugfs_deinit(), which dereferences rasdes_info
unconditionally.
Return early when no RAS DES state was allocated. In that case no RAS DES
mutex was initialized, so there is nothing to destroy.
Fixes: 4fbfa17f9a07 ("PCI: dwc: Add debugfs based Silicon Debug support for DWC")
Signed-off-by: Shuvam Pandey <shuvampandey1@gmail.com>
---
drivers/pci/controller/dwc/pcie-designware-debugfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/pci/controller/dwc/pcie-designware-debugfs.c b/drivers/pci/controller/dwc/pcie-designware-debugfs.c
index d0884253b..c3671cb2f 100644
--- a/drivers/pci/controller/dwc/pcie-designware-debugfs.c
+++ b/drivers/pci/controller/dwc/pcie-designware-debugfs.c
@@ -557,6 +557,9 @@ static void dwc_pcie_rasdes_debugfs_deinit(struct dw_pcie *pci)
{
struct dwc_pcie_rasdes_info *rinfo = pci->debugfs->rasdes_info;
+ if (!rinfo)
+ return;
+
mutex_destroy(&rinfo->reg_event_lock);
}
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH 2/2] PCI: meson: Add missing remove callback
From: Shuvam Pandey @ 2026-05-18 16:59 UTC (permalink / raw)
To: Jingoo Han, Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Bjorn Helgaas, Yue Wang,
Neil Armstrong
Cc: Rob Herring, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Fan Ni, Shradha Todi, Hanjie Lin, linux-pci, linux-amlogic,
linux-arm-kernel, linux-kernel
meson_pcie_probe() powers on the PHY and registers the DesignWare host
bridge with dw_pcie_host_init(), but the driver has no remove callback.
On driver unbind or module unload, the driver core therefore proceeds to
devres cleanup without first unregistering the host bridge or powering off
the PHY.
Add a remove callback that deinitializes the DesignWare host bridge and
powers off the PHY while device-managed resources are still valid.
Fixes: 9c0ef6d34fdb ("PCI: amlogic: Add the Amlogic Meson PCIe controller driver")
Signed-off-by: Shuvam Pandey <shuvampandey1@gmail.com>
---
drivers/pci/controller/dwc/pci-meson.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/pci/controller/dwc/pci-meson.c b/drivers/pci/controller/dwc/pci-meson.c
index 0694084f6..c96e2244a 100644
--- a/drivers/pci/controller/dwc/pci-meson.c
+++ b/drivers/pci/controller/dwc/pci-meson.c
@@ -451,6 +451,14 @@ static int meson_pcie_probe(struct platform_device *pdev)
return ret;
}
+static void meson_pcie_remove(struct platform_device *pdev)
+{
+ struct meson_pcie *mp = platform_get_drvdata(pdev);
+
+ dw_pcie_host_deinit(&mp->pci.pp);
+ meson_pcie_power_off(mp);
+}
+
static const struct of_device_id meson_pcie_of_match[] = {
{
.compatible = "amlogic,axg-pcie",
@@ -464,6 +472,7 @@ MODULE_DEVICE_TABLE(of, meson_pcie_of_match);
static struct platform_driver meson_pcie_driver = {
.probe = meson_pcie_probe,
+ .remove = meson_pcie_remove,
.driver = {
.name = "meson-pcie",
.of_match_table = meson_pcie_of_match,
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH v1] regulator: Use named initializers for arrays of i2c_device_data
From: Woody Douglass @ 2026-05-18 17:07 UTC (permalink / raw)
To: Laurent Pinchart, Uwe Kleine-König (The Capable Hub)
Cc: Liam Girdwood, Mark Brown, Markus Schneider-Pargmann,
Michael Hennerich, Support Opensource, Ivaylo Ivanov,
Claudiu Beznea, Andrei Simion, Saravanan Sekar, Matthias Brugger,
AngeloGioacchino Del Regno, Jagan Teki, Icenowy Zheng,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
In-Reply-To: <20260515122816.GB52035@killaraus.ideasonboard.com>
On 5/15/26 08:28, Laurent Pinchart wrote:
> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.
>
>
> Hi Uwe,
>
> Thank you for the patch.
>
> On Fri, May 15, 2026 at 12:31:50PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
>> While being less compact, using named initializers allows to more easily
>> see which members of the structs are assigned which value without having
>> to lookup the declaration of the struct. And it's also more robust
>> against changes to the struct definition.
>>
>> The mentioned robustness is relevant for a planned change to struct
>> i2c_device_id that replaces .driver_data by an anonymous union.
>>
>> While touching all these arrays, unify usage of whitespace and commas.
>>
>> This patch doesn't modify the compiled arrays, only their representation
>> in source form benefits. The former was confirmed with x86 and arm64
>> builds.
>>
>> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
>> ---
>> Hello,
>>
>> the mentioned change to i2c_device_id is the following:
>>
>> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
>> index 23ff24080dfd..aebd3a5e90af 100644
>> --- a/include/linux/mod_devicetable.h
>> +++ b/include/linux/mod_devicetable.h
>> @@ -477,7 +477,11 @@ struct rpmsg_device_id {
>>
>> struct i2c_device_id {
>> char name[I2C_NAME_SIZE];
>> - kernel_ulong_t driver_data; /* Data private to the driver */
>> + union {
>> + /* Data private to the driver */
>> + kernel_ulong_t driver_data;
>> + const void *driver_data_ptr;
>> + };
>> };
>>
>> /* pci_epf */
>>
>> and this requires that .driver_data is assigned via a named initializer
>> for static data. This requirement isn't a bad one because named
>> initializers are also much better readable than list initializers.
>>
>> The union added to struct i2c_device_id enables further cleanups like:
>>
>> diff --git a/drivers/regulator/ad5398.c b/drivers/regulator/ad5398.c
>> index 0123ca8157a8..dfb0b07500a7 100644
>> --- a/drivers/regulator/ad5398.c
>> +++ b/drivers/regulator/ad5398.c
>> @@ -207,8 +207,8 @@ struct ad5398_current_data_format {
>> static const struct ad5398_current_data_format df_10_4_120 = {10, 4, 0, 120000};
>>
>> static const struct i2c_device_id ad5398_id[] = {
>> - { .name = "ad5398", .driver_data = (kernel_ulong_t)&df_10_4_120 },
>> - { .name = "ad5821", .driver_data = (kernel_ulong_t)&df_10_4_120 },
>> + { .name = "ad5398", .driver_data_ptr = &df_10_4_120 },
>> + { .name = "ad5821", .driver_data_ptr = &df_10_4_120 },
>> { }
>> };
>> MODULE_DEVICE_TABLE(i2c, ad5398_id);
>> @@ -219,8 +219,7 @@ static int ad5398_probe(struct i2c_client *client)
>> struct regulator_init_data *init_data = dev_get_platdata(&client->dev);
>> struct regulator_config config = { };
>> struct ad5398_chip_info *chip;
>> - const struct ad5398_current_data_format *df =
>> - (struct ad5398_current_data_format *)id->driver_data;
>> + const struct ad5398_current_data_format *df = id->driver_data;
>>
>> chip = devm_kzalloc(&client->dev, sizeof(*chip), GFP_KERNEL);
>> if (!chip)
>>
>> that are an improvement for readability (again!) and it keeps some
>> properties of the pointers (here: being const) without having to pay
>> attention for that.
>>
>> My additional motivation for this effort is CHERI[1]. This is a hardware
>> extension that uses 128 bit pointers but unsigned long is still 64 bit.
>> So with CHERI you cannot store pointers in unsigned long variables.
>>
>> Best regards
>> Uwe
>>
>> [1] https://cheri-alliance.org/discover-cheri/
>> https://lwn.net/Articles/1037974/
>>
>> drivers/regulator/88pg86x.c | 4 +--
>> drivers/regulator/ad5398.c | 4 +--
>> drivers/regulator/da9121-regulator.c | 20 +++++++--------
>> drivers/regulator/da9210-regulator.c | 4 +--
>> drivers/regulator/da9211-regulator.c | 18 +++++++-------
>> drivers/regulator/fan53880.c | 4 +--
>> drivers/regulator/isl9305.c | 4 +--
>> drivers/regulator/lp3971.c | 2 +-
>> drivers/regulator/lp3972.c | 2 +-
>> drivers/regulator/lp872x.c | 34 +++++++++++++-------------
>> drivers/regulator/lp8755.c | 4 +--
>> drivers/regulator/ltc3589.c | 6 ++---
>> drivers/regulator/ltc3676.c | 2 +-
>> drivers/regulator/max1586.c | 2 +-
>> drivers/regulator/max20086-regulator.c | 8 +++---
>> drivers/regulator/max20411-regulator.c | 2 +-
>> drivers/regulator/max77503-regulator.c | 2 +-
>> drivers/regulator/max77675-regulator.c | 2 +-
>> drivers/regulator/max77826-regulator.c | 2 +-
>> drivers/regulator/max77838-regulator.c | 2 +-
>> drivers/regulator/max77857-regulator.c | 8 +++---
>> drivers/regulator/max8649.c | 2 +-
>> drivers/regulator/max8893.c | 2 +-
>> drivers/regulator/max8952.c | 2 +-
>> drivers/regulator/mcp16502.c | 2 +-
>> drivers/regulator/mp5416.c | 6 ++---
>> drivers/regulator/mp8859.c | 4 +--
>> drivers/regulator/mp886x.c | 6 ++---
>> drivers/regulator/mpq7920.c | 4 +--
>> drivers/regulator/mt6311-regulator.c | 4 +--
>> drivers/regulator/pf530x-regulator.c | 8 +++---
>> drivers/regulator/pf8x00-regulator.c | 8 +++---
>> drivers/regulator/pv88060-regulator.c | 4 +--
>> drivers/regulator/pv88080-regulator.c | 8 +++---
>> drivers/regulator/pv88090-regulator.c | 4 +--
>> drivers/regulator/slg51000-regulator.c | 4 +--
>> drivers/regulator/sy8106a-regulator.c | 2 +-
>> drivers/regulator/sy8824x.c | 8 +++---
>> drivers/regulator/sy8827n.c | 4 +--
>> drivers/regulator/tps6286x-regulator.c | 10 ++++----
>> drivers/regulator/tps6287x-regulator.c | 10 ++++----
>> 41 files changed, 119 insertions(+), 119 deletions(-)
> [snip]
>
>> diff --git a/drivers/regulator/pf530x-regulator.c b/drivers/regulator/pf530x-regulator.c
>> index f789c4b6a499..e7b13d60106b 100644
>> --- a/drivers/regulator/pf530x-regulator.c
>> +++ b/drivers/regulator/pf530x-regulator.c
>> @@ -353,10 +353,10 @@ static const struct of_device_id pf530x_dt_ids[] = {
>> MODULE_DEVICE_TABLE(of, pf530x_dt_ids);
>>
>> static const struct i2c_device_id pf530x_i2c_id[] = {
>> - { "pf5300", 0 },
>> - { "pf5301", 0 },
>> - { "pf5302", 0 },
>> - {},
>> + { .name = "pf5300", .driver_data = 0 },
>> + { .name = "pf5301", .driver_data = 0 },
>> + { .name = "pf5302", .driver_data = 0 },
> I think you can drop driver_data here. It doesn't appear to be used by
> the driver.
I can confirm this, the pf530x driver does not use the driver_data
member. This is an improvement, thank you!
Reviewed-by: Woodrow Douglass <wdouglass@carnegierobotics.com>
> I like the result overall. With this small issue addressed,
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
>
>> + { }
>> };
>> MODULE_DEVICE_TABLE(i2c, pf530x_i2c_id);
>>
> [snip]
>
> --
> Regards,
>
> Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v1] regulator: Use named initializers for arrays of i2c_device_data
From: Mark Brown @ 2026-05-18 17:13 UTC (permalink / raw)
To: Woody Douglass
Cc: Laurent Pinchart, Uwe Kleine-König (The Capable Hub),
Liam Girdwood, Markus Schneider-Pargmann, Michael Hennerich,
Support Opensource, Ivaylo Ivanov, Claudiu Beznea, Andrei Simion,
Saravanan Sekar, Matthias Brugger, AngeloGioacchino Del Regno,
Jagan Teki, Icenowy Zheng, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org
In-Reply-To: <54168033-c968-4565-afe8-2f1f8547ddf0@carnegierobotics.com>
[-- Attachment #1: Type: text/plain, Size: 469 bytes --]
On Mon, May 18, 2026 at 05:07:46PM +0000, Woody Douglass wrote:
> On 5/15/26 08:28, Laurent Pinchart wrote:
> > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender.
Please delete unneeded context from mails when replying. Doing this
makes it much easier to find your reply in the message, helping ensure
it won't be missed by people scrolling through the irrelevant quoted
material.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v1] virt: arm-cca-guest: use raw variant of smp_processor_id() in arm_cca_report_new()
From: Catalin Marinas @ 2026-05-18 17:21 UTC (permalink / raw)
To: Kohei Enju
Cc: Will Deacon, Sami Mujawar, Gavin Shan, Steven Price,
Suzuki K Poulose, linux-arm-kernel, linux-kernel
In-Reply-To: <agsSyRT7z-F5iBIp@FCCLS0092175.localdomain>
Hi Kohei,
On Mon, May 18, 2026 at 10:38:53PM +0900, Kohei Enju wrote:
> On 05/18 13:33, Catalin Marinas wrote:
> > On Mon, May 18, 2026 at 12:31:31PM +0900, Kohei Enju wrote:
> > > diff --git a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> > > index 0c9ea24a200c..2d450caee3e4 100644
> > > --- a/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> > > +++ b/drivers/virt/coco/arm-cca-guest/arm-cca-guest.c
> > > @@ -108,7 +108,7 @@ static int arm_cca_report_new(struct tsm_report *report, void *data)
> > > * allocate outblob based on the returned value from the 'init'
> > > * call and that cannot be done in an atomic context.
> > > */
> > > - cpu = smp_processor_id();
> > > + cpu = raw_smp_processor_id();
> >
> > That's just hiding the warning which might be genuine, irrespective of
> > what the comment says. Sashiko has some good points:
> >
> > https://sashiko.dev/#/patchset/20260518033157.1865498-1-enju.kohei@fujitsu.com
> >
> > Basically what guarantees that the cpu won't go offline? Can we use
> > migrate_disable() and ignore the smp_call_function_single() altogether?
> > It looks like a hack anyway.
[...]
> You've raised a very valid point about raw_smp_processor_id()
> potentially hiding a genuine issue. I agree this would be a concern in
> most contexts.
>
> However, this implementation was intentionally designed not to block CPU
> hotplug:
> https://lore.kernel.org/linux-arm-kernel/7a83461d-40fd-4e61-8833-5dae2abaf82b@arm.com/
>
> As mentioned in the thread above, the potential failure from the target
> CPU going offline (resulting in -ENXIO) is an expected and tolerated
> condition in this path.
> Using migrate_disable() would go against the non-blocking design goal.
>
> Given the context, the debug warning looks false positive for our
> specific use case to me, and I believe raw_smp_processor_id() correctly
> reflects the design intent by simply acquiring a CPU number without
> debug checks.
Thanks, I wasn't aware of the old discussion. If user-space can
tolerate, than it's fine.
Would you mind updating the comment above the changed line? It talks
about not allocating memory in atomic context, so migrate_disable()
would solve this. Just mention that it can't block CPU hotplug events
either and user-space can handle spurious errors.
With that:
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* Re: [PATCH] iommu: Allow device driver to use its own PASID space for SVA
From: Jason Gunthorpe @ 2026-05-18 17:52 UTC (permalink / raw)
To: Joonwon Kang
Cc: kirill.shutemov, Alexander.Grest, alexander.shishkin, amhetre,
baolu.lu, bp, dave.hansen, easwar.hariharan, hpa, iommu,
jacob.jun.pan, joro, jpb, kas, kees, kevin.tian, linux-arm-kernel,
linux-kernel, mingo, nicolinc, peterz, praan, robin.murphy,
ryasuoka, smostafa, sohil.mehta, tglx, will, x86, xin
In-Reply-To: <20260518090654.730478-1-joonwonkang@google.com>
On Mon, May 18, 2026 at 09:06:54AM +0000, Joonwon Kang wrote:
> > On Fri, May 15, 2026 at 09:46:05AM +0000, Joonwon Kang wrote:
> > > diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> > > index 0ca3912ecb7f..61e2e52105e5 100644
> > > --- a/arch/x86/kernel/traps.c
> > > +++ b/arch/x86/kernel/traps.c
> > > @@ -864,6 +864,8 @@ static bool try_fixup_enqcmd_gp(void)
> > > return false;
> > >
> > > pasid = mm_get_enqcmd_pasid(current->mm);
> > > + if (pasid == IOMMU_PASID_INVALID)
> > > + return false;
> >
> > If you do this then probably you should get rid of mm_valid_pasid(),
> > mm_get_enqcmd_pasid() already has the NULL check so the two functions
> > are kind of pointless.
> >
> > You also missed the other place calling mm_valid_pasid() that should
> > really be sensitive to this as well:
> >
> > static int prctl_enable_tagged_addr(struct mm_struct *mm, unsigned long nr_bits)
> > {
> > [..]
> > if (mm_valid_pasid(mm) &&
> > !test_bit(MM_CONTEXT_FORCE_TAGGED_SVA, &mm->context.flags))
> > return -EINVAL;
> >
> > Make that removal a prep patch
> >
>
> Thanks for pointing this out. I think mm_valid_pasid() is to check if SVA
> is currently in action while mm_get_enqcmd_pasid() is to get the PASID for
> "ENQCMD instruction execution".
> Since it is now possible with this patch to activate SVA without involving
> EL0(for ENQCMD-like instructions),
I see, this thing about which is about LAM should remain, yes
But all the "EL0" machinery about trapping and enabling ENQCMD should
be moved over to mm_get_enqcmd_pasid() and never call mm_valid_pasid()
Jason
^ permalink raw reply
* Re: [PATCH 0/3] iommu: Add PCI vendor:device ID to IOMMU fault logs
From: Jason Gunthorpe @ 2026-05-18 17:54 UTC (permalink / raw)
To: Robin Murphy
Cc: Oguz, Yigit, joro@8bytes.org, will@kernel.org,
baolu.lu@linux.intel.com, dwmw2@infradead.org,
suravee.suthikulpanit@amd.com, nicolinc@nvidia.com,
iommu@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <4cbd2bd2-9acc-4c72-a4f5-6c6cf31f71e1@arm.com>
On Mon, May 18, 2026 at 04:52:57PM +0100, Robin Murphy wrote:
> TBH I think the more appropriate solution would be to have vfio-pci register
> its own fault handler, wherein it can properly deal with rate-limiting
> and/or entirely suppressing fault reports from misbehaving userspace, and if
> and when it does want to log something it is then free to do that in
> whatever format it wants, independent of the underlying IOMMU driver.
+1
Jason
^ 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