* [PATCH 1/3] KVM: arm64: nv: Print nested mmu info in kvm_ptdump_guest_show()
From: Wei-Lin Chang @ 2026-06-23 14:24 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Itaru Kitayama, Wei-Lin Chang
In-Reply-To: <20260623142443.648972-1-weilin.chang@arm.com>
To prepare for creating per nested mmu ptdump file, extend
kvm_ptdump_guest_show() so that it differentiates canonical and nested
mmus. If the mmu is nested and valid, print VTCR, VTTBR, s2 enabled
information in addition to the ptdump.
Also switch to a lock guard for mmu_lock.
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
arch/arm64/kvm/ptdump.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/ptdump.c b/arch/arm64/kvm/ptdump.c
index c9140e22abcf..2a6afe67646a 100644
--- a/arch/arm64/kvm/ptdump.c
+++ b/arch/arm64/kvm/ptdump.c
@@ -155,9 +155,16 @@ 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);
+ if (kvm_is_nested_s2_mmu(kvm, mmu)) {
+ if (!kvm_s2_mmu_valid(mmu)) {
+ seq_puts(m, "invalid nested mmu\n");
+ return 0;
+ }
+ seq_printf(m, "0x%016llx 0x%016llx %d\n", mmu->tlb_vttbr,
+ mmu->tlb_vtcr, mmu->nested_stage2_enabled ? 1 : 0);
+ }
ret = kvm_pgtable_walk(mmu->pgt, 0, BIT(mmu->pgt->ia_bits), &walker);
- write_unlock(&kvm->mmu_lock);
return ret;
}
--
2.43.0
^ permalink raw reply related
* [PATCH 0/3] KVM: arm64: nv: Shadow ptdump fixes
From: Wei-Lin Chang @ 2026-06-23 14:24 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Marc Zyngier, Oliver Upton, Joey Gouly, Steffen Eiden,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
Itaru Kitayama, Wei-Lin Chang
Hi,
This series fixes two bugs regarding the shadow ptdump debugfs files.
It is based on kvmarm/fixes + [1] ("KVM: arm64: Reassign nested_mmus
array behind mmu_lock").
The first is a UAF. A nested mmu can still be accessed when the debugfs
file is being closed, after the nested mmus are freed. I can observe
this by turning on CONFIG_KASAN and closing the file after the VM is
destroyed. To fix this, mmu access is avoided in the .release()
callback.
The second is sleeping in atomic context, found by Itaru [2] (thanks).
Originally the code creates a debugfs file whenever a context gets bound
to an s2 mmu instance, and deletes it when it gets unbound. Problem is
the bind/unbind is done with the mmu_lock held, and debugfs file
creation and deletion can sleep. This is observable by using
CONFIG_DEBUG_ATOMIC_SLEEP. The new approach is just have one debugfs
file for each s2 mmu instance, and show their state + information when
requested, which can be invalid, or VTCR + VTTBR + whether s2 enabled +
ptdump.
The fixes are tested with CONFIG_PROVE_LOCKING,
CONFIG_DEBUG_ATOMIC_SLEEP, and CONFIG_KASAN.
Thanks!
Wei-Lin Chang
[1]: https://lore.kernel.org/kvmarm/aiKIVVeIr1aAB1yp@v4bel/
[2]: https://lore.kernel.org/kvmarm/aiuF0KSvvv-ZozI1@sm-arm-grace07/
Wei-Lin Chang (3):
KVM: arm64: nv: Print nested mmu info in kvm_ptdump_guest_show()
KVM: arm64: ptdump: Store both mmu and kvm pointers in
kvm_ptdump_guest_state
KVM: arm64: nv: Move to per nested mmu ptdump files
arch/arm64/kvm/nested.c | 16 +++++++++++-----
arch/arm64/kvm/ptdump.c | 29 +++++++++++++++++++----------
2 files changed, 30 insertions(+), 15 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH V2 3/8] Bluetooth: btnxpuart: Add M.2 Bluetooth device support using pwrseq
From: Frank Li @ 2026-06-23 14:24 UTC (permalink / raw)
To: Sherry Sun (OSS)
Cc: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
amitkumar.karwar, neeraj.sanjaykale, marcel, luiz.dentz,
hongxing.zhu, l.stach, lpieralisi, kwilczynski, mani, bhelgaas,
brgl, imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
linux-bluetooth, linux-pm, sherry.sun
In-Reply-To: <20260623030736.1421537-4-sherry.sun@oss.nxp.com>
On Tue, Jun 23, 2026 at 11:07:30AM +0800, Sherry Sun (OSS) wrote:
> From: Sherry Sun <sherry.sun@nxp.com>
>
> Power supply to the M.2 Bluetooth device attached to the host using M.2
> connector is controlled using the 'uart' pwrseq device. So add support for
> getting the pwrseq device if the OF graph link is present. Once obtained,
> pwrseq_power_on() is called to power up the M.2 Bluetooth card. The power
> sequencer descriptor is obtained via devm_pwrseq_get(), so the power-off
> and cleanup are handled automatically when the device is unbound.
>
> Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/bluetooth/btnxpuart.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/bluetooth/btnxpuart.c b/drivers/bluetooth/btnxpuart.c
> index e7036a48ce48..438ccaa2b56d 100644
> --- a/drivers/bluetooth/btnxpuart.c
> +++ b/drivers/bluetooth/btnxpuart.c
> @@ -9,6 +9,8 @@
>
> #include <linux/serdev.h>
> #include <linux/of.h>
> +#include <linux/of_graph.h>
> +#include <linux/pwrseq/consumer.h>
> #include <linux/skbuff.h>
> #include <linux/unaligned.h>
> #include <linux/firmware.h>
> @@ -1866,6 +1868,18 @@ static int nxp_serdev_probe(struct serdev_device *serdev)
> return err;
> }
>
> + if (of_graph_is_present(dev_of_node(&serdev->ctrl->dev))) {
> + struct pwrseq_desc *pwrseq;
> +
> + pwrseq = devm_pwrseq_get(&serdev->ctrl->dev, "uart");
> + if (IS_ERR(pwrseq))
> + return PTR_ERR(pwrseq);
> +
> + err = pwrseq_power_on(pwrseq);
> + if (err)
> + return err;
> + }
> +
> /* Initialize and register HCI device */
> hdev = hci_alloc_dev();
> if (!hdev) {
> --
> 2.50.1
>
>
^ permalink raw reply
* Re: [PATCH] pmdomain: bcm: bcm2835: handle genpd provider registration errors
From: Stefan Wahren @ 2026-06-23 14:12 UTC (permalink / raw)
To: Pengpeng Hou, Ulf Hansson, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Maíra Canal, Stanimir Varbanov, Eric Anholt, Rob Herring
Cc: linux-pm, linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260623135937.60740-1-pengpeng@iscas.ac.cn>
Am 23.06.26 um 15:59 schrieb Pengpeng Hou:
> bcm2835_power_probe() initializes all power domains and then registers
> the onecell genpd provider, but ignores of_genpd_add_provider_onecell()
> failures. Probe can therefore return success even though no provider was
> published.
>
> Check the provider registration return value and jump to the existing
> cleanup path on failure.
>
> Fixes: 670c672608a1 ("soc: bcm: bcm2835-pm: Add support for power domains under a new binding.")
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Stefan Wahren <wahrenst@gmx.net>
^ permalink raw reply
* Re: [PATCH v4 5/5] clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO
From: Daniele Briguglio @ 2026-06-23 14:09 UTC (permalink / raw)
To: Diederik de Haas, Heiko Stuebner, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Nicolas Frattaroli, linux-clk, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, Ricardo Pardini
In-Reply-To: <DJGH34DVKL0W.3T6UB4G4WYYUJ@cknow-tech.com>
Hi Diederik,
> My suspicion that more RK3588 based boards would be broken is because NONE use
> I2S0_8CH_MCLKOUT_TO_IO; they all use I2S0_8CH_MCLKOUT.
These bits reset to open (SYS_GRF_SOC_CON6 = 0x4600, i2sN_mclk_ioe_ clear,
1'b0 = "Output enable"), so a board doesn't need to reference the gate to
get MCLK. They're RW, so firmware can go either way, but your 0x600 has
them clear, which is why audio works today.
The series made the gate a managed clock, so with no consumer
clk_disable_unused disables it at boot. CLK_IGNORE_UNUSED leaves an
already-open gate alone, so nothing changes for those boards. Only the ones
that come up disabled, like the YY3588 and Ricardo's R58X-Pro, need _TO_IO
for the kernel to turn it back on.
> So IIUC that means I'd be testing both variants.
Right, that covers both: the mux path and the consumer path. Looking
forward to the results.
Best regards,
Daniele
^ permalink raw reply
* Re: [PATCH] mtd: nand: mtk-ecc: stop on ECC idle timeouts
From: Miquel Raynal @ 2026-06-23 14:08 UTC (permalink / raw)
To: Pengpeng Hou
Cc: Richard Weinberger, Vignesh Raghavendra, Matthias Brugger,
AngeloGioacchino Del Regno, Jorge Ramirez-Ortiz, Boris Brezillon,
linux-mtd, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260623135729.52304-1-pengpeng@iscas.ac.cn>
Hello,
> diff --git a/drivers/mtd/nand/ecc-mtk.c b/drivers/mtd/nand/ecc-mtk.c
> index c75bb8b80..96703f0a4 100644
> --- a/drivers/mtd/nand/ecc-mtk.c
> +++ b/drivers/mtd/nand/ecc-mtk.c
> @@ -123,8 +123,8 @@ static int mt7622_ecc_regs[] = {
> [ECC_DECIRQ_STA] = 0x144,
> };
>
> -static inline void mtk_ecc_wait_idle(struct mtk_ecc *ecc,
> - enum mtk_ecc_operation op)
> +static inline int mtk_ecc_wait_idle(struct mtk_ecc *ecc,
> + enum mtk_ecc_operation op)
Looks good, but could you follow up with a patch which removes the
inline keyword as well? It does not seem to serve any purpose there.
^ permalink raw reply
* [PATCH] pmdomain: bcm: bcm2835: handle genpd provider registration errors
From: Pengpeng Hou @ 2026-06-23 13:59 UTC (permalink / raw)
To: Ulf Hansson, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Stefan Wahren, Maíra Canal, Stanimir Varbanov, Eric Anholt,
Rob Herring
Cc: Pengpeng Hou, linux-pm, linux-rpi-kernel, linux-arm-kernel,
linux-kernel
bcm2835_power_probe() initializes all power domains and then registers
the onecell genpd provider, but ignores of_genpd_add_provider_onecell()
failures. Probe can therefore return success even though no provider was
published.
Check the provider registration return value and jump to the existing
cleanup path on failure.
Fixes: 670c672608a1 ("soc: bcm: bcm2835-pm: Add support for power domains under a new binding.")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/pmdomain/bcm/bcm2835-power.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/pmdomain/bcm/bcm2835-power.c b/drivers/pmdomain/bcm/bcm2835-power.c
index b76d74e38..68a0a7a8c 100644
--- a/drivers/pmdomain/bcm/bcm2835-power.c
+++ b/drivers/pmdomain/bcm/bcm2835-power.c
@@ -677,7 +677,12 @@ static int bcm2835_power_probe(struct platform_device *pdev)
if (ret)
goto fail;
- of_genpd_add_provider_onecell(dev->parent->of_node, &power->pd_xlate);
+ ret = of_genpd_add_provider_onecell(dev->parent->of_node,
+ &power->pd_xlate);
+ if (ret) {
+ dev_err_probe(dev, ret, "failed to add genpd provider\n");
+ goto fail;
+ }
dev_info(dev, "Broadcom BCM2835 power domains driver");
return 0;
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] dt-bindings: mediatek: cec: Correct the compatibles for mt7623-mt8167
From: Luca Leonardo Scorcia @ 2026-06-23 13:57 UTC (permalink / raw)
To: linux-mediatek
Cc: Luca Leonardo Scorcia, Chun-Kuang Hu, Philipp Zabel, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, CK Hu, Jitao shi,
dri-devel, devicetree, linux-kernel, linux-arm-kernel
The HDMI CEC driver for both mt7623 and mt8167 is actually the same as
mt8173-cec and the mt7623n.dtsi board include file already uses mt8173-cec
compatible as a fallback, but the documentation lists them as separate
entries. Correct the binding by adding the correct fallback.
This change fixes a dtbs_check error.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
.../bindings/display/mediatek/mediatek,cec.yaml | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
index 080cf321209e..4d741ba415e8 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml
@@ -15,10 +15,13 @@ description: |
properties:
compatible:
- enum:
- - mediatek,mt7623-cec
- - mediatek,mt8167-cec
- - mediatek,mt8173-cec
+ oneOf:
+ - const: mediatek,mt8173-cec
+ - items:
+ - enum:
+ - mediatek,mt7623-cec
+ - mediatek,mt8167-cec
+ - const: mediatek,mt8173-cec
reg:
maxItems: 1
--
2.43.0
^ permalink raw reply related
* [PATCH] mtd: nand: mtk-ecc: stop on ECC idle timeouts
From: Pengpeng Hou @ 2026-06-23 13:57 UTC (permalink / raw)
To: Miquel Raynal, Richard Weinberger, Vignesh Raghavendra,
Matthias Brugger, AngeloGioacchino Del Regno, Jorge Ramirez-Ortiz,
Boris Brezillon
Cc: Pengpeng Hou, linux-mtd, linux-kernel, linux-arm-kernel,
linux-mediatek
mtk_ecc_wait_idle() logs when the encoder or decoder does not become
idle, but returns void. Callers can therefore configure a non-idle ECC
engine or read parity bytes after an unconfirmed encoder idle state.
Return the idle poll result and propagate it from the enable and encode
paths that require the engine to be idle before continuing.
Fixes: 1d6b1e464950 ("mtd: mediatek: driver for MTK Smart Device")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/mtd/nand/ecc-mtk.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/mtd/nand/ecc-mtk.c b/drivers/mtd/nand/ecc-mtk.c
index c75bb8b80..96703f0a4 100644
--- a/drivers/mtd/nand/ecc-mtk.c
+++ b/drivers/mtd/nand/ecc-mtk.c
@@ -123,8 +123,8 @@ static int mt7622_ecc_regs[] = {
[ECC_DECIRQ_STA] = 0x144,
};
-static inline void mtk_ecc_wait_idle(struct mtk_ecc *ecc,
- enum mtk_ecc_operation op)
+static inline int mtk_ecc_wait_idle(struct mtk_ecc *ecc,
+ enum mtk_ecc_operation op)
{
struct device *dev = ecc->dev;
u32 val;
@@ -136,6 +136,8 @@ static inline void mtk_ecc_wait_idle(struct mtk_ecc *ecc,
if (ret)
dev_warn(dev, "%s NOT idle\n",
op == ECC_ENCODE ? "encoder" : "decoder");
+
+ return ret;
}
static irqreturn_t mtk_ecc_irq(int irq, void *id)
@@ -312,7 +314,11 @@ int mtk_ecc_enable(struct mtk_ecc *ecc, struct mtk_ecc_config *config)
return ret;
}
- mtk_ecc_wait_idle(ecc, op);
+ ret = mtk_ecc_wait_idle(ecc, op);
+ if (ret) {
+ mutex_unlock(&ecc->lock);
+ return ret;
+ }
ret = mtk_ecc_config(ecc, config);
if (ret) {
@@ -412,7 +418,9 @@ int mtk_ecc_encode(struct mtk_ecc *ecc, struct mtk_ecc_config *config,
if (ret)
goto timeout;
- mtk_ecc_wait_idle(ecc, ECC_ENCODE);
+ ret = mtk_ecc_wait_idle(ecc, ECC_ENCODE);
+ if (ret)
+ goto timeout;
/* Program ECC bytes to OOB: per sector oob = FDM + ECC + SPARE */
len = (config->strength * ecc->caps->parity_bits + 7) >> 3;
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] crypto: rockchip: fail ahash requests on HASH idle timeout
From: Pengpeng Hou @ 2026-06-23 13:55 UTC (permalink / raw)
To: Corentin Labbe, Herbert Xu, David S. Miller, Heiko Stuebner,
John Keeping
Cc: Pengpeng Hou, linux-crypto, linux-arm-kernel, linux-rockchip,
linux-kernel
rk_hash_run() waits for RK_CRYPTO_HASH_STS to become idle after the
final DMA transfer, but ignores the poll result. If the hash engine
never becomes idle, the driver still reads the digest registers and
finalizes the request with the previous success value.
Store the poll result and finalize the request with the timeout error
before reading the digest registers.
Fixes: 37bc22159c45 ("crypto: rockchip - use read_poll_timeout")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/crypto/rockchip/rk3288_crypto_ahash.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/rockchip/rk3288_crypto_ahash.c b/drivers/crypto/rockchip/rk3288_crypto_ahash.c
index b9f5a8b42..d3482619a 100644
--- a/drivers/crypto/rockchip/rk3288_crypto_ahash.c
+++ b/drivers/crypto/rockchip/rk3288_crypto_ahash.c
@@ -324,7 +324,12 @@ static int rk_hash_run(struct crypto_engine *engine, void *breq)
* efficiency, and make it response quickly when dma
* complete.
*/
- readl_poll_timeout(rkc->reg + RK_CRYPTO_HASH_STS, v, v == 0, 10, 1000);
+ err = readl_poll_timeout(rkc->reg + RK_CRYPTO_HASH_STS, v,
+ v == 0, 10, 1000);
+ if (err) {
+ dev_err(rkc->dev, "HASH idle timeout\n");
+ goto theend;
+ }
for (i = 0; i < crypto_ahash_digestsize(tfm) / 4; i++) {
v = readl(rkc->reg + RK_CRYPTO_HASH_DOUT_0 + i * 4);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] phy: samsung: usbdrd: propagate GS101 PIPE3 lock failures
From: Pengpeng Hou @ 2026-06-23 13:53 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Krzysztof Kozlowski, Alim Akhtar,
Pritam Manohar Sutar, Sam Protsenko, Johan Hovold,
André Draszik, Peter Griffin
Cc: Pengpeng Hou, linux-phy, linux-arm-kernel, linux-samsung-soc,
linux-kernel
The GS101 PIPE3 initialization checks the PMA PLL lock and then checks
the CDR lock. The PLL helper returns an error, but the GS101 PIPE3 init
path dropped that result. The CDR helper only logged a timeout. PHY
initialization could therefore still return success after either the PLL
or the selected receive lane had not locked.
Make the in-file SoC-specific phy_init hook return an int so helpers
with real failure results can propagate them through the existing PHY
init paths. Keep the register-only helpers returning success and use the
new return path to report the GS101 CDR wait failure. Other SoC helper
paths keep their previous success behavior.
Fixes: 32267c29bc7d ("phy: exynos5-usbdrd: support Exynos USBDRD 3.1 combo phy (HS & SS)")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/phy/samsung/phy-exynos5-usbdrd.c | 78 ++++++++++++++++-------
1 file changed, 55 insertions(+), 23 deletions(-)
diff --git a/drivers/phy/samsung/phy-exynos5-usbdrd.c b/drivers/phy/samsung/phy-exynos5-usbdrd.c
index 8711a3b62..5a8e0ce77 100644
--- a/drivers/phy/samsung/phy-exynos5-usbdrd.c
+++ b/drivers/phy/samsung/phy-exynos5-usbdrd.c
@@ -471,7 +471,7 @@ struct exynos5_usbdrd_phy;
struct exynos5_usbdrd_phy_config {
u32 id;
void (*phy_isol)(struct phy_usb_instance *inst, bool isolate);
- void (*phy_init)(struct exynos5_usbdrd_phy *phy_drd);
+ int (*phy_init)(struct exynos5_usbdrd_phy *phy_drd);
unsigned int (*set_refclk)(struct phy_usb_instance *inst);
};
@@ -708,7 +708,7 @@ exynos5_usbdrd_apply_phy_tunes(struct exynos5_usbdrd_phy *phy_drd,
}
}
-static void exynos5_usbdrd_pipe3_init(struct exynos5_usbdrd_phy *phy_drd)
+static int exynos5_usbdrd_pipe3_init(struct exynos5_usbdrd_phy *phy_drd)
{
u32 reg;
@@ -721,6 +721,8 @@ static void exynos5_usbdrd_pipe3_init(struct exynos5_usbdrd_phy *phy_drd)
reg = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYTEST);
reg &= ~PHYTEST_POWERDOWN_SSP;
writel(reg, phy_drd->reg_phy + EXYNOS5_DRD_PHYTEST);
+
+ return 0;
}
static void
@@ -831,7 +833,7 @@ exynos5_usbdrd_usbdp_g2_v4_pma_check_pll_lock(struct exynos5_usbdrd_phy *phy_drd
return err;
}
-static void
+static int
exynos5_usbdrd_usbdp_g2_v4_pma_check_cdr_lock(struct exynos5_usbdrd_phy *phy_drd)
{
static const unsigned int timeout_us = 40000;
@@ -857,9 +859,11 @@ exynos5_usbdrd_usbdp_g2_v4_pma_check_cdr_lock(struct exynos5_usbdrd_phy *phy_drd
((phy_drd->orientation == TYPEC_ORIENTATION_NORMAL)
? 0
: 2), reg);
+
+ return err;
}
-static void exynos5_usbdrd_utmi_init(struct exynos5_usbdrd_phy *phy_drd)
+static int exynos5_usbdrd_utmi_init(struct exynos5_usbdrd_phy *phy_drd)
{
u32 reg;
@@ -881,6 +885,8 @@ static void exynos5_usbdrd_utmi_init(struct exynos5_usbdrd_phy *phy_drd)
reg = readl(phy_drd->reg_phy + EXYNOS5_DRD_PHYTEST);
reg &= ~PHYTEST_POWERDOWN_HSP;
writel(reg, phy_drd->reg_phy + EXYNOS5_DRD_PHYTEST);
+
+ return 0;
}
static int exynos5_usbdrd_phy_init(struct phy *phy)
@@ -917,7 +923,9 @@ static int exynos5_usbdrd_phy_init(struct phy *phy)
writel(reg, phy_drd->reg_phy + EXYNOS5_DRD_PHYUTMICLKSEL);
/* UTMI or PIPE3 specific init */
- inst->phy_cfg->phy_init(phy_drd);
+ ret = inst->phy_cfg->phy_init(phy_drd);
+ if (ret)
+ goto disable_clks;
/* reference clock settings */
reg = inst->phy_cfg->set_refclk(inst);
@@ -940,9 +948,10 @@ static int exynos5_usbdrd_phy_init(struct phy *phy)
reg &= ~PHYCLKRST_PORTRESET;
writel(reg, phy_drd->reg_phy + EXYNOS5_DRD_PHYCLKRST);
+disable_clks:
clk_bulk_disable_unprepare(phy_drd->drv_data->n_clks, phy_drd->clks);
- return 0;
+ return ret;
}
static int exynos5_usbdrd_phy_exit(struct phy *phy)
@@ -1203,7 +1212,7 @@ static void exynos7870_usbdrd_phy_isol(struct phy_usb_instance *inst,
EXYNOS7870_USB2PHY_ENABLE, val);
}
-static void exynos7870_usbdrd_utmi_init(struct exynos5_usbdrd_phy *phy_drd)
+static int exynos7870_usbdrd_utmi_init(struct exynos5_usbdrd_phy *phy_drd)
{
u32 reg;
@@ -1291,6 +1300,8 @@ static void exynos7870_usbdrd_utmi_init(struct exynos5_usbdrd_phy *phy_drd)
if (phy_drd->drv_data->phy_tunes)
exynos5_usbdrd_apply_phy_tunes(phy_drd,
PTS_UTMI_POSTINIT);
+
+ return 0;
}
static int exynos7870_usbdrd_phy_init(struct phy *phy)
@@ -1304,11 +1315,11 @@ static int exynos7870_usbdrd_phy_init(struct phy *phy)
return ret;
/* UTMI or PIPE3 specific init */
- inst->phy_cfg->phy_init(phy_drd);
+ ret = inst->phy_cfg->phy_init(phy_drd);
clk_bulk_disable_unprepare(phy_drd->drv_data->n_clks, phy_drd->clks);
- return 0;
+ return ret;
}
static int exynos7870_usbdrd_phy_exit(struct phy *phy)
@@ -1355,10 +1366,12 @@ static const struct phy_ops exynos7870_usbdrd_phy_ops = {
.owner = THIS_MODULE,
};
-static void exynos2200_usbdrd_utmi_init(struct exynos5_usbdrd_phy *phy_drd)
+static int exynos2200_usbdrd_utmi_init(struct exynos5_usbdrd_phy *phy_drd)
{
/* Configure non-Samsung IP PHY, responsible for UTMI */
- phy_init(phy_drd->hs_phy);
+ phy_init(phy_drd->hs_phy);
+
+ return 0;
}
static void exynos2200_usbdrd_link_init(struct exynos5_usbdrd_phy *phy_drd)
@@ -1458,11 +1469,11 @@ static int exynos2200_usbdrd_phy_init(struct phy *phy)
exynos2200_usbdrd_link_attach_detach_pipe3_phy(inst);
/* UTMI or PIPE3 specific init */
- inst->phy_cfg->phy_init(phy_drd);
+ ret = inst->phy_cfg->phy_init(phy_drd);
clk_bulk_disable_unprepare(phy_drd->drv_data->n_clks, phy_drd->clks);
- return 0;
+ return ret;
}
static int exynos2200_usbdrd_phy_exit(struct phy *phy)
@@ -1516,7 +1538,7 @@ exynos5_usbdrd_usb_v3p1_pipe_override(struct exynos5_usbdrd_phy *phy_drd)
writel(reg, regs_base + EXYNOS850_DRD_SECPMACTL);
}
-static void exynos850_usbdrd_utmi_init(struct exynos5_usbdrd_phy *phy_drd)
+static int exynos850_usbdrd_utmi_init(struct exynos5_usbdrd_phy *phy_drd)
{
void __iomem *regs_base = phy_drd->reg_phy;
u32 reg;
@@ -1622,6 +1644,8 @@ static void exynos850_usbdrd_utmi_init(struct exynos5_usbdrd_phy *phy_drd)
if (ss_ports)
exynos5_usbdrd_usb_v3p1_pipe_override(phy_drd);
+
+ return 0;
}
static int exynos850_usbdrd_phy_init(struct phy *phy)
@@ -1635,12 +1659,13 @@ static int exynos850_usbdrd_phy_init(struct phy *phy)
return ret;
/* UTMI or PIPE3 specific init */
+ ret = 0;
scoped_guard(mutex, &phy_drd->phy_mutex)
- inst->phy_cfg->phy_init(phy_drd);
+ ret = inst->phy_cfg->phy_init(phy_drd);
clk_bulk_disable_unprepare(phy_drd->drv_data->n_clks, phy_drd->clks);
- return 0;
+ return ret;
}
static int exynos850_usbdrd_phy_exit(struct phy *phy)
@@ -1689,11 +1714,12 @@ static const struct phy_ops exynos850_usbdrd_phy_ops = {
.owner = THIS_MODULE,
};
-static void exynos5_usbdrd_gs101_pipe3_init(struct exynos5_usbdrd_phy *phy_drd)
+static int exynos5_usbdrd_gs101_pipe3_init(struct exynos5_usbdrd_phy *phy_drd)
{
void __iomem *regs_pma = phy_drd->reg_pma;
void __iomem *regs_phy = phy_drd->reg_phy;
u32 reg;
+ int ret;
exynos5_usbdrd_usbdp_g2_v4_ctrl_pma_ready(phy_drd);
@@ -1715,8 +1741,11 @@ static void exynos5_usbdrd_gs101_pipe3_init(struct exynos5_usbdrd_phy *phy_drd)
SECPMACTL_PMA_INIT_SW_RST);
writel(reg, regs_phy + EXYNOS850_DRD_SECPMACTL);
- if (!exynos5_usbdrd_usbdp_g2_v4_pma_check_pll_lock(phy_drd))
- exynos5_usbdrd_usbdp_g2_v4_pma_check_cdr_lock(phy_drd);
+ ret = exynos5_usbdrd_usbdp_g2_v4_pma_check_pll_lock(phy_drd);
+ if (ret)
+ return ret;
+
+ return exynos5_usbdrd_usbdp_g2_v4_pma_check_cdr_lock(phy_drd);
}
static int exynos5_usbdrd_gs101_phy_init(struct phy *phy)
@@ -1741,7 +1770,15 @@ static int exynos5_usbdrd_gs101_phy_init(struct phy *phy)
*/
exynos5_usbdrd_phy_isol(inst, false);
- return exynos850_usbdrd_phy_init(phy);
+ ret = exynos850_usbdrd_phy_init(phy);
+ if (ret) {
+ exynos5_usbdrd_phy_isol(inst, true);
+ if (inst->phy_cfg->id == EXYNOS5_DRDPHY_UTMI)
+ regulator_bulk_disable(phy_drd->drv_data->n_regulators,
+ phy_drd->regulators);
+ }
+
+ return ret;
}
static int exynos5_usbdrd_gs101_phy_exit(struct phy *phy)
@@ -2277,7 +2314,7 @@ exynosautov920_usb31drd_lane0_reset(struct exynos5_usbdrd_phy *phy_drd, int val)
writel(reg, reg_phy + EXYNOSAUTOV920_USB31DRD_PHY_RST_CTRL);
}
-static void
+static int
exynosautov920_usb31drd_pipe3_init(struct exynos5_usbdrd_phy *phy_drd)
{
void __iomem *reg_phy = phy_drd->reg_phy;
@@ -2335,6 +2372,8 @@ exynosautov920_usb31drd_pipe3_init(struct exynos5_usbdrd_phy *phy_drd)
/* override values for level settings */
exynosautov920_usb31drd_cr_write(phy_drd, 0x22, 0x00F5);
+
+ return 0;
}
static void
@@ -2353,7 +2392,7 @@ exynosautov920_usb31drd_ssphy_disable(struct exynos5_usbdrd_phy *phy_drd)
writel(reg, reg_phy + EXYNOSAUTOV920_USB31DRD_PHY_CONFIG7);
}
-static void
+static int
exynosautov920_usbdrd_utmi_init(struct exynos5_usbdrd_phy *phy_drd)
{
void __iomem *reg_phy = phy_drd->reg_phy;
@@ -2457,6 +2496,8 @@ exynosautov920_usbdrd_utmi_init(struct exynos5_usbdrd_phy *phy_drd)
reg = readl(reg_phy + EXYNOS2200_DRD_CLKRST);
reg |= EXYNOS2200_CLKRST_LINK_PCLK_SEL;
writel(reg, reg_phy + EXYNOS2200_DRD_CLKRST);
+
+ return 0;
}
static void
@@ -2504,11 +2545,11 @@ static int exynosautov920_usbdrd_phy_init(struct phy *phy)
inst->phy_cfg->phy_isol(inst, false);
/* UTMI or PIPE3 specific init */
- inst->phy_cfg->phy_init(phy_drd);
+ ret = inst->phy_cfg->phy_init(phy_drd);
clk_bulk_disable_unprepare(phy_drd->drv_data->n_clks, phy_drd->clks);
- return 0;
+ return ret;
}
static int exynosautov920_usbdrd_phy_exit(struct phy *phy)
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH v2 0/7] KVM: arm64: Fix missing ESR_ELx.IL in syndrome injection
From: Marc Zyngier @ 2026-06-23 13:53 UTC (permalink / raw)
To: Oliver Upton, Catalin Marinas, Will Deacon, kvmarm,
linux-arm-kernel, linux-kernel, Fuad Tabba
Cc: Joey Gouly, Steffen Eiden, Suzuki K Poulose, Zenghui Yu,
Vincent Donnefort, Sascha Bischoff
In-Reply-To: <20260618121643.4105064-1-tabba@google.com>
On Thu, 18 Jun 2026 13:16:36 +0100, Fuad Tabba wrote:
> After sashiko caught the missing IL bug [1], I did an audit of all ESR
> syndrome construction sites in KVM/arm64 as Marc suggested. This series
> is the result of that audit.
>
> The ARM architecture mandates ESR_ELx.IL=1 for several exception
> classes regardless of instruction length: EC=Unknown, Instruction
> Aborts, Data Aborts with ISV=0, and SError. For FPAC (EC=0x1C), IL
> reflects instruction length, but FPAC can only be generated by A64
> instructions, so IL must also be 1.
>
> [...]
Applied to fixes, thanks!
[1/7] KVM: arm64: Set ESR_ELx.IL for injected undefined exceptions at EL2
commit: daa71eca24fdfb43029830bd57ddaddf70c59b23
[2/7] KVM: arm64: Unconditionally set IL for injected undefined exceptions
commit: 1d695dc827957e9570d1b56abac1250d2d13bf0c
[3/7] KVM: arm64: Unconditionally set IL for injected abort exceptions
commit: add40af98b34764ff5603dce297160fde12d784c
[4/7] KVM: arm64: Set IL for injected FPAC exceptions during ERET emulation
commit: a52d6d68ad30374dd794bff300d8538e35ee49a8
[5/7] KVM: arm64: Set IL for emulated SError injection
commit: 7514f1785d526207af8512cc6ccb1c35c5c61767
[6/7] KVM: arm64: Set IL for nested SError injection
commit: a69412287a33c931dca9e48d30c0dbf8cde0ffe6
[7/7] KVM: arm64: Set IL in fake ESR for pKVM memory sharing exit
commit: cbe2278aa3dd6832c544782c6cfed1fbc1f71a42
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm
From: Marc Zyngier @ 2026-06-23 13:53 UTC (permalink / raw)
To: Oliver Upton, Bradley Morgan
Cc: Fuad Tabba, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Zenghui Yu, Catalin Marinas, Will Deacon, linux-arm-kernel,
kvmarm, linux-kernel
In-Reply-To: <20260621213155.6019-1-include@grrlz.net>
On Sun, 21 Jun 2026 21:31:55 +0000, Bradley Morgan wrote:
> Protected guest faults charge long term pins to the VM's mm. Teardown
> can run later from file release, where current->mm may be unrelated.
>
> Drop the charge from kvm->mm instead.
>
>
Applied to fixes, thanks!
[1/1] KVM: arm64: account pKVM reclaim against the VM mm
commit: d098bb75d14fde2f12155f1a95ec0168160867ce
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH 1/2] KVM: arm64: Fix sign-extension of MMIO loads
From: Fuad Tabba @ 2026-06-23 13:51 UTC (permalink / raw)
To: Marc Zyngier
Cc: Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Steffen Eiden, Catalin Marinas, Will Deacon, Shuah Khan,
Christoffer Dall, Victor Kamensky, linux-arm-kernel, kvmarm,
linux-kernel
In-Reply-To: <86tsqtqu9u.wl-maz@kernel.org>
On Tue, 23 Jun 2026 at 14:08, Marc Zyngier <maz@kernel.org> wrote:
>
> On Mon, 22 Jun 2026 20:07:00 +0100,
> Fuad Tabba <fuad.tabba@linux.dev> wrote:
> >
> > A sign-extending load from MMIO (LDRSB, LDRSH, LDRSW) delivers a
> > zero-extended value: in kvm_handle_mmio_return(), vcpu_data_host_to_guest()
> > masks the data to the access width after sign-extension, stripping the
> > sign bits.
> >
> > Move vcpu_data_host_to_guest() ahead of sign-extension so the width mask
> > runs first. trace_kvm_mmio() moves with it and keeps reporting the raw
> > access-width data.
> >
> > Fixes: b30070862edbd ("ARM64: KVM: MMIO support BE host running LE code")
> > Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
> > ---
> > arch/arm64/kvm/mmio.c | 7 ++++---
> > 1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/kvm/mmio.c b/arch/arm64/kvm/mmio.c
> > index e2285ed8c91de..d1c3a352d5a22 100644
> > --- a/arch/arm64/kvm/mmio.c
> > +++ b/arch/arm64/kvm/mmio.c
> > @@ -126,6 +126,10 @@ int kvm_handle_mmio_return(struct kvm_vcpu *vcpu)
> > len = kvm_vcpu_dabt_get_as(vcpu);
> > data = kvm_mmio_read_buf(run->mmio.data, len);
> >
> > + trace_kvm_mmio(KVM_TRACE_MMIO_READ, len, run->mmio.phys_addr,
> > + &data);
> > + data = vcpu_data_host_to_guest(vcpu, data, len);
>
> This helper is in charge of the endianness of the read from the
> guest's PoV. How can the sign-extension (which happens from the host's
> perspective) correctly work if it takes place after the byte swapping?
>
> To me, the real issue appears to be in the that helper, which swaps
> the data based on the size of the access instead of the width of the
> register.
>
> Or am I once more completely confused with the endianness crap?
Endianess always confuses me too :D
My reading of the ARM ARM is that the byte reversal is keyed on the access
size there too. It lives in Mem{size}, with the register width handled
separately by SignExtend(regsize):
data = Mem[address, 2]; // byte-reversed by the access size, BE
X[t] = SignExtend(data, regsize);
So vcpu_data_host_to_guest(..., len) swapping by len matches the Mem-side
reversal. Swapping by the register width would reorder bytes that were never
loaded. An LDRSH into Wt reads 2 bytes but would bswap 4: the halfword
reaches the helper as 0x0180 host-native, cpu_to_be32 turns it into
0x80010000 instead of the 0x8001 cpu_to_be16 gives, and it never sign-extends
to 0xffff8001.
If that reading holds, none of the helper's ops are individually wrong, and
the only bug was the order, with the sign-extend running before the swap and
the width mask then dropping it. But I've gone round in circles on endianness
before (to say the least), so please say if I've done it again.
Cheers,
/fuad
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm
From: Marc Zyngier @ 2026-06-23 13:50 UTC (permalink / raw)
To: Will Deacon
Cc: Bradley Morgan, Oliver Upton, Fuad Tabba, Joey Gouly,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <ajqNANUBCamSjfHM@willie-the-truck>
On Tue, 23 Jun 2026 14:41:20 +0100,
Will Deacon <will@kernel.org> wrote:
>
> On Mon, Jun 22, 2026 at 09:32:29AM +0100, Marc Zyngier wrote:
> > On Sun, 21 Jun 2026 22:31:55 +0100,
> > Bradley Morgan <include@grrlz.net> wrote:
> > >
> > > Protected guest faults charge long term pins to the VM's mm. Teardown
> > > can run later from file release, where current->mm may be unrelated.
> > >
> > > Drop the charge from kvm->mm instead.
> > >
> > > Fixes: 4e6e03f9eadd ("KVM: arm64: Hook up reclaim hypercall to pkvm_pgtable_stage2_destroy()")
> > > Signed-off-by: Bradley Morgan <include@grrlz.net>
> > > ---
> > > arch/arm64/kvm/pkvm.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> > > index 053e4f733e4b..428723b1b0f5 100644
> > > --- a/arch/arm64/kvm/pkvm.c
> > > +++ b/arch/arm64/kvm/pkvm.c
> > > @@ -352,7 +352,7 @@ static int __pkvm_pgtable_stage2_reclaim(struct kvm_pgtable *pgt, u64 start, u64
> > > page = pfn_to_page(mapping->pfn);
> > > WARN_ON_ONCE(mapping->nr_pages != 1);
> > > unpin_user_pages_dirty_lock(&page, 1, true);
> > > - account_locked_vm(current->mm, 1, false);
> > > + account_locked_vm(kvm->mm, 1, false);
> > > pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
> > > kfree(mapping);
> > > }
> >
> > Seems correct to me, as the final mmdrop(kvm->mm) occurs after S2
> > teardown.
> >
> > Will, what do you think?
>
> Thanks, this looks correct to me.
>
> While I was thinking about it, I also started looking at the use of
> 'current->mm' in kvm_arch_prepare_memory_region() in case that should
> also be 'kvm->mm'. However, I then realised that I don't really grok
> that code at all because it does a bunch of checking on the VMAs with
> mmap_read_lock(current->mm) held, but then that lock is dropped
> immediately after doing the checks so I'm not really sure what they
> are protected against. Presumably, the address space could be modified
> as soon as the lock is dropped?
>
> But it's hot, so I'm probably missing something here.
I think this is just trying to catch a few obvious issues, such as
dirty logging on device memory, but that only works for well behaved
userspace that is making "a honest mistake".
For the more trying ones, we end-up doing the same checks again at
fault time anyway.
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] arm64: uapi: Use __u128 instead of __uint128_t in UAPI headers
From: Will Deacon @ 2026-06-23 13:46 UTC (permalink / raw)
To: linux-arm-kernel, Will Deacon
Cc: catalin.marinas, kernel-team, Arnd Bergmann, Nick Desaulniers,
Steffen Eiden, Andreas Grapentin, Dave Martin, Mark Rutland,
Marc Zyngier
In-Reply-To: <20260619130835.5678-1-will@kernel.org>
On Fri, 19 Jun 2026 14:08:34 +0100, Will Deacon wrote:
> The arm64 UAPI exposes '__uint128_t' types in the members of
> 'struct user_fpsimd_state', 'struct user_pac_address_keys' and in the
> signal frame via 'struct fpsimd_context'. Since the alignment of such
> a type appears to be non-portable (16 bytes on arm64, 8 bytes on s390),
> prefer the '__u128' typedef from uapi/linux/types.h, which makes the
> alignment explicit and allows the definitions to be reused by other
> host architectures.
>
> [...]
Applied to arm64 (for-next/core), thanks!
[1/1] arm64: uapi: Use __u128 instead of __uint128_t in UAPI headers
https://git.kernel.org/arm64/c/9d6306113f92
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v4 5/5] clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO
From: Diederik de Haas @ 2026-06-23 13:45 UTC (permalink / raw)
To: Daniele Briguglio, Diederik de Haas, Heiko Stuebner,
Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Nicolas Frattaroli, linux-clk, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, Ricardo Pardini
In-Reply-To: <20260623132351.4144457-1-hello@superkali.me>
Hi Daniele,
On Tue Jun 23, 2026 at 3:23 PM CEST, Daniele Briguglio wrote:
>> md.l 0xfd58c318
>> fd58c318: 00000600
>
> Thanks. Bit 0 is clear there, so the I2S0 gate is open at the U-Boot
> prompt, after BL31 and before Linux. That matches the symptom: the
> firmware on your T6 leaves it open, and the kernel closes it once nothing
> references it.
>
> Given that, I think Heiko's suggestion makes sense here. Marking the four
> gates CLK_IGNORE_UNUSED keeps the kernel from disabling what the firmware
> already left open, and boards that reference _TO_IO still drive it through
> the consumer.
My suspicion that more RK3588 based boards would be broken is because NONE use
I2S0_8CH_MCLKOUT_TO_IO; they all use I2S0_8CH_MCLKOUT.
(And the testing was only done on not (yet?) upstreamed boards)
> Could you test that change if you get a chance? Just set the flag on the
> I2S0/1/2/3 _TO_IO gates in clk-rk3588.c and check your analog audio comes
> back. The series is already merged, so I'll send the fix as a separate
> follow-up patch, this evening if Heiko is fine with the approach.
I'm going to build a new kernel where I did ``s/0/CLK_IGNORE_UNUSED/`` 4 times
and I adjusted my NanoPC-T6 Plus board dts to use I2S0_8CH_MCLKOUT_TO_IO, while
I keep the LTS board dts to I2S0_8CH_MCLKOUT.
So IIUC that means I'd be testing both variants.
Cheers,
Diederik
^ permalink raw reply
* Re: [PATCH] KVM: arm64: account pKVM reclaim against the VM mm
From: Will Deacon @ 2026-06-23 13:41 UTC (permalink / raw)
To: Marc Zyngier
Cc: Bradley Morgan, Oliver Upton, Fuad Tabba, Joey Gouly,
Steffen Eiden, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <86zf0nq8ki.wl-maz@kernel.org>
On Mon, Jun 22, 2026 at 09:32:29AM +0100, Marc Zyngier wrote:
> On Sun, 21 Jun 2026 22:31:55 +0100,
> Bradley Morgan <include@grrlz.net> wrote:
> >
> > Protected guest faults charge long term pins to the VM's mm. Teardown
> > can run later from file release, where current->mm may be unrelated.
> >
> > Drop the charge from kvm->mm instead.
> >
> > Fixes: 4e6e03f9eadd ("KVM: arm64: Hook up reclaim hypercall to pkvm_pgtable_stage2_destroy()")
> > Signed-off-by: Bradley Morgan <include@grrlz.net>
> > ---
> > arch/arm64/kvm/pkvm.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> > index 053e4f733e4b..428723b1b0f5 100644
> > --- a/arch/arm64/kvm/pkvm.c
> > +++ b/arch/arm64/kvm/pkvm.c
> > @@ -352,7 +352,7 @@ static int __pkvm_pgtable_stage2_reclaim(struct kvm_pgtable *pgt, u64 start, u64
> > page = pfn_to_page(mapping->pfn);
> > WARN_ON_ONCE(mapping->nr_pages != 1);
> > unpin_user_pages_dirty_lock(&page, 1, true);
> > - account_locked_vm(current->mm, 1, false);
> > + account_locked_vm(kvm->mm, 1, false);
> > pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
> > kfree(mapping);
> > }
>
> Seems correct to me, as the final mmdrop(kvm->mm) occurs after S2
> teardown.
>
> Will, what do you think?
Thanks, this looks correct to me.
While I was thinking about it, I also started looking at the use of
'current->mm' in kvm_arch_prepare_memory_region() in case that should
also be 'kvm->mm'. However, I then realised that I don't really grok
that code at all because it does a bunch of checking on the VMAs with
mmap_read_lock(current->mm) held, but then that lock is dropped
immediately after doing the checks so I'm not really sure what they
are protected against. Presumably, the address space could be modified
as soon as the lock is dropped?
But it's hot, so I'm probably missing something here.
Will
^ permalink raw reply
* Re: [PATCH v1 0/3] clock-wizard fixups
From: Brian Masney @ 2026-06-23 13:40 UTC (permalink / raw)
To: Colin Foster
Cc: Datta, Shubhrajyoti, linux-kernel, linux-arm-kernel, linux-clk,
Shubhrajyoti Datta, Michal Simek, Stephen Boyd, Michael Turquette
In-Reply-To: <ajqEMXmTnpOA7tVs@colin-ia-desktop>
Hi Colin,
On Tue, Jun 23, 2026 at 08:03:45AM -0500, Colin Foster wrote:
> On Thu, May 07, 2026 at 05:29:41PM +0530, Datta, Shubhrajyoti wrote:
> > [You don't often get email from shubhraj@amd.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > On 5/7/2026 1:35 AM, Colin Foster wrote:
> > > The clock-wizard driver had a hard-coded 20KHz minimum accuracy. This
> > > led to out-of-tree drivers silently failing to set clock rates instead
> > > of dealing with the best-effort.
> > >
> > > Remove this 20KHz restriction to match the Versal clock wizard driver.
> > > There also was a bug in the difference calculation that is addressed in
> > > the first patch.
> > >
> > > The second patch optimizes the search if an exact match is found.
> > >
> > > The third removes the restriction.
> >
> > LGTM
> >
> >
> > Reviewed-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
>
> Are there any actions required from me? Hoping this doesn't slip through
> the cracks.
No there is nothing else that you need to do. Stephen hasn't made the
clk pull to Linus yet. He should assemble it this week.
For the series:
Reviewed-by: Brian Masney <bmasney@redhat.com>
^ permalink raw reply
* [PATCH] remoteproc: mediatek: Unregister init IPI on share buffer failure
From: Haoxiang Li @ 2026-06-23 13:38 UTC (permalink / raw)
To: andersson, mathieu.poirier, matthias.bgg,
angelogioacchino.delregno, olivia.wen
Cc: linux-remoteproc, linux-kernel, linux-arm-kernel, linux-mediatek,
Haoxiang Li
scp_rproc_init() registers the SCP init IPI before allocating the IPI
share buffer. If the share buffer allocation fails, the error path jumps
directly to release_dev_mem and leaves the init IPI registered.
Route that error path through the IPI unregister label so the registered
handler is cleared before unwinding the remaining resources.
Fixes: c08a82494500 ("remoteproc: mediatek: Support setting DRAM and IPI shared buffer sizes")
Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
---
drivers/remoteproc/mtk_scp.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index 85a74c9ec521..648b69f96624 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -1227,7 +1227,7 @@ static struct mtk_scp *scp_rproc_init(struct platform_device *pdev,
if (!scp->share_buf) {
dev_err(dev, "Failed to allocate IPI share buffer\n");
ret = -ENOMEM;
- goto release_dev_mem;
+ goto unregister_ipi;
}
init_waitqueue_head(&scp->run.wq);
@@ -1248,9 +1248,10 @@ static struct mtk_scp *scp_rproc_init(struct platform_device *pdev,
remove_subdev:
scp_remove_rpmsg_subdev(scp);
- scp_ipi_unregister(scp, SCP_IPI_INIT);
kfree(scp->share_buf);
scp->share_buf = NULL;
+unregister_ipi:
+ scp_ipi_unregister(scp, SCP_IPI_INIT);
release_dev_mem:
scp_unmap_memory_region(scp);
for (i = 0; i < SCP_IPI_MAX; i++)
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v4 5/5] clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO
From: Daniele Briguglio @ 2026-06-23 13:23 UTC (permalink / raw)
To: Diederik de Haas, Heiko Stuebner, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Nicolas Frattaroli, linux-clk, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, Ricardo Pardini
In-Reply-To: <DJGG8DEAKSPK.1GJ8FARAHXPXM@cknow-tech.com>
Hi Diederik,
> md.l 0xfd58c318
> fd58c318: 00000600
Thanks. Bit 0 is clear there, so the I2S0 gate is open at the U-Boot
prompt, after BL31 and before Linux. That matches the symptom: the
firmware on your T6 leaves it open, and the kernel closes it once nothing
references it.
Given that, I think Heiko's suggestion makes sense here. Marking the four
gates CLK_IGNORE_UNUSED keeps the kernel from disabling what the firmware
already left open, and boards that reference _TO_IO still drive it through
the consumer.
Could you test that change if you get a chance? Just set the flag on the
I2S0/1/2/3 _TO_IO gates in clk-rk3588.c and check your analog audio comes
back. The series is already merged, so I'll send the fix as a separate
follow-up patch, this evening if Heiko is fine with the approach.
Best regards,
Daniele
^ permalink raw reply
* [PATCH v2 2/2] drm/exynos: Add error handling to drm_encoder_init()
From: Diogo Silva @ 2026-06-23 13:19 UTC (permalink / raw)
To: Jingoo Han, Inki Dae, Seung-Woo Kim, Kyungmin Park, David Airlie,
Simona Vetter, Krzysztof Kozlowski, Alim Akhtar
Cc: dri-devel, linux-arm-kernel, linux-samsung-soc, linux-kernel,
Diogo Silva
In-Reply-To: <20260623-exynos-drm-simple-v2-0-a8d59678b7d2@gmail.com>
Not handling the return code on drm_encoder_init can lead to silent
failure and/or a drm_encoder_cleanup on a non-initialized encoder.
This patch adds error handling to the drm_encoder_init calls to prevent
that from happening.
Signed-off-by: Diogo Silva <diogompaissilva@gmail.com>
---
drivers/gpu/drm/exynos/exynos_dp.c | 8 ++++++--
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 9 +++++++--
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 ++++--
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 9 +++++++--
drivers/gpu/drm/exynos/exynos_hdmi.c | 9 +++++++--
5 files changed, 31 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c b/drivers/gpu/drm/exynos/exynos_dp.c
index a2095fb43483..1598892c602b 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -99,8 +99,12 @@ static int exynos_dp_bind(struct device *dev, struct device *master, void *data)
dp->drm_dev = drm_dev;
- drm_encoder_init(drm_dev, encoder, &exynos_dp_encoder_funcs,
- DRM_MODE_ENCODER_TMDS, NULL);
+ ret = drm_encoder_init(drm_dev, encoder, &exynos_dp_encoder_funcs,
+ DRM_MODE_ENCODER_TMDS, NULL);
+ if (ret) {
+ dev_err(dp->dev, "Failed to initialize encoder\n");
+ return ret;
+ }
drm_encoder_helper_add(encoder, &exynos_dp_encoder_helper_funcs);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 4a3d443a15e6..4e42a1da81d1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -198,8 +198,13 @@ int exynos_dpi_bind(struct drm_device *dev, struct drm_encoder *encoder)
{
int ret;
- drm_encoder_init(dev, encoder, &exynos_dpi_encoder_funcs,
- DRM_MODE_ENCODER_TMDS, NULL);
+ ret = drm_encoder_init(dev, encoder, &exynos_dpi_encoder_funcs,
+ DRM_MODE_ENCODER_TMDS, NULL);
+ if (ret) {
+ DRM_DEV_ERROR(encoder_to_dpi(encoder)->dev,
+ "failed to create encoder ret = %d\n", ret);
+ return ret;
+ }
drm_encoder_helper_add(encoder, &exynos_dpi_encoder_helper_funcs);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index 25c438cdc744..6b7561ac9bb0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -83,8 +83,10 @@ static int exynos_dsi_bind(struct device *dev, struct device *master, void *data
struct drm_device *drm_dev = data;
int ret;
- drm_encoder_init(drm_dev, encoder, &exynos_drm_dsi_encoder_funcs,
- DRM_MODE_ENCODER_TMDS, NULL);
+ ret = drm_encoder_init(drm_dev, encoder, &exynos_drm_dsi_encoder_funcs,
+ DRM_MODE_ENCODER_TMDS, NULL);
+ if (ret)
+ return ret;
ret = exynos_drm_set_possible_crtcs(encoder, EXYNOS_DISPLAY_TYPE_LCD);
if (ret < 0)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index d905dc703c06..59dea853d364 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -449,8 +449,13 @@ static int vidi_bind(struct device *dev, struct device *master, void *data)
return PTR_ERR(ctx->crtc);
}
- drm_encoder_init(drm_dev, encoder, &exynos_vidi_encoder_funcs,
- DRM_MODE_ENCODER_TMDS, NULL);
+ ret = drm_encoder_init(drm_dev, encoder, &exynos_vidi_encoder_funcs,
+ DRM_MODE_ENCODER_TMDS, NULL);
+ if (ret) {
+ DRM_DEV_ERROR(dev, "failed to initialize encoder ret = %d\n",
+ ret);
+ return ret;
+ }
drm_encoder_helper_add(encoder, &exynos_vidi_encoder_helper_funcs);
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 26baf5357997..f44586ce0fdf 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -1867,8 +1867,13 @@ static int hdmi_bind(struct device *dev, struct device *master, void *data)
hdata->phy_clk.enable = hdmiphy_clk_enable;
- drm_encoder_init(drm_dev, encoder, &exynos_hdmi_encoder_funcs,
- DRM_MODE_ENCODER_TMDS, NULL);
+ ret = drm_encoder_init(drm_dev, encoder, &exynos_hdmi_encoder_funcs,
+ DRM_MODE_ENCODER_TMDS, NULL);
+ if (ret) {
+ DRM_DEV_ERROR(dev, "failed to initialize encoder ret = %d\n",
+ ret);
+ return ret;
+ }
drm_encoder_helper_add(encoder, &exynos_hdmi_encoder_helper_funcs);
--
2.51.2
^ permalink raw reply related
* [PATCH v2 1/2] drm/exynos: Remove dependency on DRM simple helpers
From: Diogo Silva @ 2026-06-23 13:19 UTC (permalink / raw)
To: Jingoo Han, Inki Dae, Seung-Woo Kim, Kyungmin Park, David Airlie,
Simona Vetter, Krzysztof Kozlowski, Alim Akhtar
Cc: dri-devel, linux-arm-kernel, linux-samsung-soc, linux-kernel,
Diogo Silva
In-Reply-To: <20260623-exynos-drm-simple-v2-0-a8d59678b7d2@gmail.com>
Simple KMS helper are deprecated since they only add an intermediate
layer between drivers and the atomic modesetting.
This patch removes the dependency on drm simple helpers from exynos
DRM drivers.
Signed-off-by: Diogo Silva <diogompaissilva@gmail.com>
---
drivers/gpu/drm/exynos/exynos_dp.c | 9 +++++++--
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 9 +++++++--
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 9 +++++++--
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 9 +++++++--
drivers/gpu/drm/exynos/exynos_hdmi.c | 10 ++++++++--
5 files changed, 36 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_dp.c b/drivers/gpu/drm/exynos/exynos_dp.c
index b80540328150..a2095fb43483 100644
--- a/drivers/gpu/drm/exynos/exynos_dp.c
+++ b/drivers/gpu/drm/exynos/exynos_dp.c
@@ -24,11 +24,11 @@
#include <drm/drm_bridge.h>
#include <drm/drm_bridge_connector.h>
#include <drm/drm_crtc.h>
+#include <drm/drm_encoder.h>
#include <drm/drm_of.h>
#include <drm/drm_panel.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include <drm/exynos_drm.h>
#include "exynos_drm_crtc.h"
@@ -79,6 +79,10 @@ static void exynos_dp_nop(struct drm_encoder *encoder)
/* do nothing */
}
+static const struct drm_encoder_funcs exynos_dp_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const struct drm_encoder_helper_funcs exynos_dp_encoder_helper_funcs = {
.mode_set = exynos_dp_mode_set,
.enable = exynos_dp_nop,
@@ -95,7 +99,8 @@ static int exynos_dp_bind(struct device *dev, struct device *master, void *data)
dp->drm_dev = drm_dev;
- drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_TMDS);
+ drm_encoder_init(drm_dev, encoder, &exynos_dp_encoder_funcs,
+ DRM_MODE_ENCODER_TMDS, NULL);
drm_encoder_helper_add(encoder, &exynos_dp_encoder_helper_funcs);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
index 0dc36df6ada3..4a3d443a15e6 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dpi.c
@@ -12,10 +12,10 @@
#include <linux/regulator/consumer.h>
#include <drm/drm_atomic_helper.h>
+#include <drm/drm_encoder.h>
#include <drm/drm_panel.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include <video/of_videomode.h>
#include <video/videomode.h>
@@ -140,6 +140,10 @@ static void exynos_dpi_disable(struct drm_encoder *encoder)
}
}
+static const struct drm_encoder_funcs exynos_dpi_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const struct drm_encoder_helper_funcs exynos_dpi_encoder_helper_funcs = {
.mode_set = exynos_dpi_mode_set,
.enable = exynos_dpi_enable,
@@ -194,7 +198,8 @@ int exynos_dpi_bind(struct drm_device *dev, struct drm_encoder *encoder)
{
int ret;
- drm_simple_encoder_init(dev, encoder, DRM_MODE_ENCODER_TMDS);
+ drm_encoder_init(dev, encoder, &exynos_dpi_encoder_funcs,
+ DRM_MODE_ENCODER_TMDS, NULL);
drm_encoder_helper_add(encoder, &exynos_dpi_encoder_helper_funcs);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
index c4d098ab7863..25c438cdc744 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c
@@ -13,7 +13,7 @@
#include <drm/bridge/samsung-dsim.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
+#include <drm/drm_encoder.h>
#include "exynos_drm_crtc.h"
#include "exynos_drm_drv.h"
@@ -22,6 +22,10 @@ struct exynos_dsi {
struct drm_encoder encoder;
};
+static const struct drm_encoder_funcs exynos_drm_dsi_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static irqreturn_t exynos_dsi_te_irq_handler(struct samsung_dsim *dsim)
{
struct exynos_dsi *dsi = dsim->priv;
@@ -79,7 +83,8 @@ static int exynos_dsi_bind(struct device *dev, struct device *master, void *data
struct drm_device *drm_dev = data;
int ret;
- drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_TMDS);
+ drm_encoder_init(drm_dev, encoder, &exynos_drm_dsi_encoder_funcs,
+ DRM_MODE_ENCODER_TMDS, NULL);
ret = exynos_drm_set_possible_crtcs(encoder, EXYNOS_DISPLAY_TYPE_LCD);
if (ret < 0)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
index 67bbf9b8bc0e..d905dc703c06 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c
@@ -13,10 +13,10 @@
#include <drm/drm_atomic_helper.h>
#include <drm/drm_edid.h>
+#include <drm/drm_encoder.h>
#include <drm/drm_framebuffer.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include <drm/drm_vblank.h>
#include <drm/exynos_drm.h>
@@ -403,6 +403,10 @@ static void exynos_vidi_disable(struct drm_encoder *encoder)
{
}
+static const struct drm_encoder_funcs exynos_vidi_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
static const struct drm_encoder_helper_funcs exynos_vidi_encoder_helper_funcs = {
.mode_set = exynos_vidi_mode_set,
.enable = exynos_vidi_enable,
@@ -445,7 +449,8 @@ static int vidi_bind(struct device *dev, struct device *master, void *data)
return PTR_ERR(ctx->crtc);
}
- drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_TMDS);
+ drm_encoder_init(drm_dev, encoder, &exynos_vidi_encoder_funcs,
+ DRM_MODE_ENCODER_TMDS, NULL);
drm_encoder_helper_add(encoder, &exynos_vidi_encoder_helper_funcs);
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 09b2cabb236f..26baf5357997 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -36,9 +36,9 @@
#include <drm/drm_atomic_helper.h>
#include <drm/drm_bridge.h>
#include <drm/drm_edid.h>
+#include <drm/drm_encoder.h>
#include <drm/drm_print.h>
#include <drm/drm_probe_helper.h>
-#include <drm/drm_simple_kms_helper.h>
#include "exynos_drm_crtc.h"
#include "regs-hdmi.h"
@@ -1575,6 +1575,11 @@ static void hdmi_disable(struct drm_encoder *encoder)
mutex_unlock(&hdata->mutex);
}
+static const struct drm_encoder_funcs exynos_hdmi_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
+
static const struct drm_encoder_helper_funcs exynos_hdmi_encoder_helper_funcs = {
.mode_fixup = hdmi_mode_fixup,
.enable = hdmi_enable,
@@ -1862,7 +1867,8 @@ static int hdmi_bind(struct device *dev, struct device *master, void *data)
hdata->phy_clk.enable = hdmiphy_clk_enable;
- drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_TMDS);
+ drm_encoder_init(drm_dev, encoder, &exynos_hdmi_encoder_funcs,
+ DRM_MODE_ENCODER_TMDS, NULL);
drm_encoder_helper_add(encoder, &exynos_hdmi_encoder_helper_funcs);
--
2.51.2
^ permalink raw reply related
* [PATCH v2 0/2] drm/exynos: DRM encoder improvements for Exynos devices
From: Diogo Silva @ 2026-06-23 13:19 UTC (permalink / raw)
To: Jingoo Han, Inki Dae, Seung-Woo Kim, Kyungmin Park, David Airlie,
Simona Vetter, Krzysztof Kozlowski, Alim Akhtar
Cc: dri-devel, linux-arm-kernel, linux-samsung-soc, linux-kernel,
Diogo Silva
This series does two things:
- Open-code drm_simple_encoder_init() since it is deprecated
- Handle the error code from drm_encoder_init (previously
drm_simple_encoder_init) to prevent silent failures and
cleanup of uninitialized encoders
Signed-off-by: Diogo Silva <diogompaissilva@gmail.com>
---
Changes in v2:
- Fix mistake in exynos_drm_vidi
- Fix indentation
- Link to v1: https://lore.kernel.org/r/20260623-exynos-drm-simple-v1-0-bb52f098b1ee@gmail.com
---
Diogo Silva (2):
drm/exynos: Remove dependency on DRM simple helpers
drm/exynos: Add error handling to drm_encoder_init()
drivers/gpu/drm/exynos/exynos_dp.c | 13 +++++++++++--
drivers/gpu/drm/exynos/exynos_drm_dpi.c | 14 ++++++++++++--
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 11 +++++++++--
drivers/gpu/drm/exynos/exynos_drm_vidi.c | 14 ++++++++++++--
drivers/gpu/drm/exynos/exynos_hdmi.c | 15 +++++++++++++--
5 files changed, 57 insertions(+), 10 deletions(-)
---
base-commit: 60326b17f877e12846167bf8ef83680b9875218a
change-id: 20260623-exynos-drm-simple-bb5386d64597
Best regards,
--
Diogo Silva <diogompaissilva@gmail.com>
^ permalink raw reply
* Re: [PATCH v4 5/5] clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO
From: Diederik de Haas @ 2026-06-23 13:08 UTC (permalink / raw)
To: Diederik de Haas, Daniele Briguglio, Heiko Stuebner,
Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Nicolas Frattaroli, linux-clk, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, Ricardo Pardini
In-Reply-To: <DJGG8DEAKSPK.1GJ8FARAHXPXM@cknow-tech.com>
On Tue Jun 23, 2026 at 3:05 PM CEST, Diederik de Haas wrote:
> On Tue Jun 23, 2026 at 2:33 PM CEST, Daniele Briguglio wrote:
>> If that turns out to be the case, CLK_IGNORE_UNUSED on the gates is a
>> reasonable way to stop the kernel from closing a gate the firmware already
>> left open, for boards that would rather not switch their DTS to _TO_IO.
>
> I'm not so sure I agree that CLK_IGNORE_UNUSED is reasonable, but I'll leave
> judgement up to others. I'll do the test regardless, though.
Ah, just learned those should be added to your patch, in which case my
objection goes away.
^ 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