* Re: [PATCH] net: ixp4xx_hss: fix duplicate HDLC netdev allocation
From: patchwork-bot+netdevbpf @ 2026-06-25 1:09 UTC (permalink / raw)
To: Haoxiang Li
Cc: linusw, kaloz, andrew+netdev, davem, edumazet, kuba, pabeni,
huangguangbin2, lipeng321, linux-arm-kernel, netdev, linux-kernel,
stable
In-Reply-To: <20260622043015.643637-1-haoxiang_li2024@163.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 22 Jun 2026 12:30:15 +0800 you wrote:
> ixp4xx_hss_probe() allocates two HDLC netdevs. The first one is stored
> in ndev, initialized, and registered with register_hdlc_device(). The
> second one is stored in port->netdev and later used by the remove path
> for unregister_hdlc_device() and free_netdev().
>
> This means that the registered netdev is not the same object that is
> unregistered and freed on remove. It also leaks the first allocation if
> the second alloc_hdlcdev() call fails, and the first allocation is not
> checked before ndev is used.
>
> [...]
Here is the summary with links:
- net: ixp4xx_hss: fix duplicate HDLC netdev allocation
https://git.kernel.org/netdev/net/c/db818b0e8af7
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 v2 0/2] airoha: fixes for sched HTB offload support
From: patchwork-bot+netdevbpf @ 2026-06-25 1:08 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms, win847,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260619-airoha-qos-fixes-v2-0-5c43485038f9@kernel.org>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 19 Jun 2026 13:37:12 +0200 you wrote:
> ---
> Changes in v2:
> - cosmetics
> - Link to v1: https://lore.kernel.org/r/20260618-airoha-qos-fixes-v1-0-37192652157f@kernel.org
>
> ---
> Lorenzo Bianconi (2):
> net: airoha: Fix off-by-one in airoha_tc_remove_htb_queue()
> net: airoha: fix netif_set_real_num_tx_queues for sparse QoS channels
>
> [...]
Here is the summary with links:
- [net,v2,1/2] net: airoha: Fix off-by-one in airoha_tc_remove_htb_queue()
https://git.kernel.org/netdev/net/c/bfcce49c4aaa
- [net,v2,2/2] net: airoha: fix netif_set_real_num_tx_queues for sparse QoS channels
https://git.kernel.org/netdev/net/c/788663dd28e4
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 v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Jie Gan @ 2026-06-25 1:01 UTC (permalink / raw)
To: Leo Yan, Suzuki K Poulose
Cc: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang, Jingyi Wang,
Abel Vesa, Mike Leach, James Clark, Yuanfang Zhang, linux-arm-msm,
devicetree, linux-kernel, coresight, linux-arm-kernel
In-Reply-To: <20260624151610.GC575984@e132581.arm.com>
On 6/24/2026 11:16 PM, Leo Yan wrote:
> On Wed, Jun 24, 2026 at 11:08:32PM +0800, Jie Gan wrote:
>
> [...]
>
>>> Why does it fail ? power management ? hw broken ? Is it really AMBA or
>>> do you pretend that to be an AMBA device by faking the CID/PID?
>>
>> The CID reads as 0 from the register, which I suspect is a hardware design
>> issue. I have not yet confirmed this with the hardware team. As a
>> workaround, I provided a fake periphid via a DT property to bypass
>> amba_read_periphid.
>>
>>
>> Leo commented in other thread:
>>>> tnoc.c registers both an AMBA driver and a platform driver. Shouldn't >>it
>>>> be registered as a platform device instead?
>>
>> The platform driver is intended for the interconnect TraceNoC device and is
>> not designed to allocate an ATID. The issue is that the TPDM device borrows
>> the ATID from the TraceNoC device, resulting in the ATID always being 0 when
>> associated with an interconnect NoC device.
>>
>> However, I believe it is acceptable to allocate an ATID for the itNoC device
>> and the issue can be fixed with this way.
>
> I think so.
Hi Suzuki/Leo
Which solution do you prefer to address the issue?
The interconnect traceNoC platform driver is intended for the itnoc
device, implying that no TPDM devices are connected to it. So, if I
modify it to allocate an ATID, I think it would be better to rename the
“itnoc” node accordingly? Or it's ok to leave it as-is?
BTW, the traceNoC device definitely is an AMBA device with CID/PID
registers.
Thanks,
Jie
^ permalink raw reply
* [RFC PATCH] wifi: mt76: fail channel switch when TX queues do not drain
From: Pengpeng Hou @ 2026-06-25 0:38 UTC (permalink / raw)
To: Felix Fietkau
Cc: pengpeng, Lorenzo Bianconi, Ryder Lee, Shayne Chen, Sean Wang,
Matthias Brugger, AngeloGioacchino Del Regno, linux-wireless,
linux-kernel, linux-arm-kernel, linux-mediatek
__mt76_set_channel() disables the TX worker, schedules pending TX queues,
sets MT76_RESET, and waits for pending TX to drain before changing the PHY
channel state and calling the driver set_channel() callback.
The wait result is ignored. If TX does not drain within the timeout, the
function still publishes the new channel state and asks the driver to
switch channels while old-channel TX may remain pending.
Return -ETIMEDOUT when the drain wait expires. Keep the survey update on
the old channel, then clear MT76_RESET and re-enable the TX worker through
the existing exit path.
This is marked RFC because the existing channel switch path treats the TX
drain wait as best-effort. Maintainer feedback is needed on whether a TX
drain timeout should fail the channel switch for all mt76 devices or
whether the current force-forward behavior is intentional.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/net/wireless/mediatek/mt76/mac80211.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c b/drivers/net/wireless/mediatek/mt76/mac80211.c
index 13c4e8abe..37474d64c 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -1033,6 +1033,7 @@ int __mt76_set_channel(struct mt76_phy *phy, struct cfg80211_chan_def *chandef,
bool offchannel)
{
struct mt76_dev *dev = phy->dev;
+ long time_left;
int timeout = HZ / 5;
int ret;
@@ -1040,8 +1041,13 @@ int __mt76_set_channel(struct mt76_phy *phy, struct cfg80211_chan_def *chandef,
mt76_txq_schedule_pending(phy);
set_bit(MT76_RESET, &phy->state);
- wait_event_timeout(dev->tx_wait, !mt76_has_tx_pending(phy), timeout);
+ time_left = wait_event_timeout(dev->tx_wait, !mt76_has_tx_pending(phy),
+ timeout);
mt76_update_survey(phy);
+ if (!time_left) {
+ ret = -ETIMEDOUT;
+ goto out;
+ }
if (phy->chandef.chan->center_freq != chandef->chan->center_freq ||
phy->chandef.width != chandef->width)
@@ -1059,6 +1065,7 @@ int __mt76_set_channel(struct mt76_phy *phy, struct cfg80211_chan_def *chandef,
ret = dev->drv->set_channel(phy);
+out:
clear_bit(MT76_RESET, &phy->state);
mt76_worker_enable(&dev->tx_worker);
mt76_worker_schedule(&dev->tx_worker);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [RFC PATCH] mtd: rawnand: mtk: return errors when reset does not idle
From: Pengpeng Hou @ 2026-06-25 0:37 UTC (permalink / raw)
To: Miquel Raynal
Cc: pengpeng, Richard Weinberger, Vignesh Raghavendra,
Matthias Brugger, AngeloGioacchino Del Regno, linux-mtd,
linux-kernel, linux-arm-kernel, linux-mediatek
mtk_nfc_hw_reset() waits for the NFI master to become idle after forcing a
reset, but it only logs a warning when the wait times out. Probe-time
hardware init and later exec_op() calls then continue as if the reset had
completed.
Make the reset helper return the poll error and propagate it through both
initial hardware setup and NAND operation execution. Keep the final reset
writes so status registers affected by the NFI master are still forced
back to the reset state before the error is returned.
This is marked RFC because the existing code only warns about the idle
timeout and then performs the final reset writes. Maintainer feedback is
needed on whether this timeout should be treated as fatal or as a
recoverable reset condition on affected hardware.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/mtd/nand/raw/mtk_nand.c | 27 ++++++++++++++++++++-------
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/mtd/nand/raw/mtk_nand.c b/drivers/mtd/nand/raw/mtk_nand.c
index 21c7e1102..059b8070f 100644
--- a/drivers/mtd/nand/raw/mtk_nand.c
+++ b/drivers/mtd/nand/raw/mtk_nand.c
@@ -255,7 +255,7 @@ static inline u8 nfi_readb(struct mtk_nfc *nfc, u32 reg)
return readb_relaxed(nfc->regs + reg);
}
-static void mtk_nfc_hw_reset(struct mtk_nfc *nfc)
+static int mtk_nfc_hw_reset(struct mtk_nfc *nfc)
{
struct device *dev = nfc->dev;
u32 val;
@@ -269,12 +269,14 @@ static void mtk_nfc_hw_reset(struct mtk_nfc *nfc)
!(val & MASTER_STA_MASK), 50,
MTK_RESET_TIMEOUT);
if (ret)
- dev_warn(dev, "master active in reset [0x%x] = 0x%x\n",
- NFI_MASTER_STA, val);
+ dev_err(dev, "master active in reset [0x%x] = 0x%x\n",
+ NFI_MASTER_STA, val);
/* ensure any status register affected by the NFI master is reset */
nfi_writel(nfc, CON_FIFO_FLUSH | CON_NFI_RST, NFI_CON);
nfi_writew(nfc, STAR_DE, NFI_STRDATA);
+
+ return ret;
}
static int mtk_nfc_send_command(struct mtk_nfc *nfc, u8 command)
@@ -517,7 +519,10 @@ static int mtk_nfc_exec_op(struct nand_chip *chip,
if (check_only)
return 0;
- mtk_nfc_hw_reset(nfc);
+ ret = mtk_nfc_hw_reset(nfc);
+ if (ret)
+ return ret;
+
nfi_writew(nfc, CNFG_OP_CUST, NFI_CNFG);
mtk_nfc_select_target(chip, op->cs);
@@ -1084,8 +1089,10 @@ static int mtk_nfc_read_oob_std(struct nand_chip *chip, int page)
return mtk_nfc_read_page_raw(chip, NULL, 1, page);
}
-static inline void mtk_nfc_hw_init(struct mtk_nfc *nfc)
+static int mtk_nfc_hw_init(struct mtk_nfc *nfc)
{
+ int ret;
+
/*
* CNRNB: nand ready/busy register
* -------------------------------
@@ -1095,10 +1102,14 @@ static inline void mtk_nfc_hw_init(struct mtk_nfc *nfc)
nfi_writew(nfc, 0xf1, NFI_CNRNB);
nfi_writel(nfc, PAGEFMT_8K_16K, NFI_PAGEFMT);
- mtk_nfc_hw_reset(nfc);
+ ret = mtk_nfc_hw_reset(nfc);
+ if (ret)
+ return ret;
nfi_readl(nfc, NFI_INTR_STA);
nfi_writel(nfc, 0, NFI_INTR_EN);
+
+ return 0;
}
static irqreturn_t mtk_nfc_irq(int irq, void *id)
@@ -1411,7 +1422,9 @@ static int mtk_nfc_nand_chip_init(struct device *dev, struct mtk_nfc *nfc,
mtd->name = MTK_NAME;
mtd_set_ooblayout(mtd, &mtk_nfc_ooblayout_ops);
- mtk_nfc_hw_init(nfc);
+ ret = mtk_nfc_hw_init(nfc);
+ if (ret)
+ return ret;
ret = nand_scan(nand, nsels);
if (ret)
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] mmc: mtk-sd: report DMA stop timeouts as data errors
From: Pengpeng Hou @ 2026-06-25 0:35 UTC (permalink / raw)
To: Chaotian Jing
Cc: pengpeng, Ulf Hansson, Matthias Brugger,
AngeloGioacchino Del Regno, linux-mmc, linux-kernel,
linux-arm-kernel, linux-mediatek
msdc_data_xfer_done() stops the DMA engine before completing a data
request, but it only logs failures from the DMA stop and DMA-inactive
polls.
When the interrupt status also carries MSDC_INT_XFER_COMPL, the function
can still report the full data length as transferred even though the DMA
engine did not confirm that it stopped or became inactive.
Treat DMA stop/inactive timeouts as data errors. This reuses the existing
reset/error path and prevents a timed out DMA stop from being reported as a
successful full-length transfer.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/mmc/host/mtk-sd.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index b2680cc05..e3caa9c32 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -1583,7 +1583,7 @@ static void msdc_data_xfer_done(struct msdc_host *host, u32 events,
| MSDC_INT_DMA_BDCSERR | MSDC_INT_DMA_GPDCSERR
| MSDC_INT_DMA_PROTECT);
u32 val;
- int ret;
+ int dma_err = 0, ret;
spin_lock_irqsave(&host->lock, flags);
done = !host->data;
@@ -1603,18 +1603,23 @@ static void msdc_data_xfer_done(struct msdc_host *host, u32 events,
ret = readl_poll_timeout_atomic(host->base + MSDC_DMA_CTRL, val,
!(val & MSDC_DMA_CTRL_STOP), 1, 20000);
- if (ret)
+ if (ret) {
dev_dbg(host->dev, "DMA stop timed out\n");
+ dma_err = ret;
+ }
ret = readl_poll_timeout_atomic(host->base + MSDC_DMA_CFG, val,
!(val & MSDC_DMA_CFG_STS), 1, 20000);
- if (ret)
+ if (ret) {
dev_dbg(host->dev, "DMA inactive timed out\n");
+ dma_err = ret;
+ }
sdr_clr_bits(host->base + MSDC_INTEN, data_ints_mask);
dev_dbg(host->dev, "DMA stop\n");
- if ((events & MSDC_INT_XFER_COMPL) && (!stop || !stop->error)) {
+ if (!dma_err && (events & MSDC_INT_XFER_COMPL) &&
+ (!stop || !stop->error)) {
data->bytes_xfered = data->blocks * data->blksz;
} else {
dev_dbg(host->dev, "interrupt events: %x\n", events);
@@ -1622,7 +1627,9 @@ static void msdc_data_xfer_done(struct msdc_host *host, u32 events,
host->error |= REQ_DAT_ERR;
data->bytes_xfered = 0;
- if (events & MSDC_INT_DATTMO)
+ if (dma_err)
+ data->error = -ETIMEDOUT;
+ else if (events & MSDC_INT_DATTMO)
data->error = -ETIMEDOUT;
else if (events & MSDC_INT_DATCRCERR)
data->error = -EILSEQ;
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] bus: sunxi-rsb: fail hardware init on soft-reset timeout
From: Pengpeng Hou @ 2026-06-25 0:34 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: pengpeng, Jernej Skrabec, Samuel Holland, Philipp Zabel,
linux-arm-kernel, linux-sunxi, linux-kernel
sunxi_rsb_hw_init() issues a controller soft reset and waits for the reset
bit to clear, but it ignores readl_poll_timeout()'s return value.
If the controller never leaves reset, probe can continue to publish child
devices and system resume can report success without a usable RSB
controller.
Return the timeout error, assert reset again, and disable the clock before
leaving the hardware-init path.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/bus/sunxi-rsb.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/bus/sunxi-rsb.c b/drivers/bus/sunxi-rsb.c
index daf0ea563..f83224dea 100644
--- a/drivers/bus/sunxi-rsb.c
+++ b/drivers/bus/sunxi-rsb.c
@@ -669,8 +669,12 @@ static int sunxi_rsb_hw_init(struct sunxi_rsb *rsb)
/* reset the controller */
writel(RSB_CTRL_SOFT_RST, rsb->regs + RSB_CTRL);
- readl_poll_timeout(rsb->regs + RSB_CTRL, reg,
- !(reg & RSB_CTRL_SOFT_RST), 1000, 100000);
+ ret = readl_poll_timeout(rsb->regs + RSB_CTRL, reg,
+ !(reg & RSB_CTRL_SOFT_RST), 1000, 100000);
+ if (ret) {
+ dev_err(dev, "soft reset timed out\n");
+ goto err_reset_assert;
+ }
/*
* Clock frequency and delay calculation code is from
@@ -696,6 +700,8 @@ static int sunxi_rsb_hw_init(struct sunxi_rsb *rsb)
return 0;
+err_reset_assert:
+ reset_control_assert(rsb->rstc);
err_clk_disable:
clk_disable_unprepare(rsb->clk);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] mtd: rawnand: lpc32xx_mlc: fail DMA transfers on timeout
From: Pengpeng Hou @ 2026-06-25 0:33 UTC (permalink / raw)
To: Miquel Raynal
Cc: pengpeng, Richard Weinberger, Vignesh Raghavendra,
Vladimir Zapolskiy, Piotr Wojtaszczyk, linux-mtd,
linux-arm-kernel, linux-kernel
lpc32xx_xmit_dma() starts a DMA transfer and waits up to one second for
its completion, but it ignores the wait result and returns success after
unmapping the buffer.
A timed out read can therefore return success with incomplete data, and a
timed out write can continue the NAND operation without proof that the DMA
payload reached the controller.
Terminate the DMA channel on timeout, unmap the scatterlist through the
existing cleanup path, and return -ETIMEDOUT to the NAND read/write
callers.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/mtd/nand/raw/lpc32xx_mlc.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/nand/raw/lpc32xx_mlc.c b/drivers/mtd/nand/raw/lpc32xx_mlc.c
index 19b13ae53..8f6a89d9b 100644
--- a/drivers/mtd/nand/raw/lpc32xx_mlc.c
+++ b/drivers/mtd/nand/raw/lpc32xx_mlc.c
@@ -396,6 +396,7 @@ static int lpc32xx_xmit_dma(struct mtd_info *mtd, void *mem, int len,
struct lpc32xx_nand_host *host = nand_get_controller_data(chip);
struct dma_async_tx_descriptor *desc;
int flags = DMA_CTRL_ACK | DMA_PREP_INTERRUPT;
+ unsigned long time_left;
int res;
sg_init_one(&host->sgl, mem, len);
@@ -410,6 +411,7 @@ static int lpc32xx_xmit_dma(struct mtd_info *mtd, void *mem, int len,
flags);
if (!desc) {
dev_err(mtd->dev.parent, "Failed to prepare slave sg\n");
+ res = -ENXIO;
goto out1;
}
@@ -420,7 +422,13 @@ static int lpc32xx_xmit_dma(struct mtd_info *mtd, void *mem, int len,
dmaengine_submit(desc);
dma_async_issue_pending(host->dma_chan);
- wait_for_completion_timeout(&host->comp_dma, msecs_to_jiffies(1000));
+ time_left = wait_for_completion_timeout(&host->comp_dma,
+ msecs_to_jiffies(1000));
+ if (!time_left) {
+ dmaengine_terminate_sync(host->dma_chan);
+ res = -ETIMEDOUT;
+ goto out1;
+ }
dma_unmap_sg(host->dma_chan->device->dev, &host->sgl, 1,
DMA_BIDIRECTIONAL);
@@ -428,7 +436,7 @@ static int lpc32xx_xmit_dma(struct mtd_info *mtd, void *mem, int len,
out1:
dma_unmap_sg(host->dma_chan->device->dev, &host->sgl, 1,
DMA_BIDIRECTIONAL);
- return -ENXIO;
+ return res;
}
static int lpc32xx_read_page(struct nand_chip *chip, uint8_t *buf,
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH] media: mediatek: jpeg: retry HW selection after successful wait
From: Pengpeng Hou @ 2026-06-25 0:31 UTC (permalink / raw)
To: Bin Liu
Cc: pengpeng, Mauro Carvalho Chehab, Matthias Brugger,
AngeloGioacchino Del Regno, linux-media, linux-kernel,
linux-arm-kernel, linux-mediatek
wait_event_interruptible_timeout() returns a positive value when the
condition becomes true before the timeout expires.
mtk_jpegdec_worker() treats every non-zero return value as a failure and
finishes the mem2mem job with an error. A normal wakeup that indicates
that a decode engine is ready can therefore be handled as if all hardware
remained busy.
Only fail immediately on interrupted waits. Keep the existing retry limit
for real timeouts, and retry hardware selection after a successful wait.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index d147ec483..391db77a6 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1697,7 +1697,7 @@ static void mtk_jpegdec_worker(struct work_struct *work)
ret = wait_event_interruptible_timeout(jpeg->hw_wq,
atomic_read(&jpeg->hw_rdy) > 0,
MTK_JPEG_HW_TIMEOUT_MSEC);
- if (ret != 0 || (i++ > MTK_JPEG_MAX_RETRY_TIME)) {
+ if (ret < 0 || (!ret && i++ > MTK_JPEG_MAX_RETRY_TIME)) {
dev_err(jpeg->dev, "%s : %d, all HW are busy\n",
__func__, __LINE__);
v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH v3 0/7] net: wwan: t9xx: Add MediaTek T9XX WWAN driver
From: Jakub Kicinski @ 2026-06-25 0:09 UTC (permalink / raw)
To: Jack Wu via B4 Relay
Cc: jackbb_wu, Loic Poulain, Sergey Ryazanov, Johannes Berg,
Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Wen-Zhi Huang, Shi-Wei Yeh, Minano Tseng, Matthias Brugger,
AngeloGioacchino Del Regno, Simon Horman, Jonathan Corbet,
Shuah Khan, linux-kernel, netdev, linux-arm-kernel,
linux-mediatek, linux-doc
In-Reply-To: <20260624-t9xx_driver_v1-v3-0-73ff03f60c48@compal.com>
On Wed, 24 Jun 2026 18:04:06 +0800 Jack Wu via B4 Relay wrote:
> T9XX is the PCIe host device driver for MediaTek's
> t900 modem. The driver uses the WWAN framework
> infrastructure to create the following control ports
> and network interfaces for data transactions.
Replying after a long delay and then immediately posting a new version
of patches is very bad. Don't bother replying and just put the comments
you had in the changelog of the new posting. Otherwise the discussion
may get split.
^ permalink raw reply
* Re: [External Mail] [PATCH v2 1/7] net: wwan: t9xx: Add PCIe core
From: Jakub Kicinski @ 2026-06-24 23:35 UTC (permalink / raw)
To: Wu. JackBB (GSM)
Cc: Loic Poulain, Sergey Ryazanov, Johannes Berg, Andrew Lunn,
David S. Miller, Eric Dumazet, Paolo Abeni, Wen-Zhi Huang,
Shi-Wei Yeh, Minano Tseng, Matthias Brugger,
AngeloGioacchino Del Regno, Simon Horman, Jonathan Corbet,
Shuah Khan, linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-doc@vger.kernel.org
In-Reply-To: <b02c0e1e9f0449f2b819197e4329373b@compal.com>
On Wed, 24 Jun 2026 09:15:17 +0000 Wu. JackBB (GSM) wrote:
> ================================================================================================================================================================
> This message may contain information which is private, privileged or confidential of Compal Electronics, Inc. If you are not the intended recipient of this message, please notify the sender and destroy/delete the message. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information, by persons or entities other than the intended recipient is prohibited.
> ================================================================================================================================================================
If you want to do anything upstream you have to get rid of this first.
^ permalink raw reply
* Re: [PATCH 7/7] i2c: nomadik: add support for I2C_XFER_V2 - detailed fault reporting
From: Linus Walleij @ 2026-06-24 22:56 UTC (permalink / raw)
To: Dmitry Guzman
Cc: Andi Shyti, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
linux-i2c, linux-kernel, linux-trace-kernel, linux-arm-kernel
In-Reply-To: <20260623-i2c-fault-reporting-v1-7-6db1a8aabf18@mobileye.com>
On Tue, Jun 23, 2026 at 6:32 PM Dmitry Guzman
<Dmitry.Guzman@mobileye.com> wrote:
> I2C_XFER_V2 is a new API that allows I2C clients to get the detailed
> report in case of transmission failure. Previously, the only information
> returned by I2C bus controller was the error code; there was no way to
> find out how many messages or bytes in a certain message have been sent
> or received until the fault condition occurred.
>
> This commit introduces support of this feature in i2c-nomadik driver.
>
> Signed-off-by: Dmitry Guzman <Dmitry.Guzman@mobileye.com>
I don't fully understand patch 1 but if that is fine, this is fine:
Acked-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 6/7] i2c: nomadik: add quirks max_len=2047 and no_zero_len_read
From: Linus Walleij @ 2026-06-24 22:55 UTC (permalink / raw)
To: Dmitry Guzman
Cc: Andi Shyti, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
linux-i2c, linux-kernel, linux-trace-kernel, linux-arm-kernel
In-Reply-To: <20260623-i2c-fault-reporting-v1-6-6db1a8aabf18@mobileye.com>
On Tue, Jun 23, 2026 at 6:32 PM Dmitry Guzman
<Dmitry.Guzman@mobileye.com> wrote:
> In Nomadik I2c controller, register I2C_MCR has 11-bit wide LENGTH
> field. Its maximum value is 2047, so this is the maximum length of a
> single message. It is less than the common maximum I2C message length in
> I2C subsystem (8192), so define a quirk in order to report the
> unsupported message without any attempt to transfer it.
>
> Zero length reading doesn't work properly on this controller, so add
> `I2C_AQ_NO_ZERO_LEN_READ` quirk flag.
>
> Signed-off-by: Dmitry Guzman <Dmitry.Guzman@mobileye.com>
Excellent improvements, almost a Fixes: patch.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 5/7] i2c: nomadik: change print level for fault messages to debug
From: Linus Walleij @ 2026-06-24 22:54 UTC (permalink / raw)
To: Dmitry Guzman
Cc: Andi Shyti, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
linux-i2c, linux-kernel, linux-trace-kernel, linux-arm-kernel
In-Reply-To: <20260623-i2c-fault-reporting-v1-5-6db1a8aabf18@mobileye.com>
On Tue, Jun 23, 2026 at 6:32 PM Dmitry Guzman
<Dmitry.Guzman@mobileye.com> wrote:
> i2c-nomadik driver prints error message on every faulted message. This
> is not a good practice, because in I2C a fault not always is an error,
> sometimes it is the expected result. For example, scanning bus with
> `i2cdetects` prints over 100 messages in dmesg (two messages per each
> target address).
>
> To avoid excessive prints in the log, change the print level from err to
> debug.
>
> Signed-off-by: Dmitry Guzman <Dmitry.Guzman@mobileye.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 4/7] i2c: nomadik: return proper fault codes
From: Linus Walleij @ 2026-06-24 22:53 UTC (permalink / raw)
To: Dmitry Guzman
Cc: Andi Shyti, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
linux-i2c, linux-kernel, linux-trace-kernel, linux-arm-kernel
In-Reply-To: <20260623-i2c-fault-reporting-v1-4-6db1a8aabf18@mobileye.com>
On Tue, Jun 23, 2026 at 6:32 PM Dmitry Guzman
<Dmitry.Guzman@mobileye.com> wrote:
> I2C documentation Documentation/i2c/fault-codes.rst defines fault codes
> for different negative results in I2C transmittion. Previously,
> i2c-nomadik driver didn't implement them properly - it returned
> ETIMEDOUT on most errors and EIO on master arbitration lost.
>
> To comply with the documentation, return the proper fault codes for
> different conditions, namely:
>
> - EAGAIN if arbitration lost
> - EOVERFLOW if message is too long (>2047 bytes)
> - ENXIO if target address is not acknowledged
> - EIO on other errors detected by controller (for example, NACK on data)
> - ETIMEDOUT if driver gets timeout waiting for message completion
> without any fault condition detected by the controller (for example,
> too long message, or SDA/SCL line stuck on 0).
>
> Signed-off-by: Dmitry Guzman <Dmitry.Guzman@mobileye.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 3/7] i2c: nomadik: do not try to retransmit I2C message series on errors
From: Linus Walleij @ 2026-06-24 22:51 UTC (permalink / raw)
To: Dmitry Guzman
Cc: Andi Shyti, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
linux-i2c, linux-kernel, linux-trace-kernel, linux-arm-kernel
In-Reply-To: <20260623-i2c-fault-reporting-v1-3-6db1a8aabf18@mobileye.com>
On Tue, Jun 23, 2026 at 6:32 PM Dmitry Guzman
<Dmitry.Guzman@mobileye.com> wrote:
> i2c-nomadik driver of I2C bus controller in `xfer` callback retransmits
> the whole message series in cause of any fault, and returns fault only
> after third failed attempt. This behavior contradicts with API because
> not only it hides hardware faults, but also re-sends messages, while
> they are not guaranteed to be idempotent.
>
> Remove the triple attempt to send messages in `xfer` callback.
>
> Signed-off-by: Dmitry Guzman <Dmitry.Guzman@mobileye.com>
This originally came from:
commit ebd10e0783d9fb92a147e60902e22c2d3f3ad69d
Author: Virupax Sadashivpetimath <virupax.sadashivpetimath@stericsson.com>
Date: Fri May 13 12:30:23 2011 +0200
i2c-nomadik: add code to retry on timeout failure
It is seen that i2c-nomadik controller randomly stops generating the
interrupts leading to a i2c timeout. As a workaround to this problem,
add retries to the on going transfer on failure.
Signed-off-by: Virupax Sadashivpetimath
<virupax.sadashivpetimath@stericsson.com>
Reviewed-by: Jonas ABERG <jonas.aberg@stericsson.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
At that time the code looked very different:
for (j = 0; j < 3; j++) {
if (status || (dev->result)) {
(...)
break;
}
udelay(I2C_DELAY);
}
if (status == 0)
break;
We would only spin here if both status and dev->result
(the number of sent bytes) was 0. This doesn't seem to be
at all the case anymore!
I suppose it's a bit dubious code, so:
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: mm: opaque hardware page-table entry handles
From: Muhammad Usama Anjum @ 2026-06-24 22:39 UTC (permalink / raw)
To: Zi Yan, Andrew Morton, Lorenzo Stoakes, David Hildenbrand,
Liam R. Howlett, Mike Rapoport, Ryan Roberts, Anshuman Khandual,
Catalin Marinas, Will Deacon, Samuel Holland
Cc: usama.anjum, linux-mm, linux-arm-kernel, linux-kernel
In-Reply-To: <DJHEF8MWTZSC.3KMTACZH7KWP@nvidia.com>
On 24/06/2026 4:52 pm, Zi Yan wrote:
> On Wed Jun 24, 2026 at 10:09 AM EDT, Usama Anjum wrote:
>> Hi all,
>>
>> This is a direction-check with the wider community before spending time on the
>> development. This picks up the idea that was raised and broadly agreed in the
>> earlier thread (Ryan Roberts, Lorenzo Stoakes, David Hildenbrand) [1].
>>
>> The problem
>> -----------
>> Core MM code reaches page-table entries by raw pointer dereference (pte_t *,
>> pmd_t *, *pud, ...) in places, implicitly assuming a single, uniform
>> representation. Sprinkling getters wouldn't solve the problem entirely. The
>> problem is one level up: the *pointer type* itself is overloaded. At each level
>> there are really three distinct things:
>>
>> 1. a page-table entry value (pte_t, pmd_t, ...)
>> 2. a pointer to an entry value, e.g. a pXX_t on the stack
>> 3. a pointer to a live entry in the hardware page table
>
> This sounds good to me, but can you clarify the situation below?
>
> A live entry means the entry can be accessed by hardware when the code
> is manipulating it?
I think live is wrong world to chose here. Its a mistake on my end. (3) means
the pointer points into real page-table memory and that table is complete,
whether or not it's linked in yet. A withdrawn-but-not-yet-installed table is
still a hardware table and can be represented by hw_pXXp type.
> What type should we use if we are pre-populating
> PTEs in a PMD page before we establish the PMD page as a HW page table?
> In __split_huge_pmd_locked(), we do that. A PMD page is first withdrawn
> and filled with after-split PTEs, pmd_populate() and pte_offset_map()
> are used for this not-yet-HW page table. Later, pmd_populate() is used> to make this page table visible to HW. Should we have two versions of
> pmd_populate() and pte_offset_map()? Since the first pmd_populate()
> would accept pmd_t*, but the second one would accept hw_pmdp, if we are
> pedantic. Of course, we can be flexible here to use pmd_populate()
> accpeting hw_pmdp for both, since the PMD page table we are modifying
> is going to be visible to HW soon. But I think we should have clear
> definitions for where these types are used and document them well.
This is exactly the example that causes the confusion. Following the definition
above, the pmd is on the stack while the PTEs are being prepared, and the PTE
table is complete — so the pmd pointer should be pmd_t * and the PTE table
hw_ptep. I'd keep the two APIs distinct rather than overloading hw_pmdp for
both: that's what enforces the rule that no stack pointer reaches a
table-writing API, and what lets the *_stack path drop the synchronization.
(One thing I still need to chase: there are cases where we convert between pmd
and pte. I need to understand how often that happens — if it's common, a
hw_ptep could get converted into a pmd and bring the confusion back, and if we
have to account for that, definition (3) may need to change.)
>
> You probably can ask LLMs to check these ambiguous/vague uses throughout
> the code base.
>
>>
>> Today (2) and (3) share the same type - pte_t *, pmd_t *, and so on. Nothing
>> distinguishes a pointer into a live table from a pointer to a stack copy.
>>
>> A pointer to an on-stack entry value and a pointer to a live hardware entry have
>> the same type, so the compiler cannot distinguish them. Passing the stack
>> pointer to an arch helper that expects a hardware-entry pointer compiles fine,
>> but is wrong - a bug class the type system makes invisible. It also blocks
>> evolution: an arch helper may need to read beyond the addressed entry (e.g.
>> adjacent or contiguous entries), which only makes sense for a real page-table
>> pointer, not a stack copy.
>>
>> The idea
>> --------
>> Give (3) its own opaque type that cannot be dereferenced:
>>
>> /* opaque handle to a HW page-table entry; not dereferenceable */
>> typedef struct {
>> pte_t *ptr;
>> } hw_ptep;
>>
>> With this:
>>
>> - a stack value can no longer masquerade as a hardware table entry,
>> - a hardware handle can no longer be raw-dereferenced,
>> - cases that genuinely operate on a value can be refactored to pass the value
>> and let the caller, which knows whether it holds a handle or a stack copy,
>> read it once.
>>
>> The overload becomes a compile-time type error instead of a silent runtime bug,
>> and converting the tree forces every such site to be made explicit. This gives
>> us a framework where the architecture can completely virtualize the pgtable if
>> it likes; and the compiler can enforce that higher level code can't accidentally
>> work around it.
>>
>> It is opt-in by architectures and incremental. The generic definition is
>> just an alias, so arches that do not care build unchanged:
>>
>> typedef pte_t *hw_ptep;
>>
>> An arch flips to the strong struct type when it is ready, and only then does
>> it get the stronger checking. This lets the conversion land gradually.
>>
>> Beyond fixing the latent bug class, this abstraction is an enabler for upcoming
>> features that need tighter control over how page tables are accessed and
>> manipulated.
>>
>> Getter flavours
>> ---------------
>> While converting, it is useful to have two accessor flavours at each level:
>>
>> - pXXp_get(hw_ptep) plain C dereference (compiler may optimize)
>> - pXXp_get_once(hw_ptep) single-copy-atomic, not torn, elided or
>> duplicated by the compiler
>>
>> Keeping them distinct simplifies the conversion and avoids re-introducing the
>> class of lockless-read bugs seen on 32-bit.
>>
>> Example conversion
>> ------------------
>> Most of the conversion is mechanical.
>>
>> -static inline void set_ptes(struct mm_struct *mm, unsigned long addr,
>> - pte_t *ptep, pte_t pte, unsigned int nr)
>> +static inline void set_ptes(struct mm_struct *mm, unsigned long addr,
>> + hw_ptep ptep, pte_t pte, unsigned int nr)
>> {
>> page_table_check_ptes_set(mm, addr, ptep, pte, nr);
>> for (;;) {
>> set_pte(ptep, pte);
>> if (--nr == 0)
>> break;
>> - ptep++;
>> + ptep = hw_pte_next(ptep);
>> pte = pte_next_pfn(pte);
>> }
>> }
>>
>> The bulk of work is this kind of rote substitution. The genuine work is the
>> handful of sites that turn out to be operating on a stack copy rather than a
>> live entry - those are exactly the ones the new type forces us to surface and
>> fix.
>>
>> Estimated churn:
>> ----------------
>> Half way through the prototyping converting only PTE and PMD levels:
>> 77 files changed, +1801 / -1425
>> ~57 files reference the new types
>>
>> So the line count will grow once PUD/P4D/PGD and the remaining call sites are
>> converted; expect meaningfully more churn than the numbers above.
>>
>> Introduce the type as an alias, convert one helper family per patch, and flip
>> an arch to the strong type last - with non-opted arches building unchanged at
>> every step.
>>
>> Open questions
>> --------------
>> - Is the type-safety + future-feature enablement worth the churn?
>> - Naming: hw_ptep/hw_pmdp vs something else?
>> - Should all five levels be converted before merging anything, or is a staged
>> PTE-and-PMD then landing others acceptable?
>> - Do we want the two getter flavours (pXXp_get / pXXp_get_once) at every
>> level?
>>
>> [1] https://lore.kernel.org/all/a063f6c5-2785-4a9f-8079-25edb3e54cef@arm.com
>>
>> Thanks,
>> Usama
>
>
>
>
--
Thanks,
Usama
^ permalink raw reply
* Re: [PATCH 2/7] i2c: nomadik: optimize layout of struct nmk_i2c_dev
From: Linus Walleij @ 2026-06-24 22:36 UTC (permalink / raw)
To: Dmitry Guzman
Cc: Andi Shyti, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
linux-i2c, linux-kernel, linux-trace-kernel, linux-arm-kernel
In-Reply-To: <20260623-i2c-fault-reporting-v1-2-6db1a8aabf18@mobileye.com>
Hi Dmitry,
thanks for your patch!
Also nice to see some kernel contributions directly from
MobilEye!
On Tue, Jun 23, 2026 at 6:32 PM Dmitry Guzman
<Dmitry.Guzman@mobileye.com> wrote:
> Put two bool variables `xfer_done` and `has_32b_bus` and two char
> variables `tft` and `rft` together in order to reduce struct size
> wasted for padding.
>
> Signed-off-by: Dmitry Guzman <Dmitry.Guzman@mobileye.com>
(...)
> struct nmk_i2c_dev {
> struct i2c_vendor_data *vendor;
> @@ -206,13 +206,13 @@ struct nmk_i2c_dev {
> u32 clk_freq;
> unsigned char tft;
> unsigned char rft;
^
Maybe you want to take the opportunity to change these
two into u8 if you're anyway changing the layout of this
struct?
Either way:
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2] arm64: tlbflush: Reset active_cpu on ASID rollover
From: Sayali Kulkarni @ 2026-06-24 22:13 UTC (permalink / raw)
To: Linu Cherian
Cc: catalin.marinas, linux-arm-kernel, linux-kernel, will,
ryan.roberts, yang, cl, sskulkarni
In-Reply-To: <ajQM4bkKfWdPowpM@a079125.arm.com>
[-- Attachment #1: Type: text/plain, Size: 3653 bytes --]
Thank you for catching this. After going through the patch again, I
realize that the race is real. Resetting active_cpu to ACTIVE_CPU_NONE on
rollover can leave it in an inconsistent state when stale entries still
live. Note that the rollover state entries themselves aren’t the issue.
Those are handled by the existing reserved_asids/tlb_flush_pending
mechanism. It’s specifically active_cpu’s own record going inconsistent.
For v3, I am exploring handling active_cpu together with the generation so
that the reset can’t open a NONE window. Doing it in the slow path after
local flush and updating to the current CPU rather than NONE. Does that
direction seem reasonable or is there a cleaner way to avoid the
under-claim window? Will follow up with a patch once it’s figured out.
Thanks,
Sayali
On Thu, 18 Jun 2026, Linu Cherian wrote:
> Hi,
>
> On Fri, Jun 12, 2026 at 04:21:06PM -0700, Sayali Kulkarni wrote:
>> From: Sayali Kulkarni <sskulkarni@amperecomputing.com>
>>
>> Hi Catalin,
>>
>> Thank you for the review. I’ve addressed your feedback in v2:
>>
>> - Moved `WRITE_ONCE(mm->context.active_cpu, ACTIVE_CPU_NONE)` from `check_and_switch_context()` to `new_context()` after the `set_asid` label. At this point, a brand new ASID has been allocated that no CPU has ever used, so the reset is safe even for multi-threaded processes where other CPUs may still be running with the old ASID via `reserved_asids`.
>> - Updated the commit message to correct the safety reasoning: `flush_context()` only sets `tlb_flush_pending`; it does not issue a global TLB flush.
>>
>> Thanks,
>> Sayali
>>
>>
>> Once active_cpu flips to ACTIVE_CPU_MULTIPLE it never resets, even if
>> the process settles back to one CPU. Reset it to ACTIVE_CPU_NONE in
>> new_context() after a new ASID is allocated at the set_asid label.
>>
>> At this point a brand new ASID has been assigned that no CPU has ever
>> used, so ACTIVE_CPU_NONE accurately reflects reality. Any other threads
>> of the same process continue running with the old ASID via
>> reserved_asids and are unaffected.
>>
>> This gives processes a fresh chance at the local-only flush fast path
>> after each ASID generation rollover.
>>
>> Signed-off-by: Sayali Kulkarni <sskulkarni@amperecomputing.com> (Ampere)
>> ---
>> arch/arm64/mm/context.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c
>> index f34ed78393e0..46c7fd07b9bf 100644
>> --- a/arch/arm64/mm/context.c
>> +++ b/arch/arm64/mm/context.c
>> @@ -209,6 +209,7 @@ static u64 new_context(struct mm_struct *mm)
>> set_asid:
>> __set_bit(asid, asid_map);
>> cur_idx = asid;
>> + WRITE_ONCE(mm->context.active_cpu, ACTIVE_CPU_NONE);
>
> Can the above store race with the store to active_cpu in another thread,
> that updates it to ACTIVE_CPU_MULTIPLE ?
>
> Lets say we have two threads both initially running in CPU 0,
>
> Thread 1: Runs in CPU 0
>
> Encounters a rollover, updates mm->context.active_cpu to ACTIVE_CPU_NONE and
> updates mm->context.id to new asid.
>
> Thread 2: Scheduled to run on CPU 1 for the first time
>
> Observes the updated mm->context.id that belongs to the current
> generation(after the rollover) and hence proceeds to switch_mm_fastpath
> and ends up updating the active_cpu to ACTIVE_CPU_MULTIPLE.
>
> If Thread 1 and Thread 2 races, then active_cpu can get corrupted ?
>
> The reason this could be possible is that, write to active_cpu and
> mm->context.id can get reordered and we need to enforce ordering for
> correctness ?
>
> Do you see this as a valid scenario ?
>
> --
> Thanks,
> Linu Cherian.
>
>
>
>
>
>
>
>
>
>
^ permalink raw reply
* Re: [PATCH v2 0/4] media: add and use fwnode_graph_for_each_endpoint_scoped()
From: Laurent Pinchart @ 2026-06-24 22:20 UTC (permalink / raw)
To: Frank Li
Cc: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mauro Carvalho Chehab, Dafna Hirschfeld, Heiko Stuebner,
Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
driver-core, linux-acpi, linux-kernel, linux-media,
linux-rockchip, linux-arm-kernel, linux-arm-msm, imx, Guoniu Zhou,
Frank Li, Guoniu Zhou
In-Reply-To: <ajxCOE3avXXLlrfT@SMW015318>
On Wed, Jun 24, 2026 at 03:46:48PM -0500, Frank Li wrote:
> On Wed, Jun 24, 2026 at 11:02:37PM +0300, Laurent Pinchart wrote:
> > On Wed, Jun 24, 2026 at 02:35:14PM -0500, Frank Li wrote:
> > > On Wed, Jun 24, 2026 at 10:19:35PM +0300, Laurent Pinchart wrote:
> > > > On Wed, Jun 24, 2026 at 01:00:08PM -0400, Frank.Li@oss.nxp.com wrote:
> > > > > Add new helper macro fwnode_graph_for_each_endpoint_scoped() and use it
> > > > > simplify media code.
> > > > >
> > > > > Typical example should qualcomm's driver (camss.c), the v4l2_mc.c and
> > > > > rkisp1-dev.c only silience improvement.
> > > > >
> > > > > Anyways, *_for_each_*_scoped() already use widely and make code clean.
> > > > >
> > > > > Build test only.
> > > > >
> > > > > Sakari Ailus:
> > > > > when I try to improve the patch
> > > > > "Add common helper library for 1-to-1 subdev registration", I found need
> > > > > camss.c pattern, so I create this small improvement firstly.
> > > >
> > > > Those are nice cleanups, thank you.
> > > >
> > > > After applying this series, the only left users of the
> > > > fwnode_graph_for_each_endpoint() macro are in drivers/base/property.c.
> > >
> > > I already checked previously, two place use it.
> > >
> > > fwnode_graph_get_endpoint_count(), it will go though all endpoints, last
> > > ep is NULL, which totally equial to scoped() version.
> > >
> > > another one fwnode_graph_get_endpoint_by_id(), which return ep, expect
> > > caller to call put().
> > >
> > > if use scoped() version, need use no_free_ptr() at return, which make think
> > > a little bit complex.
> >
> > It would introduce a tiny bit of extra complexity there, but the
> > advantage (in my opinion) is that we'll be able to remove the less safe
> > fwnode_graph_for_each_endpoint() macro.
> >
> > Now one may argue that the risk of
> > fwnode_graph_for_each_endpoint_scoped() is returning the iterator
> > without using no_free_ptr(). I wonder if that would be easier to catch
> > in static analysis tools than the current pattern that leaks a reference
> > when exiting the loop early.
>
> It's not big deal, if everyone prefer drop fwnode_graph_for_each_endpoint(),
> I can do it.
Let's see what others think. If people prefer keeping both versions,
I'll be OK with that.
> > > It'd better leave these as it.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v1 0/3] rtc: Use named initializers for platform_device_id arrays
From: Alexandre Belloni @ 2026-06-24 21:16 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub)
Cc: Benson Leung, Guenter Roeck, linux-rtc, chrome-platform,
linux-kernel, Linus Walleij, linux-arm-kernel, Karel Balej,
Matti Vaittinen, Chanwoo Choi, Krzysztof Kozlowski,
André Draszik, linux-samsung-soc
In-Reply-To: <cover.1779950275.git.u.kleine-koenig@baylibre.com>
On Thu, 28 May 2026 08:48:09 +0200, Uwe Kleine-König (The Capable Hub) wrote:
> this series targets to use named initializers for platform_device_id
> arrays. In general these are better readable for humans and more robust
> to changes in the respective struct definition.
>
> This robustness is needed as I want to do
>
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -610,4 +610,7 @@ struct dmi_system_id {
> struct platform_device_id {
> char name[PLATFORM_NAME_SIZE];
> - kernel_ulong_t driver_data;
> + union {
> + kernel_ulong_t driver_data;
> + const void *driver_data_ptr;
> + };
> };
>
> [...]
Applied, thanks!
[1/3] rtc: Drop unused assignment of platform_device_id driver data
https://git.kernel.org/abelloni/c/ba5dca876b54
[2/3] rtc: ab8500: Simplify driver_data handling
https://git.kernel.org/abelloni/c/6e2f1f0184da
[3/3] rtc: Use named initializers for platform_device_id arrays
https://git.kernel.org/abelloni/c/041ca8884410
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 0/2] rtc: aspeed: Add AST2700 RTC support
From: Alexandre Belloni @ 2026-06-24 21:16 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, Tommy Huang
Cc: linux-rtc, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed
In-Reply-To: <20260601-ast2700-rtc-v1-0-15d4ca46500a@aspeedtech.com>
On Mon, 01 Jun 2026 17:14:05 +0800, Tommy Huang wrote:
> This patch series adds support for the ASPEED AST2700 RTC define,
> includeing dt-binding in the Document and rtc-aspeed.c
Applied, thanks!
[1/2] dt-bindings: rtc: add ASPEED AST2700 compatible
https://git.kernel.org/abelloni/c/5e7f746bc106
[2/2] rtc: aspeed: add AST2700 compatible
https://git.kernel.org/abelloni/c/3319cfeeb8c4
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] rtc: msc313: fix NULL deref in shared IRQ handler at probe
From: Alexandre Belloni @ 2026-06-24 21:16 UTC (permalink / raw)
To: Stepan Ionichev
Cc: daniel, romain.perier, linux-arm-kernel, linux-rtc, linux-kernel
In-Reply-To: <20260511032703.48262-1-sozdayvek@gmail.com>
On Mon, 11 May 2026 08:27:03 +0500, Stepan Ionichev wrote:
> msc313_rtc_probe() calls devm_request_irq() with IRQF_SHARED and
> &pdev->dev as the cookie, but platform_set_drvdata() is only called
> later after the clock setup. With a shared IRQ line, another device
> on the same line can trigger the handler in that window. The
> handler does dev_get_drvdata() on the cookie, gets NULL, and
> dereferences priv->rtc_base in interrupt context.
>
> [...]
Applied, thanks!
[1/1] rtc: msc313: fix NULL deref in shared IRQ handler at probe
https://git.kernel.org/abelloni/c/a369f48be8de
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 4/8] firmware: smccc: lfa: Add timeout and trigger watchdog
From: Nirmoy Das @ 2026-06-24 20:46 UTC (permalink / raw)
To: Andre Przywara, Mark Rutland, Lorenzo Pieralisi, Sudeep Holla
Cc: vsethi, Salman Nabi, linux-kernel, vwadekar, Trilok Soni,
linux-arm-kernel
In-Reply-To: <20260317103336.1273582-5-andre.przywara@arm.com>
Hi Andre, Veda,
On 17.03.26 12:33, Andre Przywara wrote:
> From: Vedashree Vidwans <vvidwans@nvidia.com>
>
> Enhance PRIME/ACTIVATION functions to touch watchdog and implement
> timeout mechanism. This update ensures that any potential hangs are
> detected promptly and that the LFA process is allocated sufficient
> execution time before the watchdog timer expires. These changes improve
> overall system reliability by reducing the risk of undetected process
> stalls and unexpected watchdog resets.
>
> Signed-off-by: Vedashree Vidwans <vvidwans@nvidia.com>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> drivers/firmware/smccc/lfa_fw.c | 43 ++++++++++++++++++++++++++++++---
> 1 file changed, 39 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/firmware/smccc/lfa_fw.c b/drivers/firmware/smccc/lfa_fw.c
> index 4831abf2b60e..d1b5cd29b8a0 100644
> --- a/drivers/firmware/smccc/lfa_fw.c
> +++ b/drivers/firmware/smccc/lfa_fw.c
> @@ -5,11 +5,14 @@
>
> #include <linux/arm-smccc.h>
> #include <linux/array_size.h>
> +#include <linux/delay.h>
> #include <linux/fs.h>
> #include <linux/init.h>
> #include <linux/kobject.h>
> +#include <linux/ktime.h>
> #include <linux/list.h>
> #include <linux/module.h>
> +#include <linux/nmi.h>
> #include <linux/psci.h>
> #include <linux/stop_machine.h>
> #include <linux/string.h>
> @@ -38,6 +41,11 @@
> #define LFA_PRIME_CALL_AGAIN BIT(0)
> #define LFA_ACTIVATE_CALL_AGAIN BIT(0)
>
> +#define LFA_PRIME_BUDGET_MS 30000 /* 30s cap */
> +#define LFA_PRIME_DELAY_MS 10 /* 10ms between polls */
> +#define LFA_ACTIVATE_BUDGET_MS 10000 /* 10s cap */
> +#define LFA_ACTIVATE_DELAY_MS 10 /* 10ms between polls */
> +
> /* LFA return values */
> #define LFA_SUCCESS 0
> #define LFA_NOT_SUPPORTED 1
> @@ -287,6 +295,7 @@ static int call_lfa_activate(void *data)
> struct fw_image *image = data;
> struct arm_smccc_1_2_regs reg = { 0 }, res;
>
> + touch_nmi_watchdog();
> reg.a0 = LFA_1_0_FN_ACTIVATE;
> reg.a1 = image->fw_seq_id;
> /*
> @@ -310,6 +319,7 @@ static int call_lfa_activate(void *data)
>
> static int activate_fw_image(struct fw_image *image)
> {
> + ktime_t end = ktime_add_ms(ktime_get(), LFA_ACTIVATE_BUDGET_MS);
> int ret;
>
> retry:
> @@ -324,8 +334,15 @@ static int activate_fw_image(struct fw_image *image)
> return 0;
> }
>
> - if (ret == -LFA_CALL_AGAIN)
> - goto retry;
> + if (ret == -LFA_CALL_AGAIN) {
> + /* SMC returned with call_again flag set */
> + if (ktime_before(ktime_get(), end)) {
> + msleep_interruptible(LFA_ACTIVATE_DELAY_MS);
> + goto retry;
> + }
> +
> + ret = -LFA_TIMED_OUT;
> + }
>
> lfa_cancel(image);
Correct me if I am wrong here
DEN0147 2.6.6: LFA_ACTIVATE can return LFA_BUSY ("activation postponed
... prime status not changed"), i.e. retriable like CALL_AGAIN. So we need:
if (ret == -LFA_BUSY) {
if (ktime_before(ktime_get(), end)) {
msleep_interruptible(LFA_ACTIVATE_DELAY_MS);
goto retry;
}
ret = -LFA_TIMED_OUT;
}
Regards,
Nirmoy
>
> @@ -338,6 +355,8 @@ static int activate_fw_image(struct fw_image *image)
> static int prime_fw_image(struct fw_image *image)
> {
> struct arm_smccc_1_2_regs reg = { 0 }, res;
> + ktime_t end = ktime_add_ms(ktime_get(), LFA_PRIME_BUDGET_MS);
> + int ret;
>
> if (image->may_reset_cpu) {
> pr_err("CPU reset not supported by kernel driver\n");
> @@ -345,6 +364,8 @@ static int prime_fw_image(struct fw_image *image)
> return -EINVAL;
> }
>
> + touch_nmi_watchdog();
> +
> reg.a0 = LFA_1_0_FN_PRIME;
> retry:
> /*
> @@ -363,8 +384,22 @@ static int prime_fw_image(struct fw_image *image)
> return res.a0;
> }
>
> - if (res.a1 & LFA_PRIME_CALL_AGAIN)
> - goto retry;
> + if (res.a1 & LFA_PRIME_CALL_AGAIN) {
> + /* SMC returned with call_again flag set */
> + if (ktime_before(ktime_get(), end)) {
> + msleep_interruptible(LFA_PRIME_DELAY_MS);
> + goto retry;
> + }
> +
> + pr_err("LFA_PRIME for image %s timed out",
> + get_image_name(image));
> +
> + ret = lfa_cancel(image);
> + if (ret != 0)
> + return ret;
> +
> + return -ETIMEDOUT;
> + }
>
> return 0;
> }
^ permalink raw reply
* Re: [PATCH v2 0/4] media: add and use fwnode_graph_for_each_endpoint_scoped()
From: Frank Li @ 2026-06-24 20:46 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Andy Shevchenko, Daniel Scally, Heikki Krogerus, Sakari Ailus,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Mauro Carvalho Chehab, Dafna Hirschfeld, Heiko Stuebner,
Bryan O'Donoghue, Vladimir Zapolskiy, Loic Poulain,
driver-core, linux-acpi, linux-kernel, linux-media,
linux-rockchip, linux-arm-kernel, linux-arm-msm, imx, Guoniu Zhou,
Frank Li, Guoniu Zhou
In-Reply-To: <20260624200237.GJ851255@killaraus.ideasonboard.com>
On Wed, Jun 24, 2026 at 11:02:37PM +0300, Laurent Pinchart wrote:
> On Wed, Jun 24, 2026 at 02:35:14PM -0500, Frank Li wrote:
> > On Wed, Jun 24, 2026 at 10:19:35PM +0300, Laurent Pinchart wrote:
> > > On Wed, Jun 24, 2026 at 01:00:08PM -0400, Frank.Li@oss.nxp.com wrote:
> > > > Add new helper macro fwnode_graph_for_each_endpoint_scoped() and use it
> > > > simplify media code.
> > > >
> > > > Typical example should qualcomm's driver (camss.c), the v4l2_mc.c and
> > > > rkisp1-dev.c only silience improvement.
> > > >
> > > > Anyways, *_for_each_*_scoped() already use widely and make code clean.
> > > >
> > > > Build test only.
> > > >
> > > > Sakari Ailus:
> > > > when I try to improve the patch
> > > > "Add common helper library for 1-to-1 subdev registration", I found need
> > > > camss.c pattern, so I create this small improvement firstly.
> > >
> > > Those are nice cleanups, thank you.
> > >
> > > After applying this series, the only left users of the
> > > fwnode_graph_for_each_endpoint() macro are in drivers/base/property.c.
> >
> > I already checked previously, two place use it.
> >
> > fwnode_graph_get_endpoint_count(), it will go though all endpoints, last
> > ep is NULL, which totally equial to scoped() version.
> >
> > another one fwnode_graph_get_endpoint_by_id(), which return ep, expect
> > caller to call put().
> >
> > if use scoped() version, need use no_free_ptr() at return, which make think
> > a little bit complex.
>
> It would introduce a tiny bit of extra complexity there, but the
> advantage (in my opinion) is that we'll be able to remove the less safe
> fwnode_graph_for_each_endpoint() macro.
>
> Now one may argue that the risk of
> fwnode_graph_for_each_endpoint_scoped() is returning the iterator
> without using no_free_ptr(). I wonder if that would be easier to catch
> in static analysis tools than the current pattern that leaks a reference
> when exiting the loop early.
It's not big deal, if everyone prefer drop fwnode_graph_for_each_endpoint(),
I can do it.
Frank
>
> > It'd better leave these as it.
>
> --
> Regards,
>
> Laurent Pinchart
^ 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