* Re: [PATCH] clk: stm32: allow STM32MP COMPILE_TEST builds
From: Brian Masney @ 2026-05-19 14:06 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-clk, Michael Turquette, Stephen Boyd, Maxime Coquelin,
Alexandre Torgue, Nathan Chancellor, Nick Desaulniers,
Bill Wendling, Justin Stitt, open list,
moderated list:ARM/STM32 ARCHITECTURE,
moderated list:ARM/STM32 ARCHITECTURE,
open list:CLANG/LLVM BUILD SUPPORT:Keyword:b(?i:clang|llvm)b
In-Reply-To: <20260518221230.19879-1-rosenp@gmail.com>
Hi Rosen,
On Mon, May 18, 2026 at 03:12:30PM -0700, Rosen Penev wrote:
> COMMON_CLK_STM32MP already allows COMPILE_TEST, but the parent clock
> Makefile only descends into drivers/clk/stm32 for ARCH_STM32. Use the
> STM32MP clock symbol for that directory gate instead.
>
> Building the STM32MP21 and STM32MP25 clock drivers then requires direct
> linux/bitfield.h includes for FIELD_GET(), so add them as part of exposing
> that compile-test coverage.
The second one needs to be it's own separate patch, along with a Fixes
tag.
Brian
>
> Tested with:
> make LLVM=1 ARCH=loongarch drivers/clk/stm32/
>
> Assisted-by: Codex:GPT-5.5
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/clk/Makefile | 2 +-
> drivers/clk/stm32/clk-stm32mp21.c | 1 +
> drivers/clk/stm32/clk-stm32mp25.c | 1 +
> 3 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 9c3a9703ad92..0cd2223de3ca 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -150,7 +150,7 @@ obj-y += spacemit/
> obj-$(CONFIG_PLAT_SPEAR) += spear/
> obj-y += sprd/
> obj-$(CONFIG_ARCH_STI) += st/
> -obj-$(CONFIG_ARCH_STM32) += stm32/
> +obj-$(CONFIG_COMMON_CLK_STM32MP) += stm32/
> obj-y += starfive/
> obj-$(CONFIG_ARCH_SUNXI) += sunxi/
> obj-y += sunxi-ng/
> diff --git a/drivers/clk/stm32/clk-stm32mp21.c b/drivers/clk/stm32/clk-stm32mp21.c
> index c8a37b716bd5..3c143371c77e 100644
> --- a/drivers/clk/stm32/clk-stm32mp21.c
> +++ b/drivers/clk/stm32/clk-stm32mp21.c
> @@ -5,6 +5,7 @@
> */
>
> #include <linux/bus/stm32_firewall_device.h>
> +#include <linux/bitfield.h>
> #include <linux/clk-provider.h>
> #include <linux/io.h>
> #include <linux/platform_device.h>
> diff --git a/drivers/clk/stm32/clk-stm32mp25.c b/drivers/clk/stm32/clk-stm32mp25.c
> index 52f0e8a12926..cc95fac66449 100644
> --- a/drivers/clk/stm32/clk-stm32mp25.c
> +++ b/drivers/clk/stm32/clk-stm32mp25.c
> @@ -5,6 +5,7 @@
> */
>
> #include <linux/bus/stm32_firewall_device.h>
> +#include <linux/bitfield.h>
> #include <linux/clk-provider.h>
> #include <linux/io.h>
> #include <linux/platform_device.h>
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH v4 04/13] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
From: Mostafa Saleh @ 2026-05-19 14:04 UTC (permalink / raw)
To: Aneesh Kumar K.V
Cc: Jason Gunthorpe, 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: <yq5ah5o3sdn3.fsf@kernel.org>
On Tue, May 19, 2026 at 07:30:16PM +0530, Aneesh Kumar K.V wrote:
> Mostafa Saleh <smostafa@google.com> writes:
>
> >> >
> >> > I am still running more tests, but looking more into it. Setting
> >> > force_dma_unencrypted() to true for pKVM guests is wrong, as the
> >> > guest shouldn’t try to decrypt arbitrary memory as it can include
> >> > sensitive information (for example in case of virtio sub-page
> >> > allocation) and should strictly rely on the restricted-dma-pool
> >> > for that.
> >>
> >> ??
> >>
> >> Where does force_dma_unencrypted() cause arbitary memory passed into
> >> the DMA API to be decrypted? That should never happen???
> >
> > Sorry, maybe arbitrary is not the right expression again :)
> > I mean that, with emulated devices that use the DMA-API under pKVM,
> > they will map memory coming from other layers (VFS, net) through
> > vitrio-block, virtio-net... These can be smaller than a page, and
> >
>
> Don't we PAGE_ALIGN these requests?
>
> dma_direct_alloc
> size = PAGE_ALIGN(size);
>
> iommu_dma_alloc_pages
> size_t alloc_size = PAGE_ALIGN(size);
>
>
For allocation, yes, and that's fine because we bring memory from
the pool.
But not for mapping, as dma_direct_map_phys(), where the memory is
allocated from the driver or other parts in the kernel and the page
may be shared with other kernel components.
Thanks,
Mostafa
>
> > using force_dma_unencrypted() will share the whole page.
> > And as discussed, that leaks sensitive information to the untrusted
> > host.
> > I am currently investigating passing iova/phys/size
> > to force_dma_unencrypted() and then we can share pages inplace only
> > if possible without leaking extra information.
> > I am trying to get some performance results first. But the tricky part
> > is to get the semantics right, I believe in that case those devices
> > shouldn’t use restricted-dma-pools as those should always force
> > bouncing. Instead bouncing happens through the default SWIOTLB pool,
> > if not possible to decrypt in place.
> >
>
> -aneesh
^ permalink raw reply
* Re: [PATCH v4 04/13] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
From: Aneesh Kumar K.V @ 2026-05-19 14:00 UTC (permalink / raw)
To: Mostafa Saleh, Jason Gunthorpe
Cc: 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: <agxolksC_1nfO34X@google.com>
Mostafa Saleh <smostafa@google.com> writes:
> On Tue, May 19, 2026 at 10:29:11AM -0300, Jason Gunthorpe wrote:
>> On Tue, May 19, 2026 at 11:04:37AM +0000, Mostafa Saleh wrote:
>> > On Thu, May 14, 2026 at 08:13:25PM +0530, Aneesh Kumar K.V wrote:
>> > > >>
>> > > >> What I meant was that we need a generic way to identify a pKVM guest, so
>> > > >> that we can use it in the conditional above.
>> > > >
>> > > > I have this patch, with that I can boot with your series unmodified,
>> > > > but I will need to do more testing.
>> > > >
>> > >
>> > > Thanks, I can add this to the series once you complete the required testing.
>> > >
>> >
>> > I am still running more tests, but looking more into it. Setting
>> > force_dma_unencrypted() to true for pKVM guests is wrong, as the
>> > guest shouldn’t try to decrypt arbitrary memory as it can include
>> > sensitive information (for example in case of virtio sub-page
>> > allocation) and should strictly rely on the restricted-dma-pool
>> > for that.
>>
>> ??
>>
>> Where does force_dma_unencrypted() cause arbitary memory passed into
>> the DMA API to be decrypted? That should never happen???
>
> Sorry, maybe arbitrary is not the right expression again :)
> I mean that, with emulated devices that use the DMA-API under pKVM,
> they will map memory coming from other layers (VFS, net) through
> vitrio-block, virtio-net... These can be smaller than a page, and
>
Don't we PAGE_ALIGN these requests?
dma_direct_alloc
size = PAGE_ALIGN(size);
iommu_dma_alloc_pages
size_t alloc_size = PAGE_ALIGN(size);
> using force_dma_unencrypted() will share the whole page.
> And as discussed, that leaks sensitive information to the untrusted
> host.
> I am currently investigating passing iova/phys/size
> to force_dma_unencrypted() and then we can share pages inplace only
> if possible without leaking extra information.
> I am trying to get some performance results first. But the tricky part
> is to get the semantics right, I believe in that case those devices
> shouldn’t use restricted-dma-pools as those should always force
> bouncing. Instead bouncing happens through the default SWIOTLB pool,
> if not possible to decrypt in place.
>
-aneesh
^ permalink raw reply
* Re: [PATCH] coresight: fix resource leaks on path build failure
From: James Clark @ 2026-05-19 13:57 UTC (permalink / raw)
To: Jie Gan
Cc: coresight, linux-arm-kernel, linux-kernel, Suzuki K Poulose,
Mike Leach, Leo Yan, Alexander Shishkin, Mathieu Poirier,
Tingwei Zhang, Greg Kroah-Hartman
In-Reply-To: <20260513-fix-memory-leak-issue-v1-1-49822d7bc7d4@oss.qualcomm.com>
On 13/05/2026 2:32 am, Jie Gan wrote:
> Two related leaks when _coresight_build_path() encounters an error after
> coresight_grab_device() has already incremented the pm_runtime, module,
> and device references for a node:
>
> 1. In _coresight_build_path(), if kzalloc_obj() for the path node fails
> after coresight_grab_device() succeeds, coresight_drop_device() was
> never called, permanently leaking all three references.
>
> 2. In coresight_build_path(), on failure the partial path was freed with
> kfree(path) instead of coresight_release_path(path). kfree() only
> frees the coresight_path struct itself; it does not iterate path_list
> to call coresight_drop_device() and kfree() for each coresight_node
> already added by deeper recursive calls, leaking both the pm_runtime,
> module, and device references and the node memory for every element
> on the partial path.
>
> Fix both by adding coresight_drop_device() in the OOM unwind of
> _coresight_build_path(), and replacing kfree(path) with
> coresight_release_path(path) in coresight_build_path().
>
> Fixes: 32b0707a4182 ("coresight: Add try_get_module() in coresight_grab_device()")
> Fixes: b3e94405941e ("coresight: associating path with session rather than tracer")
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
> ---
> drivers/hwtracing/coresight/coresight-core.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-core.c b/drivers/hwtracing/coresight/coresight-core.c
> index 46f247f73cf6..c1354ea8e11d 100644
> --- a/drivers/hwtracing/coresight/coresight-core.c
> +++ b/drivers/hwtracing/coresight/coresight-core.c
> @@ -825,8 +825,10 @@ static int _coresight_build_path(struct coresight_device *csdev,
> return ret;
>
> node = kzalloc_obj(struct coresight_node);
> - if (!node)
> + if (!node) {
> + coresight_drop_device(csdev);
> return -ENOMEM;
> + }
>
> node->csdev = csdev;
> list_add(&node->link, &path->path_list);
> @@ -851,7 +853,7 @@ struct coresight_path *coresight_build_path(struct coresight_device *source,
>
> rc = _coresight_build_path(source, source, sink, path);
> if (rc) {
> - kfree(path);
> + coresight_release_path(path);
> return ERR_PTR(rc);
> }
>
>
> ---
> base-commit: e98d21c170b01ddef366f023bbfcf6b31509fa83
> change-id: 20260513-fix-memory-leak-issue-034b4a45265e
>
> Best regards,
Looks good to me, but sashiko is complaining:
https://sashiko.dev/#/patchset/20260513-fix-memory-leak-issue-v1-1-49822d7bc7d4%40oss.qualcomm.com
I'm trying to understand why it's saying that, but I think the scenario
is that if there are multiple correct paths to a sink, when one path
partially fails and a second path succeeds you could get a path_list
with some garbage entries in it.
That's kind of a different and existing issue to the one you've fixed,
and assumes that multiple paths to one sink are possible, which I'm not
sure is supported?
It might be as easy as breaking the loop early for any return value
other than -ENODEV, but I'll leave it to you to decide whether to do
that here or not.
Reviewed-by: James Clark <james.clark@linaro.org>
^ permalink raw reply
* Re: [PATCH v02] mailbox: pcc: report errors for PCC clients
From: lihuisong (C) @ 2026-05-19 13:54 UTC (permalink / raw)
To: Adam Young, Sudeep Holla, Jassi Brar
Cc: linux-kernel, 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: <20260518193006.27425-1-admiyo@os.amperecomputing.com>
On 5/19/2026 3:30 AM, Adam Young wrote:
> The tx_done callback function has a return code (rc) parameter
> that the tx_done callback can use to determine how to handle an error.
> However the IRQ handler was not setting that value if there is an error.
>
> The following clients are affected:
>
> drivers/acpi/cppc_acpi.c
> drivers/i2c/busses/i2c-xgene-slimpro.c
> drivers/hwmon/xgene-hwmon.c
> drivers/soc/hisilicon/kunpeng_hccs.c
> drivers/devfreq/hisi_uncore_freq.c
>
> All of these only use the error code to report, so they
> are expecting an error code to come thorugh, but they
> do not modify behavior based on this code.
>
> In the case of an error code in the IRQ, the handler was returning
> IRQ_NONE which is not correct: the IRQ handler was matched
> to the IRQ. This mean that multiple error codes returned from
> a PCC triggered interrupt would end up disabling the device.
>
> In addition, if the error code IRQ was coming from a Type4 Device that was
> expecting an IRQ response, that device would then be hung.
>
> Fixes: c45ded7e1135 ("mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4)")
Not fix above commit.
mbox_chan_txdone() was added in below patch.
Fixes: 9c753f7c953c (mailbox: pcc: Mark Tx as complete in PCC IRQ handler)
> Signed-off-by: Adam Young <admiyo@os.amperecomputing.com>
>
> ---
> ---
> drivers/mailbox/pcc.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
> index 636879ae1db7..16b9ce087b9e 100644
> --- a/drivers/mailbox/pcc.c
> +++ b/drivers/mailbox/pcc.c
> @@ -314,6 +314,7 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
> {
> struct pcc_chan_info *pchan;
> struct mbox_chan *chan = p;
> + int rc;
>
> pchan = chan->con_priv;
>
> @@ -327,8 +328,7 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
> if (!pcc_mbox_cmd_complete_check(pchan))
> return IRQ_NONE;
>
> - if (pcc_mbox_error_check_and_clear(pchan))
> - return IRQ_NONE;
> + rc = pcc_mbox_error_check_and_clear(pchan);
I think it is not necessary. This function just return -EIO on failure.
>
> /*
> * Clear this flag after updating interrupt ack register and just
> @@ -337,8 +337,9 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
> * required to avoid any possible race in updatation of this flag.
> */
> pchan->chan_in_use = false;
> - mbox_chan_received_data(chan, NULL);
> - mbox_chan_txdone(chan, 0);
> + if (!rc)
> + mbox_chan_received_data(chan, NULL);
> + mbox_chan_txdone(chan, rc);
@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.
This is done after executing mbox_chan_received_data(). So I think this
line in this function is redundant.
Can you take a look at this agian?
>
> pcc_chan_acknowledge(pchan);
>
^ permalink raw reply
* Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations
From: Paolo Bonzini @ 2026-05-19 13:53 UTC (permalink / raw)
To: David Woodhouse
Cc: Marc Zyngier, Will Deacon, Jonathan Corbet, Shuah Khan, kvm,
Linux Doc Mailing List, Kernel Mailing List, Linux,
Sean Christopherson, Jim Mattson, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Raghavendra Rao Ananta, Eric Auger, Kees Cook, Arnd Bergmann,
Nathan Chancellor, linux-arm-kernel, kvmarm, linux-kselftest
In-Reply-To: <593a782c50f3c8656e13b36dfb975a67d43a908e.camel@infradead.org>
On Tue, May 19, 2026 at 3:00 PM David Woodhouse <dwmw2@infradead.org> wrote:
> Or some guest configurations which have only ever been tested under KVM
> could have a bug where they *rely* on the registers not being writable,
> and write values which are inconsistent with the rest of their
> configuration. Which breaks the moment those registers become writable.
Yeah, just having guests that worked by utter chance - but you still
don't want to break them - is the case that is most likely. Crappy
code that runs only under emulation/virtualization appears with
probability 1 over time.
Is this likely in this specific case---probably not, honestly.
Christoffer's patch dates back to 2018 (commit d53c2c29ae0d); *back
then* KVM/Arm was a lot less mature, and people developing for Arm on
vanilla upstream kernels have moved on from Linux 4.19.
I would still lean towards accepting the code considering the limited
complexity of the addition (in fact I like it more now that it uses
IIDR instead of v2_groups_user_writable, but that's taste). However,
there's a huge difference between setting expectations based on 2018
vs 2026 maturity, and perhaps that's why Marc overall is inclined to
put this in the category of pointless bug for bug compatibility?
In any case, there's no arguing over this documentation patch, which
is already a good thing to know.
Thanks,
Paolo
> And those hypothetical cases *do* happen. All of the time. There's a
> massive zoo of guest operating systems; not just the major players like
> Linux, FreeBSD and Windows but a whole bunch of embedded home-grown and
> network appliance kernels.
>
> Nobody is claiming that we shouldn't fix any bug ever.
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: iommu: arm,smmu: Document optional interconnects property
From: Bibek Kumar Patro @ 2026-05-19 13:53 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, iommu,
devicetree, linux-kernel
In-Reply-To: <20260518-mellow-robust-caterpillar-93fcaa@quoll>
On 5/18/2026 6:03 PM, Krzysztof Kozlowski wrote:
> On Sat, May 16, 2026 at 06:04:03PM +0530, Bibek Kumar Patro wrote:
>> Some SoC implementations require a bandwidth vote on an interconnect
>
> Then this should be disallowed for other devices in "allOf:".
>
As of now, we still are checking which all SoCs do not need this
interconnects field. So would we need to add the allOf here for now?
>> path before the SMMU register space is accessible. Add the optional
>> 'interconnects' property to the binding to allow platform DT nodes
>> to describe this path.
>>
>> The arm-smmu driver uses these properties to vote for bandwidth before
>> accessing any SMMU registers and releases the vote on runtime suspend.
>>
>> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>> ---
>> Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> index 06fb5c8e7547cb7a92823adc2772b94f747376a6..5cbf944f2d3e178b3723d4dbaa19ee0d33446979 100644
>> --- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
>> @@ -243,6 +243,15 @@ properties:
>> minItems: 1
>> maxItems: 3
>>
>> + interconnects:
>> + maxItems: 1
>> + description:
>> + Optional interconnect path to the SMMU register space. On some SoCs
>> + the SMMU registers are only accessible after a bandwidth vote has been
>
> Drivers are irrelevant here, drop. Also first sentence is redundant.
> Schema says what is and what is not optional.
>
Sure, got it. I will remove the "driver" quotation and "optional"
wording from both binding description and commit text.
Thanks & regards,
Bibek
> Best regards,
> Krzysztof
>
^ permalink raw reply
* [PATCH v2] KVM: arm64: vgic: free private_irqs when init fails after allocation
From: Michael Bommarito @ 2026-05-19 13:50 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Yao Yuan, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, linux-arm-kernel, kvmarm,
linux-kernel, stable
In-Reply-To: <20260517181331.367676-1-michael.bommarito@gmail.com>
Companion to commit 250f25367b58 ("KVM: arm64: Tear down vGIC on
failed vCPU creation"), which added the missing kvm_vgic_vcpu_destroy()
call to the kvm_share_hyp() failure path in kvm_arch_vcpu_create(). The
kvm_vgic_vcpu_init() failure path immediately above it has the same
shape and still needs the same cleanup.
Call kvm_vgic_vcpu_destroy() when kvm_vgic_vcpu_init() fails so private
IRQs allocated before a redistributor iodev registration failure are
released before the failed vCPU is freed.
Fixes: 03b3d00a70b5 ("KVM: arm64: vgic: Allocate private interrupts on demand")
Cc: stable@vger.kernel.org
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Yuan Yao <yaoyuan@linux.alibaba.com>
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
Changes in v2:
- Add the Fixes tag Marc agreed with.
- Add Yao's Reviewed-by tag.
- Trim the commit message.
arch/arm64/kvm/arm.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
index 176cbe8baad30..5d5e2f81b9c94 100644
--- a/arch/arm64/kvm/arm.c
+++ b/arch/arm64/kvm/arm.c
@@ -554,8 +554,10 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
kvm_destroy_mpidr_data(vcpu->kvm);
err = kvm_vgic_vcpu_init(vcpu);
- if (err)
+ if (err) {
+ kvm_vgic_vcpu_destroy(vcpu);
return err;
+ }
err = kvm_share_hyp(vcpu, vcpu + 1);
if (err)
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v2] spi: atmel: fix DMA channel and bounce buffer leaks
From: Mark Brown @ 2026-05-19 13:48 UTC (permalink / raw)
To: Felix Gu
Cc: Ryan Wanner, Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Radu Pirea, Richard Genoud, Wenyou Yang, linux-spi,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260517-atmel-v2-1-36c836be6345@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]
On Sun, May 17, 2026 at 06:39:54PM +0800, Felix Gu wrote:
> Changes in v2:
> - Switch to devm-managed variants to fix Claudiu Beznea's comment.
The switch to devm is possibly a bit enthusiastic.
> - host->dma_tx = dma_request_chan(dev, "tx");
> + host->dma_tx = devm_dma_request_chan(dev, "tx");
> if (IS_ERR(host->dma_tx)) {
> - host->dma_rx = dma_request_chan(dev, "rx");
> + host->dma_rx = devm_dma_request_chan(dev, "rx");
> if (IS_ERR(host->dma_rx)) {
> err = PTR_ERR(host->dma_rx);
> /*
> @@ -580,12 +581,27 @@ static int atmel_spi_configure_dma(struct spi_controller *host,
> * requested tx channel.
> */
> dev_dbg(dev, "No RX DMA channel, DMA is disabled\n");
> - goto error;
> + host->dma_rx = NULL;
> + return err;
> }
If the rx allocation fails then instead of jumping to cleanup we'll
return, and since the driver supports PIO operation it'll still be able
to probe...
> -error:
> - if (!IS_ERR(host->dma_rx))
> - dma_release_channel(host->dma_rx);
> - if (!IS_ERR(host->dma_tx))
> - dma_release_channel(host->dma_tx);
...with the tx DMA channel still allocated. This is very much an edge
case though, how much it matters is very questionalble.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v15 0/9] Add Type-C DP support for RK3399 EVB IND board
From: Heikki Krogerus @ 2026-05-19 13:43 UTC (permalink / raw)
To: Chaoyi Chen
Cc: Greg Kroah-Hartman, Dmitry Baryshkov, Peter Chen, Luca Ceresoli,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vinod Koul,
Kishon Vijay Abraham I, Heiko Stuebner, Sandy Huang, Andy Yan,
Yubing Zhang, Frank Wang, Andrzej Hajda, Neil Armstrong,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Amit Sunil Dhamne, Dragan Simic, Johan Jonker,
Diederik de Haas, Peter Robinson, Hugh Cole-Baker, linux-usb,
devicetree, linux-kernel, linux-phy, linux-arm-kernel,
linux-rockchip, dri-devel, Chaoyi Chen
In-Reply-To: <20260304094152.92-1-kernel@airkyi.com>
Hi,
On Wed, Mar 04, 2026 at 05:41:43PM +0800, Chaoyi Chen wrote:
> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>
> This series focuses on adding Type-C DP support for USBDP PHY and DP
> driver. The USBDP PHY and DP will perceive the changes in cable status
> based on the USB PD and Type-C state machines provided by TCPM. Before
> this, the USBDP PHY and DP controller of RK3399 sensed cable state
> changes through extcon, and devices such as the RK3399 Gru-Chromebook
> rely on them. This series should not break them.
What's the status with this series?
Are these inteded to go via the DRM tree?
thanks,
> ====
> 1. DisplayPort HPD status notify
>
> Before v7, I implemented a variety of DP HPD status notify. However,
> they all had various problems and it was difficult to become a generic
> solution.
>
> Under the guidance of Heikki and Dmitry, a decoupled notification
> method between the TypeC and DRM subsystems was introduced in v7.
> First, a notification is sent when TypeC registers a new altmode.
> Then, a generic DP AUX HPD bridge is implemented on the DRM side.
>
> During v7-v10, we added a new notifier in typec to notify the altmode
> device register event. With the help of Greg and Heikki, we implemented
> the reuse of notifiers for the type bus itself in patch1 of v11.
>
> The USB subsystem related parts have already been merged into the
> usb-next branch in v13 [0][1]. Therefore, this series no longer includes
> these patches starting from v14. Thanks to Greg and Heikki!
>
> [0]: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=67ab45426215c7fdccb65aecd4cac15bbe4dfcbb
> [1]: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git/commit/?h=usb-next&id=4dee13db29de6dd869af9b3827e1ff569644e838
>
> That makes it redundant for each Type-C controller driver to implement
> a similar DP AUX HPD bridge in embedded scenarios.
>
> ====
> 2. Altmode switching and orientation switching for USBDP PHY
>
> For USB Type-C interfaces, an external Type-C controller chip assists
> by detecting cable attachment, determining plug orientation, and
> reporting USB PD message. The USB/DP combo PHY supports software
> configurable pin mapping and DisplayPort lane assignment. Based on
> these message, the combo PHY can perform both altmode switching and
> orientation switching via software.
>
> The RK3399 EVB IND board has a Type-C interface DisplayPort. It use
> fusb302 chip as Type-C controller. The connection diagram is shown below:
>
> fusb302 chip +---> USB2.0 PHY ----> DWC3 USB controller
> |
> +---> USB/DP PHY0 +--> CDN-DP controller
> |
> +--> DWC3 USB controller
>
> ====
> 3. Multiple bridge model for RK3399 CDN-DP
>
> The RK3399 has two USB/DP combo PHY and one CDN-DP controller. And
> the CDN-DP can be switched to output to one of the PHYs.
>
> USB/DP PHY0 ---+
> | <----> CDN-DP controller
> USB/DP PHY1 ---+
>
> In previous versions, if both PHY ports were connected to DP,
> the CDN-DP driver would select the first PHY port for output.
>
> On Dmitry's suggestion, we introduced a multi-bridge model to support
> flexible selection of the output PHY port. For each PHY port, a
> separate encoder and bridge are registered.
>
> The change is based on the DRM AUX HPD bridge, rather than the
> extcon approach. This requires the DT to correctly describe the
> connections between the first bridge in bridge chain and DP
> controller. And Once the first bridge is obtained, we can get the
> last bridge corresponding to the USB-C connector, and then set the
> DRM connector's fwnode to the corresponding one to enable HPD
> notification.
>
> ====
> Patch1 add generic USB Type-C DP HPD bridge (Dmitry, Heikki).
> Patch2 add new API drm_aux_bridge_register_from_node() (Neil) .
> Patch3 add new Type-C mode switch for RK3399 USBDP phy binding (Krzysztof).
> Patch4 add typec_mux and typec_switch for RK3399 USBDP PHY.
> Patch5 add DRM AUX bridge support for RK3399 USBDP PHY (Neil).
> Patch6 drops CDN-DP's extcon dependency when Type-C is present (Dmitry).
> Patch7 add multiple bridges to support PHY port selection (Dmitry, Luca).
> Patch8 add missing dp_out port for RK3399 CDN-DP.
> Patch9 add Type-C DP support for RK3399 EVB IND board (Diederik, Peter).
>
> Changes in v15:
> - Link to V14: https://lore.kernel.org/all/20260119073100.143-1-kernel@airkyi.com/
> - Improve clarity by inlining drm_bridge_get() in assignment (Luca).
>
> Changes in v14:
> - Link to V13: https://lore.kernel.org/all/20251208015500.94-1-kernel@airkyi.com/
> - Drop the patches for the USB Type-C subsusytem part, as they have
> already been merged into usb-next.
>
> Changes in v13:
> - Link to V12: https://lore.kernel.org/all/20251204063109.104-1-kernel@airkyi.com/
> - Only register drm dp hpd bridge for typec port altmode device.
>
> Changes in v12:
> - Link to V11: https://lore.kernel.org/all/20251128020405.90-1-kernel@airkyi.com/
> - Add missing Signed-off-by line.
>
> Changes in v11:
> - Link to V10: https://lore.kernel.org/all/20251120022343.250-1-kernel@airkyi.com/
> - Switch to using typec bus notifiers.
>
> Changes in v10:
> - Link to V9: https://lore.kernel.org/all/20251111105040.94-1-kernel@airkyi.com/
> - Notify TYPEC_ALTMODE_UNREGISTERED when altmode removed.
> - Add drm_aux_bridge_register_from_node().
> - Fix refcount usage of drm_bridge.
>
> Changes in v9:
> - Link to V8: https://lore.kernel.org/all/20251029071435.88-1-kernel@airkyi.com/
> - Remove the exposed DRM_AUX_HPD_BRIDGE option, and select
> DRM_AUX_HPD_TYPEC_BRIDGE when it is available.
> - Add usb role switch for Type-C.
> - Remove USB2 PHY in Type-C connection.
> - ...
>
> Changes in v8:
> - Link to V7: https://lore.kernel.org/all/20251023033009.90-1-kernel@airkyi.com/
> - Export all typec device types for identification.
> - Merge generic DP HPD bridge into one module.
> - Fix coding style.
>
> Changes in v7:
> - Link to V6: https://lore.kernel.org/all/20251016022741.91-1-kernel@airkyi.com/
> - Add notifier functions for Type-C core.
> - Add generic USB Type-C DP HPD bridge.
>
> Changes in v6:
> - Link to V5: https://lore.kernel.org/all/20251011033233.97-1-kernel@airkyi.com/
> - Fix depend in Kconfig.
> - Check DP svid in tcphy_typec_mux_set().
> - Remove mode setting in tcphy_orien_sw_set().
> - Rename some variable names.
> - Attach the DP bridge to the next bridge.
>
> Changes in v5:
> - Link to V4: https://lore.kernel.org/all/20250922012039.323-1-kernel@airkyi.com/
> - Remove the calls related to `drm_aux_hpd_bridge_notify()`.
> - Place the helper functions in the same compilation unit.
> - Add more comments about parent device.
> - Add DRM AUX bridge support for RK3399 USBDP PHY
> - By parsing the HPD bridge chain, set the connector's of_node to the
> of_node corresponding to the USB-C connector.
> - Return EDID cache when other port is already enabled.
>
> Changes in v4:
> - Link to V3: https://lore.kernel.org/all/20250729090032.97-1-kernel@airkyi.com/
> - Add default HPD device for DisplayPort altmode.
> - Introduce multiple bridges for CDN-DP.
> - ...
>
> Changes in v3:
> - Link to V2: https://lore.kernel.org/all/20250718062619.99-1-kernel@airkyi.com/
> - Add more descriptions to clarify the role of the PHY in switching.
> - Fix wrong vdo value.
> - Fix port node in usb-c-connector.
>
> Changes in v2:
> - Link to V1: https://lore.kernel.org/all/20250715112456.101-1-kernel@airkyi.com/
> - Reuse dp-port/usb3-port in rk3399-typec-phy binding.
> - Fix compile error when CONFIG_TYPEC is not enabled.
> - Notify DP HPD state by USB/DP PHY.
> - Ignore duplicate HPD events.
> - Add endpoint to link DP PHY and DP controller.
> - Fix devicetree coding style.
>
> Chaoyi Chen (9):
> drm/bridge: Implement generic USB Type-C DP HPD bridge
> drm/bridge: aux: Add drm_aux_bridge_register_from_node()
> dt-bindings: phy: rockchip: rk3399-typec-phy: Support mode-switch
> phy: rockchip: phy-rockchip-typec: Add typec_mux/typec_switch support
> phy: rockchip: phy-rockchip-typec: Add DRM AUX bridge
> drm/rockchip: cdn-dp: Support handle lane info without extcon
> drm/rockchip: cdn-dp: Add multiple bridges to support PHY port
> selection
> arm64: dts: rockchip: Add missing dp_out port for RK3399 CDN-DP
> arm64: dts: rockchip: rk3399-evb-ind: Add support for DisplayPort
>
> .../phy/rockchip,rk3399-typec-phy.yaml | 6 +
> arch/arm64/boot/dts/rockchip/rk3399-base.dtsi | 10 +-
> .../boot/dts/rockchip/rk3399-evb-ind.dts | 147 +++++++
> drivers/gpu/drm/bridge/Kconfig | 10 +
> drivers/gpu/drm/bridge/Makefile | 1 +
> drivers/gpu/drm/bridge/aux-bridge.c | 24 +-
> .../gpu/drm/bridge/aux-hpd-typec-dp-bridge.c | 49 +++
> drivers/gpu/drm/rockchip/Kconfig | 1 +
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 349 +++++++++++++---
> drivers/gpu/drm/rockchip/cdn-dp-core.h | 18 +-
> drivers/phy/rockchip/Kconfig | 3 +
> drivers/phy/rockchip/phy-rockchip-typec.c | 373 +++++++++++++++++-
> include/drm/bridge/aux-bridge.h | 6 +
> 13 files changed, 913 insertions(+), 84 deletions(-)
> create mode 100644 drivers/gpu/drm/bridge/aux-hpd-typec-dp-bridge.c
>
> --
> 2.51.1
--
heikki
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Lorenzo Stoakes @ 2026-05-19 13:42 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Barry Song, Matthew Wilcox, surenb, 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: <b65722ee-6476-4038-bfbb-44a32b3544fd@kernel.org>
On Mon, May 18, 2026 at 11:53:37AM +0200, David Hildenbrand (Arm) wrote:
> On 5/17/26 10:45, Barry Song wrote:
> > On Sat, May 2, 2026 at 1:58 AM Matthew Wilcox <willy@infradead.org> wrote:
> >>
> >> On Sat, May 02, 2026 at 01:44:34AM +0800, Barry Song wrote:
> >>>
> >>> It doesn’t have to involve unmapping or applying mprotect to
> >>> the entire VMA—just a portion of it is sufficient.
> >>
> >> Yes, but that still fails to answer "does this actually happen". How much
> >> performance is all this complexity in the page fault handler buying us?
> >> If you don't answer this question, I'm just going to go in and rip it
> >> all out.
> >>
> >
> > Hi Matthew (and Lorenzo, Jan, and anyone else who may be
> > waiting for answers),
> >
> > As promised during LSF/MM/BPF, we conducted thorough
> > testing on Android phones to determine whether performing
> > I/O in `filemap_fault()` can block `vma_start_write()`.
> > I wanted to give a quick update on this question.
> >
> > Nanzhe at Xiaomi created tracing scripts and ran various
> > applications on Android devices with I/O performed under
> > the VMA lock in `filemap_fault()`. We found that:
> >
> > 1. There are very few cases where unmap() is blocked by
> > page faults. I assume this is due to buggy user code
> > or poor synchronization between reads and unmap().
> > So I assume it is not a problem.
> >
> > 2. We observed many cases where `vma_start_write()`
> > is blocked by page-fault I/O in some applications.
> > The blocking occurs in the `dup_mmap()` path during
> > fork().
> >
> > With Suren's commit fb49c455323ff ("fork: lock VMAs of
> > the parent process when forking"), we now always hold
> > `vma_write_lock()` for each VMA. Note that the
> > `mmap_lock` write lock is also held, which could lead to
> > chained waiting if page-fault I/O is performed without
> > releasing the VMA lock.
> >
> > My gut feeling is that Suren's commit may be overshooting,
> > so my rough idea is that we might want to do something like
> > the following (we haven't tested it yet and it might be
> > wrong):
> >
> > diff --git a/mm/mmap.c b/mm/mmap.c
> > index 2311ae7c2ff4..5ddaf297f31a 100644
> > --- a/mm/mmap.c
> > +++ b/mm/mmap.c
> > @@ -1762,7 +1762,13 @@ __latent_entropy int dup_mmap(struct mm_struct
> > *mm, struct mm_struct *oldmm)
> > for_each_vma(vmi, mpnt) {
> > struct file *file;
> >
> > - retval = vma_start_write_killable(mpnt);
> > + /*
> > + * For anonymous or writable private VMAs, prevent
> > + * concurrent CoW faults.
> > + */
> > + if (!mpnt->vm_file || (!(mpnt->vm_flags & VM_SHARED) &&
> > + (mpnt->vm_flags & VM_WRITE)))
> > + retval = vma_start_write_killable(mpnt);
>
> Likely is_cow_mapping() is what you would want to check to handle VMAs that
> could have anonymous pages in them.
Yes :) I made pretty much the same comment though I forgot the correct helper :P
>
> --
> Cheers,
>
> David
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH v4 04/13] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
From: Mostafa Saleh @ 2026-05-19 13:41 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Aneesh Kumar K.V, 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: <20260519132911.GA7702@ziepe.ca>
On Tue, May 19, 2026 at 10:29:11AM -0300, Jason Gunthorpe wrote:
> On Tue, May 19, 2026 at 11:04:37AM +0000, Mostafa Saleh wrote:
> > On Thu, May 14, 2026 at 08:13:25PM +0530, Aneesh Kumar K.V wrote:
> > > >>
> > > >> What I meant was that we need a generic way to identify a pKVM guest, so
> > > >> that we can use it in the conditional above.
> > > >
> > > > I have this patch, with that I can boot with your series unmodified,
> > > > but I will need to do more testing.
> > > >
> > >
> > > Thanks, I can add this to the series once you complete the required testing.
> > >
> >
> > I am still running more tests, but looking more into it. Setting
> > force_dma_unencrypted() to true for pKVM guests is wrong, as the
> > guest shouldn’t try to decrypt arbitrary memory as it can include
> > sensitive information (for example in case of virtio sub-page
> > allocation) and should strictly rely on the restricted-dma-pool
> > for that.
>
> ??
>
> Where does force_dma_unencrypted() cause arbitary memory passed into
> the DMA API to be decrypted? That should never happen???
Sorry, maybe arbitrary is not the right expression again :)
I mean that, with emulated devices that use the DMA-API under pKVM,
they will map memory coming from other layers (VFS, net) through
vitrio-block, virtio-net... These can be smaller than a page, and
using force_dma_unencrypted() will share the whole page.
And as discussed, that leaks sensitive information to the untrusted
host.
I am currently investigating passing iova/phys/size
to force_dma_unencrypted() and then we can share pages inplace only
if possible without leaking extra information.
I am trying to get some performance results first. But the tricky part
is to get the semantics right, I believe in that case those devices
shouldn’t use restricted-dma-pools as those should always force
bouncing. Instead bouncing happens through the default SWIOTLB pool,
if not possible to decrypt in place.
Thanks,
Mostafa
>
> Jason
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Lorenzo Stoakes @ 2026-05-19 13:39 UTC (permalink / raw)
To: Yang Shi
Cc: Barry Song, Matthew Wilcox, 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: <agxfLNuLCAT3F4cW@lucifer>
On Tue, May 19, 2026 at 02:12:10PM +0100, Lorenzo Stoakes wrote:
> On Mon, May 18, 2026 at 02:21:14PM -0700, Yang Shi wrote:
> > Maybe a little bit off topic. This is an interesting idea. It seems
> > possible we don't have to take vma write lock unconditionally. IIUC
> > the write lock is mainly used to serialize against page fault and
> > madvise, right? I got a crazy idea off the top of my head. We may be
>
> Err no, it serialises against literally any modification or read of any
> characteristic of VMAs.
>
> > able to just take vma write lock iff vma->anon_vma is not NULL.
>
> Except if we don't take it and vma->anon_vma is NULL, then somebody can
> anon_vma_prepare() and change vma->anon_vma midway through a fork and completely
> screw up the anon_vma fork hierarchy.
correction: this won't happen as per Barry (see - I managed to confuse myself
here :), since for vma->anon_vma install we take the mmap read lock.
BUT we also have to consider other cases.
>
> So no.
>
> >
> > First of all, write mmap_lock is held, so the vma can't go or be
> > changed under us.
>
> vma->anon_vma can be changed.
Correction: no it can't :)
>
> >
> > Secondly, if vma->anon_vma is NULL, it basically means either no page
> > fault happened or no cow happened, so there is no page table to copy,
> > this is also what copy_page_range() does currently. So we can shrink
> > the critical section to:
>
> Firstly, with no VMA write lock, !vma->anon_vma means a fault can race and
> secondly copy_page_range() checks vma_needs_copy(), there are other cases - PFN
> maps, mixed maps, UFFD W/P (ugh), guard regions.
>
> So yeah this isn't sufficient.
However this is true...
>
> >
> > if (vma->anon_vma) {
> > vma_start_write_killable(src_vma);
> > anon_vma_fork(dst_vma, src_vma);
> > copy_page_range(dst_vma, src_vma);
> > }
>
> Yeah that's totally broken fo reasons above as I said :)
>
> >
> > But page fault can happen before write mmap_lock is taken, when we
> > check vma->anon_vma, it is possible it has not been set up yet. But it
> > seems to be equivalent to page fault after fork and won't break the
> > semantic.
>
> It will totally break how the anon_vma hierarchy works :) See the links at the
> top of https://ljs.io/talks for a link to various slides on anon_vma behaviour
> (it's really a pain to think about because it's a super broken abstraction).
>
> You could end up with a CoW mapping that's unreachable from rmap and you could
> get some nasty issues with page table entries pointing at freed folios :)
Correction: actually we should be safe given mmap read lock on anon_vma install.
>
> >
> > Anyway, just a crazy idea, I may miss some corner cases.
>
> Yeah sorry to push back here but this is just not a viable approach.
>
> And this is forgetting that we have relied on page faults being blocked by fork
> _forever_, who knows what else has baked in assumptions about that
> serialisation.
>
> Forking is one of the nastiest parts of mm and has had multiple, subtle, corner
> case breakages that have been a nightmare to deal with.
>
> So I'm very much against changing this behaviour to try to fix something in the
> fault path.
>
> We should address the fault path issues in the fault path :)
Above still all true though.
>
> >
> > Thanks,
> > Yang
> >
> > }
> >
> > >
> > > Based on the above, we may want to re-check whether fork()
> > > can be blocked by page faults. At the same time, if Suren,
> > > you, or anyone else has any comments, please feel free to
> > > share them.
> > >
> > > Best Regards
> > > Barry
> > >
>
> Cheers, Lorenzo
So still a nope :)
Cheers, Lorenzo
^ 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-19 13:39 UTC (permalink / raw)
To: Mostafa Saleh
Cc: Aneesh Kumar K.V (Arm), 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: <agxETC1rXBUSkWYg@google.com>
On Tue, May 19, 2026 at 11:06:52AM +0000, Mostafa Saleh wrote:
> > > One other interesting case for device-passthrough is non-coherent
> > > devices which then require private pools for bouncing.
> >
> > Why does shared/private matter for bouncing? Why do you need to bounce
> > at all? Do cmo's not work in pkvm guests?
>
> At the moment, in iommu_dma_map_phys(), if a non coherent device
> tries to map an unaligned address or size it will be bounced.
Sure, that's fine.
> In pKVM, dma-iommu is used for assigned devices which operate on
> private memory, so bouncing that through the SWIOTLB would leak
> information from the guest as the SWIOTLB is decrypted.
Yes, a device that can do private access should not be using a shared
SWIOTLB, that should be part of the selection logic inside the SWIOTLB
stuff..
Jason
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Lorenzo Stoakes @ 2026-05-19 13:34 UTC (permalink / raw)
To: Barry Song
Cc: Yang Shi, Matthew Wilcox, 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_4w_-Y8qNLDeLX9OWpLpK01YG2bF-N6_mGypgsauvfCvkA@mail.gmail.com>
On Tue, May 19, 2026 at 07:07:37PM +0800, Barry Song wrote:
> On Tue, May 19, 2026 at 5:21 AM Yang Shi <shy828301@gmail.com> wrote:
> >
> > On Sun, May 17, 2026 at 1:45 AM Barry Song <baohua@kernel.org> wrote:
> > >
> > > On Sat, May 2, 2026 at 1:58 AM Matthew Wilcox <willy@infradead.org> wrote:
> > > >
> > > > On Sat, May 02, 2026 at 01:44:34AM +0800, Barry Song wrote:
> > > > > On Fri, May 1, 2026 at 10:57 PM Matthew Wilcox <willy@infradead.org> wrote:
> > > > > >
> > > > > > On Fri, May 01, 2026 at 06:49:58AM +0800, Barry Song wrote:
> > > > > > > 1. There is no deterministic latency for I/O completion. It depends on
> > > > > > > both the hardware and the software stack (bio/request queues and the
> > > > > > > block scheduler). Sometimes the latency is short; at other times it can
> > > > > > > be quite long. In such cases, a high-priority thread performing operations
> > > > > > > such as mprotect, unmap, prctl_set_vma, or madvise may be forced to wait
> > > > > > > for an unpredictable amount of time.
> > > > > >
> > > > > > But does that actually happen? I find it hard to believe that thread A
> > > > > > unmaps a VMA while thread B is in the middle of taking a page fault in
> > > > > > that same VMA. mprotect() and madvise() are more likely to happen, but
> > > > > > it still seems really unlikely to me.
> > > > >
> > > > > It doesn’t have to involve unmapping or applying mprotect to
> > > > > the entire VMA—just a portion of it is sufficient.
> > > >
> > > > Yes, but that still fails to answer "does this actually happen". How much
> > > > performance is all this complexity in the page fault handler buying us?
> > > > If you don't answer this question, I'm just going to go in and rip it
> > > > all out.
> > > >
> > >
> > > Hi Matthew (and Lorenzo, Jan, and anyone else who may be
> > > waiting for answers),
> > >
> > > As promised during LSF/MM/BPF, we conducted thorough
> > > testing on Android phones to determine whether performing
> > > I/O in `filemap_fault()` can block `vma_start_write()`.
> > > I wanted to give a quick update on this question.
> > >
> > > Nanzhe at Xiaomi created tracing scripts and ran various
> > > applications on Android devices with I/O performed under
> > > the VMA lock in `filemap_fault()`. We found that:
> > >
> > > 1. There are very few cases where unmap() is blocked by
> > > page faults. I assume this is due to buggy user code
> > > or poor synchronization between reads and unmap().
> > > So I assume it is not a problem.
> > >
> > > 2. We observed many cases where `vma_start_write()`
> > > is blocked by page-fault I/O in some applications.
> > > The blocking occurs in the `dup_mmap()` path during
> > > fork().
> > >
> > > With Suren's commit fb49c455323ff ("fork: lock VMAs of
> > > the parent process when forking"), we now always hold
> > > `vma_write_lock()` for each VMA. Note that the
> > > `mmap_lock` write lock is also held, which could lead to
> > > chained waiting if page-fault I/O is performed without
> > > releasing the VMA lock.
> > >
> > > My gut feeling is that Suren's commit may be overshooting,
> > > so my rough idea is that we might want to do something like
> > > the following (we haven't tested it yet and it might be
> > > wrong):
> > >
> > > diff --git a/mm/mmap.c b/mm/mmap.c
> > > index 2311ae7c2ff4..5ddaf297f31a 100644
> > > --- a/mm/mmap.c
> > > +++ b/mm/mmap.c
> > > @@ -1762,7 +1762,13 @@ __latent_entropy int dup_mmap(struct mm_struct
> > > *mm, struct mm_struct *oldmm)
> > > for_each_vma(vmi, mpnt) {
> > > struct file *file;
> > >
> > > - retval = vma_start_write_killable(mpnt);
> > > + /*
> > > + * For anonymous or writable private VMAs, prevent
> > > + * concurrent CoW faults.
> > > + */
> > > + if (!mpnt->vm_file || (!(mpnt->vm_flags & VM_SHARED) &&
> > > + (mpnt->vm_flags & VM_WRITE)))
> > > + retval = vma_start_write_killable(mpnt);
> > > if (retval < 0)
> > > goto loop_out;
> > > if (mpnt->vm_flags & VM_DONTCOPY) {
> >
> > Maybe a little bit off topic. This is an interesting idea. It seems
> > possible we don't have to take vma write lock unconditionally. IIUC
> > the write lock is mainly used to serialize against page fault and
> > madvise, right? I got a crazy idea off the top of my head. We may be
> > able to just take vma write lock iff vma->anon_vma is not NULL.
> >
> > First of all, write mmap_lock is held, so the vma can't go or be
> > changed under us.
> >
> > Secondly, if vma->anon_vma is NULL, it basically means either no page
> > fault happened or no cow happened, so there is no page table to copy,
> > this is also what copy_page_range() does currently. So we can shrink
> > the critical section to:
> >
> > if (vma->anon_vma) {
> > vma_start_write_killable(src_vma);
> > anon_vma_fork(dst_vma, src_vma);
> > copy_page_range(dst_vma, src_vma);
> > }
> >
> > But page fault can happen before write mmap_lock is taken, when we
> > check vma->anon_vma, it is possible it has not been set up yet. But it
> > seems to be equivalent to page fault after fork and won't break the
> > semantic.
>
> Re-reading Suren's commit log for fb49c455323ff8
> ("fork: lock VMAs of the parent process when forking"),
> it seems that vm_start_write() is used to protect
> against a race where anon_vma changes from NULL to
> non-NULL during fork. In that scenario, we hold the
> mmap_lock write lock, but not vma_start_write(), so a
> concurrent anon_vma_prepare() could still install an
> anon_vma.
>
> " A concurrent page fault on a page newly marked read-only by the page
> copy might trigger wp_page_copy() and a anon_vma_prepare(vma) on the
> source vma, defeating the anon_vma_clone() that wasn't done because the
> parent vma originally didn't have an anon_vma, but we now might end up
> copying a pte entry for a page that has one.
> "
>
> If that is the case, then your change does not work.
>
> Nowadays, nobody calls anon_vma_prepare(vma) directly.
I see callers? Am I imagining them? :)
https://elixir.bootlin.com/linux/v7.0.9/A/ident/anon_vma_prepare
> Instead, vmf_anon_prepare() is used, and we always
> require the mmap_lock read lock before calling
> __anon_vma_prepare(). As a result, anon_vma cannot
> transition from NULL to non-NULL during fork.
Right, yes the mmap read lock is required for that.
>
> So the original race condition has effectively
> disappeared.
Err the page tables? All the other cases which require page table copying?
Concurrent faults mean that copy_page_range() and faulting with vma->anon_vma
_or_ any of the multiple cases mentioned elsewhere.
And who knows what else serialises on that.
>
> You also mentioned the madvise() case. If I understand
> correctly, madvise() should take mmap_lock before
> modifying anon_vma. Only some parts of madvise() can
> support per-VMA locking. Therefore, we probably do not
> need:
>
> if (vma->anon_vma) {
> vma_start_write_killable(src_vma);
> ...
> }
I like how you hand wave the VMA lock operations in madvise() :)
(Maybe) guard regions being present cause page tables to be copied, they're
installed under VMA (read) lock, and can race now.
And it sets traps for future changes - introducing more horrible edge case race
conditions in fork is just a big nope nope nope.
This isn't an area to play around in.
>
> >
> > Anyway, just a crazy idea, I may miss some corner cases.
>
> To me, it seems that we could remove vma_start_write()
> entirely now. Or is that an even crazier idea?
As above that'd be totally broken. NAK.
>
> Thanks
> Barry
Thanks, Lorenzo
^ 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-19 13:29 UTC (permalink / raw)
To: Mostafa Saleh
Cc: Aneesh Kumar K.V, 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: <agxDxdxynp4KEovA@google.com>
On Tue, May 19, 2026 at 11:04:37AM +0000, Mostafa Saleh wrote:
> On Thu, May 14, 2026 at 08:13:25PM +0530, Aneesh Kumar K.V wrote:
> > >>
> > >> What I meant was that we need a generic way to identify a pKVM guest, so
> > >> that we can use it in the conditional above.
> > >
> > > I have this patch, with that I can boot with your series unmodified,
> > > but I will need to do more testing.
> > >
> >
> > Thanks, I can add this to the series once you complete the required testing.
> >
>
> I am still running more tests, but looking more into it. Setting
> force_dma_unencrypted() to true for pKVM guests is wrong, as the
> guest shouldn’t try to decrypt arbitrary memory as it can include
> sensitive information (for example in case of virtio sub-page
> allocation) and should strictly rely on the restricted-dma-pool
> for that.
??
Where does force_dma_unencrypted() cause arbitary memory passed into
the DMA API to be decrypted? That should never happen???
Jason
^ permalink raw reply
* Re: [PATCH v2 1/1] arm64: dts: s32g: add SAR ADC support for s32g2 and s32g3
From: Enric Balletbo i Serra @ 2026-05-19 13:27 UTC (permalink / raw)
To: Khristine Andreea Barbulescu
Cc: Chester Lin, Matthias Brugger, Ghennadi Procopciuc, Frank Li,
Sascha Hauer, Fabio Estevam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Pengutronix Kernel Team, linux-arm-kernel, imx,
devicetree, linux-kernel, NXP S32 Linux, Christophe Lizzi,
Alberto Ruiz
In-Reply-To: <20260514082639.1181240-2-khristineandreea.barbulescu@oss.nxp.com>
Hi,
On Thu, May 14, 2026 at 10:26 AM Khristine Andreea Barbulescu
<khristineandreea.barbulescu@oss.nxp.com> wrote:
>
> Add ADC0 and ADC1 for S32G2 and S32G3 SoCs.
>
> Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>
Reviewed-by: Enric Balletbo i Serra <eballetb@redhat.com>
Thanks,
Enric
> ---
> arch/arm64/boot/dts/freescale/s32g2.dtsi | 22 +++++++++++++++++++++-
> arch/arm64/boot/dts/freescale/s32g3.dtsi | 22 +++++++++++++++++++++-
> 2 files changed, 42 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/s32g2.dtsi b/arch/arm64/boot/dts/freescale/s32g2.dtsi
> index 51d00dac12de..6f1952fbbcfe 100644
> --- a/arch/arm64/boot/dts/freescale/s32g2.dtsi
> +++ b/arch/arm64/boot/dts/freescale/s32g2.dtsi
> @@ -3,7 +3,7 @@
> * NXP S32G2 SoC family
> *
> * Copyright (c) 2021 SUSE LLC
> - * Copyright 2017-2021, 2024-2025 NXP
> + * Copyright 2017-2021, 2024-2026 NXP
> */
>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> @@ -554,6 +554,16 @@ i2c2: i2c@401ec000 {
> status = "disabled";
> };
>
> + adc0: adc@401f8000 {
> + compatible = "nxp,s32g2-sar-adc";
> + reg = <0x401f8000 0x1000>;
> + interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks 0x41>;
> + dmas = <&edma0 0 32>;
> + dma-names = "rx";
> + status = "disabled";
> + };
> +
> swt4: watchdog@40200000 {
> compatible = "nxp,s32g2-swt";
> reg = <0x40200000 0x1000>;
> @@ -717,6 +727,16 @@ i2c4: i2c@402dc000 {
> status = "disabled";
> };
>
> + adc1: adc@402e8000 {
> + compatible = "nxp,s32g2-sar-adc";
> + reg = <0x402e8000 0x1000>;
> + interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks 0x41>;
> + dmas = <&edma1 1 32>;
> + dma-names = "rx";
> + status = "disabled";
> + };
> +
> usdhc0: mmc@402f0000 {
> compatible = "nxp,s32g2-usdhc";
> reg = <0x402f0000 0x1000>;
> diff --git a/arch/arm64/boot/dts/freescale/s32g3.dtsi b/arch/arm64/boot/dts/freescale/s32g3.dtsi
> index e314f3c7d61d..5cfb37c1216a 100644
> --- a/arch/arm64/boot/dts/freescale/s32g3.dtsi
> +++ b/arch/arm64/boot/dts/freescale/s32g3.dtsi
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> /*
> - * Copyright 2021-2025 NXP
> + * Copyright 2021-2026 NXP
> *
> * Authors: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
> * Ciprian Costea <ciprianmarian.costea@nxp.com>
> @@ -617,6 +617,16 @@ i2c2: i2c@401ec000 {
> status = "disabled";
> };
>
> + adc0: adc@401f8000 {
> + compatible = "nxp,s32g3-sar-adc", "nxp,s32g2-sar-adc";
> + reg = <0x401f8000 0x1000>;
> + interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks 0x41>;
> + dmas = <&edma0 0 32>;
> + dma-names = "rx";
> + status = "disabled";
> + };
> +
> swt4: watchdog@40200000 {
> compatible = "nxp,s32g3-swt", "nxp,s32g2-swt";
> reg = <0x40200000 0x1000>;
> @@ -792,6 +802,16 @@ i2c4: i2c@402dc000 {
> status = "disabled";
> };
>
> + adc1: adc@402e8000 {
> + compatible = "nxp,s32g3-sar-adc", "nxp,s32g2-sar-adc";
> + reg = <0x402e8000 0x1000>;
> + interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks 0x41>;
> + dmas = <&edma1 1 32>;
> + dma-names = "rx";
> + status = "disabled";
> + };
> +
> usdhc0: mmc@402f0000 {
> compatible = "nxp,s32g3-usdhc",
> "nxp,s32g2-usdhc";
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: Fix phandle-array constraints, again
From: Manivannan Sadhasivam @ 2026-05-19 13:27 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Maxime Ripard, Krzysztof Kozlowski, Conor Dooley, Wolfram Sang,
Andi Shyti, Ulf Hansson, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Johannes Berg,
Jeff Johnson, Bjorn Helgaas, Lorenzo Pieralisi,
Krzysztof Wilczyński, Bjorn Andersson, Mathieu Poirier,
Sylwester Nawrocki, Mark Brown, Greg Kroah-Hartman, dri-devel,
devicetree, linux-arm-kernel, linux-kernel, linux-i2c, linux-mmc,
netdev, linux-wireless, ath10k, ath11k, linux-pci,
linux-remoteproc, linux-sound, linux-spi, linux-usb
In-Reply-To: <20260507201749.2605365-1-robh@kernel.org>
On Thu, May 07, 2026 at 03:16:00PM -0500, Rob Herring (Arm) wrote:
> The unfortunately named 'phandle-array' property type is really a matrix
> with phandle and fixed arg cells entries. A matrix property should have 2
> levels of items constraints.
>
> Acked-by: Mark Brown <broonie@kernel.org>
> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Acked-by: Manivannan Sadhasivam <mani@kernel.org> # PCI
- Mani
> ---
> v2:
> - Add proper descriptions for 'qcom,smem-states'. Thanks Krzysztof!
> - Fix i2c-parent warning
> - Fix extra blank lines
> ---
> .../rockchip/rockchip,rk3399-cdn-dp.yaml | 2 ++
> .../bindings/i2c/i2c-demux-pinctrl.yaml | 1 +
> .../mmc/hisilicon,hi3798cv200-dw-mshc.yaml | 7 ++++---
> .../devicetree/bindings/net/qcom,bam-dmux.yaml | 12 ++++++++++++
> .../devicetree/bindings/net/qcom,ipa.yaml | 12 ++++++++++++
> .../bindings/net/wireless/qcom,ath10k.yaml | 8 +++++++-
> .../bindings/net/wireless/qcom,ath11k.yaml | 8 +++++++-
> .../net/wireless/qcom,ipq5332-wifi.yaml | 18 ++++++++++++++++++
> .../bindings/pci/toshiba,tc9563.yaml | 5 +++--
> .../remoteproc/qcom,msm8916-mss-pil.yaml | 6 ++++++
> .../remoteproc/qcom,msm8996-mss-pil.yaml | 7 +++++++
> .../bindings/remoteproc/qcom,pas-common.yaml | 6 ++++++
> .../remoteproc/qcom,qcs404-cdsp-pil.yaml | 6 ++++++
> .../remoteproc/qcom,sc7180-mss-pil.yaml | 6 ++++++
> .../remoteproc/qcom,sc7280-adsp-pil.yaml | 6 ++++++
> .../remoteproc/qcom,sc7280-mss-pil.yaml | 6 ++++++
> .../remoteproc/qcom,sc7280-wpss-pil.yaml | 6 ++++++
> .../remoteproc/qcom,sdm845-adsp-pil.yaml | 6 ++++++
> .../bindings/remoteproc/qcom,wcnss-pil.yaml | 6 ++++++
> .../devicetree/bindings/sound/samsung,tm2.yaml | 8 ++++++--
> .../bindings/spi/st,stm32mp25-ospi.yaml | 5 +++--
> .../bindings/usb/chipidea,usb2-common.yaml | 2 ++
> .../devicetree/bindings/usb/ci-hdrc-usb2.yaml | 7 ++++---
> 23 files changed, 142 insertions(+), 14 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3399-cdn-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3399-cdn-dp.yaml
> index 1a33128e77f5..195f665970bf 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3399-cdn-dp.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,rk3399-cdn-dp.yaml
> @@ -41,7 +41,9 @@ properties:
> minItems: 1
> items:
> - description: Extcon device providing the cable state for DP PHY device 0
> + maxItems: 1
> - description: Extcon device providing the cable state for DP PHY device 1
> + maxItems: 1
> description:
> List of phandle to the extcon device providing the cable state for the DP PHY.
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.yaml b/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.yaml
> index 1eaf00b90a77..deca72bfc8cf 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.yaml
> +++ b/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.yaml
> @@ -40,6 +40,7 @@ properties:
>
> i2c-parent:
> $ref: /schemas/types.yaml#/definitions/phandle-array
> + minItems: 2
> items:
> maxItems: 1
> description:
> diff --git a/Documentation/devicetree/bindings/mmc/hisilicon,hi3798cv200-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/hisilicon,hi3798cv200-dw-mshc.yaml
> index 41c9b22523e7..e447579e0f22 100644
> --- a/Documentation/devicetree/bindings/mmc/hisilicon,hi3798cv200-dw-mshc.yaml
> +++ b/Documentation/devicetree/bindings/mmc/hisilicon,hi3798cv200-dw-mshc.yaml
> @@ -39,10 +39,11 @@ properties:
> $ref: /schemas/types.yaml#/definitions/phandle-array
> description: |
> DWMMC core on Hi3798MV2x SoCs has a delay-locked-loop(DLL) attached to card data input path.
> - It is integrated into CRG core on the SoC and has to be controlled during tuning.
> + It is integrated into CRG core on the SoC and has to be controlled during tuning
> items:
> - - description: A phandle pointed to the CRG syscon node
> - - description: Sample DLL register offset in CRG address space
> + - items:
> + - description: A phandle pointed to the CRG syscon node
> + - description: Sample DLL register offset in CRG address space
>
> required:
> - compatible
> diff --git a/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> index b30544410d09..33746c238513 100644
> --- a/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> +++ b/Documentation/devicetree/bindings/net/qcom,bam-dmux.yaml
> @@ -42,7 +42,19 @@ properties:
> description: State bits used by the AP to signal the modem.
> items:
> - description: Power control
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
> - description: Power control acknowledgment
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: Names for the state bits used by the AP to signal the modem.
> diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml
> index fdeaa81b9645..68ec76fe4473 100644
> --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml
> +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml
> @@ -128,7 +128,19 @@ properties:
> description: State bits used in by the AP to signal the modem.
> items:
> - description: Whether the "ipa-clock-enabled" state bit is valid
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
> - description: Whether the IPA clock is enabled (if valid)
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: The names of the state bits used for SMP2P output
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> index c21d66c7cd55..d4f4d72ee0d3 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> @@ -158,7 +158,13 @@ properties:
> description: State bits used by the AP to signal the WLAN Q6.
> items:
> - description: Signal bits used to enable/disable low power mode
> - on WCN in the case of WoW (Wake on Wireless).
> + on WCN in the case of WoW (Wake on Wireless).
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: The names of the state bits used for SMP2P output.
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
> index 0cc1dbf2beef..d4aa56e2f823 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath11k.yaml
> @@ -80,7 +80,13 @@ properties:
> description: State bits used by the AP to signal the WLAN Q6.
> items:
> - description: Signal bits used to enable/disable low power mode
> - on WCN6750 in the case of WoW (Wake on Wireless).
> + on WCN6750 in the case of WoW (Wake on Wireless).
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: The names of the state bits used for SMP2P output.
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml
> index 37d8a0da7780..18cd91e2728c 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml
> @@ -168,8 +168,26 @@ properties:
> description: States used by the AP to signal the remote processor
> items:
> - description: Shutdown WCSS pd
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
> - description: Stop WCSS pd
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
> - description: Spawn WCSS pd
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description:
> diff --git a/Documentation/devicetree/bindings/pci/toshiba,tc9563.yaml b/Documentation/devicetree/bindings/pci/toshiba,tc9563.yaml
> index fae466064780..b3ad05d90201 100644
> --- a/Documentation/devicetree/bindings/pci/toshiba,tc9563.yaml
> +++ b/Documentation/devicetree/bindings/pci/toshiba,tc9563.yaml
> @@ -49,8 +49,9 @@ properties:
> A phandle to the parent I2C node and the slave address of the device
> used to configure tc9563 to change FTS, tx amplitude etc.
> items:
> - - description: Phandle to the I2C controller node
> - - description: I2C slave address
> + - items:
> + - description: Phandle to the I2C controller node
> + - description: I2C slave address
>
> patternProperties:
> "^pcie@[1-3],0$":
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
> index faf2712e3d27..4049157dd83d 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,msm8916-mss-pil.yaml
> @@ -108,6 +108,12 @@ properties:
> description: States used by the AP to signal the Hexagon core
> items:
> - description: Stop modem
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: Names of the states used by the AP to signal the Hexagon core
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml
> index 1b65813cc8ad..4a1b439f985e 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,msm8996-mss-pil.yaml
> @@ -101,6 +101,13 @@ properties:
> description: States used by the AP to signal the Hexagon core
> items:
> - description: Stop modem
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point or Shared
> + Memory Manager device handling the communication with a remote
> + processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: Names of the states used by the AP to signal the Hexagon core
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
> index 68c17bf18987..4607b459131b 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,pas-common.yaml
> @@ -60,6 +60,12 @@ properties:
> description: States used by the AP to signal the Hexagon core
> items:
> - description: Stop the modem
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: The names of the state bits used for SMP2P output
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml
> index bca59394aef4..e5f5f92987e1 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml
> @@ -92,6 +92,12 @@ properties:
> description: States used by the AP to signal the Hexagon core
> items:
> - description: Stop the modem
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: The names of the state bits used for SMP2P output
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml
> index 7c9accac92d0..21c82cd3be03 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7180-mss-pil.yaml
> @@ -133,6 +133,12 @@ properties:
> description: States used by the AP to signal the Hexagon core
> items:
> - description: Stop the modem
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: The names of the state bits used for SMP2P output
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-adsp-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-adsp-pil.yaml
> index 94ca7a0cc203..23b8e3079f3b 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-adsp-pil.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-adsp-pil.yaml
> @@ -91,6 +91,12 @@ properties:
> description: States used by the AP to signal the Hexagon core
> items:
> - description: Stop the modem
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: The names of the state bits used for SMP2P output
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml
> index f349c303fa07..43dfb90ac18d 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-mss-pil.yaml
> @@ -147,6 +147,12 @@ properties:
> description: States used by the AP to signal the Hexagon core
> items:
> - description: Stop the modem
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: The names of the state bits used for SMP2P output
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml
> index f4118b2da5f6..f3f3432948ed 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml
> @@ -104,6 +104,12 @@ properties:
> description: States used by the AP to signal the Hexagon core
> items:
> - description: Stop the modem
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: The names of the state bits used for SMP2P output
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml
> index a3c74871457f..9666ebf1e7b6 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml
> @@ -92,6 +92,12 @@ properties:
> description: States used by the AP to signal the Hexagon core
> items:
> - description: Stop the modem
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: The names of the state bits used for SMP2P output
> diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
> index 117fb4d0c4ad..a55e55f5f014 100644
> --- a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
> +++ b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.yaml
> @@ -84,6 +84,12 @@ properties:
> States used by the AP to signal the WCNSS core that it should shutdown
> items:
> - description: Stop the modem
> + items:
> + - description: Phandle to the Shared Memory Point 2 Point device
> + handling the communication with a remote processor
> + - description: Single bit index to toggle in the value sent to
> + the remote processor
> + maximum: 32
>
> qcom,smem-state-names:
> description: The names of the state bits used for SMP2P output
> diff --git a/Documentation/devicetree/bindings/sound/samsung,tm2.yaml b/Documentation/devicetree/bindings/sound/samsung,tm2.yaml
> index 67586ba3e0a0..985b7d29cd33 100644
> --- a/Documentation/devicetree/bindings/sound/samsung,tm2.yaml
> +++ b/Documentation/devicetree/bindings/sound/samsung,tm2.yaml
> @@ -45,8 +45,12 @@ properties:
> description: Phandles to the I2S controllers.
> $ref: /schemas/types.yaml#/definitions/phandle-array
> items:
> - - description: Phandle to I2S0.
> - - description: Phandle to I2S1.
> + - items:
> + - description: Phandle to I2S0
> + - description: Unused
> + - items:
> + - description: Phandle to I2S1
> + - description: Unused
>
> mic-bias-gpios:
> description: GPIO pin that enables the Main Mic bias regulator.
> diff --git a/Documentation/devicetree/bindings/spi/st,stm32mp25-ospi.yaml b/Documentation/devicetree/bindings/spi/st,stm32mp25-ospi.yaml
> index 272bc308726b..b6be47f67fcb 100644
> --- a/Documentation/devicetree/bindings/spi/st,stm32mp25-ospi.yaml
> +++ b/Documentation/devicetree/bindings/spi/st,stm32mp25-ospi.yaml
> @@ -49,8 +49,9 @@ properties:
> description: configure OCTOSPI delay block.
> $ref: /schemas/types.yaml#/definitions/phandle-array
> items:
> - - description: phandle to syscfg
> - - description: register offset within syscfg
> + - items:
> + - description: phandle to syscfg
> + - description: register offset within syscfg
>
> access-controllers:
> description: phandle to the rifsc device to check access right
> diff --git a/Documentation/devicetree/bindings/usb/chipidea,usb2-common.yaml b/Documentation/devicetree/bindings/usb/chipidea,usb2-common.yaml
> index 10020af15afc..e6a5e79df348 100644
> --- a/Documentation/devicetree/bindings/usb/chipidea,usb2-common.yaml
> +++ b/Documentation/devicetree/bindings/usb/chipidea,usb2-common.yaml
> @@ -97,7 +97,9 @@ properties:
> minItems: 1
> items:
> - description: vbus extcon
> + maxItems: 1
> - description: id extcon
> + maxItems: 1
>
> phy-clkgate-delay-us:
> description:
> diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
> index 691d6cf02c27..fec04702f530 100644
> --- a/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
> +++ b/Documentation/devicetree/bindings/usb/ci-hdrc-usb2.yaml
> @@ -61,9 +61,10 @@ properties:
> offset, and phy index
> $ref: /schemas/types.yaml#/definitions/phandle-array
> items:
> - - description: phandle to TCSR node
> - - description: register offset
> - - description: phy index
> + - items:
> + - description: phandle to TCSR node
> + - description: register offset
> + - description: phy index
>
> nvidia,phy:
> description: phandle of usb phy that connects to the port. Use "phys" instead.
> --
> 2.53.0
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* [PATCH v2] KVM: arm64: vgic-its: reject restored DTE with out-of-range num_eventid_bits
From: Michael Bommarito @ 2026-05-19 13:25 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Yao Yuan, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, linux-arm-kernel, kvmarm,
linux-kernel
In-Reply-To: <20260517174955.273004-1-michael.bommarito@gmail.com>
Userspace can restore an ITS Device Table Entry whose Size field encodes
more EventID bits than the virtual ITS supports. The live MAPD path
rejects that state, but vgic_its_restore_dte() accepts it and stores the
out-of-range value in dev->num_eventid_bits.
Reject restored DTEs with num_eventid_bits > VITS_TYPER_IDBITS before
allocating the device. This mirrors the MAPD check and prevents the
restored state from reaching vgic_its_restore_itt(), where the unchecked
value can be converted into an oversized scan_its_table() range.
Fixes: 57a9a117154c ("KVM: arm64: vgic-its: Device table save/restore")
Assisted-by: Claude:claude-opus-4-7
Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com>
---
Changes in v2:
- Trim the commit message to the root cause and fix.
- Shorten the in-code comment as suggested by Marc.
- Keep the validation logic unchanged.
arch/arm64/kvm/vgic/vgic-its.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
index 2ea9f1c7ebcd0..1d7e5d560af4c 100644
--- a/arch/arm64/kvm/vgic/vgic-its.c
+++ b/arch/arm64/kvm/vgic/vgic-its.c
@@ -2307,6 +2307,10 @@ static int vgic_its_restore_dte(struct vgic_its *its, u32 id,
/* dte entry is valid */
offset = (entry & KVM_ITS_DTE_NEXT_MASK) >> KVM_ITS_DTE_NEXT_SHIFT;
+ /* Mimic the MAPD behaviour and reject invalid EID bits. */
+ if (num_eventid_bits > VITS_TYPER_IDBITS)
+ return -EINVAL;
+
if (!vgic_its_check_id(its, baser, id, NULL))
return -EINVAL;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations
From: David Woodhouse @ 2026-05-19 13:24 UTC (permalink / raw)
To: Marc Zyngier, Paolo Bonzini
Cc: Will Deacon, Jonathan Corbet, Shuah Khan, kvm,
Linux Doc Mailing List, Kernel Mailing List, Linux,
Sean Christopherson, Jim Mattson, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Raghavendra Rao Ananta, Eric Auger, Kees Cook, Arnd Bergmann,
Nathan Chancellor, linux-arm-kernel, kvmarm, linux-kselftest
In-Reply-To: <86pl2rwoat.wl-maz@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2101 bytes --]
On Tue, 2026-05-19 at 13:56 +0100, Marc Zyngier wrote:
> On Tue, 19 May 2026 13:38:57 +0100,
> Marc Zyngier <maz@kernel.org> wrote:
> >
> > As I said before, I'd be OK with something that would restore IIDR to
> > REV1. But not something that actively breaks the GIC emulation by
> > reintroducing a bug. That's, by construction, dead code that will only
> > bitrot, because there is no SW that can make use of this nonsense.
>
> I will also add that if we make it a policy to preserve buggy
> behaviours that the guest cannot be relying on, then I question
> whether we should be fixing anything at all.
I think we just have a different understanding of what it practically
means to have behaviour "that the guest cannot be relying on", as in
the examples I just described for the IIDR issue.
> For example, 6.19 fixed a totally buggy behaviour where a guest
> couldn't not have more than (on most HW) 4 interrupts in flight at any
> given time. This was obviously totally bogus, and this was fixed
> unconditionally, as legitimate guests could experience gold-platted
> lock-ups.
And marked with a Fixes: tag and backported to stable, one presumes?
I'm confused that you think this is relevant. Can you contrive a
situation where a guest actually relied on this bug and *survived*,
like the situations I just explained for the IIDR issue?
You can nit-pick my hypotheticals as unlikely — and they are. But if we
always just YOLO it and change guest-visible behaviour on the basis
that it's "unlikely" to break anyone, and there are many such changes
in a given kernel deployment (e.g. from v6.6 to v6.18), then the
cumulative probability of being bitten by one of those "unlikely"
problems approaches 1.
There's a reason we do a *huge* amount of testing of what the guest
sees as we move from one kernel to the next, and back again, and
endeavour to eliminate all those differences.
And once the new kernel *is* deployed and won't be rolled back, of
course, all new launches can get the newer behaviour (and the latest
version of PSCI, etc...)
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH v02] mailbox: pcc: report errors for PCC clients
From: Sudeep Holla @ 2026-05-19 13:23 UTC (permalink / raw)
To: Adam Young
Cc: Jassi Brar, linux-kernel, Sudeep Holla, linux-hwmon,
Rafael J . Wysocki, Len Brown, linux-acpi, Andi Shyti,
Guenter Roeck, Huisong Li, MyungJoo Ham, Kyungmin Park,
Chanwoo Choi, linux-arm-kernel
In-Reply-To: <20260518193006.27425-1-admiyo@os.amperecomputing.com>
On Mon, May 18, 2026 at 03:30:06PM -0400, Adam Young wrote:
> The tx_done callback function has a return code (rc) parameter
> that the tx_done callback can use to determine how to handle an error.
> However the IRQ handler was not setting that value if there is an error.
>
> The following clients are affected:
>
> drivers/acpi/cppc_acpi.c
> drivers/i2c/busses/i2c-xgene-slimpro.c
> drivers/hwmon/xgene-hwmon.c
> drivers/soc/hisilicon/kunpeng_hccs.c
> drivers/devfreq/hisi_uncore_freq.c
>
> All of these only use the error code to report, so they
> are expecting an error code to come thorugh, but they
> do not modify behavior based on this code.
>
> In the case of an error code in the IRQ, the handler was returning
> IRQ_NONE which is not correct: the IRQ handler was matched
> to the IRQ. This mean that multiple error codes returned from
> a PCC triggered interrupt would end up disabling the device.
>
> In addition, if the error code IRQ was coming from a Type4 Device that was
> expecting an IRQ response, that device would then be hung.
>
> Fixes: c45ded7e1135 ("mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4)")
> Signed-off-by: Adam Young <admiyo@os.amperecomputing.com>
>
> ---
> ---
> drivers/mailbox/pcc.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
> index 636879ae1db7..16b9ce087b9e 100644
> --- a/drivers/mailbox/pcc.c
> +++ b/drivers/mailbox/pcc.c
> @@ -314,6 +314,7 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
> {
> struct pcc_chan_info *pchan;
> struct mbox_chan *chan = p;
> + int rc;
>
> pchan = chan->con_priv;
>
> @@ -327,8 +328,7 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
> if (!pcc_mbox_cmd_complete_check(pchan))
> return IRQ_NONE;
>
> - if (pcc_mbox_error_check_and_clear(pchan))
> - return IRQ_NONE;
> + rc = pcc_mbox_error_check_and_clear(pchan);
I think we may have to skip the check inside pcc_mbox_error_check_and_clear()
for Type 4 channel as the spec expects OSPM to ignore it. It is a separate
fix, just noting that here.
>
> /*
> * Clear this flag after updating interrupt ack register and just
> @@ -337,8 +337,9 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
> * required to avoid any possible race in updatation of this flag.
> */
> pchan->chan_in_use = false;
> - mbox_chan_received_data(chan, NULL);
> - mbox_chan_txdone(chan, 0);
> + if (!rc)
> + mbox_chan_received_data(chan, NULL);
Not sure if making this conditional is good as some platforms may expect
it to move the state machine, I am not sure 100% just thinking aloud here.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v17 09/14] crypto: qce - Remove unused ignore_buf
From: Bartosz Golaszewski @ 2026-05-19 13:17 UTC (permalink / raw)
To: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li, Andy Gross,
Neil Armstrong
Cc: dmaengine, linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, brgl, Bartosz Golaszewski, Bartosz Golaszewski
In-Reply-To: <20260519-qcom-qce-cmd-descr-v17-0-53a595414b79@oss.qualcomm.com>
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
It's unclear what the purpose of this field is. It has been here since
the initial commit but without any explanation. The driver works fine
without it. We still keep allocating more space in the result buffer, we
just don't need to store its address. While at it: move the
QCE_IGNORE_BUF_SZ definition into dma.c as it's not used outside of this
compilation unit.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/crypto/qce/dma.c | 4 ++--
drivers/crypto/qce/dma.h | 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/qce/dma.c b/drivers/crypto/qce/dma.c
index 68cafd4741ad3d91906d39e817fc7873b028d498..08bf3e8ec12433c1a8ee17003f3487e41b7329e4 100644
--- a/drivers/crypto/qce/dma.c
+++ b/drivers/crypto/qce/dma.c
@@ -9,6 +9,8 @@
#include "dma.h"
+#define QCE_IGNORE_BUF_SZ (2 * QCE_BAM_BURST_SIZE)
+
static void qce_dma_release(void *data)
{
struct qce_dma_data *dma = data;
@@ -41,8 +43,6 @@ int devm_qce_dma_request(struct device *dev, struct qce_dma_data *dma)
goto error_nomem;
}
- dma->ignore_buf = dma->result_buf + QCE_RESULT_BUF_SZ;
-
return devm_add_action_or_reset(dev, qce_dma_release, dma);
error_nomem:
diff --git a/drivers/crypto/qce/dma.h b/drivers/crypto/qce/dma.h
index 31629185000e12242fa07c2cc08b95fcbd5d4b8c..fc337c435cd14917bdfb99febcf9119275afdeba 100644
--- a/drivers/crypto/qce/dma.h
+++ b/drivers/crypto/qce/dma.h
@@ -23,7 +23,6 @@ struct qce_result_dump {
u32 status2;
};
-#define QCE_IGNORE_BUF_SZ (2 * QCE_BAM_BURST_SIZE)
#define QCE_RESULT_BUF_SZ \
ALIGN(sizeof(struct qce_result_dump), QCE_BAM_BURST_SIZE)
@@ -31,7 +30,6 @@ struct qce_dma_data {
struct dma_chan *txchan;
struct dma_chan *rxchan;
struct qce_result_dump *result_buf;
- void *ignore_buf;
};
int devm_qce_dma_request(struct device *dev, struct qce_dma_data *dma);
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2 1/1] arm64: dts: s32g: add PIT support for s32g2 and s32g3
From: Enric Balletbo i Serra @ 2026-05-19 13:23 UTC (permalink / raw)
To: Khristine Andreea Barbulescu
Cc: Chester Lin, Matthias Brugger, Ghennadi Procopciuc, Frank Li,
Sascha Hauer, Fabio Estevam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Pengutronix Kernel Team, linux-arm-kernel, imx,
devicetree, linux-kernel, NXP S32 Linux, Christophe Lizzi,
Alberto Ruiz
In-Reply-To: <20260518063547.2890353-2-khristineandreea.barbulescu@oss.nxp.com>
Hi,
Somewhat related I'd appreciate a review to:
https://lore.kernel.org/all/20260514-fix-nxp-timer-v3-1-a3e68fdb505e@redhat.com/
The changes looks good to me, so
On Mon, May 18, 2026 at 8:36 AM Khristine Andreea Barbulescu
<khristineandreea.barbulescu@oss.nxp.com> wrote:
>
> Add PIT0 and PIT1 for S32G2 and S32G3 SoCs
>
> Signed-off-by: Khristine Andreea Barbulescu <khristineandreea.barbulescu@oss.nxp.com>
Reviewed-by: Enric Balletbo i Serra <eballetb@redhat.com>
Thanks,
Enric
> ---
> arch/arm64/boot/dts/freescale/s32g2.dtsi | 20 +++++++++++++++++++-
> arch/arm64/boot/dts/freescale/s32g3.dtsi | 20 +++++++++++++++++++-
> 2 files changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/s32g2.dtsi b/arch/arm64/boot/dts/freescale/s32g2.dtsi
> index 51d00dac12de..57ff97e44507 100644
> --- a/arch/arm64/boot/dts/freescale/s32g2.dtsi
> +++ b/arch/arm64/boot/dts/freescale/s32g2.dtsi
> @@ -3,7 +3,7 @@
> * NXP S32G2 SoC family
> *
> * Copyright (c) 2021 SUSE LLC
> - * Copyright 2017-2021, 2024-2025 NXP
> + * Copyright 2017-2021, 2024-2026 NXP
> */
>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> @@ -417,6 +417,15 @@ edma0: dma-controller@40144000 {
> clock-names = "dmamux0", "dmamux1";
> };
>
> + pit0: pit@40188000 {
> + compatible = "nxp,s32g2-pit";
> + reg = <0x40188000 0x3000>;
> + interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks 61>;
> + clock-names = "pit";
> + status = "disabled";
> + };
> +
> can0: can@401b4000 {
> compatible = "nxp,s32g2-flexcan";
> reg = <0x401b4000 0xa000>;
> @@ -622,6 +631,15 @@ edma1: dma-controller@40244000 {
> clock-names = "dmamux0", "dmamux1";
> };
>
> + pit1: pit@40288000 {
> + compatible = "nxp,s32g2-pit";
> + reg = <0x40288000 0x3000>;
> + interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks 61>;
> + clock-names = "pit";
> + status = "disabled";
> + };
> +
> can2: can@402a8000 {
> compatible = "nxp,s32g2-flexcan";
> reg = <0x402a8000 0xa000>;
> diff --git a/arch/arm64/boot/dts/freescale/s32g3.dtsi b/arch/arm64/boot/dts/freescale/s32g3.dtsi
> index e314f3c7d61d..efe5398e1240 100644
> --- a/arch/arm64/boot/dts/freescale/s32g3.dtsi
> +++ b/arch/arm64/boot/dts/freescale/s32g3.dtsi
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: (GPL-2.0+ OR BSD-3-Clause)
> /*
> - * Copyright 2021-2025 NXP
> + * Copyright 2021-2026 NXP
> *
> * Authors: Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>
> * Ciprian Costea <ciprianmarian.costea@nxp.com>
> @@ -475,6 +475,15 @@ edma0: dma-controller@40144000 {
> clock-names = "dmamux0", "dmamux1";
> };
>
> + pit0: pit@40188000 {
> + compatible = "nxp,s32g3-pit", "nxp,s32g2-pit";
> + reg = <0x40188000 0x3000>;
> + interrupts = <GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks 61>;
> + clock-names = "pit";
> + status = "disabled";
> + };
> +
> can0: can@401b4000 {
> compatible = "nxp,s32g3-flexcan",
> "nxp,s32g2-flexcan";
> @@ -693,6 +702,15 @@ edma1: dma-controller@40244000 {
> clock-names = "dmamux0", "dmamux1";
> };
>
> + pit1: pit@40288000 {
> + compatible = "nxp,s32g3-pit", "nxp,s32g2-pit";
> + reg = <0x40288000 0x3000>;
> + interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clks 61>;
> + clock-names = "pit";
> + status = "disabled";
> + };
> +
> can2: can@402a8000 {
> compatible = "nxp,s32g3-flexcan",
> "nxp,s32g2-flexcan";
> --
> 2.34.1
>
^ permalink raw reply
* [PATCH v17 12/14] crypto: qce - Map crypto memory for DMA
From: Bartosz Golaszewski @ 2026-05-19 13:17 UTC (permalink / raw)
To: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li, Andy Gross,
Neil Armstrong
Cc: dmaengine, linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, brgl, Bartosz Golaszewski, Bartosz Golaszewski
In-Reply-To: <20260519-qcom-qce-cmd-descr-v17-0-53a595414b79@oss.qualcomm.com>
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
As the first step in converting the driver to using DMA for register
I/O, let's map the crypto memory range.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/crypto/qce/core.c | 23 ++++++++++++++++++++++-
drivers/crypto/qce/core.h | 6 ++++++
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
index 90f44db6606173d8afbd295a6dadea177b7bcd11..92e551f4570c0c69cbbbb709a0752fbc16c307e5 100644
--- a/drivers/crypto/qce/core.c
+++ b/drivers/crypto/qce/core.c
@@ -192,10 +192,19 @@ static void qce_cancel_work(void *data)
cancel_work_sync(work);
}
+static void qce_crypto_unmap_dma(void *data)
+{
+ struct qce_device *qce = data;
+
+ dma_unmap_resource(qce->dev, qce->base_dma, qce->dma_size,
+ DMA_BIDIRECTIONAL, 0);
+}
+
static int qce_crypto_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct qce_device *qce;
+ struct resource *res;
int ret;
qce = devm_kzalloc(dev, sizeof(*qce), GFP_KERNEL);
@@ -205,7 +214,7 @@ static int qce_crypto_probe(struct platform_device *pdev)
qce->dev = dev;
platform_set_drvdata(pdev, qce);
- qce->base = devm_platform_ioremap_resource(pdev, 0);
+ qce->base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
if (IS_ERR(qce->base))
return PTR_ERR(qce->base);
@@ -256,6 +265,18 @@ static int qce_crypto_probe(struct platform_device *pdev)
qce->async_req_enqueue = qce_async_request_enqueue;
qce->async_req_done = qce_async_request_done;
+ qce->dma_size = resource_size(res);
+ qce->base_dma = dma_map_resource(dev, res->start, qce->dma_size,
+ DMA_BIDIRECTIONAL, 0);
+ qce->base_phys = res->start;
+ ret = dma_mapping_error(dev, qce->base_dma);
+ if (ret)
+ return ret;
+
+ ret = devm_add_action_or_reset(qce->dev, qce_crypto_unmap_dma, qce);
+ if (ret)
+ return ret;
+
return devm_qce_register_algs(qce);
}
diff --git a/drivers/crypto/qce/core.h b/drivers/crypto/qce/core.h
index f092ce2d3b04a936a37805c20ac5ba78d8fdd2df..a80e12eac6c87e5321cce16c56a4bf5003474ef0 100644
--- a/drivers/crypto/qce/core.h
+++ b/drivers/crypto/qce/core.h
@@ -27,6 +27,9 @@
* @dma: pointer to dma data
* @burst_size: the crypto burst size
* @pipe_pair_id: which pipe pair id the device using
+ * @base_dma: base DMA address
+ * @base_phys: base physical address
+ * @dma_size: size of memory mapped for DMA
* @async_req_enqueue: invoked by every algorithm to enqueue a request
* @async_req_done: invoked by every algorithm to finish its request
*/
@@ -43,6 +46,9 @@ struct qce_device {
struct qce_dma_data dma;
int burst_size;
unsigned int pipe_pair_id;
+ dma_addr_t base_dma;
+ phys_addr_t base_phys;
+ size_t dma_size;
int (*async_req_enqueue)(struct qce_device *qce,
struct crypto_async_request *req);
void (*async_req_done)(struct qce_device *qce, int ret);
--
2.47.3
^ permalink raw reply related
* [PATCH v17 14/14] crypto: qce - Communicate the base physical address to the dmaengine
From: Bartosz Golaszewski @ 2026-05-19 13:17 UTC (permalink / raw)
To: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li, Andy Gross,
Neil Armstrong
Cc: dmaengine, linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, brgl, Bartosz Golaszewski, Bartosz Golaszewski
In-Reply-To: <20260519-qcom-qce-cmd-descr-v17-0-53a595414b79@oss.qualcomm.com>
In order to communicate to the BAM DMA engine which address should be
used as a scratchpad for dummy writes related to BAM pipe locking,
fill out and attach the provided metadata struct to the descriptor.
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/crypto/qce/dma.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/crypto/qce/dma.c b/drivers/crypto/qce/dma.c
index b66e6386fccda20d9462e70e51b8b485be85dec8..97b0f02c2b4d212f9e9ad41bbcb3a33e0b64835a 100644
--- a/drivers/crypto/qce/dma.c
+++ b/drivers/crypto/qce/dma.c
@@ -11,6 +11,7 @@
#include "core.h"
#include "dma.h"
+#include "regs-v5.h"
#define QCE_IGNORE_BUF_SZ (2 * QCE_BAM_BURST_SIZE)
#define QCE_BAM_CMD_SGL_SIZE 128
@@ -43,6 +44,10 @@ void qce_clear_bam_transaction(struct qce_device *qce)
int qce_submit_cmd_desc(struct qce_device *qce)
{
+ struct bam_desc_metadata meta = {
+ .scratchpad_addr = qce->base_phys + REG_VERSION,
+ .direction = DMA_MEM_TO_DEV,
+ };
struct qce_desc_info *qce_desc = qce->dma.bam_txn->desc;
struct qce_bam_transaction *bam_txn = qce->dma.bam_txn;
struct dma_async_tx_descriptor *dma_desc;
@@ -63,6 +68,10 @@ int qce_submit_cmd_desc(struct qce_device *qce)
goto err_unmap_sg;
}
+ ret = dmaengine_desc_attach_metadata(dma_desc, &meta, 0);
+ if (ret)
+ goto err_unmap_sg;
+
qce_desc->dma_desc = dma_desc;
cookie = dmaengine_submit(qce_desc->dma_desc);
--
2.47.3
^ permalink raw reply related
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