* Re: [PATCH v4 3/6] KVM: arm64: Add auto DBM support for hardware dirty tracking
From: Leonardo Bras @ 2026-07-20 12:58 UTC (permalink / raw)
To: Tian Zheng
Cc: Leonardo Bras, Oliver Upton, maz, catalin.marinas, will,
yuzenghui, wangzhou1, yangjinqian1, caijian11, liuyonglong,
yezhenyu2, yubihong, linuxarm, joey.gouly, kvmarm, kvm,
linux-arm-kernel, linux-kernel, seiden, suzuki.poulose
In-Reply-To: <alpIfIOFfrudBzD5@LeoBrasDK>
On Fri, Jul 17, 2026 at 04:21:32PM +0100, Leonardo Bras wrote:
> On Fri, Jul 17, 2026 at 11:58:06AM +0800, Tian Zheng wrote:
> >
> > On 7/16/2026 3:39 PM, Oliver Upton wrote:
> > > Hi Tian,
> > >
> > > On Thu, Jul 09, 2026 at 06:40:23PM +0800, Tian Zheng wrote:
> > > > - if (prot & KVM_PGTABLE_PROT_W)
> > > > + if (prot & KVM_PGTABLE_PROT_W) {
> > > > set |= KVM_PTE_LEAF_ATTR_LO_S2_S2AP_W;
> > > >
> > > > + /*
> > > > + * No DEVICE filter needed here: relax_perms is only called
> > > > + * on FSC_PERM faults. Device pages always get full RW from
> > > > + * initial mapping and are never write-protected during
> > > > + * migration, so they never trigger a permission fault.
> > > > + */
> > > > + if (pgt->flags & KVM_PGTABLE_S2_DBM)
> > > > + set |= KVM_PTE_LEAF_ATTR_HI_S2_DBM;
> > > > + } else {
> > > > + /*
> > > > + * Clear DBM on W→RO downgrade to prevent hardware from
> > > > + * silently upgrading RO+DBM back to W+dirty, which would
> > > > + * bypass KVM's write tracking and cause data corruption.
> > > > + */
> > > > + clr |= KVM_PTE_LEAF_ATTR_HI_S2_DBM;
> > > > + }
> > > > +
> > > This block makes it pretty evident that the DBM bit really *is* the
> > > write permission bit. I'd much rather we introduce the concept of dirty
> > > state to the page table library and migrate the abstract write
> > > permission to the DBM field, even if we don't have FEAT_HAFDBS.
> > >
>
> Ohh, that's an amazing idea!
Thinking about that again...
If we adopt the encoding with DBM being the write-permission bit, and all
PTEs have it since the start, how can we have lazy-splitting happening?
Only way I think of is removing both DBM and S2_S2AP_W bit from writable
PTEs during dirty-track enable, and re-adding them during the first write
fault. If we don't remove the DBM bit, systems with HDBSS would just dirty
it by hardware, without causing a fault.
DBM=0 would need to happen only in the first write-protect (only on
lazy-splitting). All other write-protecting would just clean the S2_S2AP_W
bit, as everything is already split.
Is that what was intended?
Thanks!
Leo
^ permalink raw reply
* Re: [PATCH] arm64: dts: mediatek: mt8192-asurada: Disable mmc1 on Spherion
From: AngeloGioacchino Del Regno @ 2026-07-20 12:58 UTC (permalink / raw)
To: Matthias Brugger, Chen-Yu Tsai
Cc: linux-mediatek, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260720092759.1831105-1-wenst@chromium.org>
On Mon, 20 Jul 2026 17:27:57 +0800, Chen-Yu Tsai wrote:
> Spherion does not have an micro SD card slot.
>
> Disable mmc1.
Applied to v7.2-next/dts64, thanks!
[1/1] arm64: dts: mediatek: mt8192-asurada: Disable mmc1 on Spherion
commit: 934cccd2c6795a20d04bd470ec7eb3151950fbfc
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH v6 01/14] media: mediatek: vcodec: support vcp architecture
From: Nicolas Dufresne @ 2026-07-20 12:57 UTC (permalink / raw)
To: Kyrie Wu, Tiffany Lin, Andrew-CT Chen, Yunfei Dong,
Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Ricardo Ribalda, Kees Cook, Hans Verkuil, Fei Shao, Haoxiang Li,
Chen-Yu Tsai, Laurent Pinchart, Tomasz Figa, Sebastian Fricke,
Philipp Zabel, Benjamin Gaignard, Qianfeng Rong, Irui Wang,
Jacopo Mondi, Fan Wu, linux-media, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
Cc: Sakari Ailus
In-Reply-To: <20260720012056.1026551-2-kyrie.wu@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 2089 bytes --]
Hi,
Le lundi 20 juillet 2026 à 09:20 +0800, Kyrie Wu a écrit :
> Some platforms expose the video codec through the VCP coprocessor.
> Use the VCP architecture when the VCP coprocessor is found.
>
> Signed-off-by: Kyrie Wu <kyrie.wu@mediatek.com>
> Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
> ---
> drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h | 1 +
> .../platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c | 3 +++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
> index 300363a40..c1642fb09 100644
> --- a/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
> +++ b/drivers/media/platform/mediatek/vcodec/common/mtk_vcodec_fw.h
> @@ -14,6 +14,7 @@ struct mtk_vcodec_enc_dev;
> enum mtk_vcodec_fw_type {
> VPU,
> SCP,
> + VCP,
> };
>
> enum mtk_vcodec_fw_use {
> diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> index e936ed8df..d220b645e 100644
> --- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> +++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec_drv.c
> @@ -379,6 +379,9 @@ static int mtk_vcodec_probe(struct platform_device *pdev)
> } else if (!of_property_read_u32(pdev->dev.of_node, "mediatek,scp",
> &rproc_phandle)) {
> fw_type = SCP;
> + } else if (!of_property_read_u32(pdev->dev.of_node, "mediatek,vcp",
> + &rproc_phandle)) {
> + fw_type = VCP;
I know I gave an rb a while ago, but then we reviewed the 8189 code, and we
underlined that this makes little sense, and that fw_type should simply be set
in the pdata. Same applies to mtk_vcodec_dec_get_chip_name(), the chip "name",
or integer form of, is clearly a 1 to 1 match for pdata.
Nicolas
> } else {
> dev_dbg(&pdev->dev, "Could not get vdec IPI device");
> return -ENODEV;
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RESEND] dt-bindings: PCI: mediatek-gen3: Allow memory-region for restricted DMA buffer
From: Manivannan Sadhasivam @ 2026-07-20 12:53 UTC (permalink / raw)
To: Rob Herring, Bjorn Helgaas, Chen-Yu Tsai
Cc: Matthias Brugger, AngeloGioacchino Del Regno, linux-pci,
linux-mediatek, devicetree, linux-arm-kernel, linux-kernel,
Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20260720092116.1823562-1-wenst@chromium.org>
On Mon, 20 Jul 2026 17:21:15 +0800, Chen-Yu Tsai wrote:
> On some SoCs without an IOMMU behind the PCIe controller, the PCIe
> controller memory access could be limited to a small region by the
> firmware configuring a memory protection unit. This memory region
> must be assigned to the PCIe controller so that the OS knows to
> use that region. Otherwise PCIe devices would not work properly.
>
> Allow the memory-region property with one item pointing to a
> restricted DMA buffer.
>
> [...]
Applied, thanks!
[1/1] dt-bindings: PCI: mediatek-gen3: Allow memory-region for restricted DMA buffer
commit: 7e38b7b0e0e582024e97289a3b63c201f226124d
Best regards,
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH RESEND] dt-bindings: PCI: mediatek-gen3: Allow memory-region for restricted DMA buffer
From: Manivannan Sadhasivam @ 2026-07-20 12:51 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Rob Herring, Bjorn Helgaas, Matthias Brugger,
AngeloGioacchino Del Regno, linux-pci, linux-mediatek, devicetree,
linux-arm-kernel, linux-kernel, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20260720092116.1823562-1-wenst@chromium.org>
On Mon, Jul 20, 2026 at 05:21:15PM +0800, Chen-Yu Tsai wrote:
> On some SoCs without an IOMMU behind the PCIe controller, the PCIe
> controller memory access could be limited to a small region by the
> firmware configuring a memory protection unit. This memory region
> must be assigned to the PCIe controller so that the OS knows to
> use that region. Otherwise PCIe devices would not work properly.
>
> Allow the memory-region property with one item pointing to a
> restricted DMA buffer.
>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Acked-by: Rob Herring (Arm) <robh@kernel.org>
> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
> ---
> Can we get this merged for v7.2? A matching device tree change was
> already merged in v7.2-rc1.
>
This is not a bug fix, so not sure if this patch can be applied for 7.2. But DTS
change getting applied before the binding change was a mistake first of all.
- Mani
>
> Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
> index fbc0378392d4..b88717dec1fa 100644
> --- a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
> +++ b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml
> @@ -116,6 +116,10 @@ properties:
> power-domains:
> maxItems: 1
>
> + memory-region:
> + maxItems: 1
> + description: phandle to restricted DMA buffer
> +
> mediatek,pbus-csr:
> $ref: /schemas/types.yaml#/definitions/phandle-array
> items:
> --
> 2.55.0.229.g6434b31f56-goog
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH 2/3] nvmem: mtk-efuse: add support for 32-bit aligned reads
From: AngeloGioacchino Del Regno @ 2026-07-20 12:48 UTC (permalink / raw)
To: rva333, Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, Andrew-CT Chen, Lala Lin
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260715-6572-nvmem-v1-2-9c13be99d077@protonmail.com>
On 7/15/26 16:27, Roman Vivchar via B4 Relay wrote:
> From: Roman Vivchar <rva333@protonmail.com>
>
> Some MediaTek SoCs, such as mt6572, don't support 8-bit reads, leading
> to zeroes or garbage data. 32-bit aligned reads must be used instead.
>
> Introduce an 'needs_aligned_read' field to the platform data to enforce
> 32-bit aligned register access. All reads will be performed by reading
> 4-byte words and masking them.
>
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
You're effectively overriding the entire mtk_reg_read function when
needs_aligned_read==true... so.... (check below)
> ---
> drivers/nvmem/mtk-efuse.c | 31 ++++++++++++++++++++++++++++---
> 1 file changed, 28 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
> index af953e1d9230..1462f2760818 100644
> --- a/drivers/nvmem/mtk-efuse.c
> +++ b/drivers/nvmem/mtk-efuse.c
> @@ -4,6 +4,7 @@
> * Author: Andrew-CT Chen <andrew-ct.chen@mediatek.com>
> */
>
> +#include <linux/align.h>
> #include <linux/device.h>
> #include <linux/module.h>
> #include <linux/mod_devicetable.h>
> @@ -14,10 +15,12 @@
>
> struct mtk_efuse_pdata {
> bool uses_post_processing;
> + bool needs_aligned_read;
> };
>
> struct mtk_efuse_priv {
> void __iomem *base;
> + const struct mtk_efuse_pdata *data;
...instead of adding pdata here...
> };
>
> static int mtk_reg_read(void *context,
> @@ -28,6 +31,26 @@ static int mtk_reg_read(void *context,
> u8 *val = _val;
> int i;
>
> + if (priv->data->needs_aligned_read) {
> + u32 pos, shift, val32;
> +
> + for (i = 0; i < bytes; i++, val++) {
> + pos = reg + i;
> +
> + /*
> + * Read on 32-bit word boundary or if it's the first
> + * iteration
> + */
> + if (i == 0 || IS_ALIGNED(pos, 4))
> + val32 = readl(priv->base + (pos & ~3));
> +
> + shift = (pos & 3) * 8;
> + *val = (val32 >> shift) & 0xff;
> + }
> +
> + return 0;
> + }
> +
> for (i = 0; i < bytes; i++, val++)
> *val = readb(addr + i);
>
> @@ -67,7 +90,6 @@ static int mtk_efuse_probe(struct platform_device *pdev)
> struct nvmem_device *nvmem;
> struct nvmem_config econfig = {};
> struct mtk_efuse_priv *priv;
> - const struct mtk_efuse_pdata *pdata;
> struct platform_device *socinfo;
>
> priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> @@ -78,7 +100,8 @@ static int mtk_efuse_probe(struct platform_device *pdev)
> if (IS_ERR(priv->base))
> return PTR_ERR(priv->base);
>
> - pdata = device_get_match_data(dev);
> + priv->data = device_get_match_data(dev);
> +
...and instead of changing a bunch of lines here...
> econfig.add_legacy_fixed_of_cells = true;
> econfig.stride = 1;
> econfig.word_size = 1;
it's easier at this point if you simply do
if (pdata->needs_aligned_read) {
econfig.stride = 4;
econfig.reg_read = mtk_reg_read_aligned;
} else {
econfig.stride = 1;
econfig.reg_read = mtk_reg_read;
}
and you avoid touching mtk_reg_read entirely.
Though it's not going to be used in any performance path, that's also faster as
there's one less branch per execution.
Cheers,
Angelo
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: nvmem: mediatek: efuse: add mt6572
From: AngeloGioacchino Del Regno @ 2026-07-20 12:48 UTC (permalink / raw)
To: rva333, Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, Andrew-CT Chen, Lala Lin
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260715-6572-nvmem-v1-1-9c13be99d077@protonmail.com>
On 7/15/26 16:27, Roman Vivchar via B4 Relay wrote:
> From: Roman Vivchar <rva333@protonmail.com>
>
> Add a compatible string for the mt6572 SoC efuse controller.
>
Please, avoid adding this to the list of compatibles that need you do specify
"mediatek,mt6572-efuse", "mediatek,efuse";
The "generic" compatible should disappear.. and plus, the MT6572 SoC seems to
be pretty special, as you had to implement aligned read just for that.
This won't be the only SoC as well, as probably all of the legacy one from the
same era will be affected... so please, add it as a const so that you can have
a devicetree with an efuse node declaring
compatible = "mediatek,mt6572-efuse";
Cheers,
Angelo
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
> ---
> Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml b/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml
> index f9323b3ecfc8..269e2b09f5c8 100644
> --- a/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml
> +++ b/Documentation/devicetree/bindings/nvmem/mediatek,efuse.yaml
> @@ -44,6 +44,7 @@ properties:
>
> - items:
> - enum:
> + - mediatek,mt6572-efuse
> - mediatek,mt7622-efuse
> - mediatek,mt7623-efuse
> - mediatek,mt7981-efuse
>
^ permalink raw reply
* Re: [PATCH 3/3] nvmem: mtk-efuse: add mt6572 support
From: AngeloGioacchino Del Regno @ 2026-07-20 12:48 UTC (permalink / raw)
To: rva333, Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, Andrew-CT Chen, Lala Lin
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260715-6572-nvmem-v1-3-9c13be99d077@protonmail.com>
On 7/15/26 16:27, Roman Vivchar via B4 Relay wrote:
> From: Roman Vivchar <rva333@protonmail.com>
>
> Add a platform data struct for the efuse controller.
>
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
> ---
> drivers/nvmem/mtk-efuse.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/nvmem/mtk-efuse.c b/drivers/nvmem/mtk-efuse.c
> index 1462f2760818..a79434608465 100644
> --- a/drivers/nvmem/mtk-efuse.c
> +++ b/drivers/nvmem/mtk-efuse.c
> @@ -124,6 +124,11 @@ static int mtk_efuse_probe(struct platform_device *pdev)
> return 0;
> }
>
> +static const struct mtk_efuse_pdata mtk_mt6572_efuse_pdata = {
> + .uses_post_processing = false,
Are you sure this SoC (or any other compatible with it) doesn't have any GPU speed
binning?
If you're really sure
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> + .needs_aligned_read = true,
> +};
> +
> static const struct mtk_efuse_pdata mtk_mt8186_efuse_pdata = {
> .uses_post_processing = true,
> .needs_aligned_read = false,
> @@ -135,6 +140,7 @@ static const struct mtk_efuse_pdata mtk_efuse_pdata = {
> };
>
> static const struct of_device_id mtk_efuse_of_match[] = {
> + { .compatible = "mediatek,mt6572-efuse", .data = &mtk_mt6572_efuse_pdata },
> { .compatible = "mediatek,mt8173-efuse", .data = &mtk_efuse_pdata },
> { .compatible = "mediatek,mt8186-efuse", .data = &mtk_mt8186_efuse_pdata },
> { .compatible = "mediatek,efuse", .data = &mtk_efuse_pdata },
>
^ permalink raw reply
* Re: [RESEND PATCH v2] PCI: imx6: Add runtime PM support for i.MX95
From: Manivannan Sadhasivam @ 2026-07-20 12:47 UTC (permalink / raw)
To: frank.li, l.stach, lpieralisi, kwilczynski, robh, bhelgaas,
s.hauer, kernel, festevam, hongxing.zhu
Cc: linux-pci, linux-arm-kernel, imx, linux-kernel, Richard Zhu
In-Reply-To: <20260715073024.1377228-1-hongxing.zhu@oss.nxp.com>
On Wed, 15 Jul 2026 15:30:24 +0800, hongxing.zhu@oss.nxp.com wrote:
> Enable runtime PM support for i.MX95 PCIe Root Complex to allow dynamic
> power management when the PCIe link is idle.
>
> The i.MX95 PCIe controller supports entering D3hot state when PCIe
> devices are not actively in use. This implementation uses
> pm_runtime_no_callbacks() to leverage the PCI core's generic runtime PM
> handling. The PCI core automatically manages D-state transitions based
> on the runtime PM state of connected endpoint devices.
>
> [...]
Applied, thanks!
[1/1] PCI: imx6: Add runtime PM support for i.MX95
commit: c2b9620359b759d2c73be47689b3a344cb4e091b
Best regards,
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v1] driver: fpga: xilinx-selectmap: add csi and rdwr support
From: Michal Simek @ 2026-07-20 12:40 UTC (permalink / raw)
To: Heiko Schocher, linux-kernel
Cc: linux-fpga, linux-arm-kernel, Moritz Fischer, Tom Rix, Xu Yilun
In-Reply-To: <20260716070020.4113618-1-hs@nabladev.com>
On 7/16/26 09:00, Heiko Schocher wrote:
> Add csi_b and rdwr pin support for the xilinx,selectmap driver.
>
> In current driver the pins are configured from DTS and set to
> GPIOD_OUT_HIGH. This works in case you have one FPGA.
>
> Extend this to really implement csi_b and rdwr pin function in
> driver, so it works with more than one FPGA.
>
> Tested on AM625 based board with 2 FPGAs connected to GPMC.
>
> Signed-off-by: Heiko Schocher <hs@nabladev.com>
> ---
>
> drivers/fpga/xilinx-selectmap.c | 20 ++++++++++++++++++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/fpga/xilinx-selectmap.c b/drivers/fpga/xilinx-selectmap.c
> index d0cbb5fdfe3a..b5fbdedf8aec 100644
> --- a/drivers/fpga/xilinx-selectmap.c
> +++ b/drivers/fpga/xilinx-selectmap.c
> @@ -19,6 +19,8 @@
> struct xilinx_selectmap_conf {
> struct xilinx_fpga_core core;
> void __iomem *base;
> + struct gpio_desc *csi_b;
> + struct gpio_desc *rdwr_b;
> };
>
> #define to_xilinx_selectmap_conf(obj) \
> @@ -30,9 +32,21 @@ static int xilinx_selectmap_write(struct xilinx_fpga_core *core,
> struct xilinx_selectmap_conf *conf = to_xilinx_selectmap_conf(core);
> size_t i;
>
> + if (conf->csi_b)
Is this really needed?
4023 int gpiod_set_value(struct gpio_desc *desc, int value)
4024 {
4025 VALIDATE_DESC(desc);
4026 /* Should be using gpiod_set_value_cansleep() */
4027 WARN_ON(desc->gdev->can_sleep);
4028 return gpiod_set_value_nocheck(desc, value);
4029 }
4030 EXPORT_SYMBOL_GPL(gpiod_set_value);
398 #define VALIDATE_DESC(desc) do { \
399 int __valid = validate_desc(desc, __func__); \
400 if (__valid <= 0) \
401 return __valid; \
402 } while (0)
385 static int validate_desc(const struct gpio_desc *desc, const char *func)
386 {
387 if (!desc)
388 return 0;
389
390 if (IS_ERR(desc)) {
391 pr_warn("%s: invalid GPIO (errorpointer: %pe)\n", func, desc);
392 return PTR_ERR(desc);
393 }
394
395 return 1;
396 }
397
You should be able to just skip it because validate_desc is checking it for you.
> + gpiod_set_value(conf->csi_b, GPIOD_OUT_HIGH);
> +
> + if (conf->rdwr_b)
> + gpiod_set_value(conf->rdwr_b, GPIOD_OUT_HIGH);
> +
> for (i = 0; i < count; ++i)
> writeb(buf[i], conf->base);
>
> + if (conf->rdwr_b)
> + gpiod_set_value(conf->rdwr_b, GPIOD_OUT_LOW);
> +
> + if (conf->csi_b)
> + gpiod_set_value(conf->csi_b, GPIOD_OUT_LOW);
> +
> return 0;
> }
>
> @@ -56,16 +70,18 @@ static int xilinx_selectmap_probe(struct platform_device *pdev)
> conf->base = base;
>
> /* CSI_B is active low */
> - gpio = devm_gpiod_get_optional(&pdev->dev, "csi", GPIOD_OUT_HIGH);
> + gpio = devm_gpiod_get_optional(&pdev->dev, "csi", GPIOD_OUT_LOW);
> if (IS_ERR(gpio))
> return dev_err_probe(&pdev->dev, PTR_ERR(gpio),
> "Failed to get CSI_B gpio\n");
> + conf->csi_b = gpio;
Isn't it easier to simply call to avoid it?
conf->csi_b = devm_gpiod_get_optional(&pdev->dev, "csi", GPIOD_OUT_LOW);
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH] KVM: arm64: ptdump: Flush the last region
From: Mark Rutland @ 2026-07-20 12:37 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: linux-arm-kernel, kvmarm, linux-kernel, Marc Zyngier,
Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Dev Jain, Ryan Roberts, Sebastian Ene, Vincent Donnefort
In-Reply-To: <n5yni7vnama2ok2uzmhahrghrioqjbpcqui44v367rqc57qzqu@wfnio5stdmp3>
On Mon, Jul 20, 2026 at 11:58:44AM +0100, Wei-Lin Chang wrote:
> On Mon, Jul 20, 2026 at 09:35:01AM +0100, Mark Rutland wrote:
> > On Sat, Jul 18, 2026 at 12:12:33AM +0100, Wei-Lin Chang wrote:
> > > @@ -155,11 +155,13 @@ static int kvm_ptdump_guest_show(struct seq_file *m, void *unused)
> > > .seq = m,
> > > };
> > >
> > > - write_lock(&kvm->mmu_lock);
> > > + guard(write_lock)(&kvm->mmu_lock);
> > > ret = kvm_pgtable_walk(mmu->pgt, 0, BIT(mmu->pgt->ia_bits), &walker);
> > > - write_unlock(&kvm->mmu_lock);
> > > + if (ret)
> > > + return ret;
> > > + note_page(&st->parser_state.ptdump, BIT(mmu->pgt->ia_bits), -1, 0);
> >
> > This can be:
> >
> > note_page_flush(&st->parser_state.ptdump);
> >
> > The level change alone should trigger the dump, so the address doesn't
> > need to be at the end of the guest IPA space.
> >
> > Importantly, note_page_flush() will pass 0 as the address, which won't
> > trigger the checks you try to suppress below.
> >
> > Please use note_page_flush() here, and drop the changes to
> > arch/arm64/mm/ptdump.c.
>
> Sorry, I shouldn't have omitted this information, but I did try
> note_page_flush(). And it gives something like this in the last row:
>
> 0x00000000ffc00000-0x0000000000000000 17592186040324M 2 R W px ux AF BLK
>
> The astronomical size is from (addr - st->start_address). As IA bits for
> stage-2 are not close to 64, we'll have large sizes for the last row.
Ok. That's a bug in the current implementation of note_page_flush(),
then. The *intent* is that note_page_flush() is used to terminate
output, and we should mak it work.
Do we need to pass additional information, or do we have the necessary
values in (or accessible from) struct ptdump_state?
> That's one of the reasons I chose to call note_page() with
> BIT(pgtable->ia_bits) as addr, to end the ptdump at the end of the guest
> IPA space.
>
> Additionally, the last row is combining two ranges:
>
> 1. 0x00000000ffc00000-0x0000000100000000 4M 2 R W px ux AF BLK
> 2. 0x0000000100000000-0x0000000000000000 BIG_SIZE - (empty prot)
>
> The attributes are wrong for the large range after
> BIT(pgtable->ia_bits). This is because before dumping the last row, the
> ptdump code is waiting to be notified of the end of the final region
> with all those {R, W, px, ux, AF, BLK} attributes. Using
> note_page_flush() essentially tells it the valid range ends at 1 << 64.
> So actually using note_page() with BIT(pgtable->ia_bits) is required for
> correctness.
>
> The kernel ptdump is not affected by this (at least from my quick test):
>
> 0xffffffffff6fe000-0xffffffffff800000 1032K PTE
> 0xffffffffff800000-0x0000000000000000 8M PMD
Yes, it's not affected because its final VA is 0xffffffffffffffff (i.e.
2^64i - 1), and so using 0 as the next address does the right thing
modulo 64 bits.
We use ptdump for non-kernel tables today (e.g. the EFI mm), so
presumably they suffer the same problem?
Mark.
^ permalink raw reply
* Re: [PATCH v2] coresight: dummy: add missing MODULE_DEVICE_TABLE()
From: Leo Yan @ 2026-07-20 12:37 UTC (permalink / raw)
To: Pengpeng Hou
Cc: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Jie Gan, coresight, linux-arm-kernel, linux-kernel
In-Reply-To: <20260720114514.51656-1-pengpeng@iscas.ac.cn>
On Mon, Jul 20, 2026 at 07:45:14PM +0800, Pengpeng Hou wrote:
> The CoreSight dummy driver has an OF match table wired into its platform
> driver, but does not export the table to module metadata. A modular build
> therefore lacks OF aliases for automatic loading.
>
> Export dummy_match with MODULE_DEVICE_TABLE().
>
> Fixes: 9d3ba0b6c056 ("Coresight: Add coresight dummy driver")
> Reviewed-by: Jie Gan <jie.gan@oss.qualcomm.com>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Leo Yan <leo.yan@arm.com>
> ---
> Changes since v1: https://lore.kernel.org/all/20260704121621.48544-1-pengpeng@iscas.ac.cn/
> - add the requested Fixes tag
> - carry Jie Gan's conditional Reviewed-by after making that change
> - rebase onto v7.2-rc4
>
> drivers/hwtracing/coresight/coresight-dummy.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-dummy.c b/drivers/hwtracing/coresight/coresight-dummy.c
> index c176a2f57300..04880d38feb7 100644
> --- a/drivers/hwtracing/coresight/coresight-dummy.c
> +++ b/drivers/hwtracing/coresight/coresight-dummy.c
> @@ -212,6 +212,7 @@ static const struct of_device_id dummy_match[] = {
> {.compatible = "arm,coresight-dummy-sink"},
> {},
> };
> +MODULE_DEVICE_TABLE(of, dummy_match);
>
> static struct platform_driver dummy_driver = {
> .probe = dummy_probe,
>
^ permalink raw reply
* Re: [PATCH v4 0/4] arm64: dts: amlogic: meson-axg: NAND fix and PCIe PHY adjustment
From: Neil Armstrong @ 2026-07-20 12:31 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, Arseniy Krasnov, Jun Yan
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <20260624135650.727077-1-jerrysteve1101@gmail.com>
Hi,
On Wed, 24 Jun 2026 21:56:40 +0800, Jun Yan wrote:
> - Disable nfc node by default ahead of nand_rb0 pin addition.
> - Add missing nand_rb0 pin to fix incomplete NAND pinctrl.
> - Disable pcie_phy by default to suppress probe warning.
> - Re-enable pcie_phy on S400 board to preserve PCIe functionality.
> - Enable mipi_pcie_analog_dphy for PCIe on S400 board.
>
> Changes in v4:
> - Add patch to enable mipi_pcie_analog_dphy for PCIe on S400 board.
> - Link to v3:
> https://lore.kernel.org/all/20260617082239.645562-1-jerrysteve1101@gmail.com/
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.3/arm64-dt)
[1/4] arm64: dts: amlogic: meson-axg: Disable nfc node by default
https://git.kernel.org/amlogic/c/77c63ef3be3972eb3d8aac2dd36f349d78620b0d
[2/4] arm64: dts: amlogic: meson-axg: Add missing nand_rb0 pin to nand_all_pins
https://git.kernel.org/amlogic/c/45eb76f9ab6854f79690d56d04df227429a536b8
[3/4] arm64: dts: amlogic: meson-axg: Disable pcie_phy node by default
https://git.kernel.org/amlogic/c/25ab968f7d27f46927658150bf466cac856e4f4f
[4/4] arm64: dts: amlogic: meson-axg-s400: enable mipi_pcie_analog_dphy for PCIe
https://git.kernel.org/amlogic/c/7f1d0cc86cb70fa550163b6f70fd1d484c03218e
These changes has been applied on the intermediate git tree [1].
The v7.3/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: [PATCH] arm64: dts: amlogic: Correct indentation and whitespace
From: Neil Armstrong @ 2026-07-20 12:31 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, devicetree, linux-arm-kernel,
linux-amlogic, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260706093508.273968-2-krzysztof.kozlowski@oss.qualcomm.com>
Hi,
On Mon, 06 Jul 2026 11:35:09 +0200, Krzysztof Kozlowski wrote:
> Correct spaces or mix of tabs+spaces into proper tab-indented lines and
> remove other whitespace violations. No functional impact (same DTB).
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.3/arm64-dt)
[1/1] arm64: dts: amlogic: Correct indentation and whitespace
https://git.kernel.org/amlogic/c/6c4345eb714f094ea579e3234cafed9f8c0634f8
These changes has been applied on the intermediate git tree [1].
The v7.3/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* Re: [PATCH v2 04/18] KVM: arm64: Add a heap allocator for the pKVM hyp
From: Vincent Donnefort @ 2026-07-20 12:30 UTC (permalink / raw)
To: Fuad Tabba
Cc: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, linux-arm-kernel, kvmarm, kernel-team,
qperret
In-Reply-To: <CA+EHjTwSupmgbjbeUap4EEwy8DP7y8euZRHd2tXc=FSDGzrghA@mail.gmail.com>
On Wed, Jul 15, 2026 at 11:59:26AM +0100, Fuad Tabba wrote:
> On Tue, 14 Jul 2026 at 19:35, Fuad Tabba <fuad.tabba@linux.dev> wrote:
> >
> > On Mon, 6 Jul 2026 at 18:54, Vincent Donnefort <vdonnefort@google.com> wrote:
> >
> > ...
> >
> > > +static u32 chunk_hash_compute(const struct chunk_hdr *chunk)
> > > +{
> > > + u32 hash = 0;
> > > +
> > > + BUILD_BUG_ON(sizeof(*chunk) != 16);
> > > +
> > > + hash ^= hash_64(*(const u64 *)chunk, 32);
> > > + hash ^= hash_32(chunk->__unmapped, 32);
> >
> > Could you state the threat model in the commit msg? The VA range is
> > hyp-private and the hash is unkeyed (anything that can write EL2
> > memory recomputes it), so this only catches _accidental_ corruption,
> > i.e. a debug aid.
> >
> > Since that's the goal, should it be gated on CONFIG_NVHE_EL2_DEBUG
> > like the other checks here? As written it's O(n) hashing per
> > hyp_alloc(), in production, for a check that only fires on a hyp bug.
> > And a plain XOR/additive checksum would be cheaper and just as good
> > for accidental corruption.
>
> Thinking about it, I was wrong to say that it would be just as good,
> slightly cheaper, but it would detect things like swaps.
>
> Still, I think this should be gated.
After a longer offline discussion, we concluded this doesn't cost anything while
the weak protection can still be effective against attackers who may not always
control the entire bit-width.
I'll add some details in the commit message.
>
> Cheers,
> /fuad
>
> >
> > > + return hash;
> > > +}
> > > +
> >
> > ...
> >
> >
> > > diff --git a/arch/arm64/kvm/hyp/nvhe/setup.c b/arch/arm64/kvm/hyp/nvhe/setup.c
> > > index 75b00c323310..1c10cf78c869 100644
> > > --- a/arch/arm64/kvm/hyp/nvhe/setup.c
> > > +++ b/arch/arm64/kvm/hyp/nvhe/setup.c
> > > @@ -10,6 +10,7 @@
> > > #include <asm/kvm_pgtable.h>
> > > #include <asm/kvm_pkvm.h>
> > >
> > > +#include <nvhe/alloc.h>
> > > #include <nvhe/early_alloc.h>
> > > #include <nvhe/ffa.h>
> > > #include <nvhe/gfp.h>
> > > @@ -363,6 +364,10 @@ int __pkvm_init(phys_addr_t phys, unsigned long size, unsigned long *per_cpu_bas
> > > if (ret)
> > > return ret;
> > >
> > > + ret = hyp_alloc_init(SZ_128M);
> >
> > Where does 128M come from? A comment would help.
This is arbitrary, big enough to allow us to allocate plenty of VMs with tracing
enable. But I will add something.
> >
> > Cheers,
> > /fuad
> >
> >
> >
> > > + if (ret)
> > > + return ret;
> > > +
> > > update_nvhe_init_params();
> > >
> > > /* Jump in the idmap page to switch to the new page-tables */
> > > --
> > > 2.55.0.rc2.803.g1fd1e6609c-goog
> > >
^ permalink raw reply
* Re: [PATCH v3 2/4] media: synopsys: hdmirx: add HDMI audio capture support
From: Igor Paunovic @ 2026-07-20 12:30 UTC (permalink / raw)
To: Dmitry Osipenko
Cc: Mauro Carvalho Chehab, Sebastian Reichel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, linux-media,
linux-rockchip, linux-arm-kernel, kernel, devicetree,
linux-kernel
In-Reply-To: <25922edc-4ff1-4d28-9a64-2c28b2b690cb@collabora.com>
Hi Dmitry,
Great to hear it works on the 5B -- thanks for testing!
Agreed on the -EBUSY guard, done in my tree exactly as you wrote it.
It also supersedes the suspend cancel/re-arm I had queued from the
bot review: with suspend refused while audio_streaming is set, the
worker can never be armed at suspend time, so those hunks are
dropped.
v4 follows shortly with this plus Sebastian's dts restructuring
(shared disabled-by-default card in rk3588-extra.dtsi, renamed to
"RK3588 HDMI-IN") and Krzysztof's binding comments (dai-common.yaml
reference + unevaluatedProperties).
Igor
On Mon, Jul 20, 2026 at 3:43 AM Dmitry Osipenko
<dmitry.osipenko@collabora.com> wrote:
>
> On 7/18/26 11:57, Igor Paunovic wrote:
> > The Synopsys DesignWare HDMI RX controller extracts the audio stream
> > embedded in the incoming HDMI signal and feeds it to an on-SoC I2S
> > controller. Expose it as an ALSA capture device by registering the
> > generic hdmi-codec as a child of the controller, so that a
> > simple-audio-card in the device tree can bind the HDMI RX audio DAI.
> >
> > The sample rate is recovered from the ACR N/CTS values together with the
> > measured TMDS character rate. A periodic worker keeps the local audio
> > reference clock locked to the source by nudging it in small ppm steps to
> > hold the audio FIFO fill level near its target, which avoids FIFO
> > under/overflow and the resulting dropped samples.
> >
> > Signed-off-by: Igor Paunovic <royalnet026@gmail.com>
> > ---
> > Changes in v3:
> > - restore the v1 audio teardown in remove(): audio_shutdown() already
> > stops the worker when the stream closes, so the extra flag clear
> > and trailing cancel added in v2 were redundant (Dmitry Osipenko)
> > - rename the ACR read locals and add a comment documenting the
> > register byte packing
> > - drop the get_dai_id stub so OF-graph cards resolve the DAI index
> > from the reg property
> >
> > Changes in v2:
> > - register the S/PDIF DAI so the indexes match the binding and reject
> > it with -EOPNOTSUPP until wired up (Sebastian Reichel)
> > - use platform_device_register_data() and drop the fixed 32-bit DMA
> > mask (Dmitry Osipenko)
> > - don't leave an ERR_PTR in audio_pdev on registration failure
> > - fix teardown ordering in remove()
> > - stop the worker before reprogramming shared state in hw_params()
> > - look up the "audio" clock by name instead of indexing clks[1]
> > - keep the worker on system_unbound_wq when re-arming
> >
> > .../platform/synopsys/hdmirx/snps_hdmirx.c | 271 ++++++++++++++++++
> > .../platform/synopsys/hdmirx/snps_hdmirx.h | 8 +
> > 2 files changed, 279 insertions(+)
>
> Works well on 5b, thanks. Only one additional review comment:
>
> Please update hdmirx_suspend() to return -EBUSY if audio_streaming=true.
>
> ```
> static __maybe_unused int hdmirx_suspend(struct device *dev)
> {
> struct snps_hdmirx_dev *hdmirx_dev = dev_get_drvdata(dev);
>
> if (READ_ONCE((hdmirx_dev->audio_streaming)))
> return -EBUSY;
> ```
>
> --
> Best regards,
> Dmitry
^ permalink raw reply
* AW: [PATCH 3/4] drm/rockchip: lvds: add RK3568 support
From: Jakob Loe @ 2026-07-20 12:20 UTC (permalink / raw)
To: 'Alibek Omarov', 'Rok Markovic'
Cc: 'Heiko Stuebner', 'Sandy Huang',
'Andy Yan', 'Maarten Lankhorst',
'Maxime Ripard', 'Thomas Zimmermann',
'David Airlie', 'Simona Vetter',
'Rob Herring', 'Krzysztof Kozlowski',
'Conor Dooley', dri-devel, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <CAKyg=SV2-81VFgr+Tq=-Si5EO-86MA+ZFoQ+DX1fEYdnnLYJng@mail.gmail.com>
Hello!
Nice to see this is still being used.
I can confirm that this actually works and outputs fine LVDS on a RK3566. Also reliably so far...
Any questions, I will see what I can help.
All the best
Jakob
-----Ursprüngliche Nachricht-----
Von: Alibek Omarov <a1ba.omarov@gmail.com>
Gesendet: Montag, 20. Juli 2026 07:39
An: Rok Markovic <rok@kanardia.eu>
Cc: Heiko Stuebner <heiko@sntech.de>; Sandy Huang <hjc@rock-chips.com>; Andy Yan <andy.yan@rock-chips.com>; Maarten Lankhorst <maarten.lankhorst@linux.intel.com>; Maxime Ripard <mripard@kernel.org>; Thomas Zimmermann <tzimmermann@suse.de>; David Airlie <airlied@gmail.com>; Simona Vetter <simona@ffwll.ch>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; dri-devel@lists.freedesktop.org; devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-rockchip@lists.infradead.org; linux-kernel@vger.kernel.org; Jakob Loeschke <jakob@loe-web.de>
Betreff: Re: [PATCH 3/4] drm/rockchip: lvds: add RK3568 support
> Based on Alibek Omarov's earlier posting [1], with the changes below.
Hi, I'm Alibek Omarov and thanks for picking up my patches. I didn't had time to finish them and these days I don't work on hardware that uses any of Rockchip SoCs. However, if I'm not wrong, it's still used in production and I had report from Jakob Loeschke (added in CC) who confirmed it worked in their setup as well.
Thanks.
^ permalink raw reply
* [PATCH v2] coresight: dummy: add missing MODULE_DEVICE_TABLE()
From: Pengpeng Hou @ 2026-07-20 11:45 UTC (permalink / raw)
To: Suzuki K Poulose
Cc: Mike Leach, James Clark, Leo Yan, Alexander Shishkin, Jie Gan,
coresight, linux-arm-kernel, linux-kernel, Pengpeng Hou
The CoreSight dummy driver has an OF match table wired into its platform
driver, but does not export the table to module metadata. A modular build
therefore lacks OF aliases for automatic loading.
Export dummy_match with MODULE_DEVICE_TABLE().
Fixes: 9d3ba0b6c056 ("Coresight: Add coresight dummy driver")
Reviewed-by: Jie Gan <jie.gan@oss.qualcomm.com>
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
Changes since v1: https://lore.kernel.org/all/20260704121621.48544-1-pengpeng@iscas.ac.cn/
- add the requested Fixes tag
- carry Jie Gan's conditional Reviewed-by after making that change
- rebase onto v7.2-rc4
drivers/hwtracing/coresight/coresight-dummy.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hwtracing/coresight/coresight-dummy.c b/drivers/hwtracing/coresight/coresight-dummy.c
index c176a2f57300..04880d38feb7 100644
--- a/drivers/hwtracing/coresight/coresight-dummy.c
+++ b/drivers/hwtracing/coresight/coresight-dummy.c
@@ -212,6 +212,7 @@ static const struct of_device_id dummy_match[] = {
{.compatible = "arm,coresight-dummy-sink"},
{},
};
+MODULE_DEVICE_TABLE(of, dummy_match);
static struct platform_driver dummy_driver = {
.probe = dummy_probe,
^ permalink raw reply related
* RE: [PATCH v10 3/4] reset: cix: add sky1 audss auxiliary reset driver
From: Joakim Zhang @ 2026-07-20 12:17 UTC (permalink / raw)
To: Philipp Zabel, mturquette@baylibre.com, sboyd@kernel.org,
bmasney@redhat.com, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org
Cc: cix-kernel-upstream, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <0d0c7befafd2e60b8887245f4e60a504704014dc.camel@pengutronix.de>
Hello Philipp,
> -----Original Message-----
> From: Philipp Zabel <p.zabel@pengutronix.de>
> Sent: Monday, July 20, 2026 3:20 PM
> To: Joakim Zhang <joakim.zhang@cixtech.com>; mturquette@baylibre.com;
> sboyd@kernel.org; bmasney@redhat.com; robh@kernel.org; krzk+dt@kernel.org;
> conor+dt@kernel.org
> Cc: cix-kernel-upstream <cix-kernel-upstream@cixtech.com>; linux-
> clk@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org
> Subject: Re: [PATCH v10 3/4] reset: cix: add sky1 audss auxiliary reset driver
>
> EXTERNAL EMAIL
>
> CAUTION: Suspicious Email from unusual domain.
>
> On Mo, 2026-07-20 at 13:15 +0800, joakim.zhang@cixtech.com wrote:
> > From: Joakim Zhang <joakim.zhang@cixtech.com>
> >
> > Add an auxiliary reset controller driver for the AUDSS CRU. Sixteen
> > software reset lines for audio subsystem peripherals are controlled
> > through one register in the CRU register map.
> >
> > The driver is created by the AUDSS clock platform driver and registers
> > the reset controller on the CRU device node.
> >
> > Signed-off-by: Joakim Zhang <joakim.zhang@cixtech.com>
> > ---
> > drivers/reset/Kconfig | 13 +++
> > drivers/reset/Makefile | 1 +
> > drivers/reset/reset-sky1-audss.c | 137
> > +++++++++++++++++++++++++++++++
> > 3 files changed, 151 insertions(+)
> > create mode 100644 drivers/reset/reset-sky1-audss.c
> >
> > diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index
> > d009eb0849a3..b19e719f2abe 100644
> > --- a/drivers/reset/Kconfig
> > +++ b/drivers/reset/Kconfig
> > @@ -300,6 +300,19 @@ config RESET_SKY1
> > help
> > This enables the reset controller for Cix Sky1.
> >
> > +config RESET_SKY1_AUDSS
> > + tristate "Cix Sky1 Audio Subsystem reset controller"
> > + depends on ARCH_CIX || COMPILE_TEST
> > + select AUXILIARY_BUS
> > + default CLK_SKY1_AUDSS
> > + help
> > + Support for block-level software reset lines in the Cix Sky1
> > + Audio Subsystem (AUDSS) Clock and Reset Unit. Sixteen reset
> > + outputs for audio peripherals are controlled through the CRU
> > + register map. The driver binds as an auxiliary device from
> > + the AUDSS clock driver. Say M or Y here if you want to build
> > + this driver.
> > +
> > config RESET_SOCFPGA
> > bool "SoCFPGA Reset Driver" if COMPILE_TEST && (!ARM
> || !ARCH_INTEL_SOCFPGA)
> > default ARM && ARCH_INTEL_SOCFPGA diff --git
> > a/drivers/reset/Makefile b/drivers/reset/Makefile index
> > 3e52569bd276..e81407ea3e29 100644
> > --- a/drivers/reset/Makefile
> > +++ b/drivers/reset/Makefile
> > @@ -39,6 +39,7 @@ obj-$(CONFIG_RESET_RZV2H_USB2PHY) +=
> > reset-rzv2h-usb2phy.o
> > obj-$(CONFIG_RESET_SCMI) += reset-scmi.o
> > obj-$(CONFIG_RESET_SIMPLE) += reset-simple.o
> > obj-$(CONFIG_RESET_SKY1) += reset-sky1.o
> > +obj-$(CONFIG_RESET_SKY1_AUDSS) += reset-sky1-audss.o
> > obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
> > obj-$(CONFIG_RESET_SUNPLUS) += reset-sunplus.o
> > obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o diff --git
> > a/drivers/reset/reset-sky1-audss.c b/drivers/reset/reset-sky1-audss.c
> > new file mode 100644
> > index 000000000000..d31d80e1251a
> > --- /dev/null
> > +++ b/drivers/reset/reset-sky1-audss.c
> > @@ -0,0 +1,137 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Cix Sky1 Audio Subsystem reset controller driver
> > + *
> > + * Copyright 2026 Cix Technology Group Co., Ltd.
> > + */
> > +
> > +#include <dt-bindings/reset/cix,sky1-audss-cru.h>
> > +
> > +#include <linux/auxiliary_bus.h>
> > +#include <linux/delay.h>
> > +#include <linux/device.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
>
> What is this used for?
Nothing; will drop it.
> > +#include <linux/regmap.h>
> > +#include <linux/reset-controller.h>
> > +
> > +#define SKY1_RESET_SLEEP_MIN_US 50
> > +#define SKY1_RESET_SLEEP_MAX_US 100
>
> Is this delay compatible with all possible modules being reset?
>
> Are min and max from a spec or is this just some safe value?
> Maybe you could only define the _MIN_US and use fsleep() below.
There is no per-block reset timing in the TRM for AUDSS SW_RST; 50 us
is a conservative safe delay. Happy to switch to fsleep(SKY1_RESET_SLEEP_MIN_US)
and drop MAX.
> > +
> > +#define AUDSS_SW_RST 0x78
> > +
> > +struct sky1_audss_reset_map {
> > + unsigned int offset;
> > + unsigned int mask;
> > +};
> > +
> > +struct sky1_audss_reset {
> > + struct reset_controller_dev rcdev;
> > + struct regmap *regmap;
> > + const struct sky1_audss_reset_map *map; };
> > +
> > +static const struct sky1_audss_reset_map sky1_audss_reset_map[] = {
> > + [AUDSS_I2S0_SW_RST] = { AUDSS_SW_RST, BIT(0) },
> > + [AUDSS_I2S1_SW_RST] = { AUDSS_SW_RST, BIT(1) },
> > + [AUDSS_I2S2_SW_RST] = { AUDSS_SW_RST, BIT(2) },
> > + [AUDSS_I2S3_SW_RST] = { AUDSS_SW_RST, BIT(3) },
> > + [AUDSS_I2S4_SW_RST] = { AUDSS_SW_RST, BIT(4) },
> > + [AUDSS_I2S5_SW_RST] = { AUDSS_SW_RST, BIT(5) },
> > + [AUDSS_I2S6_SW_RST] = { AUDSS_SW_RST, BIT(6) },
> > + [AUDSS_I2S7_SW_RST] = { AUDSS_SW_RST, BIT(7) },
> > + [AUDSS_I2S8_SW_RST] = { AUDSS_SW_RST, BIT(8) },
> > + [AUDSS_I2S9_SW_RST] = { AUDSS_SW_RST, BIT(9) },
> > + [AUDSS_WDT_SW_RST] = { AUDSS_SW_RST, BIT(10) },
> > + [AUDSS_TIMER_SW_RST] = { AUDSS_SW_RST, BIT(11) },
> > + [AUDSS_MB0_SW_RST] = { AUDSS_SW_RST, BIT(12) },
> > + [AUDSS_MB1_SW_RST] = { AUDSS_SW_RST, BIT(13) },
> > + [AUDSS_HDA_SW_RST] = { AUDSS_SW_RST, BIT(14) },
> > + [AUDSS_DMAC_SW_RST] = { AUDSS_SW_RST, BIT(15) },
> > +};
> > +
> > +static struct sky1_audss_reset *to_sky1_audss_reset(struct
> > +reset_controller_dev *rcdev) {
> > + return container_of(rcdev, struct sky1_audss_reset, rcdev); }
> > +
> > +static int sky1_audss_reset_set(struct reset_controller_dev *rcdev,
> > + unsigned long id, bool assert) {
> > + struct sky1_audss_reset *priv = to_sky1_audss_reset(rcdev);
> > + const struct sky1_audss_reset_map *signal = &priv->map[id];
> > + unsigned int value = assert ? 0 : signal->mask;
> > +
> > + return regmap_update_bits(priv->regmap, signal->offset,
> > + signal->mask, value);
>
> Consider using regmap_assign_bits() instead.
OK
> > +}
> > +
> > +static int sky1_audss_reset_assert(struct reset_controller_dev *rcdev,
> > + unsigned long id) {
> > + int ret;
> > +
> > + ret = sky1_audss_reset_set(rcdev, id, true);
> > + if (ret)
> > + return ret;
> > +
> > + usleep_range(SKY1_RESET_SLEEP_MIN_US, SKY1_RESET_SLEEP_MAX_US);
> > + return 0;
> > +}
> > +
> > +static int sky1_audss_reset_deassert(struct reset_controller_dev *rcdev,
> > + unsigned long id) {
> > + int ret;
> > +
> > + ret = sky1_audss_reset_set(rcdev, id, false);
> > + if (ret)
> > + return ret;
> > +
> > + usleep_range(SKY1_RESET_SLEEP_MIN_US, SKY1_RESET_SLEEP_MAX_US);
>
> This is the same in both assert and deassert. You could move it into the helper
> function.
Agreed. Will move the delay into sky1_audss_reset_set() and keep
assert/deassert as thin wrappers.
Thanks,
Joakim
^ permalink raw reply
* Re: [PATCH v3 0/8] Arm Live Firmware Activation (LFA) support
From: Andre Przywara @ 2026-07-20 12:08 UTC (permalink / raw)
To: Michal Suchánek
Cc: Mark Rutland, Lorenzo Pieralisi, Sudeep Holla, Conor Dooley,
vsethi, Salman Nabi, Rob Herring, linux-kernel, Varun Wadekar,
Trilok Soni, devicetree, Nirmoy Das, Krzysztof Kozlowski,
linux-arm-kernel
In-Reply-To: <alYjFwi0dnld-wP3@kunlun.suse.cz>
Hi Michal,
thanks for having a look and for testing!
On 7/14/26 13:52, Michal Suchánek wrote:
> On Mon, Jul 13, 2026 at 06:02:35PM +0200, Michal Suchánek wrote:
>> On Mon, Jul 06, 2026 at 03:44:40PM +0200, Andre Przywara wrote:
>>> Hi all,
>>>
>>> this is version 3 of the Live Firmware Activation kernel support. The
>>> device part of the code now relies on Aneesh's SMCCC bus patches[1],
>>> which solves some problems rather nicely. I also added the formerly
>>> missing sysfs ABI documentation. Based on v7.2-rc1, plus the first
>>> two patches from Aneesh's series. More detailed changelog below.
>>> ==============================
>>>
>>> This series implements the kernel side support of the Arm Live
>>> Firmware Activation (LFA) specification [2]. LFA enables the activation
>>> of updated firmware components without requiring a system reboot,
>>> reducing downtime and allowing quicker deployment of critical bug fixes
>>> in environments such as data centers and hyperscale systems.
>>> It requires explicit firmware support, both via an agent running in EL3
>>> (for instance in TF-A, already merged), but also in the firmware
>>> component to be activated. TF-RMM recently merged support for this.
>>>
>>> Unlike the usual firmware update process (which may use tools like
>>> fwupd), LFA focuses solely on the activation of an already updated
>>> firmware component, called "pending activation" in LFA lingo. This works
>>> by signalling the LFA agent (part of the EL3 runtime firmware) via an
>>> SMC call, which then does the heavy lifting of the live update, in
>>> cooperation with the to-be-updated firmware component.
>>>
>>> Key features of the driver:
>>> * Detects LFA support in system firmware (EL3).
>>> * Lists all firmware components that support live activation, identified
>>> by their GUID.
>>> * Exposes component attributes (e.g., activation capability, and
>>> activation pending) via sysfs under /sys/firmware/lfa/<GUID>/.
>>> * Provides interfaces to:
>>> - Trigger activation of an updated firmware component.
>>> - Cancel an ongoing activation if required.
>>> A more detailed list of features can be found in patch 2/8.
>>> Based on v7.2-rc1.
>>>
>>> This work is conceptually similar to Intel’s Platform Firmware Runtime
>>> Update and telemetry (PFRUT) [3] and TDX module updates [4], but
>>> targets Arm platforms. The driver has been used to successfully activate
>>> a Realm Management Monitor (RMM) firmware image in a controlled test
>>> environment. RMM is analogous to Intel’s TDX module.
>>>
>>> There is effort on similar work from the OCP [5]. Future work may
>>> include integration with utilities like fwupd to automatically select
>>> the appropriate driver, based on platform architecture, for Live/Runtime
>>> firmware updates.
>>>
>>> Please have a look, test and comment!
>>
>> Hello,
>>
>> booting a kernel with v2 of this patchset applied the module does not
>> get autoloaded. Loading it manually I get
>>
>> [ 1972.957282] [ T5195] Arm LFA: Live Firmware Activation: detected v1.0
>> [ 1972.958620] [ T5195] Arm LFA: registered LFA ACPI notification
>>
>> Is this expected?
>>
>> I would expect the driver to load automatically.
>>
>> I do not see anything in the v3 changelog obviously addressing
>> autoloading but changing to using a bus might affect that.
>>
>> I will try to update to v3 later.
>
> Hello,
>
> updating to v3 of the patchset resolves the problem.
Yes, that was indeed a change that came for free with changing the
probing method to be now SMCCC bus based. As Krzysztof rightfully
mentioned before, the driver was always probing, then bailing out if the
service was not available, which is not the way it should work under the
driver model. As a side effect, there wasn't really any discovery or
auto-loading mechanism. With the new SMCCC bus this should now all be
solved.
Thanks for testing!
Cheers,
Andre
> The driver is now autoloaded.
>
> Thanks
>
> Michal
^ permalink raw reply
* Re: [PATCH v3] arm64: ptrace: Keep 'orig_x0' in-sync with x0 on syscall entry
From: Jinjie Ruan @ 2026-07-20 12:02 UTC (permalink / raw)
To: Will Deacon, linux-arm-kernel
Cc: linux-kernel, Kees Cook, Mark Rutland, Yiqi Sun
In-Reply-To: <20260717182758.17111-1-will@kernel.org>
On 7/18/2026 2:27 AM, Will Deacon wrote:
> Commit e057b9477232 ("arm64: syscall: Ensure saved x0 is kept in-sync
> with tracer updates") attempted to resolve a long-standing issue with
> syscall entry tracing, where a tracer is able to manipulate the first
> syscall argument without being subjected to seccomp or audit checking.
>
> Unfortunately, that fix was incomplete [1], as it failed to update
> 'orig_x0' between a tracer updating x0 during a seccomp ptrace exit
> (SECCOMP_RET_TRACE) and the seccomp filter being re-evaluated.
>
> Rather than add hooks to the core seccomp code, instead move the
> synchronisation code into the ptrace GPR and syscall setting code so
> that 'orig_x0' is kept up to date with x0 whenever we're stopped on the
> syscall entry path.
>
> Cc: Kees Cook <kees@kernel.org>
> Cc: Jinjie Ruan <ruanjinjie@huawei.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Link: https://sashiko.dev/#/patchset/20260716120640.6590-1-will@kernel.org [1]
> Reported-by: Yiqi Sun <sunyiqixm@gmail.com>
> Link: https://lore.kernel.org/all/20260529065444.1336608-1-sunyiqixm@gmail.com/
> Fixes: e057b9477232 ("arm64: syscall: Ensure saved x0 is kept in-sync with tracer updates")
> Fixes: a5cd110cb836 ("arm64/ptrace: run seccomp after ptrace")
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
> arch/arm64/kernel/ptrace.c | 50 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
>
> v2: https://lore.kernel.org/r/20260716120640.6590-1-will@kernel.org
>
> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> index 4d08598e2891..2b716fa11c02 100644
> --- a/arch/arm64/kernel/ptrace.c
> +++ b/arch/arm64/kernel/ptrace.c
> @@ -560,6 +560,42 @@ static int gpr_get(struct task_struct *target,
> return membuf_write(&to, uregs, sizeof(*uregs));
> }
>
> +static void update_syscall_orig_x0_after_ptrace(struct task_struct *target)
> +{
> + struct pt_regs *regs = task_pt_regs(target);
> + struct kernel_siginfo *info = target->last_siginfo;
> +
> + /* We should only be called when target is in a ptrace stop */
> + if (WARN_ON_ONCE(!info))
> + return;
> +
> + /*
> + * Skip the update for NO_SYSCALL (set either by the user or the
> + * tracer), as regs[0] holds the return value (see the comment in
> + * el0_svc_common()) and can be unwound using syscall_rollback().
> + */
> + if (regs->syscallno == NO_SYSCALL)
> + return;
> +
> + /*
> + * For compat tasks, orig_r0 is provided directly through GPR index
> + * 17.
> + */
> + if (is_compat_thread(task_thread_info(target)))
> + return;
> +
> + /*
> + * Don't update orig_x0 for a syscall-exit-stop, as x0 now contains the
> + * return value of the system call.
> + */
> + if ((info->si_code & ~0x80) == SIGTRAP &&
> + target->ptrace_message == PTRACE_EVENTMSG_SYSCALL_EXIT) {
> + return;
> + }
> +
> + regs->orig_x0 = regs->regs[0];
> +}
> +
> static int gpr_set(struct task_struct *target, const struct user_regset *regset,
> unsigned int pos, unsigned int count,
> const void *kbuf, const void __user *ubuf)
> @@ -575,6 +611,14 @@ static int gpr_set(struct task_struct *target, const struct user_regset *regset,
> return -EINVAL;
>
> task_pt_regs(target)->user_regs = newregs;
> +
> + /*
> + * Keep orig_x0 authoritative so that seccomp (via
> + * syscall_get_arguments()), audit and the restart path all see the same
> + * first argument the syscall is dispatched with, even if it has been
> + * updated by a tracer.
> + */
> + update_syscall_orig_x0_after_ptrace(target);
Tested-by: Jinjie Ruan <ruanjinjie@huawei.com>
> return 0;
> }
>
> @@ -753,6 +797,12 @@ static int system_call_set(struct task_struct *target,
> return ret;
>
> task_pt_regs(target)->syscallno = syscallno;
> +
> + /*
> + * Re-sync orig_x0 in case the syscall number has been changed
> + * from NO_SYSCALL.
> + */
> + update_syscall_orig_x0_after_ptrace(target);
> return ret;
> }
>
^ permalink raw reply
* Re: [PATCH RFC v3 3/6] mm: rename get_user_page_vma_remote() to get_user_page_lookup_vma()
From: Usama Arif @ 2026-07-20 12:00 UTC (permalink / raw)
To: Rik van Riel
Cc: Usama Arif, linux-kernel, Andrew Morton, kernel-team,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
linux-mm, Catalin Marinas, Will Deacon, Masami Hiramatsu,
Oleg Nesterov, Peter Zijlstra, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Harry Yoo,
Jann Horn, Lance Yang, linux-arm-kernel, linux-trace-kernel
In-Reply-To: <20260717170036.743149-4-riel@surriel.com>
On Fri, 17 Jul 2026 13:00:33 -0400 Rik van Riel <riel@surriel.com> wrote:
> get_user_page_vma_remote() faults in the page at @addr in a remote mm and
> also looks up the VMA that covers it, handing both back to the caller.
>
> This cleans up the name space for adding a get_user_page_vma() variant
nit: s/name space/namespace/
> where the caller already has the vma.
>
> Assisted-by: Claude:claude-opus-4.8
> Signed-off-by: Rik van Riel <riel@surriel.com>
> ---
> arch/arm64/kernel/mte.c | 2 +-
> arch/x86/kernel/uprobes.c | 2 +-
> include/linux/mm.h | 2 +-
> mm/memory.c | 4 ++--
> mm/rmap.c | 2 +-
> 5 files changed, 6 insertions(+), 6 deletions(-)
>
I think good to add no functional change intended in the patch.
Acked-by: Usama Arif <usama.arif@linux.dev>
> diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
> index 1a9aad6ef22a..7a6ecc3d9294 100644
> --- a/arch/arm64/kernel/mte.c
> +++ b/arch/arm64/kernel/mte.c
> @@ -459,7 +459,7 @@ static int __access_remote_tags(struct mm_struct *mm, unsigned long addr,
> struct vm_area_struct *vma;
> unsigned long tags, offset;
> void *maddr;
> - struct page *page = get_user_page_vma_remote(mm, addr,
> + struct page *page = get_user_page_lookup_vma(mm, addr,
> gup_flags, &vma);
> struct folio *folio;
>
> diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
> index 3af979fb41d3..329efac0cfb3 100644
> --- a/arch/x86/kernel/uprobes.c
> +++ b/arch/x86/kernel/uprobes.c
> @@ -1036,7 +1036,7 @@ static int copy_from_vaddr(struct mm_struct *mm, unsigned long vaddr, void *dst,
> struct vm_area_struct *vma;
> struct page *page;
>
> - page = get_user_page_vma_remote(mm, vaddr, gup_flags, &vma);
> + page = get_user_page_lookup_vma(mm, vaddr, gup_flags, &vma);
> if (IS_ERR(page))
> return PTR_ERR(page);
> uprobe_copy_from_page(page, vaddr, dst, len);
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 485df9c2dbdd..24ead14b4790 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -3238,7 +3238,7 @@ long pin_user_pages_remote(struct mm_struct *mm,
> /*
> * Retrieves a single page alongside its VMA. Does not support FOLL_NOWAIT.
> */
> -static inline struct page *get_user_page_vma_remote(struct mm_struct *mm,
> +static inline struct page *get_user_page_lookup_vma(struct mm_struct *mm,
> unsigned long addr,
> int gup_flags,
> struct vm_area_struct **vmap)
> diff --git a/mm/memory.c b/mm/memory.c
> index ff338c2abe92..3b86eeaf084f 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -7039,7 +7039,7 @@ static int __access_remote_vm(struct mm_struct *mm, unsigned long addr,
> void *maddr;
> struct folio *folio;
> struct vm_area_struct *vma = NULL;
> - struct page *page = get_user_page_vma_remote(mm, addr,
> + struct page *page = get_user_page_lookup_vma(mm, addr,
> gup_flags, &vma);
>
> if (IS_ERR(page)) {
> @@ -7167,7 +7167,7 @@ static int __copy_remote_vm_str(struct mm_struct *mm, unsigned long addr,
> struct page *page;
> struct vm_area_struct *vma = NULL;
>
> - page = get_user_page_vma_remote(mm, addr, gup_flags, &vma);
> + page = get_user_page_lookup_vma(mm, addr, gup_flags, &vma);
> if (IS_ERR(page)) {
> /*
> * Treat as a total failure for now until we decide how
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 1c77d5dc06e9..b36f2e219b8f 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -2838,7 +2838,7 @@ struct page *make_device_exclusive(struct mm_struct *mm, unsigned long addr,
> * (non-device-exclusive) PTE and issue a MMU_NOTIFY_EXCLUSIVE.
> */
> retry:
> - page = get_user_page_vma_remote(mm, addr,
> + page = get_user_page_lookup_vma(mm, addr,
> FOLL_GET | FOLL_WRITE | FOLL_SPLIT_PMD,
> &vma);
> if (IS_ERR(page))
> --
> 2.53.0-Meta
>
>
^ permalink raw reply
* [PATCH v2] media: mediatek: jpeg: retry HW selection after successful wait
From: Pengpeng Hou @ 2026-07-20 11:53 UTC (permalink / raw)
To: Bin Liu, Mauro Carvalho Chehab
Cc: Nicolas Dufresne, Matthias Brugger, AngeloGioacchino Del Regno,
linux-media, linux-kernel, linux-arm-kernel, linux-mediatek,
Pengpeng Hou
wait_event_interruptible_timeout() returns a positive value when its
condition becomes true before timeout. mtk_jpegdec_worker() treats every
nonzero result as failure, so a normal decoder wakeup can finish the
mem2mem job as though no hardware became available.
Handle an interrupted wait and exhausted timeout retries separately, and
retry hardware selection after a successful wakeup. The encoder uses
wait_event_interruptible(), whose successful return is zero, so this change
does not alter its separate no-timeout waiting policy.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
Changes since v1: https://lore.kernel.org/all/20260625003142.99598-1-pengpeng@iscas.ac.cn/
- split interrupted waits, timeout exhaustion and successful wakeups
- use distinct diagnostics and explain why the encoder path is outside this
fix
- rebase onto v7.2-rc4
drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index d147ec483081..9634c95aaada 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1697,9 +1697,15 @@ static void mtk_jpegdec_worker(struct work_struct *work)
ret = wait_event_interruptible_timeout(jpeg->hw_wq,
atomic_read(&jpeg->hw_rdy) > 0,
MTK_JPEG_HW_TIMEOUT_MSEC);
- if (ret != 0 || (i++ > MTK_JPEG_MAX_RETRY_TIME)) {
- dev_err(jpeg->dev, "%s : %d, all HW are busy\n",
- __func__, __LINE__);
+ if (ret < 0) {
+ dev_err(jpeg->dev, "decoder HW wait interrupted: %d\n",
+ ret);
+ v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
+ return;
+ }
+
+ if (!ret && i++ > MTK_JPEG_MAX_RETRY_TIME) {
+ dev_err(jpeg->dev, "all decoder HW are busy\n");
v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
return;
}
^ permalink raw reply related
* Re: [PATCH v3 0/2] PHY: Add support for MT8196 DSI PHY
From: Vinod Koul @ 2026-07-20 11:43 UTC (permalink / raw)
To: chunfeng.yun, AngeloGioacchino Del Regno
Cc: neil.armstrong, robh, krzk+dt, conor+dt, chunkuang.hu, p.zabel,
matthias.bgg, justin.yeh, linux-arm-kernel, linux-mediatek,
linux-phy, devicetree, linux-kernel, dri-devel, kernel
In-Reply-To: <20260713103805.23030-1-angelogioacchino.delregno@collabora.com>
On Mon, 13 Jul 2026 12:38:03 +0200, AngeloGioacchino Del Regno wrote:
> Changes in v3:
> - Actually sent the correct patch series (sorry, I had messed up v2)
> - Added definitions for minimum and maximum PLL rates
>
> Changes in v2:
> - Added a few comments and fix scheduling while atomic issue in clk
> enable ops by waiting with udelay() instead
> - Removed one unnecessary delay after clk/pwr isolation disablement
>
> [...]
Applied, thanks!
[1/2] dt-bindings: phy: mediatek,dsi-phy: Add support for MT8196
commit: 215cd5def8eca1c2aa7ca043483d96155a1c3ed6
[2/2] phy: mediatek: Add support for MT8196 MIPI DSI PHY
commit: 2ec9c210c1f931389709aee403d28e4f32676385
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH 3/3] usb: typec: Use %pe to print error pointers
From: Badhri Jagan Sridharan @ 2026-07-20 11:38 UTC (permalink / raw)
To: Subasri S
Cc: Peter Chen, Greg Kroah-Hartman, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Duncan Sands,
Chas Williams, Minas Harutyunyan, Hans de Goede, Heikki Krogerus,
linux-usb, imx, linux-arm-kernel, linux-kernel, linux-atm-general,
netdev
In-Reply-To: <20260719-usb-ptr_err_patchset-v1-3-85f7f2e4fefb@gmail.com>
On Sun, Jul 19, 2026 at 5:56 AM Subasri S <subasris1210@gmail.com> wrote:
>
> Use the %pe format specifier instead of %ld with PTR_ERR() for printing
> error pointers in various typec drivers. This prints symbolic
> error names (e.g.-ENOMEM) instead of errno numbers (e.g. -12),
> making error logs more readable.
>
> This patch fixes coccinelle reported warnings:
> ./typec/tcpm/tcpm.c:4799:60-67: WARNING: Consider using %pe to print PTR_ERR()
> ./typec/mux/pi3usb30532.c:143:3-10: WARNING: Consider using %pe to print PTR_ERR()
> ./typec/mux/pi3usb30532.c:155:3-10: WARNING: Consider using %pe to print PTR_ERR()
> ./typec/wusb3801.c:281:5-12: WARNING: Consider using %pe to print PTR_ERR()
>
> Compile tested only.
>
> Signed-off-by: Subasri S <subasris1210@gmail.com>
Reviewed-by: Badhri Jagan Sridharan <badhri@google.com>
> ---
> drivers/usb/typec/mux/pi3usb30532.c | 8 ++++----
> drivers/usb/typec/tcpm/tcpm.c | 2 +-
> drivers/usb/typec/wusb3801.c | 4 ++--
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/usb/typec/mux/pi3usb30532.c b/drivers/usb/typec/mux/pi3usb30532.c
> index 985683fe49e9..a2357a28ecf4 100644
> --- a/drivers/usb/typec/mux/pi3usb30532.c
> +++ b/drivers/usb/typec/mux/pi3usb30532.c
> @@ -139,8 +139,8 @@ static int pi3usb30532_probe(struct i2c_client *client)
>
> pi->sw = typec_switch_register(dev, &sw_desc);
> if (IS_ERR(pi->sw)) {
> - dev_err(dev, "Error registering typec switch: %ld\n",
> - PTR_ERR(pi->sw));
> + dev_err(dev, "Error registering typec switch: %pe\n",
> + pi->sw);
> return PTR_ERR(pi->sw);
> }
>
> @@ -151,8 +151,8 @@ static int pi3usb30532_probe(struct i2c_client *client)
> pi->mux = typec_mux_register(dev, &mux_desc);
> if (IS_ERR(pi->mux)) {
> typec_switch_unregister(pi->sw);
> - dev_err(dev, "Error registering typec mux: %ld\n",
> - PTR_ERR(pi->mux));
> + dev_err(dev, "Error registering typec mux: %pe\n",
> + pi->mux);
> return PTR_ERR(pi->mux);
> }
>
> diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
> index 89eec20a2064..ad10470ea73b 100644
> --- a/drivers/usb/typec/tcpm/tcpm.c
> +++ b/drivers/usb/typec/tcpm/tcpm.c
> @@ -4796,7 +4796,7 @@ static void tcpm_typec_connect(struct tcpm_port *port)
> port->partner_desc.accessory = TYPEC_ACCESSORY_NONE;
> partner = typec_register_partner(port->typec_port, &port->partner_desc);
> if (IS_ERR(partner)) {
> - dev_err(port->dev, "Failed to register partner (%ld)\n", PTR_ERR(partner));
> + dev_err(port->dev, "Failed to register partner (%pe)\n", partner);
> return;
> }
>
> diff --git a/drivers/usb/typec/wusb3801.c b/drivers/usb/typec/wusb3801.c
> index 6062875fb04a..86d13ab41670 100644
> --- a/drivers/usb/typec/wusb3801.c
> +++ b/drivers/usb/typec/wusb3801.c
> @@ -277,8 +277,8 @@ static void wusb3801_hw_update(struct wusb3801 *wusb3801)
> if (partner_type != WUSB3801_STAT_PARTNER_STANDBY) {
> wusb3801->partner = typec_register_partner(port, &desc);
> if (IS_ERR(wusb3801->partner))
> - dev_err(dev, "Failed to register partner: %ld\n",
> - PTR_ERR(wusb3801->partner));
> + dev_err(dev, "Failed to register partner: %pe\n",
> + wusb3801->partner);
> }
>
> data_role = pwr_role == TYPEC_SOURCE ? TYPEC_HOST : TYPEC_DEVICE;
>
> --
> 2.43.0
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox