* Re: [PATCH 2/3] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Marek Vasut @ 2026-06-18 2:50 UTC (permalink / raw)
To: Marc Zyngier, Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Rob Herring, devicetree, linux-arm-kernel, linux-doc,
linux-kernel, linux-renesas-soc
In-Reply-To: <864ij1tyrj.wl-maz@kernel.org>
On 6/17/26 9:24 AM, Marc Zyngier wrote:
Hello Marc,
>> Renesas R-Car S4/V4H/V4M GIC600 integration has address width for AXI
>> or APB interface configured to 32 bit, it can therefore access only
>> the first 4 GiB of physical address space. This information comes from
>> R-Car V4H Interface Specification sheet, there is currently no technical
>> update number assigned to this limitation. Further input from hardware
>> engineer indicates that this limitation also applies to R-Car S4 and V4M.
>> Name the limitation GEN4GICITS1, and add a driver quirk to mitigate this
>> limitation.
My concern is this ^ , I do not have an erratum number, because there
isn't one. I am in touch with the hardware engineer and I did get a
glimpse at internal details of the three SoC, which confirm the
limitations. Is this sufficient ?
>> Note that the 0x0201743b GIC600 ID is not Renesas-specific, it is
>> common for many ARM GICv3 implementations. Therefore, add an extra
>
> Not quite. It designates GIC600 unambiguously.
What I am trying to communicate is, that the 0x0201743b ID is not ID of
the Renesas GIC implementation, but it is a generic ARM GIC600 ID. That
is why we cannot match the quirk on the ID (it is generic ARM GIC600
ID), and instead we have to match the quirk on the [ ID combined with
of_machine_is_compatible("renesas,...") ].
> It is just that GIC600
> is integrated in zillions of SoCs, most of which don't have this
> problem (the machine I'm typing this from has a GIC600 *and* 96GB of
> RAM).
Right.
Shall I reword this paragraph somehow to make it clearer ?
>> of_machine_is_compatible() check.
>>
>> The GIC600 implementation in R-Car S4/V4H/V4M is r1p6.
>
> Is this relevant?
I included it for the sake of completeness and to provide all relevant
information, based on previous discussions about similar limitations
that I could find on lore.k.o
[...]
>> +#ifdef CONFIG_RENESAS_ERRATUM_GEN4GICITS1
>> + {
>> + .desc = "ITS: Renesas R-Car Gen4 GIC600 32-bit limit",
>> + .iidr = 0x0201743b,
>> + .mask = 0xffffffff,
>> + .init = its_enable_renesas_gen4,
>> + },
>> #endif
>> {
>> }
>
>
> Honestly, that's a bit too much copy-paste for my taste. Just refactor
> the erratum handling to be more generic, something like this:
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index 291d7668cc8da..380c4758647d2 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -4894,10 +4894,17 @@ static bool __maybe_unused its_enable_quirk_hip09_162100801(void *data)
> return true;
> }
>
> -static bool __maybe_unused its_enable_rk3568002(void *data)
> +static const char * const dma_impaired_platforms[] = {
> +#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
> + "rockchip,rk3566",
> + "rockchip,rk3568",
> +#endif
> + NULL,
> +};
> +
> +static bool __maybe_unused its_enable_dma32(void *data)
> {
> - if (!of_machine_is_compatible("rockchip,rk3566") &&
> - !of_machine_is_compatible("rockchip,rk3568"))
> + if (!of_machine_compatible_match(dma_impaired_platforms))
> return false;
>
> gfp_flags_quirk |= GFP_DMA32;
> @@ -4972,14 +4979,12 @@ static const struct gic_quirk its_quirks[] = {
> .property = "dma-noncoherent",
> .init = its_set_non_coherent,
> },
> -#ifdef CONFIG_ROCKCHIP_ERRATUM_3568002
> {
> - .desc = "ITS: Rockchip erratum RK3568002",
> + .desc = "ITS: Broken GIC600 integration limited to 32bit PA",
> .iidr = 0x0201743b,
> .mask = 0xffffffff,
> - .init = its_enable_rk3568002,
> + .init = its_enable_dma32,
> },
> -#endif
> {
> }
> };
>
> Then add the two lines you need in a separate patch.
Will do in V2.
> In the future, please provide a cover letter when you have more than a
> single patch (git will happily generate one for you).
OK
^ permalink raw reply
* Re: [PATCH 1/3] PCI: rcar-gen4: Configure AXIINTC if iMSI-RX not used
From: Marek Vasut @ 2026-06-18 2:21 UTC (permalink / raw)
To: Geert Uytterhoeven, Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Marc Zyngier, Rob Herring, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <CAMuHMdU0SJ0q2hcpu+qZCH3eZ5eFDyo8Z964h9DhuSaQ7QdHSg@mail.gmail.com>
On 6/17/26 10:26 AM, Geert Uytterhoeven wrote:
Hello Geert,
>> +static void rcar_gen4_pcie_host_msi_init(struct dw_pcie_rp *pp)
>> +{
>> + struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
>> + struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
>> + u32 val;
>> +
>> + /* Make sure MSICAP0 MSIE is configured. */
>> + val = dw_pcie_readl_dbi(dw, MSICAP0);
>> + if (pci_msi_enabled())
>> + val |= MSICAP0_MSIE;
>> + else
>> + val &= ~MSICAP0_MSIE;
>> + dw_pcie_writel_dbi(dw, MSICAP0, val);
>> +
>> + if (!pci_msi_enabled() || pp->use_imsi_rx) {
>> + /* Clear AXIINTC mapping. */
>> + writel(0, rcar->base + AXIINTCADDR);
>> + writel(0, rcar->base + AXIINTCCONT);
>> + } else {
>> + /* Point AXIINTC to GIC ITS and enable. */
>> + writel(AXIINTCADDR_VAL, rcar->base + AXIINTCADDR);
>> + writel(INTC_EN | INTC_MASK, rcar->base + AXIINTCCONT);
>> + }
>> +
>> + /* Configure MSI interrupt signal */
>> + val = readl(rcar->base + PCIEINTSTS0EN);
>> + if (pci_msi_enabled())
>> + val |= MSI_CTRL_INT;
>> + else
>> + val &= ~MSI_CTRL_INT;
>> + writel(val, rcar->base + PCIEINTSTS0EN);
>> +}
>> +
>> static int rcar_gen4_pcie_enable_device(struct pci_host_bridge *bridge,
>
> FTR, this has a contextual dependency on "[PATCH v2] PCI: rcar-gen4:
> Limit Max_Read_Request_Size and Max_Payload_Size to 256 Bytes"
> (https://lore.kernel.org/all/20260519195219.189323-1-marek.vasut+renesas@mailbox.org).
It is not an explicit dependency, I only had these patches in my tree
and clearly that was an interaction. I'll rebase this dependency out for V2.
Thanks!
--
Best regards,
Marek Vasut
^ permalink raw reply
* Re: [PATCH v6 03/20] dma-direct: use DMA_ATTR_CC_SHARED in alloc/free paths
From: Alexey Kardashevskiy @ 2026-06-18 2:39 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Aneesh Kumar K.V (Arm), iommu, linux-arm-kernel, linux-kernel,
linux-coco, Robin Murphy, Marek Szyprowski, Will Deacon,
Marc Zyngier, Steven Price, Suzuki K Poulose, Catalin Marinas,
Jiri Pirko, Mostafa Saleh, Petr Tesarik, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86, Jiri Pirko,
Michael Kelley, Cheloha, Scott
In-Reply-To: <20260617154101.GE3577091@ziepe.ca>
On 18/6/26 01:41, Jason Gunthorpe wrote:
> On Wed, Jun 17, 2026 at 10:50:39AM +1000, Alexey Kardashevskiy wrote:
>>> @@ -193,16 +193,31 @@ void *dma_direct_alloc(struct device *dev, size_t size,
>>> dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
>>> {
>>> bool remap = false, set_uncached = false;
>>> - bool mark_mem_decrypt = true;
>>> + bool mark_mem_decrypt = false;
>>> struct page *page;
>>> void *ret;
>>> + /*
>>> + * DMA_ATTR_CC_SHARED is not a caller-visible dma_alloc_*()
>>> + * attribute. The direct allocator uses it internally after it has
>>> + * decided that the backing pages must be shared/decrypted, so the
>>> + * rest of the allocation path can consistently select DMA addresses,
>>> + * choose compatible pools and restore encryption on free.
>>
>> Why this limit?
>>
>> Context: I am looking for a memory pool for a few shared pages (to
>> do some guest<->host communication), SWIOTLB seems like the right
>> fit but swiotlb_alloc() is not exported and
>> dma_direct_alloc(DMA_ATTR_CC_SHARED) is not allowed. Thanks,
>
> Then setup your struct device so that the DMA API knows the
> guest<->host channel requires unecrypted and it will work correctly.
>
> I think this is a reasonable API to use for that, and I was just
> advocating that hyperv should be using it too.
>
> But it all relies on a properly setup struct device.
Sounds good but how do I do that in practice? DMA_ATTR_CC_SHARED is not externally available so I'll have to trick the DMA layer into using SWIOTLB (which is still all shared, right?) as I specifically want to skip page conversions. Setting low DMA mask won't guarantee that the DMA layer won't allocate a page outside of SWIOTLB and convert it. Manually do
dev->dma_io_tlb_mem->force_bounce = true;
dev->dma_io_tlb_mem->for_allow = true;
?
Or follow the Aneesh'es genpool approach? Thanks,
>
> Jason
--
Alexey
^ permalink raw reply
* Question: SPEAr PLGPIO irq_enable on PREEMPT_RT and regmap updates
From: Runyu Xiao @ 2026-06-18 2:34 UTC (permalink / raw)
To: Viresh Kumar, Linus Walleij
Cc: Sebastian Andrzej Siewior, Clark Williams, Steven Rostedt,
linux-arm-kernel, soc, linux-gpio, linux-rt-devel, linux-kernel,
jianhao.xu, runyu.xiao
Hi,
While auditing GPIO/pinctrl irqchip callbacks, our static analysis tool
flagged the SPEAr PLGPIO irq_enable path, and we manually reviewed it
against the current tree.
The path is:
irq_startup()
-> plgpio_irq_enable()
-> gpiochip_enable_irq()
-> spin_lock_irqsave(&plgpio->lock)
-> plgpio_reg_reset()
-> regmap_update_bits()
On PREEMPT_RT, plgpio->lock is a regular spinlock_t and can become a
sleeping lock. Since irq_enable/irq_disable can be called from IRQ
management paths while the IRQ descriptor raw lock is held, taking that
regular spinlock there looks unsafe.
A minimal Lockdep reproducer preserving this irq_chip::irq_enable carrier
reports:
BUG: sleeping function called from invalid context
irqs_disabled(): 1
plgpio_rt_spin_lock_irqsave
plgpio_irq_enable
request_threaded_irq_probe_path
My first thought was to convert the PLGPIO register lock to
raw_spinlock_t. However, that does not seem sufficient because the IE/EIT
updates go through regmap_update_bits()/regmap_read()/regmap_write(). For
the syscon/MMIO regmap used here, regmap may still take its own regular
fast-IO lock unless the regmap was created with use_raw_spinlock. So a
raw_spinlock_t conversion in the PLGPIO driver alone may just move the
PREEMPT_RT problem one level down into regmap.
The repair I am considering is to keep the gpiolib resource updates in
the fast irq_enable/irq_disable callbacks, but defer the actual PLGPIO
IE/EIT register writes to irq_bus_sync_unlock(), after the IRQ core has
dropped desc->lock. The driver would keep per-line shadow state for:
- IRQ disabled/enabled state
- pending IE update
- edge direction state
- pending EIT update
and then synchronize those shadow updates from irq_bus_sync_unlock()
under a mutex.
In other words, the fast callbacks would only update local shadow state
and call gpiochip_enable_irq()/gpiochip_disable_irq(), while the sleepable
regmap writes would be batched into the irq bus sync phase.
Does that sound like an acceptable direction for SPEAr PLGPIO, or would
you prefer a different fix, such as changing the underlying syscon regmap
locking model or handling only the IE register path?
The draft patch I have locally is roughly:
pinctrl: spear: defer PLGPIO IRQ updates to bus sync
and it changes only drivers/pinctrl/spear/pinctrl-plgpio.c.
Thanks,
Runyu
^ permalink raw reply
* [PATCH v2] nvme-apple: Use acquire/release for queue enabled state
From: Gui-Dong Han @ 2026-06-18 2:15 UTC (permalink / raw)
To: sven, kbusch, linux-nvme
Cc: axboe, hch, sagi, j, neal, asahi, linux-kernel, linux-arm-kernel,
baijiaju1990, Gui-Dong Han
apple_nvme_init_queue() initializes queue state and then marks the queue
enabled. The interrupt and request paths check enabled before using that
queue state.
The old wmb() after WRITE_ONCE(enabled, true) does not publish the
earlier initialization before enabled becomes visible. Use a release store
when enabling the queue and acquire loads when testing it.
Although the shutdown-side enabled accesses are not used for publishing
queue initialization, use helpers for them as well for consistency.
Fixes: 5bd2927aceba ("nvme-apple: Add initial Apple SoC NVMe driver")
Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com>
---
v2:
- Drop the old wmb(), as suggested by Keith Busch.
- Use the queue enabled helpers in apple_nvme_disable(), as suggested by
Keith Busch.
v1:
- Found by auditing READ_ONCE() used for synchronization.
- A similar fix can be found in 8df672bfe3ec.
---
drivers/nvme/host/apple.c | 30 +++++++++++++++++++++++-------
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/drivers/nvme/host/apple.c b/drivers/nvme/host/apple.c
index f9327feb87d0..291271c3954b 100644
--- a/drivers/nvme/host/apple.c
+++ b/drivers/nvme/host/apple.c
@@ -151,6 +151,23 @@ struct apple_nvme_queue {
bool enabled;
};
+static inline bool apple_nvme_queue_enabled(struct apple_nvme_queue *q)
+{
+ /* Pair with apple_nvme_enable_queue(). */
+ return smp_load_acquire(&q->enabled);
+}
+
+static inline void apple_nvme_enable_queue(struct apple_nvme_queue *q)
+{
+ /* Publish queue initialization before setting q->enabled. */
+ smp_store_release(&q->enabled, true);
+}
+
+static inline void apple_nvme_disable_queue(struct apple_nvme_queue *q)
+{
+ WRITE_ONCE(q->enabled, false);
+}
+
/*
* The apple_nvme_iod describes the data in an I/O.
*
@@ -677,7 +694,7 @@ static bool apple_nvme_handle_cq(struct apple_nvme_queue *q, bool force)
bool found;
DEFINE_IO_COMP_BATCH(iob);
- if (!READ_ONCE(q->enabled) && !force)
+ if (!apple_nvme_queue_enabled(q) && !force)
return false;
found = apple_nvme_poll_cq(q, &iob);
@@ -780,7 +797,7 @@ static blk_status_t apple_nvme_queue_rq(struct blk_mq_hw_ctx *hctx,
* We should not need to do this, but we're still using this to
* ensure we can drain requests on a dying queue.
*/
- if (unlikely(!READ_ONCE(q->enabled)))
+ if (unlikely(!apple_nvme_queue_enabled(q)))
return BLK_STS_IOERR;
if (!nvme_check_ready(&anv->ctrl, req, true))
@@ -863,7 +880,7 @@ static void apple_nvme_disable(struct apple_nvme *anv, bool shutdown)
nvme_quiesce_io_queues(&anv->ctrl);
if (!dead) {
- if (READ_ONCE(anv->ioq.enabled)) {
+ if (apple_nvme_queue_enabled(&anv->ioq)) {
apple_nvme_remove_sq(anv);
apple_nvme_remove_cq(anv);
}
@@ -887,8 +904,8 @@ static void apple_nvme_disable(struct apple_nvme *anv, bool shutdown)
nvme_disable_ctrl(&anv->ctrl, false);
}
- WRITE_ONCE(anv->ioq.enabled, false);
- WRITE_ONCE(anv->adminq.enabled, false);
+ apple_nvme_disable_queue(&anv->ioq);
+ apple_nvme_disable_queue(&anv->adminq);
mb(); /* ensure that nvme_queue_rq() sees that enabled is cleared */
nvme_quiesce_admin_queue(&anv->ctrl);
@@ -1016,8 +1033,7 @@ static void apple_nvme_init_queue(struct apple_nvme_queue *q)
memset(q->tcbs, 0, anv->hw->max_queue_depth
* sizeof(struct apple_nvmmu_tcb));
memset(q->cqes, 0, depth * sizeof(struct nvme_completion));
- WRITE_ONCE(q->enabled, true);
- wmb(); /* ensure the first interrupt sees the initialization */
+ apple_nvme_enable_queue(q);
}
static void apple_nvme_reset_work(struct work_struct *work)
--
2.34.1
^ permalink raw reply related
* [PATCH v4] dmaengine: sun6i-dma: Fix memory leak in sun6i_dma_terminate_all
From: Hongling Zeng @ 2026-06-18 2:06 UTC (permalink / raw)
To: vkoul, Frank.Li, wens, jernej.skrabec, samuel, mripard, arnd
Cc: dmaengine, linux-arm-kernel, linux-sunxi, linux-kernel,
zhongling0719, Hongling Zeng, Frank Li
When terminating DMA transfers, active descriptors are not properly
reclaimed. Only cyclic descriptors were handled, leaving non-cyclic
descriptors and their LLI chains to be permanently leaked.
Fix by using vchan_terminate_vdesc() which handles both cyclic and
non-cyclic descriptors by adding them to desc_terminated queue for
proper cleanup.
Add pchan->desc != pchan->done check to prevent double-adding completed
descriptors, which would corrupt the list.
Fixes: 555859308723 ("dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller")
Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Suggested-by: Frank Li <Frank.li@oss.nxp.com>
---
Change in v2;
-Add pchan->desc != pchan->done check to prevent race condition
where completed descriptors could be double-added to desc_completed
list, causing list corruption
---
Change in v3:
-Fix by using vchan_terminate_vdesc() as suggested by Frank Li
---
Change in v4:
-Correct the commit message
---
drivers/dma/sun6i-dma.c | 13 +++++--------
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
index 7a79f346250a..134ae840f176 100644
--- a/drivers/dma/sun6i-dma.c
+++ b/drivers/dma/sun6i-dma.c
@@ -946,16 +946,13 @@ static int sun6i_dma_terminate_all(struct dma_chan *chan)
spin_lock_irqsave(&vchan->vc.lock, flags);
- if (vchan->cyclic) {
- vchan->cyclic = false;
- if (pchan && pchan->desc) {
- struct virt_dma_desc *vd = &pchan->desc->vd;
- struct virt_dma_chan *vc = &vchan->vc;
-
- list_add_tail(&vd->node, &vc->desc_completed);
- }
+ if (pchan && pchan->desc && pchan->desc != pchan->done) {
+ struct virt_dma_desc *vd = &pchan->desc->vd;
+
+ vchan_terminate_vdesc(vd);
}
+ vchan->cyclic = false;
vchan_get_all_descriptors(&vchan->vc, &head);
if (pchan) {
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v3 01/10] mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()
From: Peng Fan @ 2026-06-18 1:57 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: linux-remoteproc, imx, linux-arm-kernel, linux-rt-devel,
Bjorn Andersson, Clark Williams, Fabio Estevam, Frank Li,
Jassi Brar, Mathieu Poirier, Pengutronix Kernel Team,
Sascha Hauer, Steven Rostedt
In-Reply-To: <ajNO3KSZV/elWONW@shlinux89>
On Thu, Jun 18, 2026 at 09:50:20AM +0800, Peng Fan wrote:
>Hi Sebastian,
>
>Thanks for your patch.
>
>On Wed, Jun 17, 2026 at 08:55:26AM +0200, Sebastian Andrzej Siewior wrote:
>>imx_mu_generic_tx() for the IMX_MU_TYPE_TXDB_V2 type polls on a register
>>which may timeout and is recognized as an error. This error is siltently
>>dropped and not dropped to the caller.
>>
>>Forward the error to the caller.
>>
>>Fixes: b5ef17917f3a7 ("mailbox: imx: fix TXDB_V2 channel race condition")
>>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>>---
>> drivers/mailbox/imx-mailbox.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>>diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
>>index 246a9a9e39520..0028073be4a71 100644
>>--- a/drivers/mailbox/imx-mailbox.c
>>+++ b/drivers/mailbox/imx-mailbox.c
>>@@ -227,6 +227,7 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
>> u32 val;
>> int ret, count;
>>
>>+ ret = 0;
>> switch (cp->type) {
>> case IMX_MU_TYPE_TX:
>> imx_mu_write(priv, *arg, priv->dcfg->xTR + cp->idx * 4);
>>@@ -259,7 +260,7 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
>> return -EINVAL;
>> }
>>
>>- return 0;
>>+ return ret;
>> }
>
>I just rethink about the logic here and rewrite the logic as below.
>error code is propogated to caller and poll timeout are removed.
>Please see whether it looks good for you or not.
Ignore this. Pushed the button too early
>
>[PATCH] mailbox: imx: make TXDB non-blocking and avoid polling in atomic context
>
>+
> imx_mu_write(priv, IMX_MU_xCR_GIRn(priv->dcfg->type, cp->idx),
> priv->dcfg->xCR[IMX_MU_GCR]);
Oh. there might be issues without waiting here. For example, Linux just writes
the doorbell to notify SCMI processor power up a power domain, but when linux
continues to write registers, the SCMI processor may not fetch the message, then
linux will crash.
Regards
Peng
>- ret = -ETIMEDOUT;
>- count = 0;
>- while (ret && (count < 10)) {
>- ret =
>- readl_poll_timeout(priv->base + priv->dcfg->xCR[IMX_MU_GCR], val,
>- !(val & IMX_MU_xCR_GIRn(priv->dcfg->type, cp->idx)),
>- 0, 10000);
>-
>- if (ret) {
>- dev_warn_ratelimited(priv->dev,
>- "channel type: %d timeout, %d times, retry\n",
>- cp->type, ++count);
>- }
>- }
> break;
> default:
> dev_warn_ratelimited(priv->dev, "Send data on wrong channel type: %d\n", cp->type);
>--
>2.50.1
>
>Thanks,
>Peng
>
>>
>> static int imx_mu_generic_rx(struct imx_mu_priv *priv,
>>
>>--
>>2.53.0
>>
>
>
^ permalink raw reply
* Re: [PATCH v7 15/20] perf: arm_pmuv3: Handle IRQs for Partitioned PMU guest counters
From: wuyifan @ 2026-06-18 1:53 UTC (permalink / raw)
To: Colton Lewis, kvm
Cc: Alexandru Elisei, Paolo Bonzini, Jonathan Corbet, Russell King,
Catalin Marinas, Will Deacon, Marc Zyngier, Oliver Upton,
Mingwei Zhang, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Mark Rutland, Shuah Khan, Ganapatrao Kulkarni, James Clark,
linux-doc, linux-kernel, linux-arm-kernel, kvmarm,
linux-perf-users, linux-kselftest, wangyushan, Zhou Wang, xuwei5,
prime.zeng, fanghao11
In-Reply-To: <20260504211813.1804997-16-coltonlewis@google.com>
Hi Colton,
On 5/5/2026 5:18 AM, Colton Lewis wrote:
> static irqreturn_t armv8pmu_handle_irq(struct arm_pmu *cpu_pmu)
> {
> - u64 pmovsr;
> struct perf_sample_data data;
> struct pmu_hw_events *cpuc = this_cpu_ptr(cpu_pmu->hw_events);
> struct pt_regs *regs;
> + u64 host_set = kvm_pmu_host_counter_mask(cpu_pmu);
> + u64 pmovsr;
kvm_pmu_host_counter_mask() is called from armv8pmu_handle_irq(). This
interrupt fires in both host and guest contexts.
However, kvm_pmu_host_counter_mask() dereferences
host_data_ptr(nr_event_counters). This indirection requires
kvm_arm_hyp_percpu_base[cpu] to be initialized, which only happens during
KVM hypervisor setup. When the interrupt fires in a guest kernel where
KVM is
compiled but not active, the per-CPU base is NULL and the dereference
faults.
Thanks,
Yifan
^ permalink raw reply
* Re: [PATCH v1] mfd: mt6397-irq: Fix PM notifier use-after-free
From: 최유호 @ 2026-06-18 1:53 UTC (permalink / raw)
To: Lee Jones
Cc: Matthias Brugger, AngeloGioacchino Del Regno, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <20260617152615.GO10056@google.com>
On Wed, 17 Jun 2026 at 11:26, Lee Jones <lee@kernel.org> wrote:
> [Severity: High]
> Is it safe to explicitly remove the IRQ domain here while the devm-managed
> parent threaded IRQ remains active?
>
> The parent IRQ was requested earlier via devm_request_threaded_irq(). Because
> devres cleanup does not run until the probe function completely fails and
> returns, the parent IRQ remains active and enabled during this window.
>
> If an interrupt triggers during this error path, the active IRQ handler
> mt6397_irq_thread() will execute and call mt6397_irq_handle_reg(). This in
> turn calls irq_find_mapping(), which will dereference the freed irq_domain,
> resulting in a use-after-free.
Thanks for pointing this out. Findings 1 and 3 look like pre-existing
issues. Finding 2, however, appears to be related to the error-path cleanup
I added.
I will rework the patch so the notifier and irq_domain cleanup ordering is
handled consistently.
^ permalink raw reply
* Re: [PATCH v3 01/10] mailbox: imx: Forward the timeout/ error in imx_mu_generic_tx()
From: Peng Fan @ 2026-06-18 1:50 UTC (permalink / raw)
To: Sebastian Andrzej Siewior
Cc: linux-remoteproc, imx, linux-arm-kernel, linux-rt-devel,
Bjorn Andersson, Clark Williams, Fabio Estevam, Frank Li,
Jassi Brar, Mathieu Poirier, Pengutronix Kernel Team,
Sascha Hauer, Steven Rostedt
In-Reply-To: <20260617-imx_mbox_rproc-v3-1-77948112defc@linutronix.de>
Hi Sebastian,
Thanks for your patch.
On Wed, Jun 17, 2026 at 08:55:26AM +0200, Sebastian Andrzej Siewior wrote:
>imx_mu_generic_tx() for the IMX_MU_TYPE_TXDB_V2 type polls on a register
>which may timeout and is recognized as an error. This error is siltently
>dropped and not dropped to the caller.
>
>Forward the error to the caller.
>
>Fixes: b5ef17917f3a7 ("mailbox: imx: fix TXDB_V2 channel race condition")
>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>---
> drivers/mailbox/imx-mailbox.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
>index 246a9a9e39520..0028073be4a71 100644
>--- a/drivers/mailbox/imx-mailbox.c
>+++ b/drivers/mailbox/imx-mailbox.c
>@@ -227,6 +227,7 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
> u32 val;
> int ret, count;
>
>+ ret = 0;
> switch (cp->type) {
> case IMX_MU_TYPE_TX:
> imx_mu_write(priv, *arg, priv->dcfg->xTR + cp->idx * 4);
>@@ -259,7 +260,7 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
> return -EINVAL;
> }
>
>- return 0;
>+ return ret;
> }
I just rethink about the logic here and rewrite the logic as below.
error code is propogated to caller and poll timeout are removed.
Please see whether it looks good for you or not.
[PATCH] mailbox: imx: make TXDB non-blocking and avoid polling in atomic context
The IMX_MU_TYPE_TXDB_V2 path currently writes to the GIR register and
then polls until the bit is cleared using readl_poll_timeout().
Because send_data() is invoked under spin_lock_irqsave() from the mailbox
core, meaning the polling loop can run in atomic context with interrupts
disabled. In the worst case, the current implementation may busy-wait for
up to 100ms, leading to excessive interrupt latency and potential soft
lockup warnings.
Moreover, the TXDB channel implements a doorbell mechanism, where the
sender only needs to trigger the event when the channel is idle. Waiting
for the GIR bit to clear after the write is no good with polling.
Fix this by:
- Checking the GIR bit before issuing the write
- Returning -EBUSY if the channel is still active
- Removing the post-write polling loop
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
drivers/mailbox/imx-mailbox.c | 21 ++++++---------------
1 file changed, 6 insertions(+), 15 deletions(-)
diff --git a/drivers/mailbox/imx-mailbox.c b/drivers/mailbox/imx-mailbox.c
index 796ba983db29e..ed53bcffec673 100644
--- a/drivers/mailbox/imx-mailbox.c
+++ b/drivers/mailbox/imx-mailbox.c
@@ -241,7 +241,6 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
{
u32 *arg = data;
u32 val;
- int ret, count;
switch (cp->type) {
case IMX_MU_TYPE_TX:
@@ -253,22 +252,14 @@ static int imx_mu_generic_tx(struct imx_mu_priv *priv,
queue_work(system_bh_wq, &cp->txdb_work);
break;
case IMX_MU_TYPE_TXDB_V2:
+ val = readl(priv->base + priv->dcfg->xCR[IMX_MU_GCR]);
+ if (val & IMX_MU_xCR_GIRn(priv->dcfg->type, cp->idx)) {
+ dev_info(priv->dev, "channel [%d] type: %d busy\n", cp->idx, cp->type);
+ return -EBUSY;
+ }
+
imx_mu_write(priv, IMX_MU_xCR_GIRn(priv->dcfg->type, cp->idx),
priv->dcfg->xCR[IMX_MU_GCR]);
- ret = -ETIMEDOUT;
- count = 0;
- while (ret && (count < 10)) {
- ret =
- readl_poll_timeout(priv->base + priv->dcfg->xCR[IMX_MU_GCR], val,
- !(val & IMX_MU_xCR_GIRn(priv->dcfg->type, cp->idx)),
- 0, 10000);
-
- if (ret) {
- dev_warn_ratelimited(priv->dev,
- "channel type: %d timeout, %d times, retry\n",
- cp->type, ++count);
- }
- }
break;
default:
dev_warn_ratelimited(priv->dev, "Send data on wrong channel type: %d\n", cp->type);
--
2.50.1
Thanks,
Peng
>
> static int imx_mu_generic_rx(struct imx_mu_priv *priv,
>
>--
>2.53.0
>
^ permalink raw reply related
* RE: [PATCH v4 3/5] dt-bindings: clock: cix,sky1-audss-clock: add audss clock controller
From: Joakim Zhang @ 2026-06-18 1:43 UTC (permalink / raw)
To: Conor Dooley
Cc: mturquette@baylibre.com, sboyd@kernel.org, bmasney@redhat.com,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
p.zabel@pengutronix.de, Gary Yang, cix-kernel-upstream,
linux-clk@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20260617-clinic-blank-61289f8fc1c2@spud>
Hello,
> -----Original Message-----
> From: Conor Dooley <conor@kernel.org>
> Sent: Wednesday, June 17, 2026 11:56 PM
> To: Joakim Zhang <joakim.zhang@cixtech.com>
> Cc: mturquette@baylibre.com; sboyd@kernel.org; bmasney@redhat.com;
> robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org;
> p.zabel@pengutronix.de; Gary Yang <gary.yang@cixtech.com>; cix-kernel-
> upstream <cix-kernel-upstream@cixtech.com>; linux-clk@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [PATCH v4 3/5] dt-bindings: clock: cix,sky1-audss-clock: add audss
> clock controller
>
> On Wed, Jun 17, 2026 at 02:04:35PM +0800, joakim.zhang@cixtech.com wrote:
> > From: Joakim Zhang <joakim.zhang@cixtech.com>
> >
> > The AUDSS CRU contains an internal clock tree of muxes, dividers and
> > gates for DSP, I2S, HDA, DMAC and related blocks. The clock provider
> > is a child node of the cix,sky1-audss-system-control syscon and
> > accesses registers through the parent MMIO region.
>
> Why can this not just be part of the parent syscon node?
The clock and reset blocks are handled by different subsystems and maintainers (clk vs reset). Putting the clock provider on the parent syscon node would mean a single driver has to register both the reset controller and the clock provider on one device, which doesn't fit well.
Thanks,
Joakim
^ permalink raw reply
* RE: [PATCH v4 1/5] dt-bindings: soc: cix,sky1-system-control: add audss system control
From: Joakim Zhang @ 2026-06-18 1:38 UTC (permalink / raw)
To: Conor Dooley, krzk+dt@kernel.org
Cc: mturquette@baylibre.com, sboyd@kernel.org, bmasney@redhat.com,
robh@kernel.org, conor+dt@kernel.org, p.zabel@pengutronix.de,
Gary Yang, cix-kernel-upstream, linux-clk@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20260617-chummy-automatic-6c11e9958bbf@spud>
Hello,
> -----Original Message-----
> From: Conor Dooley <conor@kernel.org>
> Sent: Wednesday, June 17, 2026 11:54 PM
> To: Joakim Zhang <joakim.zhang@cixtech.com>
> Cc: mturquette@baylibre.com; sboyd@kernel.org; bmasney@redhat.com;
> robh@kernel.org; krzk+dt@kernel.org; conor+dt@kernel.org;
> p.zabel@pengutronix.de; Gary Yang <gary.yang@cixtech.com>; cix-kernel-
> upstream <cix-kernel-upstream@cixtech.com>; linux-clk@vger.kernel.org;
> devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-arm-
> kernel@lists.infradead.org
> Subject: Re: [PATCH v4 1/5] dt-bindings: soc: cix,sky1-system-control: add audss
> system control
>
> On Wed, Jun 17, 2026 at 02:04:33PM +0800, joakim.zhang@cixtech.com wrote:
> > From: Joakim Zhang <joakim.zhang@cixtech.com>
> >
> > The Cix Sky1 Audio Subsystem (AUDSS) groups audio-related clock, reset
> > and control registers in a dedicated CRU block. Software reset lines
> > are exposed on the syscon parent via #reset-cells, following the same
> > model as the existing Sky1 FCH and S5 system control bindings.
> >
> > A clock-controller child node is required under the audss syscon. It
> > has no reg property of its own and accesses the parent register block
> > for mux, divider and gate fields.
> >
> > The AUDSS is also controlled by one power domain and reset part.
> >
> > Signed-off-by: Joakim Zhang <joakim.zhang@cixtech.com>
> > ---
> > .../soc/cix/cix,sky1-system-control.yaml | 48 +++++++++++++++++++
> > .../reset/cix,sky1-audss-system-control.h | 25 ++++++++++
> > 2 files changed, 73 insertions(+)
> > create mode 100644
> > include/dt-bindings/reset/cix,sky1-audss-system-control.h
> >
> > diff --git
> > a/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.ya
> > ml
> > b/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.ya
> > ml index a01a515222c6..5a1cd5c24ade 100644
> > ---
> > a/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-control.ya
> > ml
> > +++ b/Documentation/devicetree/bindings/soc/cix/cix,sky1-system-contro
> > +++ l.yaml
> > @@ -19,6 +19,7 @@ properties:
> > - enum:
> > - cix,sky1-system-control
> > - cix,sky1-s5-system-control
> > + - cix,sky1-audss-system-control
> > - const: syscon
>
> If the only thing these share are being a reset controller and having a syscon
> fallback, I think it should be in a different file.
>
Thanks for the review. I'll split the AUDSS bindings into a separate YAML file.
One follow-up: should the AUDSS CRU driver be split out as well? I'm inclined to do that, so each binding maps to its own driver, but wanted to check whether you'd prefer a separate audss reset driver or keeping everything in reset-sky1 before I rework the series.
Hello @krzk+dt@kernel.org, what's your opinion?
Thanks,
Joakim
^ permalink raw reply
* [linusw-nomadik:ux500-power-domains-v7.1 6/11] include/linux/mfd/dbx500-prcmu.h:408:19: error: redefinition of 'prcmu_abb_read'
From: kernel test robot @ 2026-06-18 1:30 UTC (permalink / raw)
To: Linus Walleij; +Cc: oe-kbuild-all, linux-arm-kernel
tree: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git ux500-power-domains-v7.1
head: b2481ed07ce2ef552c0104079bdcde6d532ec16b
commit: a5269e25e37c9ec0e13756f8fc3d109eaa291721 [6/11] pmdomain: st: ux500: Control DB8500 EPODs
config: sh-allyesconfig (https://download.01.org/0day-ci/archive/20260618/202606180825.vUSQntkJ-lkp@intel.com/config)
compiler: sh4-linux-gcc (GCC) 16.1.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260618/202606180825.vUSQntkJ-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202606180825.vUSQntkJ-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from drivers/pmdomain/st/ste-ux500-pm-domain.c:13:
>> include/linux/mfd/dbx500-prcmu.h:408:19: error: redefinition of 'prcmu_abb_read'
408 | static inline int prcmu_abb_read(u8 slave, u8 reg, u8 *value, u8 size)
| ^~~~~~~~~~~~~~
In file included from include/linux/mfd/dbx500-prcmu.h:212:
include/linux/mfd/db8500-prcmu.h:638:19: note: previous definition of 'prcmu_abb_read' with type 'int(u8, u8, u8 *, u8)' {aka 'int(unsigned char, unsigned char, unsigned char *, unsigned char)'}
638 | static inline int prcmu_abb_read(u8 slave, u8 reg, u8 *value, u8 size)
| ^~~~~~~~~~~~~~
>> include/linux/mfd/dbx500-prcmu.h:413:19: error: redefinition of 'prcmu_abb_write'
413 | static inline int prcmu_abb_write(u8 slave, u8 reg, u8 *value, u8 size)
| ^~~~~~~~~~~~~~~
include/linux/mfd/db8500-prcmu.h:643:19: note: previous definition of 'prcmu_abb_write' with type 'int(u8, u8, u8 *, u8)' {aka 'int(unsigned char, unsigned char, unsigned char *, unsigned char)'}
643 | static inline int prcmu_abb_write(u8 slave, u8 reg, u8 *value, u8 size)
| ^~~~~~~~~~~~~~~
>> include/linux/mfd/dbx500-prcmu.h:424:19: error: redefinition of 'prcmu_config_clkout'
424 | static inline int prcmu_config_clkout(u8 clkout, u8 source, u8 div)
| ^~~~~~~~~~~~~~~~~~~
include/linux/mfd/db8500-prcmu.h:608:19: note: previous definition of 'prcmu_config_clkout' with type 'int(u8, u8, u8)' {aka 'int(unsigned char, unsigned char, unsigned char)'}
608 | static inline int prcmu_config_clkout(u8 clkout, u8 source, u8 div)
| ^~~~~~~~~~~~~~~~~~~
>> include/linux/mfd/dbx500-prcmu.h:486:19: error: redefinition of 'prcmu_ac_wake_req'
486 | static inline int prcmu_ac_wake_req(void)
| ^~~~~~~~~~~~~~~~~
include/linux/mfd/db8500-prcmu.h:648:19: note: previous definition of 'prcmu_ac_wake_req' with type 'int(void)'
648 | static inline int prcmu_ac_wake_req(void)
| ^~~~~~~~~~~~~~~~~
>> include/linux/mfd/dbx500-prcmu.h:491:20: error: redefinition of 'prcmu_ac_sleep_req'
491 | static inline void prcmu_ac_sleep_req(void) {}
| ^~~~~~~~~~~~~~~~~~
include/linux/mfd/db8500-prcmu.h:653:20: note: previous definition of 'prcmu_ac_sleep_req' with type 'void(void)'
653 | static inline void prcmu_ac_sleep_req(void) {}
| ^~~~~~~~~~~~~~~~~~
vim +/prcmu_abb_read +408 include/linux/mfd/dbx500-prcmu.h
fea799e3d3ab84a Mattias Nilsson 2011-08-12 407
fea799e3d3ab84a Mattias Nilsson 2011-08-12 @408 static inline int prcmu_abb_read(u8 slave, u8 reg, u8 *value, u8 size)
fea799e3d3ab84a Mattias Nilsson 2011-08-12 409 {
fea799e3d3ab84a Mattias Nilsson 2011-08-12 410 return -ENOSYS;
fea799e3d3ab84a Mattias Nilsson 2011-08-12 411 }
fea799e3d3ab84a Mattias Nilsson 2011-08-12 412
fea799e3d3ab84a Mattias Nilsson 2011-08-12 @413 static inline int prcmu_abb_write(u8 slave, u8 reg, u8 *value, u8 size)
fea799e3d3ab84a Mattias Nilsson 2011-08-12 414 {
fea799e3d3ab84a Mattias Nilsson 2011-08-12 415 return -ENOSYS;
fea799e3d3ab84a Mattias Nilsson 2011-08-12 416 }
fea799e3d3ab84a Mattias Nilsson 2011-08-12 417
3c3e489831b601e Mattias Nilsson 2012-03-08 418 static inline int prcmu_abb_write_masked(u8 slave, u8 reg, u8 *value, u8 *mask,
3c3e489831b601e Mattias Nilsson 2012-03-08 419 u8 size)
3c3e489831b601e Mattias Nilsson 2012-03-08 420 {
3c3e489831b601e Mattias Nilsson 2012-03-08 421 return -ENOSYS;
3c3e489831b601e Mattias Nilsson 2012-03-08 422 }
3c3e489831b601e Mattias Nilsson 2012-03-08 423
fea799e3d3ab84a Mattias Nilsson 2011-08-12 @424 static inline int prcmu_config_clkout(u8 clkout, u8 source, u8 div)
fea799e3d3ab84a Mattias Nilsson 2011-08-12 425 {
fea799e3d3ab84a Mattias Nilsson 2011-08-12 426 return 0;
fea799e3d3ab84a Mattias Nilsson 2011-08-12 427 }
fea799e3d3ab84a Mattias Nilsson 2011-08-12 428
fea799e3d3ab84a Mattias Nilsson 2011-08-12 429 static inline int prcmu_request_clock(u8 clock, bool enable)
fea799e3d3ab84a Mattias Nilsson 2011-08-12 430 {
fea799e3d3ab84a Mattias Nilsson 2011-08-12 431 return 0;
6b6fae2b890826c Mattias Nilsson 2012-01-13 432 }
6b6fae2b890826c Mattias Nilsson 2012-01-13 433
6b6fae2b890826c Mattias Nilsson 2012-01-13 434 static inline long prcmu_round_clock_rate(u8 clock, unsigned long rate)
6b6fae2b890826c Mattias Nilsson 2012-01-13 435 {
6b6fae2b890826c Mattias Nilsson 2012-01-13 436 return 0;
6b6fae2b890826c Mattias Nilsson 2012-01-13 437 }
6b6fae2b890826c Mattias Nilsson 2012-01-13 438
6b6fae2b890826c Mattias Nilsson 2012-01-13 439 static inline int prcmu_set_clock_rate(u8 clock, unsigned long rate)
6b6fae2b890826c Mattias Nilsson 2012-01-13 440 {
6b6fae2b890826c Mattias Nilsson 2012-01-13 441 return 0;
6b6fae2b890826c Mattias Nilsson 2012-01-13 442 }
6b6fae2b890826c Mattias Nilsson 2012-01-13 443
6b6fae2b890826c Mattias Nilsson 2012-01-13 444 static inline unsigned long prcmu_clock_rate(u8 clock)
6b6fae2b890826c Mattias Nilsson 2012-01-13 445 {
6b6fae2b890826c Mattias Nilsson 2012-01-13 446 return 0;
fea799e3d3ab84a Mattias Nilsson 2011-08-12 447 }
fea799e3d3ab84a Mattias Nilsson 2011-08-12 448
fea799e3d3ab84a Mattias Nilsson 2011-08-12 449 static inline int prcmu_set_ape_opp(u8 opp)
fea799e3d3ab84a Mattias Nilsson 2011-08-12 450 {
fea799e3d3ab84a Mattias Nilsson 2011-08-12 451 return 0;
fea799e3d3ab84a Mattias Nilsson 2011-08-12 452 }
fea799e3d3ab84a Mattias Nilsson 2011-08-12 453
fea799e3d3ab84a Mattias Nilsson 2011-08-12 454 static inline int prcmu_get_ape_opp(void)
fea799e3d3ab84a Mattias Nilsson 2011-08-12 455 {
fea799e3d3ab84a Mattias Nilsson 2011-08-12 456 return APE_100_OPP;
fea799e3d3ab84a Mattias Nilsson 2011-08-12 457 }
fea799e3d3ab84a Mattias Nilsson 2011-08-12 458
686f871b7109e7e Ulf Hansson 2012-09-24 459 static inline int prcmu_request_ape_opp_100_voltage(bool enable)
686f871b7109e7e Ulf Hansson 2012-09-24 460 {
686f871b7109e7e Ulf Hansson 2012-09-24 461 return 0;
686f871b7109e7e Ulf Hansson 2012-09-24 462 }
686f871b7109e7e Ulf Hansson 2012-09-24 463
fea799e3d3ab84a Mattias Nilsson 2011-08-12 464 static inline int prcmu_set_arm_opp(u8 opp)
fea799e3d3ab84a Mattias Nilsson 2011-08-12 465 {
fea799e3d3ab84a Mattias Nilsson 2011-08-12 466 return 0;
fea799e3d3ab84a Mattias Nilsson 2011-08-12 467 }
fea799e3d3ab84a Mattias Nilsson 2011-08-12 468
fea799e3d3ab84a Mattias Nilsson 2011-08-12 469 static inline int prcmu_get_arm_opp(void)
fea799e3d3ab84a Mattias Nilsson 2011-08-12 470 {
fea799e3d3ab84a Mattias Nilsson 2011-08-12 471 return ARM_100_OPP;
fea799e3d3ab84a Mattias Nilsson 2011-08-12 472 }
fea799e3d3ab84a Mattias Nilsson 2011-08-12 473
fea799e3d3ab84a Mattias Nilsson 2011-08-12 474 static inline int prcmu_get_ddr_opp(void)
fea799e3d3ab84a Mattias Nilsson 2011-08-12 475 {
fea799e3d3ab84a Mattias Nilsson 2011-08-12 476 return DDR_100_OPP;
fea799e3d3ab84a Mattias Nilsson 2011-08-12 477 }
fea799e3d3ab84a Mattias Nilsson 2011-08-12 478
fea799e3d3ab84a Mattias Nilsson 2011-08-12 479 static inline void prcmu_system_reset(u16 reset_code) {}
fea799e3d3ab84a Mattias Nilsson 2011-08-12 480
fea799e3d3ab84a Mattias Nilsson 2011-08-12 481 static inline u16 prcmu_get_reset_code(void)
fea799e3d3ab84a Mattias Nilsson 2011-08-12 482 {
fea799e3d3ab84a Mattias Nilsson 2011-08-12 483 return 0;
fea799e3d3ab84a Mattias Nilsson 2011-08-12 484 }
fea799e3d3ab84a Mattias Nilsson 2011-08-12 485
5261e101198e7ef Arun Murthy 2012-05-21 @486 static inline int prcmu_ac_wake_req(void)
5261e101198e7ef Arun Murthy 2012-05-21 487 {
5261e101198e7ef Arun Murthy 2012-05-21 488 return 0;
5261e101198e7ef Arun Murthy 2012-05-21 489 }
fea799e3d3ab84a Mattias Nilsson 2011-08-12 490
fea799e3d3ab84a Mattias Nilsson 2011-08-12 @491 static inline void prcmu_ac_sleep_req(void) {}
fea799e3d3ab84a Mattias Nilsson 2011-08-12 492
:::::: The code at line 408 was first introduced by commit
:::::: fea799e3d3ab84ac675de7e48a13a79fb76b6e63 mfd: Create a common interface for dbx500 PRCMU drivers
:::::: TO: Mattias Nilsson <mattias.i.nilsson@stericsson.com>
:::::: CC: Samuel Ortiz <sameo@linux.intel.com>
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH v2 4/4] irqchip/gic-v3-its: some minor improvement in comments
From: Kemeng Shi @ 2026-06-18 1:14 UTC (permalink / raw)
To: maz, tglx; +Cc: linux-arm-kernel, linux-kernel, shikemeng
In-Reply-To: <20260618011459.58347-1-shikemeng@huaweicloud.com>
1. "If it some" -> "If some"
2. "by table by reading" -> by reading"
3. "reading bit at offset '62'" -> "reading GITS_BASER_INDIRECT"
Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
---
drivers/irqchip/irq-gic-v3-its.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 449e2cfd0c99..5bc8bba733dd 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -163,7 +163,7 @@ struct event_lpi_map {
/*
* The ITS view of a device - belongs to an ITS, owns an interrupt
- * translation table, and a list of interrupts. If it some of its
+ * translation table, and a list of interrupts. If some of its
* LPIs are injected into a guest (GICv4), the event_map.vm field
* indicates which one.
*/
@@ -2504,7 +2504,7 @@ static bool its_parse_indirect_baser(struct its_node *its,
if ((esz << ids) > (psz * 2)) {
/*
* Find out whether hw supports a single or two-level table by
- * table by reading bit at offset '62' after writing '1' to it.
+ * reading GITS_BASER_INDIRECT after writing '1' to it.
*/
its_write_baser(its, baser, val | GITS_BASER_INDIRECT);
indirect = !!(baser->val & GITS_BASER_INDIRECT);
--
2.33.0
^ permalink raw reply related
* [PATCH v2 1/4] irqchip/gic-v3-its: Fix memleak in its_probe_one()
From: Kemeng Shi @ 2026-06-18 1:14 UTC (permalink / raw)
To: maz, tglx; +Cc: linux-arm-kernel, linux-kernel, shikemeng
In-Reply-To: <20260618011459.58347-1-shikemeng@huaweicloud.com>
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 | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 291d7668cc8d..d721b6101e0a 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -5326,7 +5326,7 @@ static int __init its_probe_one(struct its_node *its)
err = its_init_domain(its);
if (err)
- goto out_free_tables;
+ goto out_free_col;
raw_spin_lock(&its_lock);
list_add(&its->entry, &its_nodes);
@@ -5334,6 +5334,8 @@ static int __init its_probe_one(struct its_node *its)
return 0;
+out_free_col:
+ kfree(its->collections);
out_free_tables:
its_free_tables(its);
out_free_cmd:
--
2.33.0
^ permalink raw reply related
* [PATCH v2 3/4] irqchip/gic-v3-its: Add ITS address info in more error logs
From: Kemeng Shi @ 2026-06-18 1:14 UTC (permalink / raw)
To: maz, tglx; +Cc: linux-arm-kernel, linux-kernel, shikemeng
In-Reply-To: <20260618011459.58347-1-shikemeng@huaweicloud.com>
We have a lot of logs containing ITS address info which is helpful to
distiguish which ITS occurs error. Just add ITS address info into more
exsiting error logs.
Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
---
drivers/irqchip/irq-gic-v3-its.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 3e4edcb64065..449e2cfd0c99 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -1120,7 +1120,7 @@ static struct its_cmd_block *its_allocate_entry(struct its_node *its)
while (its_queue_full(its)) {
count--;
if (!count) {
- pr_err_ratelimited("ITS queue not draining\n");
+ pr_err_ratelimited("ITS@%pa queue not draining\n", &its->phys_base);
return NULL;
}
cpu_relax();
@@ -1196,8 +1196,8 @@ static int its_wait_for_range_completion(struct its_node *its,
count--;
if (!count) {
- pr_err_ratelimited("ITS queue timeout (%llu %llu)\n",
- to_idx, linear_idx);
+ pr_err_ratelimited("ITS@%pa queue timeout (%llu %llu)\n",
+ &its->phys_base, to_idx, linear_idx);
return -1;
}
prev_idx = rd_idx;
@@ -1244,7 +1244,7 @@ post: \
raw_spin_unlock_irqrestore(&its->lock, flags); \
\
if (its_wait_for_range_completion(its, rd_idx, next_cmd)) \
- pr_err_ratelimited("ITS cmd %ps failed\n", builder); \
+ pr_err_ratelimited("ITS@%pa cmd %ps failed\n", &its->phys_base, &builder); \
}
static void its_build_sync_cmd(struct its_node *its,
@@ -2411,7 +2411,8 @@ static int its_setup_baser(struct its_node *its, struct its_baser *baser,
/* 52bit PA is supported only when PageSize=64K */
if (psz != SZ_64K) {
- pr_err("ITS: no 52bit PA support when psz=%d\n", psz);
+ pr_err("ITS@%pa: no 52bit PA support when psz=%d\n",
+ &its->phys_base, psz);
its_free_pages(base, order);
return -ENXIO;
}
@@ -5181,7 +5182,7 @@ static int its_init_vpe_domain(void)
vpe_proxy.dev = its_create_device(its, devid, entries, false);
if (!vpe_proxy.dev) {
kfree(vpe_proxy.vpes);
- pr_err("ITS: Can't allocate GICv4 proxy device\n");
+ pr_err("ITS@%pa: Can't allocate GICv4 proxy device\n", &its->phys_base);
return -ENOMEM;
}
--
2.33.0
^ permalink raw reply related
* [PATCH v2 2/4] irqchip/gic-v3-its: Fix its node leak in gic_acpi_parse_madt_its()
From: Kemeng Shi @ 2026-06-18 1:14 UTC (permalink / raw)
To: maz, tglx; +Cc: linux-arm-kernel, linux-kernel, shikemeng
In-Reply-To: <20260618011459.58347-1-shikemeng@huaweicloud.com>
Fix its node leak when its_probe_one() failed in
gic_acpi_parse_madt_its().
Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com>
---
drivers/irqchip/irq-gic-v3-its.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index d721b6101e0a..3e4edcb64065 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -5747,9 +5747,13 @@ static int __init gic_acpi_parse_madt_its(union acpi_subtable_headers *header,
its->flags |= ITS_FLAGS_FORCE_NON_SHAREABLE;
err = its_probe_one(its);
- if (!err)
- return 0;
+ if (err)
+ goto probe_err;
+
+ return 0;
+probe_err:
+ its_node_destroy(its);
node_err:
iort_deregister_domain_token(its_entry->translation_id);
dom_err:
--
2.33.0
^ permalink raw reply related
* [PATCH v2 0/4] Some Minor cleanups and fixes
From: Kemeng Shi @ 2026-06-18 1:14 UTC (permalink / raw)
To: maz, tglx; +Cc: linux-arm-kernel, linux-kernel, shikemeng, w30042819
From: w30042819 <wanghaitao78@h-partners.com>
There are some random fixes and cleanups to irqchip/gic-v3-its. More
details can be found in respective patches.
Thanks.
v1->v2:
- Drop unneeded patches and some minor improvement.
Kemeng Shi (4):
irqchip/gic-v3-its: Fix memleak in its_probe_one()
irqchip/gic-v3-its: Fix its node leak in gic_acpi_parse_madt_its()
irqchip/gic-v3-its: Add ITS address info in more error logs
irqchip/gic-v3-its: some minor improvement in comments
drivers/irqchip/irq-gic-v3-its.c | 29 ++++++++++++++++++-----------
1 file changed, 18 insertions(+), 11 deletions(-)
--
2.33.0
^ permalink raw reply
* Re: [PATCH 1/6] irqchip/gic-v3-its: Fix LPI range leak and refactor error handler in its_lpi_alloc()
From: Kemeng Shi @ 2026-06-18 1:00 UTC (permalink / raw)
To: Marc Zyngier; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <86y0gds700.wl-maz@kernel.org>
在 2026/6/17 20:09:51, Marc Zyngier 写道:
> 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.
OK. I will drop this patch in next version.
Thanks,
Kemeng>
> M.
>
^ permalink raw reply
* Re: [PATCH 2/6] irqchip/gic-v3-its: Fix memleak in its_probe_one()
From: Kemeng Shi @ 2026-06-18 1:00 UTC (permalink / raw)
To: Marc Zyngier; +Cc: tglx, linux-arm-kernel, linux-kernel
In-Reply-To: <86zf0ts739.wl-maz@kernel.org>
在 2026/6/17 20:07:54, Marc Zyngier 写道:
> 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.
>
Thanks for feedback. I will drop its_free_collections() in release code in next
version.
Thanks,
Kemeng> M.
>
^ permalink raw reply
* Re: [PATCH v2 1/2] soc: aspeed: add BMC-side PCIe BMC device driver
From: Andrew Jeffery @ 2026-06-18 0:58 UTC (permalink / raw)
To: Grégoire Layet
Cc: joel, andrew, jacky_chou, yh_chung, ninad, linux-aspeed,
linux-arm-kernel, linux-kernel, anirudhsriniv
In-Reply-To: <CAFi2wKYgxKpp0ezzryYhFPDeqAeHhUq9Lhm67pVpnXRg+c2Vhw@mail.gmail.com>
Hi Grégoire,
On Wed, 2026-06-17 at 08:40 +0200, Grégoire Layet wrote:
> Hello Andrew,
>
> > The concept sounds reasonable to me. There's probably some bikeshedding
> > to do on the devicetree property though.
>
> Yes, having looked at how it's done, I would say :
> 'aspeed,vuart-over-pci' and 'aspeed,kcs-over-pci' flags would be
> better.
>
> > Can you outline the duplication you're concerned about? I think it's a
> > matter of resolving the SCU syscon to its regmap, then performing the
> > necessary accesses?
>
> Both drivers will need to set :
> - Enable PCI BMC Device MMIO
> - Enable PCI BMC Device IRQ
> - Enable PCI BMC Device MSI rooting over PCI Device 1 (BAR1)
> - Enable Host 2 BMC MSI interrupts
> - PCI device class to 0xff000000 to be identified as a MFD device. The
> reset default is 0x0C070100 which is an IPMI KCS device, but that
> causes issues as it is detected by ipmi_si but can't be loaded because
> of non default KCS address.
>
> Sorry for my errors, there is not that much. But both drivers will do
> almost the same initialisation. That was my code duplication concern.
I think it's valid to be concerned, but perhaps not for the reason of
code duplication. If there are multiple consumers then we need to
ensure consistency of configuration and correctness wrt to enabling /
disabling the capability based on the number of consumers.
>
> > I think it's not as bad as you make it out to be. The SCU's regmap
> > protects updates to individual registers under a lock, so concurrent
> > modification isn't a concern. The hardware design choices make all of
> > this slightly awkward for any related software design. As an
> > alternative you could implement a mini subsystem that relevant drivers
> > could call through to set the bits, but I currently think that's
> > unnecessary work.
>
> You are right it's not as bad as I thought.
> For now, I will focus on the VUART until the solution has been
> validated. Then I will easily do the same for the KCS over PCI.
I think it's a good step to at least solve one thing at a time, so long
as we're not precluding making those future steps.
>
> So I'll do for the V3 of the BMC side driver:
> - modify the device tree binding to have 'aspeed,ast2600-vuart' and
> add the 'aspeed,vuart-over-pci' boolean flag, only for the ast2600.
Just to confirm, you're proposing modifying the 8250 binding?
> - modify the '8250_aspeed_vuart' driver to add 'aspeed,ast2600-vuart' support.
> - add vuart over pci enable and disable code to the '8250_aspeed_vuart' driver.
>
Sounds like a reasonable start to me.
Andrew
^ permalink raw reply
* Re: [PATCH v6] soc: aspeed: lpc-snoop: Fix usercopy overflow in snoop_file_read
From: Andrew Jeffery @ 2026-06-18 0:44 UTC (permalink / raw)
To: Karthikeyan KS
Cc: joel, andrew, Kees Cook, linux-arm-kernel, linux-aspeed,
linux-kernel, linux-hardening
In-Reply-To: <20260617131013.64188-1-karthiproffesional@gmail.com>
On Wed, 2026-06-17 at 13:10 +0000, Karthikeyan KS wrote:
> This looks like a lot of heavily LLM-assisted effort. Please review the
> relevant documentation, starting here:
> https://docs.kernel.org/process/submitting-patches.html#using-assisted-by
>
> ==> I partly agree. The code and bug analysis are done manually.
> LLM use was the out of tree test harness and lightly polishing
> the commit message. None of the submitted code is generated.
> If you'd prefer, I can reword the changelog in my own words or
> add an Assisted-by tag ?
>
Thanks for the clarification. It's probably okay as-is in that case,
but that was unclear previously.
> I feel the testing strategy is pretty questionable. Any invariant
> violation is possible with that type of meddling.
>
> ==> The underlying bug is a kfifo SPSC contract violation. My intent with the
> test wasn't to simulate the race itself, but to reconstruct the post race state
> specifically where (in - out) exceeds the buffer size and show it causes a
> usercopy overflow in the unpatched code, handled safely after the fix.
>
> ==> I take your point that forcing that state can itself produce violations that
> wouldn't occur naturally. Since the bug is provable from the source but hard to
> trigger on demand, I'd rather ask what validation you'd accept here?
I'm aiming to build confidence that the change has been tested in
practice beyond spherical-cow circumstances. Isolating the conditions
this way seems okay, but I'd class the testing approach as necessary-
but-not-sufficient. It's important that the change is tested under
typical conditions to build confidence against regressions, as well as
atypical conditions.
>
> I was interested in whether you drove the interrupt sequence via
> emulated hardware. I asked because upstream qemu doesn't currently
> support the snoop device.
>
> ==> My apologies for the confusion, I mixed up things. I have not driven the
> interrupt sequence in emulation; as you noted, upstream QEMU doesn't model the
> snoop device. I've described the actual hardware context below.
>
> In v3 you said:
> The issue was observed on physical AST2600 (dual-core Cortex-A7)
> in production under heavy POST code traffic during concurrent
> userspace reads.
> https://lore.kernel.org/all/20260527175939.2939714-1-karthiproffesional@gmail.com/
> Is this true? What platform did you test with?
>
> ==> Yes, the underlying failure is real. It was observed on an AST2600-based
> production BMC running a vendor BSP kernel under continuous host reboot
> cycles. Because that platform can't currently be brought up on pure
> mainline without substantial out-of-tree board support, I have not run
> this exact mainline patch on the physical silicon, observed under the
> BSP kernel, not yet verified as the mainline patch. I should have made
> that distinction clear earlier in the thread.
Can you confirm you you have tested on hardware a backport of this
patch to your BSP kernel?
>
> ==> If there's a way you'd consider valid for validating a fix like this
> without a full mainline bring up on the SoC, such as a targeted kfifo unit
> test, or something else you'd accept.I'd appreciate the pointer and I'll
> do that.
No, I believe the change is fine, but the claim of testing under qemu
when qemu doesn't model the necessary hardware was a red flag that
needed to be addressed, doubly so in the absence of your track record
of upstream work.
Thanks,
Andrew
^ permalink raw reply
* Re: [PATCH net] net: ethernet: mtk_eth_soc: fix supported_interface set after phylink_create
From: patchwork-bot+netdevbpf @ 2026-06-18 0:20 UTC (permalink / raw)
To: Christian Marangi
Cc: nbd, lorenzo, andrew+netdev, davem, edumazet, kuba, pabeni,
matthias.bgg, angelogioacchino.delregno, linux, daniel, netdev,
linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260615151106.15438-1-ansuelsmth@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 15 Jun 2026 17:11:00 +0200 you wrote:
> Everything configured in phylink_config it's assumed to be set before
> calling phylink_create() to permit correct parsing of all the different
> modes and capabilities.
>
> Commit 51cf06ddafc9 ("net: ethernet: mtk_eth_soc: add support for MT7988
> internal 2.5G PHY") while introducing support for 2.5G phy for MT7988,
> probably due to an auto-rebase, placed the configuration of the INTERNAL
> interface mode for the supported_interfaces for phylink_config right after
> phylink_create() introducing a possible problem with supported interfaces
> parsing.
>
> [...]
Here is the summary with links:
- [net] net: ethernet: mtk_eth_soc: fix supported_interface set after phylink_create
https://git.kernel.org/netdev/net/c/e4b4d8410c7c
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] net: airoha: Stop TX queues on error path in airoha_dev_open
From: Jakub Kicinski @ 2026-06-17 23:44 UTC (permalink / raw)
To: Wayen Yan
Cc: netdev, lorenzo, horms, pabeni, edumazet, andrew+netdev,
angelogioacchino.delregno, matthias.bgg, linux-arm-kernel,
linux-mediatek
In-Reply-To: <178160729880.2156257.7978513589649053826@gmail.com>
On Tue, 16 Jun 2026 18:50:39 +0800 Wayen Yan wrote:
> In airoha_dev_open(), if airoha_set_vip_for_gdm_port() fails after
> netif_tx_start_all_queues() has been called, the TX queues remain
> started while the device configuration is incomplete. This leaves
> the device in an inconsistent state where packets could be
> transmitted before the VIP/IFC port configuration is complete.
Not sure if this was superseded by another posting but FWIW
this posting did not apply.
^ permalink raw reply
* [PATCH v2] firmware: arm_ffa: Fix NULL dereference in ffa_partition_info_get()
From: Unnathi Chalicheemala @ 2026-06-17 23:35 UTC (permalink / raw)
To: Sudeep Holla, Jens Wiklander
Cc: linux-arm-kernel, linux-kernel, linux-arm-msm, kernel,
Trilok Soni, Satya Durga Srinivasu Prabhala,
Unnathi Chalicheemala
ffa_partition_info_get() passes uuid_str directly to uuid_parse()
without a NULL check. When a caller passes NULL, uuid_parse() ->
__uuid_parse() -> uuid_is_valid() dereferences the pointer, causing
a kernel panic:
Unable to handle kernel NULL pointer dereference at virtual address
0000000000000040
pc : uuid_parse+0x40/0xac
lr : ffa_partition_info_get+0x1c/0x94 [arm_ffa]
Add a NULL guard before uuid_parse() so a NULL argument returns
-ENODEV instead of crashing. Callers are expected to always supply
a valid partition UUID, so NULL is not a supported input.
Fixes: d0c0bce83122 ("firmware: arm_ffa: Setup in-kernel users of FFA partitions")
Signed-off-by: Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com>
---
Changes in v2:
- Drop special-casing of NULL/empty string to uuid_null; treat NULL as
an error instead - as pointed out by Sudeep in v1.
- Simplify to a single NULL guard before uuid_parse() rather than a
separate branch
- Link to v1: https://patch.msgid.link/20260611-ffa_partition_nullptr_fix-v1-1-ec2b7ef7e130@oss.qualcomm.com
---
drivers/firmware/arm_ffa/driver.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
index b9f17fda7243..4090be782329 100644
--- a/drivers/firmware/arm_ffa/driver.c
+++ b/drivers/firmware/arm_ffa/driver.c
@@ -1129,7 +1129,7 @@ static int ffa_partition_info_get(const char *uuid_str,
uuid_t uuid;
struct ffa_partition_info *pbuf;
- if (uuid_parse(uuid_str, &uuid)) {
+ if (!uuid_str || uuid_parse(uuid_str, &uuid)) {
pr_err("invalid uuid (%s)\n", uuid_str);
return -ENODEV;
}
---
base-commit: ba3e43a9e601636f5edb54e259a74f96ca3b8fd8
change-id: 20260604-ffa_partition_nullptr_fix-66f37bb2630b
Best regards,
--
Unnathi Chalicheemala <unnathi.chalicheemala@oss.qualcomm.com>
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox