* Re: [PATCH 00/19] init: discoverable root partitions, a.k.a. an omittable "root=" cmdline option
From: Christian Brauner @ 2026-06-17 12:41 UTC (permalink / raw)
To: Vincent Mailhol
Cc: Jens Axboe, Davidlohr Bueso, Alexander Viro, Jan Kara,
linux-kernel, linux-block, linux-efi, linux-fsdevel,
Richard Henderson, Matt Turner, Magnus Lindholm, linux-alpha,
Vineet Gupta, linux-snps-arc, Russell King, linux-arm-kernel,
Catalin Marinas, Will Deacon, Huacai Chen, WANG Xuerui, loongarch,
Thomas Bogendoerfer, linux-mips, James E.J. Bottomley,
Helge Deller, linux-parisc, Madhavan Srinivasan, Michael Ellerman,
linuxppc-dev, Paul Walmsley, Palmer Dabbelt, Albert Ou,
linux-riscv, Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
linux-s390, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, Jonathan Corbet, Shuah Khan, linux-doc
In-Reply-To: <20260615-discoverable-root_partitions-v1-0-39c78fac42e2@kernel.org>
On Mon, Jun 15, 2026 at 06:08:56PM +0200, Vincent Mailhol wrote:
> DPS [1] defines GPT partition type UUIDs for OS partitions and
> attributes that control whether such partitions should be
> automatically discovered. The specification states that:
>
> The OS can discover and mount the necessary file systems with a
> non-existent or incomplete /etc/fstab file and without the root=
> kernel command line option.
>
> DPS is already implemented in systemd-gpt-auto-generator [2], which,
> when embedded in an initrd, indeed allows automatic detection of the
> root filesystem through its partition type UUID.
>
> This series adds this discovery feature directly into the kernel so
> that people who are not using systemd or not using an initrd can still
> benefit from it. The implementation follows the same model as
> systemd-gpt-auto-generator:
I happen to co-maintain the DPS. It is userspace policy and complex
userspace policy at that and does not belong into the kernel.
This also implements a really tiny portion of the spec. It deals with a
lot more complex concepts such as automatic partitioning during
installation, verity, LUKS, containers. This is really not intended for
the kernel at all. I mean, it's great that this spec is being used but I
do not want this in the kernel just for the sake of auto-discovery.
The DPS is completely generic and can be implemented by tooling other
than systemd (util-linux implements it and so does refind iirc). I think
not wanting to use or build alternative userspace tooling for this is a
really weak argument for pushing this into the kernel.
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Sync SPSR_EL1 when injecting an exception into a pVM
From: Marc Zyngier @ 2026-06-17 12:41 UTC (permalink / raw)
To: Oliver Upton, linux-arm-kernel, kvmarm, linux-kernel, Fuad Tabba
Cc: Joey Gouly, Steffen Eiden, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Sascha Bischoff, Andrew Jones
In-Reply-To: <20260612113414.1022901-1-tabba@google.com>
On Fri, 12 Jun 2026 12:34:14 +0100, Fuad Tabba wrote:
> When pKVM injects a synchronous exception into a protected guest, it
> re-enters without restoring the guest's EL1 sysregs and writes the EL1
> exception registers to hardware by hand: ESR_EL1 and ELR_EL1, but not
> SPSR_EL1. enter_exception64() sets SPSR_EL1 (the interrupted PSTATE)
> only in memory, so the guest's handler reads a stale SPSR_EL1 and
> restores the wrong PSTATE on eret.
>
> [...]
Applied to fixes, thanks!
[1/1] KVM: arm64: Sync SPSR_EL1 when injecting an exception into a pVM
commit: ec40342aaca8162bc8ab2607076535ebab1838b8
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v9 9/9] perf test: Add Arm CoreSight callchain test
From: Leo Yan @ 2026-06-17 12:33 UTC (permalink / raw)
To: James Clark
Cc: linux-arm-kernel, coresight, linux-perf-users,
Arnaldo Carvalho de Melo, John Garry, Will Deacon, Mike Leach,
Suzuki K Poulose, Namhyung Kim, Mark Rutland, Alexander Shishkin,
Jiri Olsa, Ian Rogers, Adrian Hunter, Al Grant, Paschalis Mpeis,
Amir Ayupov
In-Reply-To: <6855d77f-d2f4-4dab-8481-a8c586e4872b@linaro.org>
On Wed, Jun 17, 2026 at 11:03:07AM +0100, James Clark wrote:
[...]
> > + # It is safe to use 'i3i' with a three-instruction interval, since the
> > + # workload is compiled with -O0.
> > + perf script --itrace=g16i3il64 -i "$data" > "$script"
>
> Is there a reason we don't generate callstacks on branch samples and use
> --itrace=g16bl64? That removes the magic number 3 and reduces the output
> file size and test runtime a bit.
I checked Intel-PT which does not generate callchain and branch stack for
branch samples. I just keep cs-etm aligned.
I can add callstack / branch stack for branch samples.
> All I had to do was copy the same "if (etm->synth_opts.callchain) { ..."
> block to cs_etm__synth_branch_sample(). It seems like the grepping doesn't
> exactly match the branch sample format so the test fails, but I'm sure that
> could be fixed.
This is likely caused by the regular expr.
> I suppose there is value in testing instruction output, but maybe we can add
> the option for users to add callstacks to branch samples, even if it's not
> tested.
I will try to update the test for branch samples.
Thanks,
Leo
^ permalink raw reply
* [PATCH 3/3] phy: rockchip: phy-rockchip-inno-csidphy: add clock lane phase tuning
From: Gerald Loacker @ 2026-06-17 12:23 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, Gerald Loacker
In-Reply-To: <20260617-feature-mipi-csi-dphy-4k60-v1-0-4611ff00b0ff@wolfvision.net>
At high data rates like 4K60 (2500 Mbps), such as when using an
LT6911GXD bridge chip on an RK3588 board, fixed default timing parameters
can cause signal integrity issues and clock-data recovery failures.
The driver currently lacks a mechanism to adjust the clock lane sampling
phase to compensate for board-specific trace variations.
Resolve this by parsing and applying the optional 'rockchip,clk-lane-phase'
device tree property. This enables board-specific tuning of the clock
lane sampling phase in ~40 ps steps (range 0-7) to optimize link
stability. If the property is absent, the driver falls back to the
hardware default.
Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
---
drivers/phy/rockchip/phy-rockchip-inno-csidphy.c | 25 ++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
index 5281f8dea0ad3..3a15840e86cad 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
@@ -69,6 +69,10 @@
#define RK1808_CSIDPHY_CLK_CALIB_EN 0x168
#define RK3568_CSIDPHY_CLK_CALIB_EN 0x168
+#define CSIDPHY_LANE_CLK_3_PHASE 0x38
+#define CSIDPHY_CLK_PHASE_MASK GENMASK(6, 4)
+#define CSIDPHY_CLK_PHASE_DEFAULT 3
+
#define RESETS_MAX 2
/*
@@ -151,6 +155,7 @@ struct rockchip_inno_csidphy {
const struct dphy_drv_data *drv_data;
struct phy_configure_opts_mipi_dphy config;
u8 hsfreq;
+ int clk_phase;
};
static inline void write_grf_reg(struct rockchip_inno_csidphy *priv,
@@ -304,6 +309,13 @@ static int rockchip_inno_csidphy_power_on(struct phy *phy)
rockchip_inno_csidphy_ths_settle(priv, priv->hsfreq,
CSIDPHY_LANE_THS_SETTLE(i));
+ if (priv->clk_phase >= 0) {
+ val = readl(priv->phy_base + CSIDPHY_LANE_CLK_3_PHASE);
+ val &= ~CSIDPHY_CLK_PHASE_MASK;
+ val |= FIELD_PREP(CSIDPHY_CLK_PHASE_MASK, priv->clk_phase);
+ writel(val, priv->phy_base + CSIDPHY_LANE_CLK_3_PHASE);
+ }
+
write_grf_reg(priv, GRF_DPHY_CSIPHY_CLKLANE_EN, 0x1);
write_grf_reg(priv, GRF_DPHY_CSIPHY_DATALANE_EN,
GENMASK(priv->config.lanes - 1, 0));
@@ -449,6 +461,7 @@ static int rockchip_inno_csidphy_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct phy_provider *phy_provider;
struct phy *phy;
+ u32 phase;
int ret;
priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
@@ -464,6 +477,18 @@ static int rockchip_inno_csidphy_probe(struct platform_device *pdev)
return -ENODEV;
}
+ priv->clk_phase = -1;
+ if (device_property_read_u32(dev, "rockchip,clk-lane-phase",
+ &phase) == 0) {
+ if (phase >= BIT(3)) {
+ dev_err(dev,
+ "rockchip,clk-lane-phase %u out of range [0,7]\n",
+ phase);
+ return -EINVAL;
+ }
+ priv->clk_phase = phase;
+ }
+
priv->grf = syscon_regmap_lookup_by_phandle(dev->of_node,
"rockchip,grf");
if (IS_ERR(priv->grf)) {
--
2.34.1
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase property
From: Gerald Loacker @ 2026-06-17 12:23 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, Gerald Loacker
In-Reply-To: <20260617-feature-mipi-csi-dphy-4k60-v1-0-4611ff00b0ff@wolfvision.net>
Add support for the optional rockchip,clk-lane-phase device tree property
to allow board-specific tuning of the clock lane sampling phase for
improved signal integrity across supported data rates.
Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
---
Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
index 03950b3cad08c..0d824d1511bc0 100644
--- a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
+++ b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml
@@ -56,6 +56,13 @@ properties:
description:
Some additional phy settings are access through GRF regs.
+ rockchip,clk-lane-phase:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 7
+ description:
+ Clock lane sampling phase in 40 ps steps. The hardware default is 3.
+
required:
- compatible
- reg
--
2.34.1
^ permalink raw reply related
* [PATCH 1/3] phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table
From: Gerald Loacker @ 2026-06-17 12:23 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, Gerald Loacker
In-Reply-To: <20260617-feature-mipi-csi-dphy-4k60-v1-0-4611ff00b0ff@wolfvision.net>
The rk1808 hsfreq table capped at 2499 Mbps, preventing a data rate of
exactly 2500 Mbps. Extend the final entry to 2500 Mbps to support this
rate.
This is essential for RK3588 reusing this array and fully supporting
rates up to 2500 Mbps.
Fixes: bd1f775d6027 ("phy/rockchip: add Innosilicon-based CSI dphy")
Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
---
drivers/phy/rockchip/phy-rockchip-inno-csidphy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
index c79fb53d8ee5c..5281f8dea0ad3 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
@@ -170,7 +170,7 @@ static const struct hsfreq_range rk1808_mipidphy_hsfreq_ranges[] = {
{ 299, 0x06}, { 399, 0x08}, { 499, 0x0b}, { 599, 0x0e},
{ 699, 0x10}, { 799, 0x12}, { 999, 0x16}, {1199, 0x1e},
{1399, 0x23}, {1599, 0x2d}, {1799, 0x32}, {1999, 0x37},
- {2199, 0x3c}, {2399, 0x41}, {2499, 0x46}
+ {2199, 0x3c}, {2399, 0x41}, {2500, 0x46}
};
static const struct hsfreq_range rk3326_mipidphy_hsfreq_ranges[] = {
--
2.34.1
^ permalink raw reply related
* [PATCH 0/3] phy: rockchip: inno-csidphy: fix 2500 Mbps support and add clock lane phase tuning
From: Gerald Loacker @ 2026-06-17 12:23 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, Gerald Loacker
This series fixes and extends the Rockchip Innosilicon CSI D-PHY driver
to support data rates up to 2500 Mbps and adds optional board-specific
clock lane phase tuning for signal integrity.
Patch 1 fixes an off-by-one error in the rk1808 hsfreq range table:
the final entry was capped at 2499 Mbps, causing a rejection of the
maximum supported rate of 2500 Mbps.
Patches 2 and 3 add an optional rockchip,clk-lane-phase device tree
property that allows tuning the clock lane sampling phase in ~40 ps
steps to compensate for board-level signal integrity variations.
---
Gerald Loacker (3):
phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table
dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase property
phy: rockchip: phy-rockchip-inno-csidphy: add clock lane phase tuning
.../bindings/phy/rockchip-inno-csi-dphy.yaml | 7 ++++++
drivers/phy/rockchip/phy-rockchip-inno-csidphy.c | 27 +++++++++++++++++++++-
2 files changed, 33 insertions(+), 1 deletion(-)
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260617-feature-mipi-csi-dphy-4k60-9879c3d1fe4f
Best regards,
--
Gerald Loacker <gerald.loacker@wolfvision.net>
^ permalink raw reply
* Re: [PATCH] net: airoha: Clean up RX queues in airoha_dev_stop
From: Simon Horman @ 2026-06-17 12:22 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, lorenzo, pabeni, kuba, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178160746585.2156302.190868309474762875@gmail.com>
On Tue, Jun 16, 2026 at 06:50:48PM +0800, Wayen Yan wrote:
> When the last port is stopped, airoha_dev_stop() clears TX queues
> but neglects to clean up RX queues. This can lead to:
> - RX ring buffer descriptors remaining valid after device close
> - Potential DMA synchronization issues on device reopen
> - Risk of use-after-free if pages are freed while DMA is still active
>
> Add cleanup loop for RX queues to mirror the TX queue cleanup,
> ensuring symmetric resource management.
>
> Fixes: 20bf7d07c956 ("net: airoha: add QDMA support for Airoha EN7581 Ethernet")
> Signed-off-by: Wayen Yan <win847@gmail.com>
Hi Wayen Yan,
There is AI-generated review of this patch-set available on both
https://sashiko.dev and https://netdev-ai.bots.linux.dev/sashiko/
I asked AI to summarise these concerns, it came up with the
following. I would appreciate it if you could look over this feedback.
1. NAPI Synchronization:
While the TX path is managed by the netdev layer during stop, the RX path
relies on the NAPI subsystem. Since NAPI remains active during
`airoha_dev_stop()`, the new cleanup loop could race with the poller
(`airoha_qdma_rx_process`). It would be safer to call `napi_disable()`
before draining the queues to ensure exclusive access to the descriptors.
2. RX Queue Refill:
Unlike TX, the RX hardware requires descriptors to be pre-allocated and
posted by the driver to receive data. Because this patch empties the rings,
`airoha_dev_open()` needs a corresponding update to refill them (e.g.,
via `airoha_qdma_fill_rx_queue()`). Without this, the interface will
encounter an empty ring on restart, leading to an RX stall.
3. SKB Accumulation:
The cleanup should also account for the `q->skb` pointer used for
fragmented packets. If a partial packet is sitting in the queue when the
interface is stopped, freeing it and resetting the pointer to NULL will
prevent a memory leak and ensure the next session starts with a clean
state.
^ permalink raw reply
* Re: [PATCH 1/6] irqchip/gic-v3-its: Fix LPI range leak and refactor error handler in its_lpi_alloc()
From: Marc Zyngier @ 2026-06-17 12:09 UTC (permalink / raw)
To: Kemeng Shi; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <cda86396-afe1-4bc9-97c2-0e7a3c739217@huaweicloud.com>
On Tue, 16 Jun 2026 02:31:22 +0100,
Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>
> 在 2026/6/15 16:52:56, Marc Zyngier 写道:
> > On Mon, 15 Jun 2026 04:29:05 +0100,
> > Kemeng Shi <shikemeng@huaweicloud.com> wrote:
> >>
> >> Fix the LIP range leak when bitmap_zalloc() failed. Besides refactor
> >
> > Typo.
> >
> >> error handling code to make it a little simpler.
> >
> > No. Please don't mix fixes and (totally pointless) refactoring.
> OK, I will only keep fix in this patch.>
> >>
> >> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
> >> ---
> >> drivers/irqchip/irq-gic-v3-its.c | 21 +++++++++------------
> >> 1 file changed, 9 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> >> index 291d7668cc8d..2b7b546c43c8 100644
> >> --- a/drivers/irqchip/irq-gic-v3-its.c
> >> +++ b/drivers/irqchip/irq-gic-v3-its.c
> >> @@ -2217,10 +2217,9 @@ static int __init its_lpi_init(u32 id_bits)
> >> static unsigned long *its_lpi_alloc(int nr_irqs, u32 *base, int *nr_ids)
> >> {
> >> unsigned long *bitmap = NULL;
> >> - int err = 0;
> >>
> >> do {
> >> - err = alloc_lpi_range(nr_irqs, base);
> >> + int err = alloc_lpi_range(nr_irqs, base);
> >> if (!err)
> >> break;
> >>
> >> @@ -2228,22 +2227,20 @@ static unsigned long *its_lpi_alloc(int nr_irqs, u32 *base, int *nr_ids)
> >> } while (nr_irqs > 0);
> >>
> >> if (!nr_irqs)
> >> - err = -ENOSPC;
> >> -
> >> - if (err)
> >> - goto out;
> >> + goto err_out;
> >>
> >> bitmap = bitmap_zalloc(nr_irqs, GFP_ATOMIC);
> >> if (!bitmap)
> >> - goto out;
> >> + goto err_free_lpi;
> >>
> >> *nr_ids = nr_irqs;
> >> -
> >> -out:
> >> - if (!bitmap)
> >> - *base = *nr_ids = 0;
> >> -
> >> return bitmap;
> >> +
> >> +err_free_lpi:
> >> + free_lpi_range(*base, nr_irqs);
> >> +err_out:
> >> + *base = *nr_ids = 0;
> >> + return NULL;
> >> }
> >>
> >> static void its_lpi_free(unsigned long *bitmap, u32 base, u32 nr_ids)
> >
> > Honestly, I question the validity of handling errors this way. You are
> > already unable to allocate a per-device bitmap. And yet you are
> > calling free_lpi_range(), which has the interesting property of
> > *allocating* memory. Which you don't have. Oh wait...
> You are right. I'm considering use xarray to track the lpi range or
> modify free_lpi_range to try merge first before memory allocation.
> What would you recommend?
My personal take on this is that leaking a few LPIs is not a big deal,
given how many we have. You are trying to optimise for an error case
that never happens, and I really don't want to add more complexity to
this.
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH 2/6] irqchip/gic-v3-its: Fix memleak in its_probe_one()
From: Marc Zyngier @ 2026-06-17 12:07 UTC (permalink / raw)
To: Kemeng Shi; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <bf396073-9a23-4602-ad64-ac3f38f2df65@huaweicloud.com>
On Tue, 16 Jun 2026 02:39:10 +0100,
Kemeng Shi <shikemeng@huaweicloud.com> wrote:
>
> 在 2026/6/15 16:59:14, Marc Zyngier 写道:
> > On Mon, 15 Jun 2026 04:29:06 +0100,
> > Kemeng Shi <shikemeng@huaweicloud.com> wrote:
> >>
> >> Fix collection leak when its_init_domain() failed in its_probe_one().
> >>
> >> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
> >> ---
> >> drivers/irqchip/irq-gic-v3-its.c | 10 +++++++++-
> >> 1 file changed, 9 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> >> index 2b7b546c43c8..df26ddc97ae2 100644
> >> --- a/drivers/irqchip/irq-gic-v3-its.c
> >> +++ b/drivers/irqchip/irq-gic-v3-its.c
> >> @@ -3032,6 +3032,12 @@ static int its_alloc_collections(struct its_node *its)
> >> return 0;
> >> }
> >>
> >> +static void its_free_collections(struct its_node *its)
> >> +{
> >> + kfree(its->collections);
> >> + its->collections = NULL;
> >> +}
> >
> > Why do we need an extra helper for something that has a single calling
> > spot? Why is it important to set collections to NULL, given that we're
> > about to free the structure without even looking further?
> >
> The extra helper is added for symmetry with its_alloc_collections(), keeping
> allocation/deallocation logic paired.
But there is zero logic here. None. it is a call to kfree(), just
that, and we don't need any additional abstraction.
> In this way, we need to only modified
> allocation/deallocation function if more member is added for collections.
Well, when we get there, we can always add an abstraction.
> Setting collections to NULL is a personal habit to quickly catch use-after-free
> of collections. Could drop this which is not that import.
I don't see the point of doing that.
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] KVM: arm64: nv: Write ESR_EL2 for injected nested SError exceptions
From: Marc Zyngier @ 2026-06-17 12:04 UTC (permalink / raw)
To: Oliver Upton, Catalin Marinas, Will Deacon, Fuad Tabba
Cc: Joey Gouly, Suzuki K Poulose, Zenghui Yu, kvmarm,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260615131116.390977-1-tabba@google.com>
On Mon, 15 Jun 2026 14:11:16 +0100, Fuad Tabba wrote:
> kvm_inject_el2_exception() writes ESR_EL2 for synchronous exceptions
> but not for SError. enter_exception64() does not write ESR_ELx for any
> exception type, so the constructed syndrome is dropped. A guest L2
> hypervisor taking a nested SError observes stale ESR_EL2.
>
> This affects both kvm_inject_nested_serror() and the EASE path in
> kvm_inject_nested_sea().
>
> [...]
Applied to fixes, thanks!
[1/1] KVM: arm64: nv: Write ESR_EL2 for injected nested SError exceptions
commit: e2cb1f4578625e71f461d5c1ce70984193389cbb
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] net: airoha: Fix MODULE_LICENSE to match SPDX GPL-2.0-only identifier
From: Leon Romanovsky @ 2026-06-17 11:58 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Wayen Yan, netdev, lorenzo, horms, pabeni, kuba, edumazet,
andrew+netdev, angelogioacchino.delregno, matthias.bgg,
linux-arm-kernel, linux-mediatek
In-Reply-To: <178156440888.329386.11011872053824456703.git-patchwork-notify@kernel.org>
On Mon, Jun 15, 2026 at 11:00:08PM +0000, patchwork-bot+netdevbpf@kernel.org wrote:
> Hello:
>
> This patch was applied to netdev/net-next.git (main)
> by Jakub Kicinski <kuba@kernel.org>:
>
> On Sun, 14 Jun 2026 07:52:39 +0800 you wrote:
> > Both airoha_eth.c and airoha_npu.c declare SPDX-License-Identifier:
> > GPL-2.0-only but use MODULE_LICENSE("GPL"), which the kernel module
> > loader interprets as GPL-2.0+ (any GPL version). This mismatch causes
> > license compliance tools (FOSSology, ScanCode, etc.) to misidentify
> > the effective license as more permissive than intended.
> >
> > Replace MODULE_LICENSE("GPL") with MODULE_LICENSE("GPL v2") to
> > align with the GPL-2.0-only SPDX identifier. Per include/linux/module.h,
> > "GPL v2" maps to GPL-2.0-only, matching the source files' declared
> > license.
> >
> > [...]
>
> Here is the summary with links:
> - net: airoha: Fix MODULE_LICENSE to match SPDX GPL-2.0-only identifier
> https://git.kernel.org/netdev/net-next/c/b0d62ed16424
Jakub,
This patch doesn't fix anything. License rules are pretty clear.
Documentation/process/license-rules.rst
444 "GPL" Module is licensed under GPL version 2. This
445 does not express any distinction between
446 GPL-2.0-only or GPL-2.0-or-later. The exact
447 license information can only be determined
448 via the license information in the
449 corresponding source files.
450
451 "GPL v2" Same as "GPL". It exists for historic
452 reasons.
>
> You are awesome, thank you!
> --
> Deet-doot-dot, I am a bot.
> https://korg.docs.kernel.org/patchwork/pwbot.html
>
>
>
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Handle race between interrupt affinity change and LPI disabling
From: Marc Zyngier @ 2026-06-17 11:51 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, kvm, Marc Zyngier
Cc: Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Hyunwoo Kim
In-Reply-To: <20260615181625.3029352-1-maz@kernel.org>
On Mon, 15 Jun 2026 19:16:25 +0100, Marc Zyngier wrote:
> Hyunwoo Kim reports some really bad races should the following
> situation occur:
>
> - LPI-I is pending in vcpu-B's AP list
> - vcpu-A writes to vcpu-B's RD to disable its LPIs
> - vcpu-C moves I from B to C
>
> [...]
Applied to fixes, thanks!
[1/1] KVM: arm64: Handle race between interrupt affinity change and LPI disabling
commit: 7258770e5814f15e8308ebda82ac9acf6964ba8e
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] KVM: arm64: vgic: Check the interrupt is still ours before migrating it
From: Marc Zyngier @ 2026-06-17 11:51 UTC (permalink / raw)
To: oupton, joey.gouly, seiden, suzuki.poulose, yuzenghui,
catalin.marinas, will, Sascha.Bischoff, jic23, timothy.hayes,
eric.auger, christoffer.dall, andre.przywara, Hyunwoo Kim
Cc: linux-arm-kernel, kvmarm
In-Reply-To: <aiHnI1mu6SGQrgnz@v4bel>
On Fri, 05 Jun 2026 05:59:15 +0900, Hyunwoo Kim wrote:
> vgic_prune_ap_list() drops both ap_list_lock and irq_lock while migrating
> an interrupt to another vCPU. After reacquiring the locks it only checks
> that the affinity is unchanged (target_vcpu == vgic_target_oracle(irq))
> before moving the interrupt, which assumes that an interrupt whose affinity
> is preserved is still queued on this vCPU's ap_list.
>
> That assumption no longer holds if the interrupt is taken off the ap_list
> while the locks are dropped. vgic_flush_pending_lpis() removes the
> interrupt from the list and sets irq->vcpu to NULL, but leaves
> enabled/pending/target_vcpu untouched. As the interrupt is still enabled
> and pending, vgic_target_oracle() returns the same target_vcpu, so the
> affinity check passes and list_del() is run a second time on an entry that
> has already been removed.
>
> [...]
Applied to fixes, thanks!
[1/1] KVM: arm64: vgic: Check the interrupt is still ours before migrating it
commit: 0074b82cdfcb5fd13710a0ac308ade68ac6f6fbe
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v2] KVM: arm64: nv: Fix SPSR_EL2 restore in kvm_hyp_handle_mops()
From: Marc Zyngier @ 2026-06-17 11:50 UTC (permalink / raw)
To: Oliver Upton, Catalin Marinas, Will Deacon, Weiming Shi
Cc: Joey Gouly, Steffen Eiden, Suzuki K Poulose, Zenghui Yu,
Jakub Kicinski, Andrew Morton, Hans Verkuil, Mark Rutland,
Kristina Martsenko, linux-arm-kernel, kvmarm, Zhong Wang,
Xuanqing Shi, stable
In-Reply-To: <20260617040820.2194831-2-bestswngs@gmail.com>
On Wed, 17 Jun 2026 12:08:21 +0800, Weiming Shi wrote:
> kvm_hyp_handle_mops() resets the single-step state machine as part of
> rewinding state for a MOPS exception by modifying vcpu_cpsr() and
> writing the result directly into hardware.
>
> In the case of nested virtualization, vcpu_cpsr() is a synthetic value
> such that the rest of KVM can deal with vEL2 cleanly. That means the
> value requires translation before being written into hardware, which is
> unfortunately missing from the MOPS handler.
>
> [...]
Applied to fixes, thanks!
[1/1] KVM: arm64: nv: Fix SPSR_EL2 restore in kvm_hyp_handle_mops()
commit: ff1022c3de46753eb7eba2f6efd990569e66ff95
Cheers,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [RFC PATCH v2 1/3] mm/huge_memory: make persistent huge zero folio read-only
From: David Hildenbrand (Arm) @ 2026-06-17 11:50 UTC (permalink / raw)
To: Dave Hansen, Xueyuan Chen, akpm, linux-mm
Cc: linux-kernel, linux-arm-kernel, x86, catalin.marinas, will, tglx,
mingo, bp, dave.hansen, luto, peterz, hpa, ljs, liam, vbabka,
rppt, surenb, mhocko, ziy, baolin.wang, npache, ryan.roberts,
dev.jain, baohua, lance.yang, yang, jannh
In-Reply-To: <930d9121-9176-4a7b-a2d7-8224f94000d3@intel.com>
On 6/9/26 21:33, Dave Hansen wrote:
> On 6/9/26 07:37, Xueyuan Chen wrote:
>> +bool __weak arch_make_pages_readonly(struct page *page, int nr_pages)
>> +{
>> + return false;
>> +}
>
> This is a rather wonky function. It's going to cause all kinds of fun if
> it is used like this:
>
> arch_make_pages_readonly(syscall_table, 1);
>
> It's also kinda weird to have it return a bool, and not check that bool
> at the single call site. Some things come to mind:
>
> 1. This function needs commenting. It needs to say what it does, when
> architectures should override it and what their implementations
> should look like. It needs to be clear that this can't be used for
> anything really important. What should architectures do with alias
> mappings? Are they allowed to touch non-direct map aliases? Are they
> required to?
Yes, kerneldoc please.
> 2. The return type needs to be reconsidered. Is 'bool' even acceptable?
> Should it just be 'void' if callers can't do anything when it fails?
> 3. What should the naming be? "readonly" vs "ro". Should it have a
> "maybe" since it's kinda optional?
We're adjusting the directmap, remapping a r/w page to be r/o. I think we should
be very clear about which transition we expect+support.
Also, I rather hate the "set_memory" naming scheme ... "set_direct_map" is
clearer. Anyhow ...
Now we are throwing a "arch_make_pages_*" into the mix.
Should it really contain the "arch"?
Should it really contain the "make" ?
Why can't we just reuse set_memory_ro and pass address+nr_pages? (highmem check?
Could that be moved in there?)
Or do we want a "change_direct_map_ro()" / "remap_direct_map_ro" interface?
> 4. Should this new API be folio or page-based in the first place?
> 5. Is mm/huge_memory.c the right place to define a generic mm function,
> even a stub?
+1
--
Cheers,
David
^ permalink raw reply
* [PATCH] Revert "ASoC: rockchip: rockchip_sai: Use guard() for spin locks"
From: Nicolas Frattaroli @ 2026-06-17 11:46 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Heiko Stuebner
Cc: bui duc phuc, linux-rockchip, linux-sound, linux-arm-kernel,
linux-kernel, kernel, Nicolas Frattaroli
This reverts commit f7fe9f7073602958d6b63cc58a144094533377fa.
This is very noisy pointless churn that was not tested by the submitter,
nor was it addressed to the driver's maintainer. It mixes unrelated
whitespace changes (eliminating the blank line between the includes -
why?) with hard to review diffs that add a whole indentation level to
the function for no benefit, while also not following kernel code style
by doing stuff like "ret == 0".
The driver is better off without these changes, and they're not worth
the time to validate whether they really do make no functional changes.
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
sound/soc/rockchip/rockchip_sai.c | 262 +++++++++++++++++++-------------------
1 file changed, 133 insertions(+), 129 deletions(-)
diff --git a/sound/soc/rockchip/rockchip_sai.c b/sound/soc/rockchip/rockchip_sai.c
index a195e96fed0a..ed393e5034a4 100644
--- a/sound/soc/rockchip/rockchip_sai.c
+++ b/sound/soc/rockchip/rockchip_sai.c
@@ -18,6 +18,7 @@
#include <sound/pcm_params.h>
#include <sound/dmaengine_pcm.h>
#include <sound/tlv.h>
+
#include "rockchip_sai.h"
#define DRV_NAME "rockchip-sai"
@@ -215,12 +216,14 @@ static void rockchip_sai_xfer_clk_stop_and_wait(struct rk_sai_dev *sai, unsigned
static int rockchip_sai_runtime_suspend(struct device *dev)
{
struct rk_sai_dev *sai = dev_get_drvdata(dev);
+ unsigned long flags;
rockchip_sai_fsync_lost_detect(sai, 0);
rockchip_sai_fsync_err_detect(sai, 0);
- scoped_guard(spinlock_irqsave, &sai->xfer_lock)
- rockchip_sai_xfer_clk_stop_and_wait(sai, NULL);
+ spin_lock_irqsave(&sai->xfer_lock, flags);
+ rockchip_sai_xfer_clk_stop_and_wait(sai, NULL);
+ spin_unlock_irqrestore(&sai->xfer_lock, flags);
regcache_cache_only(sai->regmap, true);
/*
@@ -480,6 +483,7 @@ static int rockchip_sai_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
struct rk_sai_dev *sai = snd_soc_dai_get_drvdata(dai);
unsigned int mask = 0, val = 0;
unsigned int clk_gates;
+ unsigned long flags;
int ret = 0;
pm_runtime_get_sync(dai->dev);
@@ -495,56 +499,56 @@ static int rockchip_sai_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
sai->is_master_mode = false;
break;
default:
- pm_runtime_put(dai->dev);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_pm_put;
}
- scoped_guard(spinlock_irqsave, &sai->xfer_lock) {
- rockchip_sai_xfer_clk_stop_and_wait(sai, &clk_gates);
- if (sai->initialized) {
- if (sai->has_capture && sai->has_playback)
- rockchip_sai_xfer_stop(sai, -1);
- else if (sai->has_capture)
- rockchip_sai_xfer_stop(sai, SNDRV_PCM_STREAM_CAPTURE);
- else
- rockchip_sai_xfer_stop(sai, SNDRV_PCM_STREAM_PLAYBACK);
- } else {
- rockchip_sai_clear(sai, 0);
- sai->initialized = true;
- }
+ spin_lock_irqsave(&sai->xfer_lock, flags);
+ rockchip_sai_xfer_clk_stop_and_wait(sai, &clk_gates);
+ if (sai->initialized) {
+ if (sai->has_capture && sai->has_playback)
+ rockchip_sai_xfer_stop(sai, -1);
+ else if (sai->has_capture)
+ rockchip_sai_xfer_stop(sai, SNDRV_PCM_STREAM_CAPTURE);
+ else
+ rockchip_sai_xfer_stop(sai, SNDRV_PCM_STREAM_PLAYBACK);
+ } else {
+ rockchip_sai_clear(sai, 0);
+ sai->initialized = true;
+ }
- regmap_update_bits(sai->regmap, SAI_CKR, mask, val);
-
- mask = SAI_CKR_CKP_MASK | SAI_CKR_FSP_MASK;
- switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
- case SND_SOC_DAIFMT_NB_NF:
- val = SAI_CKR_CKP_NORMAL | SAI_CKR_FSP_NORMAL;
- break;
- case SND_SOC_DAIFMT_NB_IF:
- val = SAI_CKR_CKP_NORMAL | SAI_CKR_FSP_INVERTED;
- break;
- case SND_SOC_DAIFMT_IB_NF:
- val = SAI_CKR_CKP_INVERTED | SAI_CKR_FSP_NORMAL;
- break;
- case SND_SOC_DAIFMT_IB_IF:
- val = SAI_CKR_CKP_INVERTED | SAI_CKR_FSP_INVERTED;
- break;
- default:
- ret = -EINVAL;
- break;
- }
+ regmap_update_bits(sai->regmap, SAI_CKR, mask, val);
- if (ret == 0) {
- regmap_update_bits(sai->regmap, SAI_CKR, mask, val);
- rockchip_sai_fmt_create(sai, fmt);
- }
-
- if (clk_gates)
- regmap_update_bits(sai->regmap, SAI_XFER,
- SAI_XFER_CLK_MASK | SAI_XFER_FSS_MASK,
- clk_gates);
+ mask = SAI_CKR_CKP_MASK | SAI_CKR_FSP_MASK;
+ switch (fmt & SND_SOC_DAIFMT_INV_MASK) {
+ case SND_SOC_DAIFMT_NB_NF:
+ val = SAI_CKR_CKP_NORMAL | SAI_CKR_FSP_NORMAL;
+ break;
+ case SND_SOC_DAIFMT_NB_IF:
+ val = SAI_CKR_CKP_NORMAL | SAI_CKR_FSP_INVERTED;
+ break;
+ case SND_SOC_DAIFMT_IB_NF:
+ val = SAI_CKR_CKP_INVERTED | SAI_CKR_FSP_NORMAL;
+ break;
+ case SND_SOC_DAIFMT_IB_IF:
+ val = SAI_CKR_CKP_INVERTED | SAI_CKR_FSP_INVERTED;
+ break;
+ default:
+ ret = -EINVAL;
+ goto err_xfer_unlock;
}
+ regmap_update_bits(sai->regmap, SAI_CKR, mask, val);
+
+ rockchip_sai_fmt_create(sai, fmt);
+
+err_xfer_unlock:
+ if (clk_gates)
+ regmap_update_bits(sai->regmap, SAI_XFER,
+ SAI_XFER_CLK_MASK | SAI_XFER_FSS_MASK,
+ clk_gates);
+ spin_unlock_irqrestore(&sai->xfer_lock, flags);
+err_pm_put:
pm_runtime_put(dai->dev);
return ret;
@@ -560,6 +564,7 @@ static int rockchip_sai_hw_params(struct snd_pcm_substream *substream,
unsigned int ch_per_lane, slot_width;
unsigned int val, fscr, reg;
unsigned int lanes, req_lanes;
+ unsigned long flags;
int ret = 0;
if (!rockchip_sai_stream_valid(substream, dai))
@@ -586,8 +591,8 @@ static int rockchip_sai_hw_params(struct snd_pcm_substream *substream,
dev_err(sai->dev, "not enough lanes (%d) for requested number of %s channels (%d)\n",
lanes, reg == SAI_TXCR ? "playback" : "capture",
params_channels(params));
- pm_runtime_put(sai->dev);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_pm_put;
} else {
lanes = req_lanes;
}
@@ -613,88 +618,84 @@ static int rockchip_sai_hw_params(struct snd_pcm_substream *substream,
val = SAI_XCR_VDW(32);
break;
default:
- pm_runtime_put(sai->dev);
- return -EINVAL;
+ ret = -EINVAL;
+ goto err_pm_put;
}
val |= SAI_XCR_CSR(lanes);
- scoped_guard(spinlock_irqsave, &sai->xfer_lock) {
+ spin_lock_irqsave(&sai->xfer_lock, flags);
+
+ regmap_update_bits(sai->regmap, reg, SAI_XCR_VDW_MASK | SAI_XCR_CSR_MASK, val);
- regmap_update_bits(sai->regmap, reg, SAI_XCR_VDW_MASK | SAI_XCR_CSR_MASK, val);
+ if (!sai->is_tdm)
+ regmap_update_bits(sai->regmap, reg, SAI_XCR_SBW_MASK,
+ SAI_XCR_SBW(params_physical_width(params)));
- if (!sai->is_tdm)
- regmap_update_bits(sai->regmap, reg, SAI_XCR_SBW_MASK,
- SAI_XCR_SBW(params_physical_width(params)));
+ regmap_read(sai->regmap, reg, &val);
- regmap_read(sai->regmap, reg, &val);
+ slot_width = SAI_XCR_SBW_V(val);
+ ch_per_lane = params_channels(params) / lanes;
- slot_width = SAI_XCR_SBW_V(val);
- ch_per_lane = params_channels(params) / lanes;
+ regmap_update_bits(sai->regmap, reg, SAI_XCR_SNB_MASK,
+ SAI_XCR_SNB(ch_per_lane));
- regmap_update_bits(sai->regmap, reg, SAI_XCR_SNB_MASK,
- SAI_XCR_SNB(ch_per_lane));
+ fscr = SAI_FSCR_FW(sai->fw_ratio * slot_width * ch_per_lane);
- fscr = SAI_FSCR_FW(sai->fw_ratio * slot_width * ch_per_lane);
+ switch (sai->fpw) {
+ case FPW_ONE_BCLK_WIDTH:
+ fscr |= SAI_FSCR_FPW(1);
+ break;
+ case FPW_ONE_SLOT_WIDTH:
+ fscr |= SAI_FSCR_FPW(slot_width);
+ break;
+ case FPW_HALF_FRAME_WIDTH:
+ fscr |= SAI_FSCR_FPW(sai->fw_ratio * slot_width * ch_per_lane / 2);
+ break;
+ default:
+ dev_err(sai->dev, "Invalid Frame Pulse Width %d\n", sai->fpw);
+ ret = -EINVAL;
+ goto err_xfer_unlock;
+ }
- switch (sai->fpw) {
- case FPW_ONE_BCLK_WIDTH:
- fscr |= SAI_FSCR_FPW(1);
- break;
- case FPW_ONE_SLOT_WIDTH:
- fscr |= SAI_FSCR_FPW(slot_width);
- break;
- case FPW_HALF_FRAME_WIDTH:
- fscr |= SAI_FSCR_FPW(sai->fw_ratio * slot_width * ch_per_lane / 2);
- break;
- default:
- dev_err(sai->dev, "Invalid Frame Pulse Width %d\n", sai->fpw);
+ regmap_update_bits(sai->regmap, SAI_FSCR,
+ SAI_FSCR_FW_MASK | SAI_FSCR_FPW_MASK, fscr);
+
+ if (sai->is_master_mode) {
+ bclk_rate = sai->fw_ratio * slot_width * ch_per_lane * params_rate(params);
+ ret = clk_set_rate(sai->mclk, sai->mclk_rate);
+ if (ret) {
+ dev_err(sai->dev, "Failed to set mclk to %u: %pe\n",
+ sai->mclk_rate, ERR_PTR(ret));
+ goto err_xfer_unlock;
+ }
+
+ mclk_rate = clk_get_rate(sai->mclk);
+ if (mclk_rate < bclk_rate) {
+ dev_err(sai->dev, "Mismatch mclk: %u, at least %u\n",
+ mclk_rate, bclk_rate);
ret = -EINVAL;
- break;
+ goto err_xfer_unlock;
}
- if (ret == 0) {
- regmap_update_bits(sai->regmap, SAI_FSCR,
- SAI_FSCR_FW_MASK | SAI_FSCR_FPW_MASK, fscr);
-
- if (sai->is_master_mode) {
- bclk_rate = sai->fw_ratio * slot_width *
- ch_per_lane * params_rate(params);
- ret = clk_set_rate(sai->mclk, sai->mclk_rate);
- if (ret)
- dev_err(sai->dev, "Failed to set mclk to %u: %pe\n",
- sai->mclk_rate, ERR_PTR(ret));
- else {
- mclk_rate = clk_get_rate(sai->mclk);
- if (mclk_rate < bclk_rate) {
- dev_err(sai->dev, "Mismatch mclk: %u, at least %u\n",
- mclk_rate, bclk_rate);
- ret = -EINVAL;
- } else {
-
- div_bclk = DIV_ROUND_CLOSEST(mclk_rate, bclk_rate);
- mclk_req_rate = bclk_rate * div_bclk;
-
- if (mclk_rate <
- mclk_req_rate - CLK_SHIFT_RATE_HZ_MAX ||
- mclk_rate >
- mclk_req_rate + CLK_SHIFT_RATE_HZ_MAX) {
- dev_err(sai->dev,
- "Mismatch mclk: %u, expected %u (+/- %dHz)\n",
- mclk_rate, mclk_req_rate,
- CLK_SHIFT_RATE_HZ_MAX);
- ret = -EINVAL;
- } else
- regmap_update_bits(sai->regmap,
- SAI_CKR,
- SAI_CKR_MDIV_MASK,
- SAI_CKR_MDIV(div_bclk));
- }
- }
- }
+ div_bclk = DIV_ROUND_CLOSEST(mclk_rate, bclk_rate);
+ mclk_req_rate = bclk_rate * div_bclk;
+
+ if (mclk_rate < mclk_req_rate - CLK_SHIFT_RATE_HZ_MAX ||
+ mclk_rate > mclk_req_rate + CLK_SHIFT_RATE_HZ_MAX) {
+ dev_err(sai->dev, "Mismatch mclk: %u, expected %u (+/- %dHz)\n",
+ mclk_rate, mclk_req_rate, CLK_SHIFT_RATE_HZ_MAX);
+ ret = -EINVAL;
+ goto err_xfer_unlock;
}
+
+ regmap_update_bits(sai->regmap, SAI_CKR, SAI_CKR_MDIV_MASK,
+ SAI_CKR_MDIV(div_bclk));
}
+err_xfer_unlock:
+ spin_unlock_irqrestore(&sai->xfer_lock, flags);
+err_pm_put:
pm_runtime_put(sai->dev);
return ret;
@@ -704,6 +705,7 @@ static int rockchip_sai_prepare(struct snd_pcm_substream *substream,
struct snd_soc_dai *dai)
{
struct rk_sai_dev *sai = snd_soc_dai_get_drvdata(dai);
+ unsigned long flags;
if (!rockchip_sai_stream_valid(substream, dai))
return 0;
@@ -724,12 +726,13 @@ static int rockchip_sai_prepare(struct snd_pcm_substream *substream,
* udelay falls short.
*/
udelay(20);
- scoped_guard(spinlock_irqsave, &sai->xfer_lock)
- regmap_update_bits(sai->regmap, SAI_XFER,
- SAI_XFER_CLK_MASK |
- SAI_XFER_FSS_MASK,
- SAI_XFER_CLK_EN |
- SAI_XFER_FSS_EN);
+ spin_lock_irqsave(&sai->xfer_lock, flags);
+ regmap_update_bits(sai->regmap, SAI_XFER,
+ SAI_XFER_CLK_MASK |
+ SAI_XFER_FSS_MASK,
+ SAI_XFER_CLK_EN |
+ SAI_XFER_FSS_EN);
+ spin_unlock_irqrestore(&sai->xfer_lock, flags);
}
rockchip_sai_fsync_lost_detect(sai, 1);
@@ -912,6 +915,7 @@ static int rockchip_sai_set_tdm_slot(struct snd_soc_dai *dai,
int slots, int slot_width)
{
struct rk_sai_dev *sai = snd_soc_dai_get_drvdata(dai);
+ unsigned long flags;
unsigned int clk_gates;
int sw = slot_width;
@@ -927,16 +931,16 @@ static int rockchip_sai_set_tdm_slot(struct snd_soc_dai *dai,
return -EINVAL;
pm_runtime_get_sync(dai->dev);
- scoped_guard(spinlock_irqsave, &sai->xfer_lock) {
- rockchip_sai_xfer_clk_stop_and_wait(sai, &clk_gates);
- regmap_update_bits(sai->regmap, SAI_TXCR, SAI_XCR_SBW_MASK,
- SAI_XCR_SBW(sw));
- regmap_update_bits(sai->regmap, SAI_RXCR, SAI_XCR_SBW_MASK,
- SAI_XCR_SBW(sw));
- regmap_update_bits(sai->regmap, SAI_XFER,
- SAI_XFER_CLK_MASK | SAI_XFER_FSS_MASK,
- clk_gates);
- }
+ spin_lock_irqsave(&sai->xfer_lock, flags);
+ rockchip_sai_xfer_clk_stop_and_wait(sai, &clk_gates);
+ regmap_update_bits(sai->regmap, SAI_TXCR, SAI_XCR_SBW_MASK,
+ SAI_XCR_SBW(sw));
+ regmap_update_bits(sai->regmap, SAI_RXCR, SAI_XCR_SBW_MASK,
+ SAI_XCR_SBW(sw));
+ regmap_update_bits(sai->regmap, SAI_XFER,
+ SAI_XFER_CLK_MASK | SAI_XFER_FSS_MASK,
+ clk_gates);
+ spin_unlock_irqrestore(&sai->xfer_lock, flags);
pm_runtime_put(dai->dev);
return 0;
---
base-commit: 5b33fc6492a7b7a62359157db0f92f5b6e9af690
change-id: 20260617-sai-revert-8f7ba19962cb
Best regards,
--
Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
^ permalink raw reply related
* Re: [PATCH 1/9] dt-bindings: nvmem: imx-ocotp: Add support for secure-enclave
From: Frieder Schrempf @ 2026-06-17 11:36 UTC (permalink / raw)
To: Krzysztof Kozlowski, Frieder Schrempf
Cc: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260617-prodigious-private-inchworm-beae1e@quoll>
On 17.06.26 12:49, Krzysztof Kozlowski wrote:
> On Tue, Jun 16, 2026 at 01:52:16PM +0200, Frieder Schrempf wrote:
>> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>>
>> Some SoCs like the i.MX9 family allow full access to the fuses only
>> through the secure enclave firmware API. Add a property to reference
>> the secure enclave node and let the driver use the API.
>>
>> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
>> ---
>> Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
>> index a8076d0e2737..14a6429f4a4c 100644
>> --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
>> +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
>> @@ -53,6 +53,10 @@ properties:
>> reg:
>> maxItems: 1
>>
>> + secure-enclave:
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + description: A phandle to the secure enclave node
>
> Two things here:
> 1. Here you describe what for is that phandle, how it is used by the
> hardware. Currently the description repeats the property name and type,
> so not much useful.
Ok, agree.
>
> 2. If you access OTP via firmware, then this is completely different
> interface than MMIO, thus:
> A. reg is not appropriate
> B. Device is very different thus it has different compatible and I even
> claim should be in different binding. Devices having completely
> different SW interface should not be in the same binding, at least
> usually.
>
> If any of above is not accurate, then your commit msg should answer why
> and give some background.
Thanks for the feedback!
The driver currently uses the limited MMIO (FSB) interface to access the
OTPs. The intention is to support the firmware interface alongside the
MMIO interface so the driver can pick the interface that is available
(firmware might not be loaded) and fallback to MMIO.
Following your argument would mean a driver deciding by itself which
interface to use at runtime is not something we want to have in general,
right?
In turn this would mean we need two drivers, or at least two
compatibles/bindings for something that is effectively the same hardware.
Actually, my first RFC approach [1] was to create a separate driver. But
in the end it seemed very weird to have two drivers and two DT nodes for
the same hardware block. Also I have no idea what happens if both
interfaces are used at the same time.
The other idea from back then was to replace the MMIO (FSB) interface
with ELE, but this would mean that we rely on the proprietary ELE
firmware to be available for simple things like reading a MAC address,
which is not desirable either, I guess.
In which direction should I move on with this?
[1]
https://patchwork.kernel.org/project/linux-arm-kernel/patch/20250416142715.1042363-1-frieder@fris.de/
^ permalink raw reply
* Re: [PATCH net 4/4] net: ti: icssg: Fix XSK zero copy TX during application wakeup
From: Meghana Malladi @ 2026-06-17 11:31 UTC (permalink / raw)
To: Jakub Kicinski
Cc: diogo.ivo, haokexin, vadim.fedorenko, devnexen, horms,
jacob.e.keller, sdf, john.fastabend, hawk, daniel, ast, pabeni,
edumazet, davem, andrew+netdev, bpf, linux-kernel, netdev,
linux-arm-kernel, srk, Vignesh Raghavendra, Roger Quadros,
danishanwar
In-Reply-To: <20260616081954.0d12aa13@kernel.org>
On 6/16/26 20:49, Jakub Kicinski wrote:
> On Tue, 16 Jun 2026 16:41:00 +0530 Meghana Malladi wrote:
>> On 6/16/26 04:51, Jakub Kicinski wrote:
>>> On Fri, 12 Jun 2026 00:27:44 +0530 Meghana Malladi wrote:
>>>> @@ -169,9 +169,6 @@ static int emac_xsk_xmit_zc(struct prueth_emac *emac,
>>>>
>>>> num_tx++;
>>>> }
>>>> -
>>>> - xsk_tx_release(tx_chn->xsk_pool);
>>>> - return num_tx;
>>>
>>> Why are you deleting this?
>>>
>>
>> xsk_sendmsg() also calls this without an rcu-lock when transmitting the
>> packets if the xmit was successful, so I was assuming it is not required
>> and I removed this.
>
> I think you still need it. Besides, seems like a separate cleanup.
>
Okay, I will add it back then.
>>>> void prueth_xmit_free(struct prueth_tx_chn *tx_chn,
>>>> @@ -279,9 +276,6 @@ int emac_tx_complete_packets(struct prueth_emac *emac, int chn,
>>>> num_tx++;
>>>> }
>>>>
>>>> - if (!num_tx)
>>>> - return 0;
>>>
>>> Does something prevent us from running all this code if budget is 0?
>>> If budget is 0 we can complete normal Tx with skbs but we must
>>> not touch any AF-XDP related state.
>>
>> Can you elaborate more, I couldn't interpret your comment here
>
> netpoll may call napi from any context, including from IRQ.
> It uses budget of 0 to indicate that it's trying to only reap tx
> completions, without doing any Rx or XDP work. XDPs can't be called
> from IRQ context.
>
Ah I wasn't aware of this, I will add a check to ensure AF_XDP runs only
when budget > 0 then.
>>>> netif_txq = netdev_get_tx_queue(ndev, chn);
>>>> netdev_tx_completed_queue(netif_txq, num_tx, total_bytes);
>>>>
>>>> @@ -306,7 +300,9 @@ int emac_tx_complete_packets(struct prueth_emac *emac, int chn,
>>>>
>>>> netif_txq = netdev_get_tx_queue(ndev, chn);
>>>> txq_trans_cond_update(netif_txq);
>>>
>>> This looks misplaced, now we will hit it even if we didn't complete
>>> or submit any Tx.
>>
>> This code needs to be hit for packet transmission in zero copy mode.
>> emac_xsk_xmit_zc() submits the packets to the DMA in NAPI context,
>> when application wakes up the driver and triggers NAPI. Once DMA
>> transfer is done, irq gets triggered NAPI gets called which will handle
>> the tx packet completion + submit next Tx batch packets to the DMA.
>>
>> if (tx_chn->xsk_pool) -> check ensure this hits and runs for zero copy
>> only. Also above check (!num_tx) returns early during the application
>> wakeup (where budget is zero), hence it is removed.
>
> I'm commenting on txq_trans_cond_update(), you're calling it
> effectively on every NAPI call when XSK is bound, whether
> Tx is making progress or not.
Ok got it, but I wonder if it will hurt in anyway to call this even when
there are no Tx completions.
Nonetheless, I will move this inside xsk_frames_done check.
^ permalink raw reply
* Re: [PATCH net-next v7 2/2] net: ti: icssg-prueth: Add ethtool ops for Frame Preemption MAC Merge
From: Meghana Malladi @ 2026-06-17 11:25 UTC (permalink / raw)
To: MD Danish Anwar, Jakub Kicinski
Cc: elfring, haokexin, vadim.fedorenko, devnexen, horms,
jacob.e.keller, arnd, basharath, afd, parvathi, vladimir.oltean,
rogerq, pabeni, edumazet, davem, andrew+netdev, linux-arm-kernel,
netdev, linux-kernel, srk, vigneshr
In-Reply-To: <a62d5243-d641-48e7-a1f5-88150513be48@ti.com>
On 6/17/26 10:58, MD Danish Anwar wrote:
> Meghana,
>
> On 16/06/26 6:24 pm, Meghana Malladi wrote:
>> Hi Jakub,
>>
>> On 6/16/26 05:09, Jakub Kicinski wrote:
>>> On Mon, 15 Jun 2026 16:10:41 -0700 Jakub Kicinski wrote:
>>>>> diff --git a/drivers/net/ethernet/ti/icssg/icssg_stats.h b/drivers/
>>>>> net/ethernet/ti/icssg/icssg_stats.h
>>>>> index 5ec0b38e0c67..8073deac35c3 100644
>>>>> --- a/drivers/net/ethernet/ti/icssg/icssg_stats.h
>>>>> +++ b/drivers/net/ethernet/ti/icssg/icssg_stats.h
>>>>> @@ -189,6 +187,11 @@ static const struct icssg_pa_stats
>>>>> icssg_all_pa_stats[] = {
>>>>> ICSSG_PA_STATS(FW_INF_DROP_PRIOTAGGED),
>>>>> ICSSG_PA_STATS(FW_INF_DROP_NOTAG),
>>>>> ICSSG_PA_STATS(FW_INF_DROP_NOTMEMBER),
>>>>> + ICSSG_PA_STATS(FW_PREEMPT_BAD_FRAG),
>>>>> + ICSSG_PA_STATS(FW_PREEMPT_ASSEMBLY_ERR),
>>>>> + ICSSG_PA_STATS(FW_PREEMPT_FRAG_CNT_TX),
>>>>> + ICSSG_PA_STATS(FW_PREEMPT_ASSEMBLY_OK),
>>>>> + ICSSG_PA_STATS(FW_PREEMPT_FRAG_CNT_RX),
>>>>> ICSSG_PA_STATS(FW_RX_EOF_SHORT_FRMERR),
>>>>> ICSSG_PA_STATS(FW_RX_B0_DROP_EARLY_EOF),
>>>>> ICSSG_PA_STATS(FW_TX_JUMBO_FRM_CUTOFF),
>>>>
>>>> [Medium]
>>>> Are these five new entries duplicating values that already have a
>>>> standard uAPI?
>>>>
>>>> The same five firmware counters are exposed through the new
>>>> .get_mm_stats callback as the standardized MAC Merge stats
>>>> (MACMergeFrameAssOkCount, MACMergeFrameAssErrorCount,
>>>> MACMergeFragCountRx,
>>>> MACMergeFragCountTx, MACMergeFrameSmdErrorCount in struct
>>>> ethtool_mm_stats), and adding them to icssg_all_pa_stats[] also
>>>> publishes them via emac_get_strings() / emac_get_ethtool_stats() as
>>>> ethtool -S strings.
>>>>
>>>> Documentation/networking/statistics.rst describes ethtool -S as the
>>>> private-driver-stats interface; counters that have a standard uAPI are
>>>> expected to flow only through that uAPI.
>>>>
>>>> Could the firmware-register lookup table used by emac_get_stat_by_name()
>>>> be separated from the ethtool -S string table, so the new preemption
>>>> counters feed get_mm_stats without also showing up under ethtool -S?
>>>
>>> This -- not sure about the other complaints but this one looks legit.
>>
>> I agree that this is legit, but right now there is no other place holder
>> other than pa stats to put the mac merge firmware counters. I believe
>
> You can put a boolean is_standard_stats. Only those where
> is_standard_stats=false will be populated via ethtool. Others will be
> populated via the standard interface.
>
> Look at icssg_miig_stats for reference.
>
Sure, since you were already doing some refactoring w.r.t HSR standard
stats I thought this could also be covered there.
I will send out another version addressing this then.
>> the effort needs to go in re-structuring the hardware and firmware stats
>> implementation to address this issue.
>>
>
^ permalink raw reply
* Re: [PATCH v2 0/3] ASoC: rockchip: Use guard() for spin locks
From: Nicolas Frattaroli @ 2026-06-17 11:24 UTC (permalink / raw)
To: Heiko Stuebner, Liam Girdwood, phucduc.bui, Mark Brown
Cc: Nicolas Frattaroli, Jaroslav Kysela, Takashi Iwai, linux-sound,
linux-rockchip, linux-arm-kernel, linux-kernel
In-Reply-To: <178120760640.484538.12942087225448845771.b4-ty@b4>
On Thursday, 11 June 2026 21:53:26 Central European Summer Time Mark Brown wrote:
> On Thu, 04 Jun 2026 10:35:50 +0700, phucduc.bui@gmail.com wrote:
> > ASoC: rockchip: Use guard() for spin locks
> >
> > From: bui duc phuc <phucduc.bui@gmail.com>
> >
> > Hi all,
> >
> > This series converts spinlock handling in the Rockchip sound drivers
> > to use guard() helpers.
> > The changes are code cleanup only and should have no functional impact.
> >
> > [...]
>
> Applied to
>
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.2
>
> Thanks!
FWIW, the SAI patch wasn't sent to the proper maintainer e-mail
for it which is why I didn't notice this series at all until now,
and the whole thing is pointless churn that wasn't even tested.
From a cursory glance, whatever LLM was pointed at this and decided
to make the output my problem also didn't do a good job, the scoped
indentation of rockchip_sai_runtime_suspend seems pointless because
it could've been replaced by a pm guard followed by a spinlock guard,
without an additional level of indentation, and `if (ret == 0) {` is
not kernel style.
It's not worth the revert but it sucks that I have to now set up a
new lei search for all the drivers I am supposed to receive mail for
because vibecoders can't be bothered to run get_maintainers as they
pad their CV with nonsense like this.
>
> [1/3] ASoC: rockchip: rockchip_i2s: Use guard() for spin locks
> https://git.kernel.org/broonie/sound/c/4bda5af16920
> [2/3] ASoC: rockchip: i2s-tdm: Use guard() for spin locks
> https://git.kernel.org/broonie/sound/c/ec22437fc41a
> [3/3] ASoC: rockchip: rockchip_sai: Use guard() for spin locks
> https://git.kernel.org/broonie/sound/c/f7fe9f707360
>
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.
>
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
>
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
>
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
>
> Thanks,
> Mark
>
>
>
^ permalink raw reply
* Re: [PATCH v3 2/7] gpio: regmap: add gpio_regmap_get_gpiochip() accessor
From: Michael Walle @ 2026-06-17 11:19 UTC (permalink / raw)
To: Yu-Chun Lin [林祐君], Bartosz Golaszewski,
Andy Shevchenko
Cc: linusw@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, afaerber@suse.com, wbg@kernel.org,
mathieu.dubois-briand@bootlin.com, lars@metafoo.de,
Michael.Hennerich@analog.com, jic23@kernel.org,
nuno.sa@analog.com, andy@kernel.org, dlechner@baylibre.com,
TY_Chang[張子逸], linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org, linux-iio@vger.kernel.org,
CY_Huang[黃鉦晏],
Stanley Chang[昌育德],
James Tai [戴志峰]
In-Reply-To: <61c053a5a8e6461f9e6fcd40b6b5064d@realtek.com>
[-- Attachment #1: Type: text/plain, Size: 2246 bytes --]
Hi,
On Wed Jun 17, 2026 at 11:54 AM CEST, Yu-Chun Lin [林祐君] wrote:
> Hi Michael,
>
>> Hi,
>>
>> On Wed Jun 17, 2026 at 10:36 AM CEST, Yu-Chun Lin [林祐君] wrote:
>>>>>>> Without an accessor like gpio_regmap_get_gpiochip(), we cannot
>>>>>>> retrieve the gpio_chip instantiated inside gpio-regmap.c to
>>>>>>> fulfill these requirements in our
>>>>>>> map() function.
>>>>
>>>> Why is gpiochip_irq_reqres() called in the first place? Isn't that
>>>> only called if the irq handling is set up via gc->irq.chip and not
>>>> via
>>>> gpiochip_irqchip_add_domain() like in gpio-regmap?
>>>>
>>>
>>> The panic was caused by my driver including
>>> 'GPIOCHIP_IRQ_RESOURCE_HELPERS', which forced the call to 'gpiochip_irq_reqres()' and crashed.
>>
>> But why did you use it if your irq domain isn't managed by the gpiolib, but rather your own >irq domain? Before going with option #3 I'd double check if that is correct in your driver.
>>
>> -michael
>
> Do you mean that a custom IRQ domain shouldn't be mixed with gpiolib features like
> 'GPIOCHIP_IRQ_RESOURCE_HELPERS'?
Honestly, I'm not sure. I've never done anything with irq domains
except for using the regmap_irq_chip. But from what I can tell is
that GPIOCHIP_IRQ_RESOURCE_HELPERS are tied to the handling with
gc->irq.chip, which isn't used at all if you add the domain via
gpiochip_irqchip_add_domain(). Please correct me if I'm wrong
though.
-michael
> Additional information: our GPIO controller receives 3 separate interrupt lines.
> Because the standard 'regmap_irq_chip' mechanism in 'gpio-regmap' does not support
> this multi-line hardware design, we are forced to create our own IRQ domain and pass
> it via 'config->irq_domain'.
>
> Given this constraint (that we must use our own IRQ domain), are you suggesting
> that we should implement our own 'irq_request_resources' and
> 'irq_release_resources' callbacks instead of relying on
> 'GPIOCHIP_IRQ_RESOURCE_HELPERS'?
>
> But if that is the case, we would much prefer to let the core gpiolib handle
> these resource and state management tasks for us *as proposed in option 3), rather
> than duplicating the effort in our driver.
>
> Best Regards,
> Yu-Chun
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]
^ permalink raw reply
* Re: [PATCH v9 9/9] perf test: Add Arm CoreSight callchain test
From: Leo Yan @ 2026-06-17 11:11 UTC (permalink / raw)
To: James Clark
Cc: linux-arm-kernel, coresight, linux-perf-users,
Arnaldo Carvalho de Melo, John Garry, Will Deacon, Mike Leach,
Suzuki K Poulose, Namhyung Kim, Mark Rutland, Alexander Shishkin,
Jiri Olsa, Ian Rogers, Adrian Hunter, Al Grant, Paschalis Mpeis,
Amir Ayupov
In-Reply-To: <00183ce3-e387-4ca3-9eb8-67aa6a1221e5@linaro.org>
On Wed, Jun 17, 2026 at 09:38:42AM +0100, James Clark wrote:
[...]
> > +noinline void callchain_do_syscall(void)
> > +{
> > + syscall(SYS_getpid);
>
> I get this error when compiling for x86, but it works on Arm:
>
> tests/workloads/callchain.c:17:10: error: use of undeclared identifier
> 'SYS_getpid'; did you mean '__getpgid'?
> syscall(SYS_getpid);
> ^~~~~~~~~~
> __getpgid
> /usr/include/unistd.h:659:16: note: '__getpgid' declared here
> extern __pid_t __getpgid (__pid_t __pid) __THROW;
Thanks for finding this.
This is not the issue for program itself actually, it contains
tools/arch/x86/include/uapi/asm/unistd_64.h rather than uAPI headers
provided in toolchain or kernel.
At current stage, we can simply change to syscall(SYS_gettid) to
workaround the issue.
^ permalink raw reply
* Re: [PATCH v3] clk: mvebu: ap-cpu: fix missing clk_put() in ap_cpu_clock_probe()
From: Brian Masney @ 2026-06-17 11:00 UTC (permalink / raw)
To: Wentao Liang
Cc: andrew, gregory.clement, sebastian.hesselbarth, mturquette, sboyd,
linux-arm-kernel, linux-clk, linux-kernel
In-Reply-To: <20260617014126.1716291-1-vulab@iscas.ac.cn>
On Wed, Jun 17, 2026 at 01:41:26AM +0000, Wentao Liang wrote:
> The function ap_cpu_clock_probe() calls of_clk_get() to obtain a
> reference to the parent clock for each CPU cluster, but it never
> releases it with clk_put(). The returned clk is used only to read
> the parent's name via __clk_get_name(), and the reference is leaked
> on every successful cluster initialization as well as on the error
> path when devm_clk_hw_register() fails.
>
> Rather than adding clk_put() calls, replace the of_clk_get() +
> __clk_get_name() pattern with of_clk_get_parent_name(), which is
> the intended API for this use case and handles the reference
> counting internally. This matches the pattern already used by the
> sibling drivers clk-cpu.c and clk-corediv.c.
>
> Fixes: f756e362d9384 ("clk: mvebu: add CPU clock driver for Armada 7K/8K")
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
Reviewed-by: Brian Masney <bmasney@redhat.com>
For the future, if someone leaves a tag like Reviewed-by, or Tested-by,
then include it with your next version, unless something major changes
with the code. Don't post another version since Stephen's automation
will pick up my tag when he merges this.
Brian
^ permalink raw reply
* Re: [PATCH 15/78] ASoC: codecs: cs42l43: Use guard() for mutex locks
From: Charles Keepax @ 2026-06-17 10:57 UTC (permalink / raw)
To: phucduc.bui
Cc: Mark Brown, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Cheng-Yi Chiang, Tzung-Bi Shih, Guenter Roeck, Benson Leung,
David Rhodes, Richard Fitzgerald, povik+lin, Support Opensource,
Nick Li, Herve Codina, Srinivas Kandagatla, Matthias Brugger,
AngeloGioacchino Del Regno, Shenghao Ding, Kevin Lu, Baojun Xu,
Sen Wang, Oder Chiou, Lars-Peter Clausen, nuno.sa, Steven Eckhoff,
patches, chrome-platform, asahi, linux-arm-msm, linux-sound,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260617103235.449609-16-phucduc.bui@gmail.com>
On Wed, Jun 17, 2026 at 05:31:32PM +0700, phucduc.bui@gmail.com wrote:
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> Clean up the code using guard() for mutex locks.
> Merely code refactoring, and no behavior change.
>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
> @@ -913,17 +908,13 @@ int cs42l43_jack_put(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *u
> if (override >= e->items)
> return -EINVAL;
>
> - mutex_lock(&priv->jack_lock);
> + guard(mutex)(&priv->jack_lock);
I believe you have to use scoped_guard here, as there is a return
from the function above, if memory serves it attempts to release
the mutex on that path despite it being above the guard.
Be worth having a quick scan through the rest of the series for
this as well.
Thanks,
Charles
^ 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