* Re: [PATCH v2 2/4] drm/verisilicon: add model ID constants and DCU Lite chip identity
From: Icenowy Zheng @ 2026-05-19 7:37 UTC (permalink / raw)
To: Joey Lu, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260519055114.1886525-3-a0987203069@gmail.com>
在 2026-05-19二的 13:51 +0800，Joey Lu写道：
> Introduce symbolic constants VSDC_MODEL_DC8200 and
> VSDC_MODEL_DCU_LITE
> to replace magic numbers in the hardware database and probe path.
>
> Register the DCU Lite chip identity (model 0x0, revision 0x5560,
> customer_id 0x305) in vs_chip_identities[], making the existing
> vs_fill_chip_identity() path able to recognise Nuvoton MA35D1
> hardware
> purely through register reads.
The HWDB change should be added in the end of the series, making it a
gate to the newly added changes that is finally opened when
everything's ready.
>
> Also add three register-level macros for forthcoming DCU Lite
> support:
> - VSDC_DISP_IRQ_VSYNC(n) in vs_crtc_regs.h, for per-output VSYNC IRQ
> bits used by the DCU Lite IRQ enable/status registers.
> - VSDC_FB_CONFIG_ENABLE, VSDC_FB_CONFIG_VALID and
> VSDC_FB_CONFIG_RESET
> in vs_primary_plane_regs.h, for the framebuffer enable and
> commit-cycle bits used by the DCU Lite plane update path.
Maybe you can split the register change
>
> No behaviour change for existing DC8200 platforms.
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ---
> drivers/gpu/drm/verisilicon/vs_crtc_regs.h | 1 +
> drivers/gpu/drm/verisilicon/vs_hwdb.c | 16 ++++++++++++--
> --
> drivers/gpu/drm/verisilicon/vs_hwdb.h | 3 +++
> .../gpu/drm/verisilicon/vs_primary_plane_regs.h | 3 +++
> 4 files changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/verisilicon/vs_crtc_regs.h
> b/drivers/gpu/drm/verisilicon/vs_crtc_regs.h
> index c7930e817635..d4da22b08cd5 100644
> --- a/drivers/gpu/drm/verisilicon/vs_crtc_regs.h
> +++ b/drivers/gpu/drm/verisilicon/vs_crtc_regs.h
> @@ -54,6 +54,7 @@
> #define VSDC_DISP_GAMMA_DATA(n) (0x1460 +
> 0x4 * (n))
>
> #define VSDC_DISP_IRQ_STA 0x147C
> +#define VSDC_DISP_IRQ_VSYNC(n) BIT(n)
>
> #define VSDC_DISP_IRQ_EN 0x1480
>
> diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.c
> b/drivers/gpu/drm/verisilicon/vs_hwdb.c
> index 09336af0900a..a25c4b16181d 100644
> --- a/drivers/gpu/drm/verisilicon/vs_hwdb.c
> +++ b/drivers/gpu/drm/verisilicon/vs_hwdb.c
> @@ -90,7 +90,7 @@ static const struct vs_formats
> vs_formats_with_yuv444 = {
>
> static struct vs_chip_identity vs_chip_identities[] = {
> {
> - .model = 0x8200,
> + .model = VSDC_MODEL_DC8200,
I don't think such a macro is needed.
> .revision = 0x5720,
> .customer_id = ~0U,
>
> @@ -98,7 +98,7 @@ static struct vs_chip_identity vs_chip_identities[]
> = {
> .formats = &vs_formats_no_yuv444,
> },
> {
> - .model = 0x8200,
> + .model = VSDC_MODEL_DC8200,
> .revision = 0x5721,
> .customer_id = 0x30B,
>
> @@ -106,7 +106,7 @@ static struct vs_chip_identity
> vs_chip_identities[] = {
> .formats = &vs_formats_no_yuv444,
> },
> {
> - .model = 0x8200,
> + .model = VSDC_MODEL_DC8200,
> .revision = 0x5720,
> .customer_id = 0x310,
>
> @@ -114,13 +114,21 @@ static struct vs_chip_identity
> vs_chip_identities[] = {
> .formats = &vs_formats_with_yuv444,
> },
> {
> - .model = 0x8200,
> + .model = VSDC_MODEL_DC8200,
> .revision = 0x5720,
> .customer_id = 0x311,
>
> .display_count = 2,
> .formats = &vs_formats_no_yuv444,
> },
> + {
> + .model = VSDC_MODEL_DCU_LITE,
The number is 0x0 and the whole public name of this IP is
"DCUltraLite", w/o any numbers.
I suggest leave it at 0x0 and add a comment saying this is DCUltraLite
-- Verisilicon people are abusing suffix for their IP names now.
> + .revision = 0x5560,
> + .customer_id = 0x305,
> +
> + .display_count = 1,
> + .formats = &vs_formats_no_yuv444,
> + },
> };
>
> int vs_fill_chip_identity(struct regmap *regs,
> diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.h
> b/drivers/gpu/drm/verisilicon/vs_hwdb.h
> index 92192e4fa086..cca126bd2da5 100644
> --- a/drivers/gpu/drm/verisilicon/vs_hwdb.h
> +++ b/drivers/gpu/drm/verisilicon/vs_hwdb.h
> @@ -9,6 +9,9 @@
> #include <linux/regmap.h>
> #include <linux/types.h>
>
> +#define VSDC_MODEL_DC8200 0x8200
> +#define VSDC_MODEL_DCU_LITE 0x0
> +
> struct vs_formats {
> const u32 *array;
> unsigned int num;
> diff --git a/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
> b/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
> index cbb125c46b39..67d4b00f294e 100644
> --- a/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
> +++ b/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
> @@ -16,6 +16,9 @@
> #define VSDC_FB_STRIDE(n) (0x1408 + 0x4 * (n))
>
> #define VSDC_FB_CONFIG(n) (0x1518 + 0x4 * (n))
> +#define VSDC_FB_CONFIG_ENABLE BIT(0)
> +#define VSDC_FB_CONFIG_VALID BIT(3)
> +#define VSDC_FB_CONFIG_RESET BIT(4)
Should the new IRQ register to be added here too?
Thanks,
Icenowy
> #define VSDC_FB_CONFIG_CLEAR_EN BIT(8)
> #define VSDC_FB_CONFIG_ROT_MASK GENMASK(13,
> 11)
> #define VSDC_FB_CONFIG_ROT(v) ((v) << 11)
^ permalink raw reply
* Re: [PATCH 4/8] drm/panthor: Add support for protected memory allocation in panthor
From: Boris Brezillon @ 2026-05-19 7:39 UTC (permalink / raw)
To: Chia-I Wu
Cc: Liviu Dudau, Marcin Ślusarz, Ketil Johnsen, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Jonathan Corbet, Shuah Khan, Sumit Semwal,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian König, Steven Price, Daniel Almeida, Alice Ryhl,
Matthias Brugger, AngeloGioacchino Del Regno, dri-devel,
linux-doc, linux-kernel, linux-media, linaro-mm-sig,
linux-arm-kernel, linux-mediatek, Florent Tomasin, nd
In-Reply-To: <CAPaKu7R9ET767qc3eppBUfG2RAeyrg7E-gE0turgp-u_FU4+Vg@mail.gmail.com>
On Mon, 18 May 2026 17:36:40 -0700
Chia-I Wu <olvaffe@gmail.com> wrote:
> On Mon, May 18, 2026 at 12:16 AM Boris Brezillon
> <boris.brezillon@collabora.com> wrote:
> >
> > On Wed, 13 May 2026 12:31:32 -0700
> > Chia-I Wu <olvaffe@gmail.com> wrote:
> >
> > > On Tue, May 12, 2026 at 8:39 AM Liviu Dudau <liviu.dudau@arm.com> wrote:
> > > >
> > > > On Tue, May 12, 2026 at 04:11:11PM +0200, Boris Brezillon wrote:
> > > > > On Tue, 12 May 2026 14:47:27 +0100
> > > > > Liviu Dudau <liviu.dudau@arm.com> wrote:
> > > > >
> > > > > > On Thu, May 07, 2026 at 01:53:56PM +0200, Boris Brezillon wrote:
> > > > > > > On Thu, 7 May 2026 11:02:26 +0200
> > > > > > > Marcin Ślusarz <marcin.slusarz@arm.com> wrote:
> > > > > > >
> > > > > > > > On Tue, May 05, 2026 at 06:15:23PM +0200, Boris Brezillon wrote:
> > > > > > > > > > @@ -277,9 +286,21 @@ int panthor_device_init(struct panthor_device *ptdev)
> > > > > > > > > > return ret;
> > > > > > > > > > }
> > > > > > > > > >
> > > > > > > > > > + /* If a protected heap name is specified but not found, defer the probe until created */
> > > > > > > > > > + if (protected_heap_name && strlen(protected_heap_name)) {
> > > > > > > > >
> > > > > > > > > Do we really need this strlen() > 0? Won't dma_heap_find() fail is the
> > > > > > > > > name is "" already?
> > > > > > > >
> > > > > > > > If dma_heap_find() will fail, then the whole probe with fail too.
> > > > > > > > This check prevents that.
> > > > > > >
> > > > > > > Yeah, that's also a questionable design choice. I mean, we can
> > > > > > > currently probe and boot the FW even though we never setup the
> > > > > > > protected FW sections, so why should we defer the probe here? Can't we
> > > > > > > just retry the next time a group with the protected bit is created and
> > > > > > > fail if we can find a protected heap?
> > > > > >
> > > > > > The problem we have with the current firmware is that it does a number of setup steps at "boot"
> > > > > > time only. One of the steps is preparing its internal structures for when it enters protected
> > > > > > mode and it stores them in the buffer passed in at firmware loading. We cannot later run the
> > > > > > process when we have a group with protected mode set.
> > > > >
> > > > > No, but we can force a full/slow reset and have that thing
> > > > > re-initialized, can't we? I mean, that's basically what we do when a
> > > > > fast reset fails: we re-initialize all the sections and reset again, at
> > > > > which point the FW should start from a fresh state, and be able to
> > > > > properly initialize the protected-related stuff if protected sections
> > > > > are populated. Am I missing something?
> > > >
> > > > Right, we can do that. For some reason I keep associating the reset with the
> > > > error handling and not with "normal" operations.
> > > I kind of hope we end up with either
> > >
> > > - panthor knows the exact heap to use and fails with EPROBE_DEFER if
> > > the heap is missing, or
> > > - panthor gets a dma-buf from userspace and does the full reset
> > > - userspace also needs to provide a dma-buf for each protected
> > > group for the suspend buffer
> > >
> > > than something in-between. The latter is more ad-hoc and basically
> > > kicks the issue to the userspace.
> >
> > Indeed, the second option is more ad-hoc, but when you think about it,
> > userspace has to have this knowledge, because it needs to know the
> > dma-heap to use for buffer allocation that cross a device boundary
> > anyway. Think about frames produced by a video decoder, and composited
> > by the GPU into a protected scanout buffer that's passed to the KMS
> > device. Why would the GPU driver be source of truth when it comes to
> > choosing the heap to use to allocate protected buffers for the video
> > decoder or those used for the display?
> I don't think the GPU driver is ever the source of truth. If the
> system integrator wants to specify the source of truth (SoT) from
> kernel space, they should use the device tree (or module params /
> config options). If they want to specify the SoT in userspace, then we
> don't really care how it is done other than providing an ioctl.
> Panthor is always on the receiving end.
Okay, we're on the same page then.
>
> If we don't want to delay this functionality, but it takes time to
> converge on SoT, maybe a solution that is not a long-term promise can
> work? Of the options on the table (dt, module params, kconfig options,
> ioctls), a kconfig option, potentially marked as experimental, seems
> like a good candidate.
If Panthor is only a consumer, I actually think it'd be easier to just
let userspace pass the protected FW section as an imported buffer
through an ioctl for now. It means we don't need any of the
modifications to the dma_heap API in this series, and userspace is free
to choose its SoT (efuse, DT, ...) and pass the info back to mesa/GBM
somehow (envvar, driconf, ...). The only thing we need to ensure is if
lazy protected FW section allocation is going to work, but given the
current code purely and simply ignores those sections, and the FW is
still able to boot and act properly (at least on v10-v13), I'm pretty
confident this is okay, unless there's some trick the MCU can do to
detect that the protected section isn't mapped (which I doubt, because
the MCU doesn't know it lives behind an MMU).
Of course, once we have a consensus on how to describe this in the DT,
we can switch Panthor over to "protected dma_heap selection through DT",
and reflect that through the ioctl that exposes whether protected
support is ready or not (would be a DEV_QUERY), such that userspace can
skip this "PROTM initialization" step.
We're talking about an extra ioctl to set those buffers, and a
DEV_QUERY to query the state (ready or not), the size of the global
protected buffer (protected FW section) and the size of the protected
suspend buffer. The protected suspend buffer would be allocated and
passed at group creation time (extra arg passed to the existing
GROUP_CREATE ioctl). So, overall, I don't consider it a huge liability
in term of maintenance cost.
>
> >
> > >
> > > For the former, expressing the relation in DT seems to be the best,
> > > but only if possible :-). Otherwise, a kconfig option (instead of
> > > module param) should be easier to work with.
> > >
> > > Looking at the userspace implementation, can we also have an panthor
> > > ioctl to return the heap to userspace?
> >
> > Yes, it's something we can add, but again, I'm questioning the
> > usefulness of this: how can we ensure the heap used by panthor to
> > allocate its protected FW buffers is suitable for scanout buffers
> > (buffers that can be used by display drivers). There needs to be a glue
> > leaving in usersland and taking the decision, and I'm not too sure
> > trusting any of the component in the chain (vdec, gpu, display) is the
> > right thing to do.
> The heap returned by panthor is only for panfrost/panvk. It says
> nothing about compatibility with other components on the system.
Okay, if it's used only for internal buffers, I guess that's fine.
^ permalink raw reply
* [PATCH v2] dt-bindings: arm-smmu: Constrain clocks for newer Qualcomm variants
From: Krzysztof Kozlowski @ 2026-05-19 7:41 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, iommu,
devicetree, linux-kernel
Cc: Krzysztof Kozlowski, Shawn Guo
Many of SMMU on Qualcomm SoCs come in two flavors using the same front
compatible but a bit different fallback:
1. For application processor, usually without any controllable
clocks,
2. For the Adreno GPU, with some controllable clock(s) and using
additionally qcom,adreno-smmu fallback compatible.
Add missing constraints for Glymur SMMU on Adreno GPU and several other
Qualcomm SMMUs for application processors, to restrict the clocks
property to a specific length.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Changes in v2:
1. Tags
2. Fix grammar in commit msg
---
.../devicetree/bindings/iommu/arm,smmu.yaml | 38 ++++++++++++++++++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index 06fb5c8e7547..ed0d10157bd6 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -566,7 +566,9 @@ allOf:
properties:
compatible:
items:
- - const: qcom,sm8750-smmu-500
+ - enum:
+ - qcom,glymur-smmu-500
+ - qcom,sm8750-smmu-500
- const: qcom,adreno-smmu
- const: qcom,smmu-500
- const: arm,mmu-500
@@ -595,6 +597,7 @@ allOf:
- qcom,sdm845-smmu-500
- qcom,sdx55-smmu-500
- qcom,sdx65-smmu-500
+ - qcom,sdx75-smmu-500
- qcom,sm6350-smmu-500
- qcom,sm6375-smmu-500
then:
@@ -602,6 +605,39 @@ allOf:
clock-names: false
clocks: false
+ # Disallow clocks for all other platforms where specific compatible is used
+ # with different fallbacks and only one combination has no clocks
+ - if:
+ properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,eliza-smmu-500
+ - qcom,glymur-smmu-500
+ - qcom,kaanapali-smmu-500
+ - qcom,milos-smmu-500
+ - qcom,qcs615-smmu-500
+ - qcom,qcs8300-smmu-500
+ - qcom,sa8775p-smmu-500
+ - qcom,sm6115-smmu-500
+ - qcom,sm6125-smmu-500
+ - qcom,sm6350-smmu-500
+ - qcom,sm6375-smmu-500
+ - qcom,sm8150-smmu-500
+ - qcom,sm8250-smmu-500
+ - qcom,sm8350-smmu-500
+ - qcom,sm8450-smmu-500
+ - qcom,sm8550-smmu-500
+ - qcom,sm8650-smmu-500
+ - qcom,sm8750-smmu-500
+ - qcom,x1e80100-smmu-500
+ - const: qcom,smmu-500
+ - const: arm,mmu-500
+ then:
+ properties:
+ clock-names: false
+ clocks: false
+
- if:
properties:
compatible:
--
2.51.0
^ permalink raw reply related
* [PATCH v2] dt-bindings: arm-smmu: Constrain clocks for newer Qualcomm variants
From: Krzysztof Kozlowski @ 2026-05-19 7:41 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel, iommu,
devicetree, linux-kernel
Cc: Krzysztof Kozlowski, Shawn Guo
Many of SMMU on Qualcomm SoCs come in two flavors using the same front
compatible but a bit different fallback:
1. For application processor, usually without any controllable
clocks,
2. For the Adreno GPU, with some controllable clock(s) and using
additionally qcom,adreno-smmu fallback compatible.
Add missing constraints for Glymur SMMU on Adreno GPU and several other
Qualcomm SMMUs for application processors, to restrict the clocks
property to a specific length.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Changes in v2:
1. Tags
2. Fix grammar in commit msg
---
.../devicetree/bindings/iommu/arm,smmu.yaml | 38 ++++++++++++++++++-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index 06fb5c8e7547..ed0d10157bd6 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -566,7 +566,9 @@ allOf:
properties:
compatible:
items:
- - const: qcom,sm8750-smmu-500
+ - enum:
+ - qcom,glymur-smmu-500
+ - qcom,sm8750-smmu-500
- const: qcom,adreno-smmu
- const: qcom,smmu-500
- const: arm,mmu-500
@@ -595,6 +597,7 @@ allOf:
- qcom,sdm845-smmu-500
- qcom,sdx55-smmu-500
- qcom,sdx65-smmu-500
+ - qcom,sdx75-smmu-500
- qcom,sm6350-smmu-500
- qcom,sm6375-smmu-500
then:
@@ -602,6 +605,39 @@ allOf:
clock-names: false
clocks: false
+ # Disallow clocks for all other platforms where specific compatible is used
+ # with different fallbacks and only one combination has no clocks
+ - if:
+ properties:
+ compatible:
+ items:
+ - enum:
+ - qcom,eliza-smmu-500
+ - qcom,glymur-smmu-500
+ - qcom,kaanapali-smmu-500
+ - qcom,milos-smmu-500
+ - qcom,qcs615-smmu-500
+ - qcom,qcs8300-smmu-500
+ - qcom,sa8775p-smmu-500
+ - qcom,sm6115-smmu-500
+ - qcom,sm6125-smmu-500
+ - qcom,sm6350-smmu-500
+ - qcom,sm6375-smmu-500
+ - qcom,sm8150-smmu-500
+ - qcom,sm8250-smmu-500
+ - qcom,sm8350-smmu-500
+ - qcom,sm8450-smmu-500
+ - qcom,sm8550-smmu-500
+ - qcom,sm8650-smmu-500
+ - qcom,sm8750-smmu-500
+ - qcom,x1e80100-smmu-500
+ - const: qcom,smmu-500
+ - const: arm,mmu-500
+ then:
+ properties:
+ clock-names: false
+ clocks: false
+
- if:
properties:
compatible:
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v2] dt-bindings: arm-smmu: Constrain clocks for newer Qualcomm variants
From: Krzysztof Kozlowski @ 2026-05-19 7:43 UTC (permalink / raw)
To: Krzysztof Kozlowski, Will Deacon, Robin Murphy, Joerg Roedel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-kernel,
iommu, devicetree, linux-kernel
Cc: Shawn Guo
In-Reply-To: <20260519074113.61464-2-krzysztof.kozlowski@oss.qualcomm.com>
On 19/05/2026 09:41, Krzysztof Kozlowski wrote:
> Many of SMMU on Qualcomm SoCs come in two flavors using the same front
> compatible but a bit different fallback:
>
> 1. For application processor, usually without any controllable
> clocks,
>
> 2. For the Adreno GPU, with some controllable clock(s) and using
> additionally qcom,adreno-smmu fallback compatible.
>
> Add missing constraints for Glymur SMMU on Adreno GPU and several other
> Qualcomm SMMUs for application processors, to restrict the clocks
> property to a specific length.
>
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
> Reviewed-by: Shawn Guo <shengchao.guo@oss.qualcomm.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
Apologies, that's a duplicated posting.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 4/4] drm/verisilicon: add Nuvoton MA35D1 DCU Lite display controller support
From: Icenowy Zheng @ 2026-05-19 7:44 UTC (permalink / raw)
To: Joey Lu, maarten.lankhorst, mripard, tzimmermann, airlied, simona,
robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260519055114.1886525-5-a0987203069@gmail.com>
在 2026-05-19二的 13:51 +0800，Joey Lu写道：
> The Nuvoton MA35D1 SoC integrates a Verisilicon DCU Lite display
> controller. While its register layout is broadly similar to the
> DC8200,
> several differences require dedicated hardware ops:
>
> 1. No CONFIG_EX commit path: framebuffer updates use enable (bit 0)
> and
> reset (bit 4) bits in FB_CONFIG instead of the DC8200 staging
> registers
> (FB_CONFIG_EX, FB_TOP_LEFT, FB_BOTTOM_RIGHT, FB_BLEND_CONFIG,
> PANEL_CONFIG_EX).
>
> 2. No PANEL_START register: panel output starts when
> PANEL_CONFIG.RUNNING is set; no multi-display sync start register
> is used.
>
> 3. Different IRQ registers: DCU Lite uses DISP_IRQ_STA (0x147C) /
> DISP_IRQ_EN (0x1480) versus DC8200's TOP_IRQ_ACK (0x0010) /
> TOP_IRQ_EN (0x0014).
>
> 4. Per-frame commit cycle: DCU Lite requires the VALID bit in
> FB_CONFIG
> to be set at the start of each atomic commit (crtc_begin) and
> cleared
> after (crtc_flush).
>
> 5. Simpler clock topology: only "core" (bus gate) and "pix0" (pixel
> divider) clocks; no axi or ahb clocks. Make axi_clk and ahb_clk
> optional (devm_clk_get_optional_enabled) so DCU Lite nodes without
> those clocks are handled gracefully.
>
> Add vs_dcu_lite.c implementing the vs_dc_funcs vtable for the above
> differences. After chip identity detection, vs_dc_probe() now
> selects
> vs_dcu_lite_funcs when the identified model is VSDC_MODEL_DCU_LITE
> (model register reads 0, revision 0x5560, customer_id 0x305).
>
> Extend Kconfig to allow building on ARCH_MA35 platforms.
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ---
> drivers/gpu/drm/verisilicon/Kconfig | 2 +-
> drivers/gpu/drm/verisilicon/Makefile | 2 +-
> drivers/gpu/drm/verisilicon/vs_dc.c | 9 ++-
> drivers/gpu/drm/verisilicon/vs_dc.h | 1 +
> drivers/gpu/drm/verisilicon/vs_dcu_lite.c | 78
> +++++++++++++++++++++++
> 5 files changed, 87 insertions(+), 5 deletions(-)
> create mode 100644 drivers/gpu/drm/verisilicon/vs_dcu_lite.c
>
> diff --git a/drivers/gpu/drm/verisilicon/Kconfig
> b/drivers/gpu/drm/verisilicon/Kconfig
> index 7cce86ec8603..295d246eb4b4 100644
> --- a/drivers/gpu/drm/verisilicon/Kconfig
> +++ b/drivers/gpu/drm/verisilicon/Kconfig
> @@ -2,7 +2,7 @@
> config DRM_VERISILICON_DC
> tristate "DRM Support for Verisilicon DC-series display
> controllers"
> depends on DRM && COMMON_CLK
> - depends on RISCV || COMPILE_TEST
> + depends on RISCV || ARCH_MA35 || COMPILE_TEST
> select DRM_BRIDGE_CONNECTOR
> select DRM_CLIENT_SELECTION
> select DRM_DISPLAY_HELPER
> diff --git a/drivers/gpu/drm/verisilicon/Makefile
> b/drivers/gpu/drm/verisilicon/Makefile
> index f4fbd9f7d6a2..bf88f627e65c 100644
> --- a/drivers/gpu/drm/verisilicon/Makefile
> +++ b/drivers/gpu/drm/verisilicon/Makefile
> @@ -1,5 +1,5 @@
> # SPDX-License-Identifier: GPL-2.0-only
>
> -verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o
> vs_drm.o vs_hwdb.o vs_plane.o vs_primary_plane.o
> +verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o
> vs_dcu_lite.o vs_drm.o vs_hwdb.o vs_plane.o vs_primary_plane.o
>
> obj-$(CONFIG_DRM_VERISILICON_DC) += verisilicon-dc.o
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c
> b/drivers/gpu/drm/verisilicon/vs_dc.c
> index c94957024189..77bc63c629f7 100644
> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
> @@ -90,13 +90,13 @@ static int vs_dc_probe(struct platform_device
> *pdev)
> return PTR_ERR(dc->core_clk);
> }
>
> - dc->axi_clk = devm_clk_get_enabled(dev, "axi");
> + dc->axi_clk = devm_clk_get_optional_enabled(dev, "axi");
> if (IS_ERR(dc->axi_clk)) {
> dev_err(dev, "can't get axi clock\n");
> return PTR_ERR(dc->axi_clk);
> }
>
> - dc->ahb_clk = devm_clk_get_enabled(dev, "ahb");
> + dc->ahb_clk = devm_clk_get_optional_enabled(dev, "ahb");
> if (IS_ERR(dc->ahb_clk)) {
> dev_err(dev, "can't get ahb clock\n");
> return PTR_ERR(dc->ahb_clk);
> @@ -134,7 +134,10 @@ static int vs_dc_probe(struct platform_device
> *pdev)
> dev_info(dev, "Found DC%x rev %x customer %x\n", dc-
> >identity.model,
> dc->identity.revision, dc->identity.customer_id);
>
> - dc->funcs = &vs_dc8200_funcs;
> + if (dc->identity.model == VSDC_MODEL_DC8200)
Don't do that. The model value is only for matching hardware values,
not for detecting what's present. Don't forget that DC8000 has a model
value of 0x8000, but behaves similarly with DCUltraLite with a model
value of 0x0.
I suggest adding another field for assigning helper functions.
My suggestion is here:
```
enum vs_dc_generation {
VSDC_GEN_DC8000,
VSDC_GEN_DC8200
};
```
Thanks,
Icenowy
> + dc->funcs = &vs_dc8200_funcs;
> + else
> + dc->funcs = &vs_dcu_lite_funcs;
>
> if (port_count > dc->identity.display_count) {
> dev_err(dev, "too many downstream ports than HW
> capability\n");
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.h
> b/drivers/gpu/drm/verisilicon/vs_dc.h
> index 45172c1a525c..d77d4a1babdf 100644
> --- a/drivers/gpu/drm/verisilicon/vs_dc.h
> +++ b/drivers/gpu/drm/verisilicon/vs_dc.h
> @@ -66,5 +66,6 @@ struct vs_dc {
> };
>
> extern const struct vs_dc_funcs vs_dc8200_funcs;
> +extern const struct vs_dc_funcs vs_dcu_lite_funcs;
>
> #endif /* _VS_DC_H_ */
> diff --git a/drivers/gpu/drm/verisilicon/vs_dcu_lite.c
> b/drivers/gpu/drm/verisilicon/vs_dcu_lite.c
> new file mode 100644
> index 000000000000..11ef57d5ebaa
> --- /dev/null
> +++ b/drivers/gpu/drm/verisilicon/vs_dcu_lite.c
> @@ -0,0 +1,78 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2026 Joey Lu <yclu4@nuvoton.com>
> + */
> +
> +#include <linux/regmap.h>
> +
> +#include "vs_crtc_regs.h"
> +#include "vs_dc.h"
> +#include "vs_primary_plane_regs.h"
> +
> +static void vs_dcu_lite_bridge_enable(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_RESET);
> +}
> +
> +static void vs_dcu_lite_bridge_disable(struct vs_dc *dc, unsigned
> int output)
> +{
> + regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_RESET);
> +}
> +
> +static void vs_dcu_lite_crtc_begin(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_VALID);
> +}
> +
> +static void vs_dcu_lite_crtc_flush(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_VALID);
> +}
> +
> +static void vs_dcu_lite_crtc_enable(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_ENABLE);
> +}
> +
> +static void vs_dcu_lite_crtc_disable(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_ENABLE);
> +}
> +
> +static void vs_dcu_lite_enable_vblank(struct vs_dc *dc, unsigned int
> output)
> +{
> + regmap_set_bits(dc->regs, VSDC_DISP_IRQ_EN,
> + VSDC_DISP_IRQ_VSYNC(output));
> +}
> +
> +static void vs_dcu_lite_disable_vblank(struct vs_dc *dc, unsigned
> int output)
> +{
> + regmap_clear_bits(dc->regs, VSDC_DISP_IRQ_EN,
> + VSDC_DISP_IRQ_VSYNC(output));
> +}
> +
> +static u32 vs_dcu_lite_irq_handler(struct vs_dc *dc)
> +{
> + u32 irqs;
> +
> + regmap_read(dc->regs, VSDC_DISP_IRQ_STA, &irqs);
> + return irqs;
> +}
> +
> +const struct vs_dc_funcs vs_dcu_lite_funcs = {
> + .bridge_enable = vs_dcu_lite_bridge_enable,
> + .bridge_disable =
> vs_dcu_lite_bridge_disable,
> + .crtc_begin = vs_dcu_lite_crtc_begin,
> + .crtc_flush = vs_dcu_lite_crtc_flush,
> + .crtc_enable = vs_dcu_lite_crtc_enable,
> + .crtc_disable = vs_dcu_lite_crtc_disable,
> + .enable_vblank = vs_dcu_lite_enable_vblank,
> + .disable_vblank =
> vs_dcu_lite_disable_vblank,
> + .irq_handler = vs_dcu_lite_irq_handler,
> +};
^ permalink raw reply
* Re: [PATCH] fbdev: imxfb: Use of_device_get_match_data()
From: Helge Deller @ 2026-05-19 7:52 UTC (permalink / raw)
To: Rosen Penev, linux-fbdev
Cc: Sascha Hauer, Pengutronix Kernel Team, Frank Li, Fabio Estevam,
moderated list:FREESCALE IMX / MXC FRAMEBUFFER DRIVER,
open list:FRAMEBUFFER LAYER,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, open list
In-Reply-To: <20260518211303.10777-1-rosenp@gmail.com>
On 5/18/26 23:13, Rosen Penev wrote:
> Use of_device_get_match_data() to fetch the platform ID entry directly
> instead of open-coding an of_match_device() lookup. No NULL check is
> needed as every compatible string has a corresponding data section.
>
> This also lets the driver drop the of_device.h include.
>
> Assisted-by: Codex:GPT-5.5
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/video/fbdev/imxfb.c | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
applied.
Thanks!
Helge
^ permalink raw reply
* Re: [PATCH] KVM: arm64: vgic: free private_irqs when init fails after allocation
From: Marc Zyngier @ 2026-05-19 7:53 UTC (permalink / raw)
To: Michael Bommarito
Cc: Yao Yuan, Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, linux-arm-kernel, kvmarm,
linux-kernel
In-Reply-To: <CAJJ9bXyHRVqnL_n6wwyAXDK=1GmaKgDy41tjMRhXjTObbft7gg@mail.gmail.com>
On Tue, 19 May 2026 01:26:58 +0100,
Michael Bommarito <michael.bommarito@gmail.com> wrote:
>
> On Mon, May 18, 2026 at 1:31 AM Yao Yuan <yaoyuan@linux.alibaba.com> wrote:
> > Ah. One thing I forgot to say:
> >
> > Do we need a fixes: tag here ?
>
> I struggled with that a bit. Will's sister commit in 250f25367b58
> didn't have a Fixes: tag, but if I had to pick, it would probably be
> this:
> Fixes: 03b3d00a70b5 ("KVM: arm64: vgic: Allocate private interrupts on demand")
>
> If you agree, I can send v2 with that added
Seems correct to me. Please send v2 at your earliest convenience with
a trimmed commit message (potentially limited to the first paragraph).
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v6 04/11] drm/hisilicon/kirin: switch to of_drm_get_bridge_by_endpoint()
From: Louis Chauvet @ 2026-05-18 8:52 UTC (permalink / raw)
To: Luca Ceresoli, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Sumit Semwal,
John Stultz, Tomi Valkeinen, Michal Simek
Cc: Hui Pu, Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel,
linux-arm-msm, freedreno, linux-arm-kernel
In-Reply-To: <20260511-drm-bridge-alloc-getput-panel_or_bridge-v6-4-f61c9e498b3f@bootlin.com>
On 5/11/26 18:40, Luca Ceresoli wrote:
> This driver calls drm_of_find_panel_or_bridge() with a NULL pointer in the
> @panel parameter, thus using a reduced feature set of that function.
> Replace this call with the simpler of_drm_get_bridge_by_endpoint().
>
> Since of_drm_get_bridge_by_endpoint() increases the refcount of the
> returned bridge, ensure it is put on removal. Here the bridge pointer is
> only stored in a temporary variable, so a cleanup action is enough.
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Reviewed-by: Louis Chauvet <louis.chauvet@bootlin.com>
> ---
> drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 9 ++++-----
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> index e80debdc4176..ab3cd309505a 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c
> @@ -778,17 +778,16 @@ static int dsi_host_init(struct device *dev, struct dw_dsi *dsi)
> static int dsi_bridge_init(struct drm_device *dev, struct dw_dsi *dsi)
> {
> struct drm_encoder *encoder = &dsi->encoder;
> - struct drm_bridge *bridge;
> + struct drm_bridge *bridge __free(drm_bridge_put) = NULL;
> struct device_node *np = dsi->dev->of_node;
> - int ret;
>
> /*
> * Get the endpoint node. In our case, dsi has one output port1
> * to which the external HDMI bridge is connected.
> */
> - ret = drm_of_find_panel_or_bridge(np, 1, 0, NULL, &bridge);
> - if (ret)
> - return ret;
> + bridge = of_drm_get_bridge_by_endpoint(np, 1, 0);
> + if (IS_ERR(bridge))
> + return PTR_ERR(bridge);
>
> /* associate the bridge to dsi encoder */
> return drm_bridge_attach(encoder, bridge, NULL, 0);
>
^ permalink raw reply
* Re: [PATCH 1/8] mm: Add ptep_try_install() for lockless empty-slot installs
From: David Hildenbrand (Arm) @ 2026-05-19 8:00 UTC (permalink / raw)
To: Tejun Heo
Cc: David Vernet, Andrea Righi, Changwoo Min, Alexei Starovoitov,
Andrii Nakryiko, Daniel Borkmann, Martin KaFai Lau,
Kumar Kartikeya Dwivedi, Catalin Marinas, Will Deacon,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
Andrew Morton, Mike Rapoport, Emil Tsalapatis, sched-ext, bpf,
x86, linux-arm-kernel, linux-mm, linux-kernel
In-Reply-To: <agtuPrgIDNKSu2Oo@slm.duckdns.org>
On 5/18/26 21:53, Tejun Heo wrote:
> Hello,
>
> On Mon, May 18, 2026 at 10:06:29AM +0200, David Hildenbrand (Arm) wrote:
>> On 5/17/26 23:12, Tejun Heo wrote:
>>> +static inline bool ptep_try_install(pte_t *ptep, pte_t new_pte)
>>> +{
>>> + return false;
>>> +}
>>> +#endif
>>
>> Ehm, what?
>>
>> This is a very, very, very bad generic idea/interface.
>>
>> On which ptes is this supposed to be used? User ptes or kernel ptes?
>>
>> Surely we don't want this on user ptes.
>
> Yeah, this is only for the BPF arena PTEs which are already managed in their
> own way. I'd be happy to place / gate it however appropriate.
So, we only use it within apply_to_page_range() with init_mm, where we don't use
page table locks.
Usually we seem to grab the &arena->spinlock to protect the kernel page tables.
And you're saying that we might get called from a page fault handler where that
lock can already be held.
Is that really possible? I'd much rather prefer to trylock and retry, unless
that can really result in deadlocks. But I have the feeling that such deadlocks
should be impossible here.
Can you elaborate on the deadlock situation and how that can happen in valid
scenarios?
The thing is that ptep_try_install() relies on other page table walking and
insertion code to do the right thing. Shaky.
For example, staring at apply_range_set_cb(), what prevents:
(1) apply_range_set_cb() finding pte_none(ptep_get(pte)
(2) apply_range_set_scratch_cb() succeeding ptep_try_install()
(3) apply_range_set_cb() overwriting the pte with set_pte_at()
Between (2) and (3) CPUs could access the scratch PTE.
--
Cheers,
David
^ permalink raw reply
* [PATCH v2] usb: gadget: aspeed_udc: avoid past-the-end iterator in dequeue
From: Maoyi Xie @ 2026-05-19 8:02 UTC (permalink / raw)
To: Andrew Jeffery, Neal Liu
Cc: Greg Kroah-Hartman, Benjamin Herrenschmidt, Joel Stanley,
Andrew Jeffery, Alan Stern, linux-aspeed, linux-arm-kernel,
linux-usb, linux-kernel
In-Reply-To: <20260518073403.1285339-1-maoyi.xie@ntu.edu.sg>
ast_udc_ep_dequeue() declares the loop cursor `req` outside the
list_for_each_entry(). After the loop it tests `&req->req != _req`
to decide whether the request was found. If the queue holds no
match, `req` is past-the-end. It then aliases
container_of(&ep->queue, struct ast_udc_request, queue) via offset
cancellation. Whether that synthetic address equals `_req` depends
on heap layout. The function can return 0 without dequeueing
anything.
Walk the list with a separate `iter`. Set `req` only when a
request matches. After the loop, `req` is NULL if nothing
matched.
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
---
v2: Switch the loop body to Alan Stern's shape: test inside
the if, assign `req`, break. Same behaviour as v1.
v1: https://lore.kernel.org/linux-usb/20260518073403.1285339-1-maoyi.xie@ntu.edu.sg/
drivers/usb/gadget/udc/aspeed_udc.c | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
--- a/drivers/usb/gadget/udc/aspeed_udc.c 2026-05-19 15:29:28.690931576 +0800
+++ b/drivers/usb/gadget/udc/aspeed_udc.c 2026-05-19 15:29:59.482953528 +0800
@@ -692,26 +692,30 @@
{
struct ast_udc_ep *ep = to_ast_ep(_ep);
struct ast_udc_dev *udc = ep->udc;
- struct ast_udc_request *req;
+ struct ast_udc_request *req = NULL, *iter;
unsigned long flags;
int rc = 0;
spin_lock_irqsave(&udc->lock, flags);
/* make sure it's actually queued on this endpoint */
- list_for_each_entry(req, &ep->queue, queue) {
- if (&req->req == _req) {
- list_del_init(&req->queue);
- ast_udc_done(ep, req, -ESHUTDOWN);
- _req->status = -ECONNRESET;
+ list_for_each_entry(iter, &ep->queue, queue) {
+ if (&iter->req == _req) {
+ req = iter;
break;
}
}
- /* dequeue request not found */
- if (&req->req != _req)
+ if (!req) {
rc = -EINVAL;
+ goto out;
+ }
+
+ list_del_init(&req->queue);
+ ast_udc_done(ep, req, -ESHUTDOWN);
+ _req->status = -ECONNRESET;
+out:
spin_unlock_irqrestore(&udc->lock, flags);
return rc;
--
2.34.1
^ permalink raw reply
* [PATCH v6 0/9] unwind, arm64: add sframe unwinder for kernel
From: Dylan Hatch @ 2026-05-19 6:49 UTC (permalink / raw)
To: Roman Gushchin, Weinan Liu, Will Deacon, Josh Poimboeuf,
Indu Bhagat, Peter Zijlstra, Steven Rostedt, Catalin Marinas,
Jiri Kosina, Mark Rutland, Jens Remus
Cc: Dylan Hatch, Prasanna Kumar T S M, Puranjay Mohan, Song Liu,
joe.lawrence, linux-toolchains, linux-kernel, live-patching,
linux-arm-kernel, Randy Dunlap, Mostafa Saleh, Herbert Xu,
David S. Miller
Implement a generic kernel sframe-based [1] unwinder. The main goal is
to improve reliable stacktrace on arm64 by unwinding across exception
boundaries.
On x86, the ORC unwinder provides reliable stacktrace through similar
methodology, but arm64 lacks the necessary support from objtool to
create ORC unwind tables.
Currently, there's already a sframe unwinder proposed for userspace: [2].
To maintain common definitions and algorithms for sframe lookup, a
substantial portion of this patch series aims to refactor the sframe
lookup code to support both kernel and userspace sframe sections.
Currently, only GNU Binutils support sframe. This series relies on the
Sframe V3 format, which is supported in binutils 2.46.
These patches are based on Steven Rostedt's sframe/core branch [3],
which is and aggregation of existing work done for x86 sframe userspace
unwind, and contains [2]. This branch is, in turn, based on Linux
v7.1-rc2. This full series (applied to the sframe/core branch) is
available on github: [4].
Ref:
[1]: https://sourceware.org/binutils/docs/sframe-spec.html
[2]: https://lore.kernel.org/all/20260505121718.3572346-1-jremus@linux.ibm.com/
[3]: https://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git/log/?h=sframe/core
[4]: https://github.com/dylanbhatch/linux/tree/sframe-v6
Changes since v5:
- Rebase on latest sframe/core branch [3] (based on v7.1-rc2).
- (Mark) Drop CFI annotations from el1*_64_* entry functions.
- (Mark) Add CFI annotations for leaf functions in lib/ and crypto/.
- (Jens) Sort module FDEs at load-time, drop linear search method.
- (Jens) Fix mistake in module SFrame validation where temp copy is not
yet embedded within a struct module.
- (Jens) Initialize debug info for kernel .sframe sections.
- (Mark) Move kernel-specific unwind fields to struct kunwind_state.
- (Mark) Drop SP from unwind state.
- (Mark) Rename unwind_next_frame_sframe -> kunwind_next_regs_sframe,
add checks to assert a correct KUNWIND_SOURCE_REGS_PC state.
- (Mark) Drop unused flexible FDE handling.
- (Mark) Check CFA alignment to 16 bytes instead of 8 bytes.
- (Mark) For non-KUNWIND_SOURCE_REGS_PC state, drop the fallback to
SFrame unwind if FP unwind fails in kunwind_next().
Dylan Hatch (8):
sframe: Allow kernelspace sframe sections
arm64, unwind: build kernel with sframe V3 info
arm64, crypto/lib: Annotate leaf functions with CFI info.
sframe: Provide PC lookup for vmlinux .sframe section
arm64/module, sframe: Add sframe support for modules
sframe: Introduce in-kernel SFRAME_VALIDATION
sframe: Initialize debug info for kernel sections
unwind: arm64: Use sframe to unwind interrupt frames
Weinan Liu (1):
arm64: entry: add unwind info for call_on_irq_stack()
MAINTAINERS | 4 +-
Makefile | 8 +
arch/Kconfig | 27 +-
arch/arm64/Kconfig | 1 +
arch/arm64/crypto/aes-ce-ccm-core.S | 12 +-
arch/arm64/crypto/aes-neonbs-core.S | 40 +-
arch/arm64/crypto/ghash-ce-core.S | 20 +-
arch/arm64/crypto/sm4-ce-ccm-core.S | 16 +-
arch/arm64/crypto/sm4-ce-cipher-core.S | 4 +-
arch/arm64/crypto/sm4-ce-core.S | 44 +-
arch/arm64/crypto/sm4-ce-gcm-core.S | 16 +-
arch/arm64/crypto/sm4-neon-core.S | 12 +-
arch/arm64/include/asm/linkage.h | 30 ++
arch/arm64/include/asm/module.h | 6 +
arch/arm64/include/asm/sections.h | 1 +
arch/arm64/include/asm/unwind_sframe.h | 54 +++
arch/arm64/kernel/entry.S | 14 +
arch/arm64/kernel/module.c | 8 +
arch/arm64/kernel/setup.c | 2 +
arch/arm64/kernel/stacktrace.c | 222 +++++++++-
arch/arm64/kernel/vdso/Makefile | 2 +-
arch/arm64/kernel/vmlinux.lds.S | 2 +
arch/arm64/lib/clear_page.S | 4 +-
arch/arm64/lib/clear_user.S | 4 +-
arch/arm64/lib/copy_from_user.S | 4 +-
arch/arm64/lib/copy_page.S | 4 +-
arch/arm64/lib/copy_to_user.S | 4 +-
arch/arm64/lib/memchr.S | 4 +-
arch/arm64/lib/memcmp.S | 4 +-
arch/arm64/lib/memcpy.S | 8 +-
arch/arm64/lib/memset.S | 8 +-
arch/arm64/lib/mte.S | 28 +-
arch/arm64/lib/strchr.S | 4 +-
arch/arm64/lib/strcmp.S | 4 +-
arch/arm64/lib/strlen.S | 4 +-
arch/arm64/lib/strncmp.S | 4 +-
arch/arm64/lib/strnlen.S | 4 +-
arch/arm64/lib/tishift.S | 12 +-
.../{unwind_user_sframe.h => unwind_sframe.h} | 6 +-
arch/x86/include/asm/unwind_user.h | 12 +-
include/asm-generic/sections.h | 4 +
include/asm-generic/vmlinux.lds.h | 15 +
include/linux/sframe.h | 67 ++-
include/linux/unwind_types.h | 46 ++
include/linux/unwind_user_types.h | 41 --
kernel/unwind/Makefile | 2 +-
kernel/unwind/sframe.c | 419 ++++++++++++++----
kernel/unwind/sframe_debug.h | 13 +
kernel/unwind/user.c | 45 +-
49 files changed, 979 insertions(+), 340 deletions(-)
create mode 100644 arch/arm64/include/asm/unwind_sframe.h
rename arch/x86/include/asm/{unwind_user_sframe.h => unwind_sframe.h} (50%)
create mode 100644 include/linux/unwind_types.h
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply
* Re: [PATCH] iommu: Allow device driver to use its own PASID space for SVA
From: Joonwon Kang @ 2026-05-19 8:11 UTC (permalink / raw)
To: jgg
Cc: Alexander.Grest, alexander.shishkin, amhetre, baolu.lu, bp,
dave.hansen, easwar.hariharan, hpa, iommu, jacob.jun.pan,
joonwonkang, joro, jpb, kas, kees, kevin.tian, kirill.shutemov,
linux-arm-kernel, linux-kernel, mingo, nicolinc, peterz, praan,
robin.murphy, ryasuoka, smostafa, sohil.mehta, tglx, will, x86,
xin
In-Reply-To: <20260518175249.GS7702@ziepe.ca>
> On Mon, May 18, 2026 at 09:06:54AM +0000, Joonwon Kang wrote:
> > > On Fri, May 15, 2026 at 09:46:05AM +0000, Joonwon Kang wrote:
> > > > diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> > > > index 0ca3912ecb7f..61e2e52105e5 100644
> > > > --- a/arch/x86/kernel/traps.c
> > > > +++ b/arch/x86/kernel/traps.c
> > > > @@ -864,6 +864,8 @@ static bool try_fixup_enqcmd_gp(void)
> > > > return false;
> > > >
> > > > pasid = mm_get_enqcmd_pasid(current->mm);
> > > > + if (pasid == IOMMU_PASID_INVALID)
> > > > + return false;
> > >
> > > If you do this then probably you should get rid of mm_valid_pasid(),
> > > mm_get_enqcmd_pasid() already has the NULL check so the two functions
> > > are kind of pointless.
> > >
> > > You also missed the other place calling mm_valid_pasid() that should
> > > really be sensitive to this as well:
> > >
> > > static int prctl_enable_tagged_addr(struct mm_struct *mm, unsigned long nr_bits)
> > > {
> > > [..]
> > > if (mm_valid_pasid(mm) &&
> > > !test_bit(MM_CONTEXT_FORCE_TAGGED_SVA, &mm->context.flags))
> > > return -EINVAL;
> > >
> > > Make that removal a prep patch
> > >
> >
> > Thanks for pointing this out. I think mm_valid_pasid() is to check if SVA
> > is currently in action while mm_get_enqcmd_pasid() is to get the PASID for
> > "ENQCMD instruction execution".
>
> > Since it is now possible with this patch to activate SVA without involving
> > EL0(for ENQCMD-like instructions),
>
> I see, this thing about which is about LAM should remain, yes
>
> But all the "EL0" machinery about trapping and enabling ENQCMD should
> be moved over to mm_get_enqcmd_pasid() and never call mm_valid_pasid()
Yes, it makes sense. Let me fix that in the next version.
Thanks,
Joonwon Kang
^ permalink raw reply
* Re: [PATCH v4 0/3] ARM: dts: aspeed-g6: add AST2600 I3C nodes and bindings
From: Dawid Glazik @ 2026-05-19 8:19 UTC (permalink / raw)
To: Andrew Jeffery, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, linux-aspeed
Cc: devicetree, linux-arm-kernel, linux-kernel, maciej.lawniczak
In-Reply-To: <23203c124a158536c272d1bffb2657a0d713f8ce.camel@codeconstruct.com.au>
On 5/18/2026 7:02 AM, Andrew Jeffery wrote:
>
> Sorry for the delay.
>
> Given Krzysztof's R-b tag for patch 2 I've applied 3 (along with 1) to
> the BMC tree. Patch 2 should be picked up by Lee through the MFD tree.
>
> Cheers,
>
> Andrew
Hi Andrew,
Great news! Thank you.
Dawid
^ permalink raw reply
* Re: [RFC PATCH v4 00/14] coco/TSM: Host-side Arm CCA IDE setup via connect/disconnect callbacks
From: Suzuki K Poulose @ 2026-05-19 8:24 UTC (permalink / raw)
To: Will Deacon, Aneesh Kumar K.V (Arm)
Cc: linux-coco, kvmarm, linux-arm-kernel, linux-kernel,
Alexey Kardashevskiy, Catalin Marinas, Dan Williams,
Jason Gunthorpe, Jonathan Cameron, Marc Zyngier, Samuel Ortiz,
Steven Price, Xu Yilun
In-Reply-To: <agsNO9cc7H-b0H8L@willie-the-truck>
On 18/05/2026 13:59, Will Deacon wrote:
> On Mon, Apr 27, 2026 at 12:21:07PM +0530, Aneesh Kumar K.V (Arm) wrote:
>> arch/arm64/include/asm/rmi_cmds.h | 85 +++
>> arch/arm64/include/asm/rmi_smc.h | 168 +++++
>
> Curious, but why does this stuff have to live in the arch code? Wouldn't
> it be better off somewhere like drivers/firmware/ or
> include/linux/arm-rmi.h?
Good point. RMI interface is only available for arm64 (not in Arm32).
That said, it is indeed a firmware ! ;-) interface. The APIs are closely
integrated with the KVM Realm management. If the general consensus is
to move them under drivers/firmware (like PSCI), we could take that
approach.
Suzuki
>
> Will
^ permalink raw reply
* Re: cleanup the RAID6 P/Q library v3
From: Christoph Hellwig @ 2026-05-19 8:24 UTC (permalink / raw)
To: Andrew Morton
Cc: Christoph Hellwig, Catalin Marinas, Will Deacon, Ard Biesheuvel,
Huacai Chen, WANG Xuerui, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Herbert Xu, Dan Williams,
Chris Mason, David Sterba, Arnd Bergmann, Song Liu, Yu Kuai,
Li Nan, linux-kernel, linux-arm-kernel, loongarch, linuxppc-dev,
linux-riscv, linux-s390, linux-crypto, linux-btrfs, linux-arch,
linux-raid
In-Reply-To: <20260518141205.c100f76eec5f58e78bbbf7af@linux-foundation.org>
On Mon, May 18, 2026 at 02:12:05PM -0700, Andrew Morton wrote:
> Cool, I'll add this to mm.git's mm-nonmm-unstable branch for some
> linux-next testing.
>
> AI review found quite a lot to talk about:
> https://sashiko.dev/#/patchset/20260518051804.462141-1-hch@lst.de
Not a lot of it is very useful, though:
raid6: turn the userspace test harness into a kunit test
- complains about basically adding need_resched, which we've decided
we won't do now that we have lazy preempt. This is probably going
to come up in lots of places because of the old training data
raid6: use named initializers for struct raid6_calls
- whining about keeping totally pointless comments
raid6: warn when using less than four devices
- complains about warning for btrfs which is clearly documented as the
outcome in the commit log
- and also complaining that the enforcement isn't hard enough, but the
WARN_ON is the best we can do here
raid6: rework registration of optimized algorithms
- less registration causing less kunit coverage: that's intentional
as it keeps testing time down and similar to other arch optimized
tests in crc and crypto code. It also doesn't really reduce
coverage as before this series there was none.
raid6: use static_call for gen_syndrom and xor_syndrom
- doesn't seem to know that bool fails when an initcall fails
raid6_kunit: use KUNIT_CASE_PARAM
- whining about the code style. I don't really like it either,
but the kunit case stuff is a mess
There are a few somewhat useful things, though.
raid6: hide internals
- yes, the -I is duplicate and should be fixed
raid6: rework registration of optimized algorithms
- avx2 instead of avx512 is probably the right thing for no
benchmarking, but if it was intentional (it wasn't), that should
be document. So I'll just switch back to the previous version to
keep the state of the art
^ permalink raw reply
* Re: [PATCH v2 0/3] arm64: perf: Skip device memory during user callchain unwinding
From: Fredrik Markstrom @ 2026-05-19 8:25 UTC (permalink / raw)
To: Will Deacon
Cc: Catalin Marinas, Shuah Khan, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Santosh Shilimkar, Olof Johansson, Tony Lindgren,
linux-arm-kernel, linux-kernel, linux-kselftest, linux-perf-users,
Nicolas Pitre, Ivar Holmqvist, Malin Jonsson
In-Reply-To: <agsq4wZMGth-T3BG@willie-the-truck>
On Mon, May 18, 2026 at 04:06:11PM +0100, Will Deacon wrote:
> On Thu, Apr 30, 2026 at 12:55:12PM +0200, Fredrik Markstrom wrote:
> > Perf callchain unwinding follows userspace frame pointers via
> > copy_from_user. A corrupted or malicious frame pointer can point
> > into device I/O memory mapped into the process (e.g. via UIO or
> > /dev/mem), causing the kernel to read from MMIO regions in PMU
> > interrupt context. Such reads can have side effects on hardware
> > (clearing status registers, advancing FIFOs, triggering DMA) and
> > on arm64 can produce a synchronous external abort that panics the
> > kernel.
>
> Hmm, but why is unwinding special in this case? If userspace has access
> to sensitive MMIO/device mappings, it can presumably pass them to
> syscalls and trigger crashes all over the place?
You’re totally right, a broken app with access to hardware like this can
already cause chaos by passing bad pointers to syscalls etc. But the big
difference here is who is to blame when things crash.
If an app passes a bad pointer to a syscall, it’s self-inflicted.
Unwinding here is asynchronous and unrelated to the application.
Perf interrupts a perfectly healthy app at a random moment. If that app
is using the frame pointer as a normal register (totally legal in
optimized code), it might hold a junk value that points to MMIO memory.
If the kernel blindly follows that junk pointer during an unwind, perf
causes the crash. I think it's acceptable that an app (with hardware
access) causes a crash if buggy, but I don't think it's acceptable that
a profiling tool is causing a crash just by looking at it.
Fredrik
>
> Will
^ permalink raw reply
* Re: [PATCH 0/3] phy: zynqmp: fix SERDES scrambler register handling and enable for USB
From: Laurent Pinchart @ 2026-05-19 8:25 UTC (permalink / raw)
To: Radhey Shyam Pandey
Cc: vkoul, neil.armstrong, michal.simek, linux-kernel, linux-phy,
linux-arm-kernel, git, Tomi Valkeinen
In-Reply-To: <20260511163135.2924642-1-radhey.shyam.pandey@amd.com>
Hi Radhey,
I haven't really been involved with the phy-zynqmp driver for a while,
despite still being listed as a maintainer. I have just sent a patch
(you're on CC) to hand maintainership duties over to Tomi Valkeinen, who
took over maintainership of the ZynqMP DPSUB driver. As Tomi isn't
really involved with the PHYs, in particular with the non-DP PHYs
supported by the driver, it could also make more sense for someone from
AMD to take over maintainer duties for phy-zynqmp.
On Mon, May 11, 2026 at 10:01:32PM +0530, Radhey Shyam Pandey wrote:
> This series fixes three related issues in the ZynqMP SERDES PHY
> scrambler/encoder bypass path:
>
> 1. The L0_TM_DISABLE_SCRAMBLE_ENCODER mask incorrectly included bit 2
> of L0_TX_DIG_61, which is a reserved read-only field. Correct the
> mask to (BIT(3) | GENMASK(1, 0)).
>
> 2. xpsgtr_bypass_scrambler_8b10b() used xpsgtr_write_phy() which
> performs a full register write, clobbering unrelated bits. Switch
> to xpsgtr_clr_set_phy() with clr=mask, set=mask to preserve other
> register fields.
>
> 3. USB Gen1 requires PHY-side scrambling and 8b/10b encoding as
> mandated by the USB 3.x specification. The driver was incorrectly
> bypassing these for USB, the same as SATA and SGMII where encoding
> is handled in the controller.
>
> Nava kishore Manne (3):
> phy: zynqmp: fix L0_TM_DISABLE_SCRAMBLE_ENCODER mask
> phy: zynqmp: use read-modify-write for SERDES scrambler bypass
> phy: zynqmp: keep SERDES scrambler and 8b/10b enabled for USB
>
> drivers/phy/xilinx/phy-zynqmp.c | 37 ++++++++++++++++++++++++++-------
> 1 file changed, 30 insertions(+), 7 deletions(-)
>
>
> base-commit: 5d6919055dec134de3c40167a490f33c74c12581
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 2/5] dt-bindings: connector: Add fsl,io-connector binding
From: Krzysztof Kozlowski @ 2026-05-19 8:29 UTC (permalink / raw)
To: Chancel Liu
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, festevam@gmail.com,
mturquette@baylibre.com, sboyd@kernel.org, kernel@pengutronix.de,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-clk@vger.kernel.org, Chancel Liu (OSS)
In-Reply-To: <AM9PR04MB83538C4A07A6835FF8A74793E3002@AM9PR04MB8353.eurprd04.prod.outlook.com>
On Tue, May 19, 2026 at 02:56:24AM +0000, Chancel Liu wrote:
> > >>> +description:
> > >>> + The NXP I/O connector represents a physically present I/O
> > >>> +connector on the
> > >>> + base board. It acts as a nexus that exposes a constrained set of
> > >>> +I/O
> > >>> + resources, such as GPIOs, clocks, PWMs and interrupts, through
> > >>> +fixed
> > >>> + electrical wiring. All actual hardware providers reside on the base
> > board.
> > >>> + The connector node only defines index-based mappings to those
> > >> providers.
> > >>> +
> > >>> +properties:
> > >>> + compatible:
> > >>> + const: fsl,io-connector
> > >>
> > >> Everything is IO. Everything is connector, so your compatible does
> > >> not match requirements from writing bindings.
> > >>
> > >
> > > Yes, this compatible is too generic. I will rename the compatible to
> > > fsl,aud-io-connector.
> >
> > aud is not much better. Which boards have it? What's the pinout? What's
> > standard? Is it described anywhere? If so, provide reference to spec/docs.
> >
>
> This is not an industry standard electrical interface. This connector
Then if you do not have standard, then you have board specific layouts
thus you need board-specific compatibles. You can use fallbacks. Generic
fallback could work, but both io-connector and aud-io-connector are just
too generic. Every connector is "connector" and "io", thus absolutely
anything can be "io-connector". "aud" improves it only a bit, thus
honestly I would go with board specific fallback as well.
> is present on i.MX95-19x19-EVK and i.MX952-EVK. For example, the
> "i.MX 95 19mm x 19mm Evaluation Kit" homepage[1] publicly documents an
> audio board connection through which IMX-AUD-IO card is connected. The
> detailed user manual (UM12022) is listed as official documentation[2],
> but it is behind an NXP login, so it is not suitable as a public
> reference for upstream. Therefore I list it here to illustrate it's
> mechanism:
>
> +-----------------------------+
> | Base Board |
> | +-----+ +---------+ | +---------+
> | | SPI +------+ | | | |
> | +-----+ | | | GPIO MAP | |
> | | +--|-----------+ |
> | +-----+ | | | | |
> | | I2C +------+ | | | |
> | +-----+ | | | CLOCK MAP | AUD-IO |
> | |connector+--|-----------+ CARD |
> | +-----+ | | | | |
> | | I2S +------+ | | | |
> | +-----+ | | | | |
> | | | | INT MAP | |
> | +-----+ | +--|-----------+ |
> | | I/O +------+ | | | |
> | +-----+ +---------+ | +---------+
> +-----------------------------+
>
> [1]https://www.nxp.com/design/design-center/development-boards-and-designs/IMX95LPD5EVK-19
> [2]https://docs.nxp.com/bundle/UM12022/page/topics/pcie_interface1.html
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] ASoC: mediatek: mt2701: fix snprintf bounds
From: Mark Brown @ 2026-05-19 8:33 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-sound, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Matthias Brugger, AngeloGioacchino Del Regno,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
In-Reply-To: <20260519010440.629290-1-rosenp@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 653 bytes --]
On Mon, May 18, 2026 at 06:04:40PM -0700, Rosen Penev wrote:
> For whatever reason, GCC is unable to figure out that i2s_num is a
> single digit number, with MT2701_BASE_CLK_NUM being the maximum value it
> represents. Add a min() call to help it out and fix W=1 errors regarding
> snprintf bounds.
> + i2s_num = min(MT2701_BASE_CLK_NUM, afe_priv->soc->i2s_num);
> /* Get I2S related clocks */
> - for (i = 0; i < afe_priv->soc->i2s_num; i++) {
> + for (i = 0; i < i2s_num; i++) {
This makes the code rather obscure and will start silently failing if we
ever get more than 9 clocks, we should at least put a build time assert
or a warn on in there.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] firmware: arm_scmi: Fix OOB in scmi_power_name_get()
From: Cristian Marussi @ 2026-05-19 8:36 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Cristian Marussi, Dan Carpenter, Sudeep Holla, arm-scmi,
linux-arm-kernel, linux-kernel
In-Reply-To: <agcNULwGvCACUYx2@pluto>
On Fri, May 15, 2026 at 01:10:56PM +0100, Cristian Marussi wrote:
> On Fri, May 15, 2026 at 02:00:24PM +0200, Geert Uytterhoeven wrote:
> > Hi Cristian,
> >
> > On Fri, 15 May 2026 at 13:46, Cristian Marussi <cristian.marussi@arm.com> wrote:
> > > On Fri, May 15, 2026 at 01:29:27PM +0200, Geert Uytterhoeven wrote:
> > > > On Fri, 15 May 2026 at 12:28, Dan Carpenter <error27@gmail.com> wrote:
> > > > > On Fri, May 15, 2026 at 11:59:15AM +0200, Geert Uytterhoeven wrote:
> > > > > > scmi_power_name_get() does not validate the domain number passed by the
> > > > > > external caller, which may lead to an out-of-bounds access.
> > > > >
> > > > > Is an external caller an out of tree caller? So far as I can see this
> > > >
> > > > I meant a caller outside drivers/firmware/arm_scmi/.
> > > >
> > > > > is only called by scmi_pm_domain_probe().
> > > > >
> > > > > scmi_pd->name = power_ops->name_get(ph, i);
> > > > >
> > > > > where i < num_domains.
> > > >
> > > > You are right. But this seems to be only API implementation in
> > > > drivers/firmware/arm_scmi/ that does not validate the passed domain
> > > > number.
> > >
> > > Yes we tend to validate protocol operations calls even if apparently
> > > safe from teh caller perspective...indeed I have this fixed locally
> > > since ages in an horrible patch, that does a lot more, and that I
> > > never posted :P
> > >
> > > Usually, if it is worth, we also build an internal domain get helper to
> > > reuse across the protocol unit...but here really there are only 2 call-sites.
> > >
> > > What I am not sure is what to return: "unknown" is safer as of now than NULL
> > > for sure, but really, what happened is NOT that the name was "unknown" (which
> > > by itself would be out-of-spec behaviour) it is more that the whole domain that
> > > was referred to that was invalid and NOT existent...
> > >
> > > ....mmm I suppose we are opening another can of worms here :P
> >
> > Like scmi_perf_info_get() returning ERR_PTR(-EINVAL) instead of NULL,
> > and scmi_perf_domain_probe() never checking the return value anyway?
>
> ...oh probably more than that...and related vendor FW that already exploits
> these missing checks here and there to arbitrarily skip domains and return
> out-of-spec non-contigous sets of domains becasue they cannot bother to
> implement properly the spec (or they have simply forked their codebase from
> an old drop and never updated it again...)...so that any kernel-side fix
> you made along the road carries the risk of breaking something and a string
> of possibly needed quirks...
Anyway, it is the safest option on the table until proper checks are in place.
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Thanks,
Cristian
^ permalink raw reply
* Re: [PATCH 1/4] firmware: arm_scmi: Read sensor config as 32-bit value
From: Cristian Marussi @ 2026-05-19 8:38 UTC (permalink / raw)
To: Sudeep Holla; +Cc: Cristian Marussi, arm-scmi, linux-arm-kernel
In-Reply-To: <20260517-scmi_fixes-v1-1-d86daec4defd@kernel.org>
On Sun, May 17, 2026 at 08:02:40PM +0100, Sudeep Holla wrote:
> The SENSOR_CONFIG_GET response contains a 32-bit sensor_config field,
> and the xfer is initialized with a 4-byte RX buffer. Reading it with
> get_unaligned_le64() can consume bytes past the returned payload.
>
> Use get_unaligned_le32() to match the protocol layout and the allocated
> response size.
>
> Fixes: 7b83c5f41088 ("firmware: arm_scmi: Add SCMI v3.0 sensor configuration support")
> Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
> ---
> drivers/firmware/arm_scmi/sensors.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/arm_scmi/sensors.c b/drivers/firmware/arm_scmi/sensors.c
> index 882d55f987d2..836c294a9f42 100644
> --- a/drivers/firmware/arm_scmi/sensors.c
> +++ b/drivers/firmware/arm_scmi/sensors.c
> @@ -793,7 +793,7 @@ static int scmi_sensor_config_get(const struct scmi_protocol_handle *ph,
> if (!ret) {
> struct scmi_sensor_info *s = si->sensors + sensor_id;
>
> - *sensor_config = get_unaligned_le64(t->rx.buf);
> + *sensor_config = get_unaligned_le32(t->rx.buf);
> s->sensor_config = *sensor_config;
> }
Reviewed-by: Cristian Marussi <cristian.marussi@arm.com>
Thanks,
Cristian
^ permalink raw reply
* [PATCH] arm64: dts: mediatek: mt8516: remove cpu3 armpll clock-name
From: Luca Leonardo Scorcia @ 2026-05-19 8:39 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Fabien Parent, devicetree, linux-kernel, linux-arm-kernel
The armpll clock in cpu3 clock-names property comes from MediaTek sources,
but it's unused in the kernel and not populated in the clocks property.
Let's remove it and align the node with other cpu nodes of the same SoC.
Fixes: 5236347bde42 ("arm64: dts: mediatek: add dtsi for MT8516")
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
arch/arm64/boot/dts/mediatek/mt8516.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/mediatek/mt8516.dtsi b/arch/arm64/boot/dts/mediatek/mt8516.dtsi
index 42712ac2b88d..21882ac4fadb 100644
--- a/arch/arm64/boot/dts/mediatek/mt8516.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8516.dtsi
@@ -99,7 +99,7 @@ cpu3: cpu@3 {
<&CPU_SLEEP_0_0 &CPU_SLEEP_0_0 &CPU_SLEEP_0_0>;
clocks = <&infracfg CLK_IFR_MUX1_SEL>,
<&topckgen CLK_TOP_MAINPLL_D2>;
- clock-names = "cpu", "intermediate", "armpll";
+ clock-names = "cpu", "intermediate";
operating-points-v2 = <&cluster0_opp>;
#cooling-cells = <2>;
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 2/3] memory: mtk-smi: Add a flag skip_rpm
From: Xueqi Zhang (张雪琦) @ 2026-05-19 8:40 UTC (permalink / raw)
To: robh@kernel.org, matthias.bgg@gmail.com,
Yong Wu (吴勇), AngeloGioacchino Del Regno,
krzk@kernel.org, conor+dt@kernel.org
Cc: Wendy-ST Lin (林詩庭),
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
Project_Global_Chrome_Upstream_Group, devicetree@vger.kernel.org
In-Reply-To: <1a8b6793-661f-4676-bb29-6c1ee11a3ce9@collabora.com>
Hi Angelo,
Thanks for the detailed explanation. I now understand your concern
about being future-proof and maintaining a unified pm_runtime flow.
In our current MT8196 DTS, these RTFF-managed SMI common nodes
do not have a 'power-domains' property, as the power is handled
automatically by the hardware.
If we follow your suggestion to keep the pm_runtime_{en,dis}able()
calls but set clk_required = 0, the runtime callback functions
(smi_common_runtime_resume/suspend) will still be triggered.
To avoid any potential conflicts with the RTFF hardware's automatic
register restoration and to save unnecessary software overhead,
I propose to:
1. Use the 'rtff_managed' flag as you suggested.
2. Set clk_required = 0 when 'rtff_managed' is true.
3. Add a check inside the runtime_resume/suspend callbacks: if
'rtff_managed' is true, return immediately without performing
any register backup or restoration.
This way, we keep the standard pm_runtime infrastructure as you
requested, while ensuring the software doesn't interfere with the
RTFF hardware's operations.
Does this sound reasonable to you?
Thanks,
Xueqi
On Mon, 2026-05-18 at 12:02 +0200, AngeloGioacchino Del Regno wrote:
> On 5/18/26 09:16, Xueqi Zhang (张雪琦) wrote:
> > Hi Angelo,
> >
> > First of all, please accept my apologies for the delayed response.
> > I
> > have been deeply occupied with MT8196 Aluminium pKVM SMMU and SMI
> > related tasks recently.
> >
> > Regarding your question, my previous description in the patch was
> > not
> > accurate enough and may have caused some confusion. In fact, not
> > all SMI commons have their backup/restore handled by the RTFF
> > hardware. The SMI commons are distributed across various subsystems
> > (e.g., mminfra, venc, display, cam, etc.). Currently, only the SMI
> > common under the mminfra subsystem is backed up and restored by
> > the RTFF hardware.
> >
> > Therefore, I believe adding a specific 'skip_rpm' flag is more
> > appropriate here. If we were to differentiate this based on a new
> > MTK_SMI_GEN3 type, it would imply that all SMI common modules of
> > that generation would skip the RPM operations, which is not the
> > intended behavior.
> >
> > To make this clearer, I plan to update the commit message in the
> > next version as follows:
> >
> > Subject: memory: mtk-smi: Add skip_rpm flag for certain MT8196 SMI
> > commons
>
> memory: mtk-smi: Allow no clocks for RTFF managed SMI commons
>
> >
> > Body:
> > On MT8196, certain SMI commons are backed up and restored by the
> > RTFF
> > hardware rather than by software.
> >
> > For these specific SMI commons, software-controlled register backup
> > and restore in the runtime callback is no longer necessary.
> > Therefore,
> > introduce a 'skip_rpm' flag to bypass these redundant RPMoperations
> > for these SMI commons.
> >
> > What do you think about this approach?
> >
>
> That would be kind-of ok, but keep in mind: pm_runtime doesn't only
> manage clocks.
>
> I think that the best option here would be to allow having no clocks
> instead,
> and to still call pm_runtime_{en,dis}able() - as that would get a bit
> more
> future-proof, should any other (newer, older, etc) SoC need to
> declare any power
> domain but still no clocks.
>
> So at this point, I think that just doing something like:
>
> if (common->plat->has_gals) {
> if (common->plat->rtff_managed) <--- not "skip_rpm"
> clk_required = 0;
> else if (common->plat->type == MTK_SMI_GEN2)
> clk_required = MTK_SMI_COM_GALS_REQ_CLK_NR;
> else if (common->plat->type == MTK_SMI_GEN2_SUB_COMM)
> clk_required = MTK_SMI_SUB_COM_GALS_REQ_CLK_NR;
> }
>
> should be sufficient (and/or check zero required clocks in
> smi_dts_clk_init).
>
> Cheers,
> Angelo
>
> > Thanks,
> > Xueqi
> >
> > On Thu, 2025-03-20 at 13:11 +0100, AngeloGioacchino Del Regno
> > wrote:
> > > External email : Please do not click links or open attachments
> > > until
> > > you have verified the sender or the content.
> > >
> > >
> > > Il 20/03/25 08:36, Xueqi Zhang ha scritto:
> > > > MT8196 SMI commons is backed up/restored by RTFF HW.
> > > > It doesn't need SW control the register backup/store
> > > > in the runtime callback.Therefore, add a flag skip_rpm
> > > > to help skip RPM operations for SMI commons.
> > > >
> > > > Signed-off-by: Xueqi Zhang <xueqi.zhang@mediatek.com>
> > >
> > > So the MT8196 SMI common doesn't require any clocks?
> > >
> > > That's fine for me, but this looks bloody similar to MT6989's SMI
> > > common, which
> > > is SMI GEN3 and not GEN2....
> > >
> > > ....so, are you sure that you need a `skip_rpm` flag and not new
> > > MTK_SMI_GEN3 and
> > > MTK_SMI_GEN3_SUB_COMM types? :-)
> > >
> > > Regards,
> > > Angelo
> > >
> > > > ---
> > > > drivers/memory/mtk-smi.c | 11 ++++++++---
> > > > 1 file changed, 8 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/memory/mtk-smi.c b/drivers/memory/mtk-
> > > > smi.c
> > > > index a8f5467d6b31..b9affa3c3185 100644
> > > > --- a/drivers/memory/mtk-smi.c
> > > > +++ b/drivers/memory/mtk-smi.c
> > > > @@ -123,6 +123,7 @@ static const char * const
> > > > mtk_smi_common_clks[]
> > > > = {"apb", "smi", "gals0", "gals1
> > > > struct mtk_smi_common_plat {
> > > > enum mtk_smi_type type;
> > > > bool has_gals;
> > > > + bool skip_rpm;
> > > > u32 bus_sel; /* Balance some larbs
> > > > to
> > > > enter mmu0 or mmu1 */
> > > >
> > > > const struct mtk_smi_reg_pair *init;
> > > > @@ -547,6 +548,9 @@ static int mtk_smi_dts_clk_init(struct
> > > > device
> > > > *dev, struct mtk_smi *smi,
> > > > {
> > > > int i, ret;
> > > >
> > > > + if (smi->plat->skip_rpm)
> > > > + return 0;
> > > > +
> > > > for (i = 0; i < clk_nr_required; i++)
> > > > smi->clks[i].id = clks[i];
> > > > ret = devm_clk_bulk_get(dev, clk_nr_required, smi-
> > > > >clks);
> > > > @@ -783,7 +787,7 @@ static int mtk_smi_common_probe(struct
> > > > platform_device *pdev)
> > > > common->dev = dev;
> > > > common->plat = of_device_get_match_data(dev);
> > > >
> > > > - if (common->plat->has_gals) {
> > > > + if (!common->plat->skip_rpm && common->plat->has_gals) {
> > > > if (common->plat->type == MTK_SMI_GEN2)
> > > > clk_required =
> > > > MTK_SMI_COM_GALS_REQ_CLK_NR;
> > > > else if (common->plat->type ==
> > > > MTK_SMI_GEN2_SUB_COMM)
> > > > @@ -814,13 +818,14 @@ static int mtk_smi_common_probe(struct
> > > > platform_device *pdev)
> > > > }
> > > >
> > > > /* link its smi-common if this is smi-sub-common */
> > > > - if (common->plat->type == MTK_SMI_GEN2_SUB_COMM) {
> > > > + if (common->plat->type == MTK_SMI_GEN2_SUB_COMM &&
> > > > !common-
> > > > > plat->skip_rpm) {
> > > >
> > > > ret = mtk_smi_device_link_common(dev, &common-
> > > > > smi_common_dev);
> > > >
> > > > if (ret < 0)
> > > > return ret;
> > > > }
> > > >
> > > > - pm_runtime_enable(dev);
> > > > + if (!common->plat->skip_rpm)
> > > > + pm_runtime_enable(dev);
> > > > platform_set_drvdata(pdev, common);
> > > > return 0;
> > > > }
> > >
> > >
>
>
^ permalink raw reply
* Re: [PATCH v2 1/2] i2c: imx: Don't recover bus when arbitration lost
From: Dan Scally @ 2026-05-19 8:42 UTC (permalink / raw)
To: Oleksij Rempel, Pengutronix Kernel Team
Cc: linux-i2c, imx, linux-arm-kernel, Andi Shyti, Frank Li,
Sascha Hauer, Fabio Estevam, Gao Pan, Fugang Duan, Wolfram Sang
In-Reply-To: <20260424-i2c-imx-fixes-v2-1-34fb9504aaeb@ideasonboard.com>
Hello Oleksij / all
On 24/04/2026 13:36, Daniel Scally wrote:
> In i2c_imx_xfer_common(), the driver attempts bus recovery whenever
> i2c_imx_start() fails. One of the failure modes for i2c_imx_start()
> is an arbitration-lost signal which results when a second I2C master
> on the bus tries to control the bus simultaneously, which is a normal
> and expected behaviour.
>
> Bus recovery is not the right response for this case. Add a check for
> the -EAGAIN return code to avoid running the bus recovery.
>
> Fixes: 1c4b6c3bcf30d ("i2c: imx: implement bus recovery")
> Signed-off-by: Daniel Scally <dan.scally@ideasonboard.com>
> ---
I raised this patch after we had issues with one of the i2c controllers on imx8mp. In that case, the
bus had multiple masters that were causing the SoC's i2c controller to lose arbitration. The result
was that the framework attempted to run i2c_generic_scl_recovery() and regularly hit the "SCL is
stuck low, exit recovery" message [1] because the bus was busy rather than stuck.
I'm now experiencing a different issue with the imx8mp in which a different controller - which isn't
on a multiple-masters bus - starts transacting fine early in boot, but then seems to get stuck - any
attempt to start a transaction by either a driver or i2ctransfer results in the IAL bit in I2C_I2SR
being set and so the driver reports that it's lost arbitration [2]. In this case, the bus recovery
is needed to fix the problem, and so this commit hurts things rather than helps them. This problem
isn't consistent - I get it on maybe 10% of boots.
I'm trying to find a way to handle the two problems together. I can move the retries into the
i2x-imx driver like below, and that works so far:
diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index a208fefd3c3b3..cee333236646a 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -1551,7 +1551,20 @@ static int i2c_imx_xfer_common(struct i2c_adapter *adapter,
int use_dma = 0;
/* Start I2C transfer */
- result = i2c_imx_start(i2c_imx, atomic);
+ for (unsigned int try = 0; try <= 3; try++) {
+ result = i2c_imx_start(i2c_imx, atomic);
+ if (result == -EAGAIN) {
+ i2c_imx_stop(i2c_imx, atomic);
+
+ if (i2c_imx->slave)
+ i2c_imx_slave_init(i2c_imx);
+
+ continue;
+ }
+
+ break;
+ }
+
if (result) {
/*
* Bus recovery uses gpiod_get_value_cansleep() which is not
That way it retries 3 times if i2c_bus_busy() reports -EAGAIN from lost arbitration, but then gives
up and runs the bus recovery if none of the retries works. I do wonder why the i2c controller is
setting the IAL bit though given there's no other master on the bus. If I use a logic analyser to
track traffic on the bus I can't see anything anomalous, so I thought I'd check whether anyone has
experienced something similar before.
[1] https://elixir.bootlin.com/linux/v7.0.1/source/drivers/i2c/i2c-core-base.c#L254
[2] https://elixir.bootlin.com/linux/v7.0.1/source/drivers/i2c/busses/i2c-imx.c#L548
> drivers/i2c/busses/i2c-imx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
> index a208fefd3c3b35672a00eda8448f24859aaa793a..b68a0f7105682006bbcfee52891c9a9c2d8c009e 100644
> --- a/drivers/i2c/busses/i2c-imx.c
> +++ b/drivers/i2c/busses/i2c-imx.c
> @@ -1552,7 +1552,7 @@ static int i2c_imx_xfer_common(struct i2c_adapter *adapter,
>
> /* Start I2C transfer */
> result = i2c_imx_start(i2c_imx, atomic);
> - if (result) {
> + if (result && result != -EAGAIN) {
> /*
> * Bus recovery uses gpiod_get_value_cansleep() which is not
> * allowed within atomic context.
>
^ 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