* 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 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: [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 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
* [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
* [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] 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] 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
* [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
* [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
* 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
* 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] 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 v8 2/5] thermal: samsung: Add Exynos ACPM TMU driver GS101
From: Alexey Klimov @ 2026-06-25 1:32 UTC (permalink / raw)
To: Tudor Ambarus, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartlomiej Zolnierkiewicz, Krzysztof Kozlowski, Kees Cook,
Gustavo A. R. Silva, Peter Griffin, André Draszik,
Alim Akhtar
Cc: jyescas, linux-kernel, linux-samsung-soc, linux-pm, devicetree,
linux-hardening, linux-arm-kernel, Krzysztof Kozlowski
In-Reply-To: <20260603-acpm-tmu-v8-2-0f1810a356e6@linaro.org>
On Wed Jun 3, 2026 at 2:00 PM BST, Tudor Ambarus wrote:
> Add driver for the Thermal Management Unit (TMU) managed via the Alive
> Clock and Power Manager (ACPM), found on Samsung Exynos SoCs such as
> the Google GS101.
>
> The TMU on the GS101 utilizes a hybrid management model shared between
> the Application Processor (AP) and the ACPM firmware. The driver
> maintains direct memory-mapped access to the TMU interrupt pending
> registers to identify thermal events, while delegating functional
> tasks - such as sensor initialization, threshold configuration, and
> temperature acquisition, to the ACPM firmware via the ACPM IPC
> protocol.
[..]
> +++ b/drivers/thermal/samsung/acpm-tmu.c
[...]
> +static struct platform_driver acpm_tmu_driver = {
> + .driver = {
> + .name = "gs-tmu",
Should it be "gs-tmu" still?
https://lore.kernel.org/linux-samsung-soc/56c1bb6d-54e4-4977-bd88-9ce7a6086b1d@linaro.org/
> + .pm = pm_ptr(&acpm_tmu_pm_ops),
> + .of_match_table = acpm_tmu_match,
> + },
> + .probe = acpm_tmu_probe,
> + .remove = acpm_tmu_remove,
> +};
> +module_platform_driver(acpm_tmu_driver);
Thanks,
Alexey
^ permalink raw reply
* RE: [PATCH v6 2/9] dt-bindings: media: nxp: Add Wave6 video codec device
From: Nas Chung @ 2026-06-25 1:43 UTC (permalink / raw)
To: Conor Dooley
Cc: mchehab@kernel.org, hverkuil@xs4all.nl, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-imx@nxp.com, linux-arm-kernel@lists.infradead.org,
jackson.lee, lafley.kim, marek.vasut@mailbox.org
In-Reply-To: <20260624-junkyard-sensuous-fcd43189b593@spud>
Hi, Conor.
>-----Original Message-----
>From: Conor Dooley <conor@kernel.org>
>Sent: Thursday, June 25, 2026 1:42 AM
>To: Nas Chung <nas.chung@chipsnmedia.com>
>Cc: mchehab@kernel.org; hverkuil@xs4all.nl; robh@kernel.org;
>krzk+dt@kernel.org; conor+dt@kernel.org; shawnguo@kernel.org;
>s.hauer@pengutronix.de; linux-media@vger.kernel.org;
>devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-imx@nxp.com;
>linux-arm-kernel@lists.infradead.org; jackson.lee
><jackson.lee@chipsnmedia.com>; lafley.kim <lafley.kim@chipsnmedia.com>;
>marek.vasut@mailbox.org
>Subject: Re: [PATCH v6 2/9] dt-bindings: media: nxp: Add Wave6 video codec
>device
>
>On Wed, Jun 24, 2026 at 04:20:36PM +0900, Nas Chung wrote:
>> Add documentation for the Chips&Media Wave6 video codec on NXP i.MX SoCs.
>>
>> The hardware contains one control register region and four interface
>> register regions for a shared video processing engine. The control region
>> manages shared resources such as firmware memory, while each interface
>> region has its own MMIO range and interrupt.
>>
>> The control region and each interface region are distinct DMA requesters
>> and can be associated with separate IOMMU stream IDs. Represent the
>> control region as the parent node and the interface register regions as
>> child nodes to describe these resources.
>>
>> Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
>> ---
>> .../bindings/media/nxp,imx95-vpu.yaml | 163 ++++++++++++++++++
>> MAINTAINERS | 7 +
>> 2 files changed, 170 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/media/nxp,imx95-
>vpu.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
>b/Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
>> new file mode 100644
>> index 000000000000..9a5ca53e15a3
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
>> @@ -0,0 +1,163 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/media/nxp,imx95-vpu.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Chips&Media Wave6 Series multi-standard codec IP on NXP i.MX SoCs
>> +
>> +maintainers:
>> + - Nas Chung <nas.chung@chipsnmedia.com>
>> + - Jackson Lee <jackson.lee@chipsnmedia.com>
>> +
>> +description:
>> + The Chips&Media Wave6 codec IP is a multi-standard video
>encoder/decoder.
>> + On NXP i.MX SoCs, the Wave6 codec IP exposes one control register
>region and
>> + four interface register regions for a shared video processing engine.
>> + The parent node describes the control region, which has its own MMIO
>range and
>> + manages shared resources such as firmware memory. The child nodes
>describe the
>> + interface register regions. Each interface region has its own MMIO
>range and
>> + interrupt.
>> + The control region and the interface regions are distinct DMA
>requesters.
>> + The control region and each interface region can be associated with
>separate
>> + IOMMU stream IDs, allowing DMA isolation between them.
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - nxp,imx95-vpu
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + clocks:
>> + items:
>> + - description: VPU core clock
>> + - description: VPU associated block clock
>> +
>> + clock-names:
>> + items:
>> + - const: core
>> + - const: vpublk
>> +
>> + power-domains:
>> + items:
>> + - description: Main VPU power domain
>> + - description: Performance power domain
>> +
>> + power-domain-names:
>> + items:
>> + - const: vpu
>> + - const: perf
>> +
>> + memory-region:
>> + maxItems: 1
>> +
>> + sram:
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + description:
>> + phandle to the SRAM node used to store reference data, reducing DMA
>> + memory bandwidth.
>> +
>> + iommus:
>> + maxItems: 1
>> +
>> + "#cooling-cells":
>> + const: 2
>> +
>> + "#address-cells":
>> + const: 2
>> +
>> + "#size-cells":
>> + const: 2
>> +
>> + ranges: true
>> +
>> +patternProperties:
>> + "^interface@[0-9a-f]+$":
>
>I have to wonder if this interface business is required at all.
>Why can this not go into the parent, with each region fetchable via
>reg-names, interrupt-names and iommu-names?
Thanks for your feedback.
I did try the flat model, but the blocker is the IOMMU.
The control region and four interface regions are independent DMA requesters
with distinct stream IDs, and each interface can be assigned to a different VM,
driving the video core with its own isolated memory.
If all stream IDs are listed under the parent's iommus, they bind to a
single device and share one domain, so the isolation is lost.
This is the main reason I added the interface nodes.
Thanks.
Nas.
>
>Cheers,
>Conor.
>
>> + type: object
>> + description:
>> + An interface register region within the Chips&Media Wave6 codec IP.
>> + Each region has its own MMIO range and interrupt and can be
>associated
>> + with a separate IOMMU stream ID for DMA isolation.
>> + additionalProperties: false
>> +
>> + properties:
>> + reg:
>> + maxItems: 1
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> + iommus:
>> + maxItems: 1
>> +
>> + required:
>> + - reg
>> + - interrupts
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - clocks
>> + - clock-names
>> + - power-domains
>> + - power-domain-names
>> + - memory-region
>> + - "#address-cells"
>> + - "#size-cells"
>> + - ranges
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>> + #include <dt-bindings/clock/nxp,imx95-clock.h>
>> +
>> + soc {
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> +
>> + video-codec@4c4c0000 {
>> + compatible = "nxp,imx95-vpu";
>> + reg = <0x0 0x4c4c0000 0x0 0x10000>;
>> + clocks = <&scmi_clk 115>,
>> + <&vpu_blk_ctrl IMX95_CLK_VPUBLK_WAVE>;
>> + clock-names = "core", "vpublk";
>> + power-domains = <&scmi_devpd 21>,
>> + <&scmi_perf 10>;
>> + power-domain-names = "vpu", "perf";
>> + memory-region = <&vpu_boot>;
>> + sram = <&sram1>;
>> + iommus = <&smmu 0x32>;
>> + #cooling-cells = <2>;
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>> +
>> + interface@4c480000 {
>> + reg = <0x0 0x4c480000 0x0 0x10000>;
>> + interrupts = <GIC_SPI 299 IRQ_TYPE_LEVEL_HIGH>;
>> + iommus = <&smmu 0x33>;
>> + };
>> +
>> + interface@4c490000 {
>> + reg = <0x0 0x4c490000 0x0 0x10000>;
>> + interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
>> + iommus = <&smmu 0x34>;
>> + };
>> +
>> + interface@4c4a0000 {
>> + reg = <0x0 0x4c4a0000 0x0 0x10000>;
>> + interrupts = <GIC_SPI 301 IRQ_TYPE_LEVEL_HIGH>;
>> + iommus = <&smmu 0x35>;
>> + };
>> +
>> + interface@4c4b0000 {
>> + reg = <0x0 0x4c4b0000 0x0 0x10000>;
>> + interrupts = <GIC_SPI 302 IRQ_TYPE_LEVEL_HIGH>;
>> + iommus = <&smmu 0x36>;
>> + };
>> + };
>> + };
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index efbf808063e5..77ea3a1a966b 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -28688,6 +28688,13 @@ S: Maintained
>> F: Documentation/devicetree/bindings/media/cnm,wave521c.yaml
>> F: drivers/media/platform/chips-media/wave5/
>>
>> +WAVE6 VPU CODEC DRIVER
>> +M: Nas Chung <nas.chung@chipsnmedia.com>
>> +M: Jackson Lee <jackson.lee@chipsnmedia.com>
>> +L: linux-media@vger.kernel.org
>> +S: Maintained
>> +F: Documentation/devicetree/bindings/media/nxp,imx95-vpu.yaml
>> +
>> WHISKEYCOVE PMIC GPIO DRIVER
>> M: Kuppuswamy Sathyanarayanan
><sathyanarayanan.kuppuswamy@linux.intel.com>
>> L: linux-gpio@vger.kernel.org
>> --
>> 2.31.1
>>
^ permalink raw reply
* RE: [External Mail] Re: [PATCH v3 0/7] net: wwan: t9xx: Add MediaTek T9XX WWAN driver
From: Wu. JackBB (GSM) @ 2026-06-25 1:55 UTC (permalink / raw)
To: Jakub Kicinski
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: <20260624170917.09967c74@kernel.org>
Hi Jakub,
> 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.
Sorry about the confusion.
I have a question about the preferred workflow: the cover
letter changelog would get quite long if I include detailed
explanations for each sashiko comment we chose not to fix.
Was the concern more about timing? Should we have replied
to the sashiko review promptly when it came in, rather than
waiting until the full v3 was ready?
Thanks for the guidance.
================================================================================================================================================================
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.
================================================================================================================================================================
^ permalink raw reply
* Re: [PATCH net v3] net: airoha: fix BQL underflow in shared QDMA TX ring
From: patchwork-bot+netdevbpf @ 2026-06-25 2:00 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, win847,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260620-airoha-bql-fixes-v3-1-76b95374e63e@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sat, 20 Jun 2026 17:04:51 +0200 you wrote:
> When multiple netdevs share a QDMA TX ring and one device is stopped,
> netdev_tx_reset_subqueue() zeroes that device's BQL counters while its
> pending skbs remain in the shared HW TX ring. When NAPI later completes
> those skbs via netdev_tx_completed_queue(), the already-zeroed
> dql->num_queued counter underflows.
>
> Fix the issue:
> - Remove netdev_tx_reset_subqueue() from airoha_dev_stop() so pending
> skbs are completed naturally by NAPI with proper BQL accounting.
> - Rework airoha_qdma_tx_cleanup() to disable TX DMA, flush BQL
> counters, DMA-unmap and free all pending skbs while skb->dev
> references are still valid. Use a per-queue flushing flag checked
> under q->lock in airoha_dev_xmit() to prevent races between teardown
> and transmit. Call airoha_qdma_stop_napi() before
> airoha_qdma_tx_cleanup() at the call sites.
> - Move DMA engine start into probe. Split DMA teardown so TX DMA is
> disabled in airoha_qdma_tx_cleanup() and RX DMA in
> airoha_qdma_cleanup().
> - Remove qdma->users counter since DMA lifetime is now tied to
> probe/cleanup rather than per-netdev open/stop.
>
> [...]
Here is the summary with links:
- [net,v3] net: airoha: fix BQL underflow in shared QDMA TX ring
https://git.kernel.org/netdev/net/c/611709830945
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 v6 9/9] arm64: dts: freescale: imx95: Add video codec node
From: Nas Chung @ 2026-06-25 2:11 UTC (permalink / raw)
To: Francesco Dolcini
Cc: mchehab@kernel.org, hverkuil@xs4all.nl, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, shawnguo@kernel.org,
s.hauer@pengutronix.de, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-imx@nxp.com, linux-arm-kernel@lists.infradead.org,
jackson.lee, lafley.kim, marek.vasut@mailbox.org
In-Reply-To: <20260624115050.GA38214@francesco-nb>
Hi, Francesco.
>-----Original Message-----
>From: Francesco Dolcini <francesco@dolcini.it>
>Sent: Wednesday, June 24, 2026 8:51 PM
>To: Nas Chung <nas.chung@chipsnmedia.com>
>Cc: mchehab@kernel.org; hverkuil@xs4all.nl; robh@kernel.org;
>krzk+dt@kernel.org; conor+dt@kernel.org; shawnguo@kernel.org;
>s.hauer@pengutronix.de; linux-media@vger.kernel.org;
>devicetree@vger.kernel.org; linux-kernel@vger.kernel.org; linux-imx@nxp.com;
>linux-arm-kernel@lists.infradead.org; jackson.lee
><jackson.lee@chipsnmedia.com>; lafley.kim <lafley.kim@chipsnmedia.com>;
>marek.vasut@mailbox.org
>Subject: Re: [PATCH v6 9/9] arm64: dts: freescale: imx95: Add video codec
>node
>
>On Wed, Jun 24, 2026 at 04:20:43PM +0900, Nas Chung wrote:
>> Add the Chips and Media wave633 video codec node on IMX95 SoCs.
>>
>> Signed-off-by: Nas Chung <nas.chung@chipsnmedia.com>
>> ---
>> .../boot/dts/freescale/imx95-19x19-evk.dts | 11 ++++++
>> arch/arm64/boot/dts/freescale/imx95.dtsi | 36 +++++++++++++++++++
>> 2 files changed, 47 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
>b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
>> index 041fd838fabb..7edd1c69966a 100644
>> --- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
>> +++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
>> @@ -76,6 +76,11 @@ linux_cma: linux,cma {
>> linux,cma-default;
>> reusable;
>> };
>> +
>> + vpu_boot: memory@a0000000 {
>> + reg = <0 0xa0000000 0 0x100000>;
>> + no-map;
>> + };
>> };
>>
>> flexcan1_phy: can-phy0 {
>> @@ -1142,3 +1147,9 @@ &tpm6 {
>> pinctrl-0 = <&pinctrl_tpm6>;
>> status = "okay";
>> };
>> +
>> +&vpu {
>> + memory-region = <&vpu_boot>;
>> + sram = <&sram1>;
>
>Can the `sram` node moved to imx95.dtsi or not?
Thanks for your feedback.
Agreed, I'll move the sram property to imx95.dtsi in v7.
Thanks.
Nas.
>
>Francesco
^ permalink raw reply
* Re: [PATCH] net: stmmac: fix missed le32_to_cpu()
From: Jakub Kicinski @ 2026-06-25 2:22 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Ben Dooks, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Russell King (Oracle), netdev, linux-stm32, linux-arm-kernel,
linux-kernel
In-Reply-To: <b375d36c-112e-4662-b538-fd10fa927ecc@bootlin.com>
On Mon, 22 Jun 2026 19:51:39 +0200 Maxime Chevallier wrote:
> Hi Ben,
>
> On 6/22/26 16:37, Ben Dooks wrote:
> > The print in ndesc_display_ring() sends the des2 and des3
> > to the pr_info() without passing them through the relevant
> > conversion to cpu order.
> >
> > Fix the (prototype) sparse warnings by using le32_to_cpu():
> > drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: warning: incorrect type in argument 6 (different base types)
> > drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: expected unsigned int
> > drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: got restricted __le32 [usertype] des2
> > drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: warning: incorrect type in argument 7 (different base types)
> > drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: expected unsigned int
> > drivers/net/ethernet/stmicro/stmmac/norm_desc.c:258:17: got restricted __le32 [usertype] des3
> >
> > Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
>
> I agree on the principle, but this isn't a fix so this'll have to wait
> until net-next re-opens :)
Humpf, why are we not seeing this on x86 allmodconfig ? 🤔️
$ make C=1 W=1 drivers/net/ethernet/stmicro/stmmac/norm_desc.o
DESCEND objtool
CC [M] drivers/net/ethernet/stmicro/stmmac/norm_desc.o
CHECK drivers/net/ethernet/stmicro/stmmac/norm_desc.c
$
^ permalink raw reply
* Re: [PATCH 1/8] clk: qcom: dispcc-sm8450: Fix mdss clocks
From: Esteban Urrutia @ 2026-06-25 2:22 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Will Deacon, Robin Murphy,
Joerg Roedel (AMD), Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, iommu,
linux-arm-kernel, linux-phy
In-Reply-To: <65873506-1a9a-40ec-ac67-60f61a0b4b4c@oss.qualcomm.com>
On 6/23/26 11:50 AM, Konrad Dybcio wrote:
> This can also be fixed by migrating to use qcom_cc_driver_data,
> which takes a list of alpha PLLs to be configured, and thenthere's
> a switch-statement in clk-alpha-pll.c that always assigns the
> correct function
If this is done, should a patch that migrates to qcom_cc_driver_data and a
patch that fixes the issue be sent, or should only a single patch be sent?
Regards,
Esteban
^ permalink raw reply
* Re: [PATCH v3 00/12] arm64: Add HOTPLUG_PARALLEL support for secondary CPUs
From: Jinjie Ruan @ 2026-06-25 1:34 UTC (permalink / raw)
To: Will Deacon
Cc: catalin.marinas, tsbogend, tglx, mingo, bp, dave.hansen, hpa,
peterz, kees, nathan, linusw, ojeda, david.kaplan, lukas.bulwahn,
ryan.roberts, maz, timothy.hayes, lpieralisi, thuth,
menglong8.dong, oupton, yeoreum.yun, miko.lenczewski, broonie,
kevin.brodsky, james.clark, yangyicong, tabba, osandov, arnd,
anshuman.khandual, david, akpm, ljs, dev.jain, yang,
chaitanyas.prakash, kprateek.nayak, chenl311, sshegde,
thorsten.blum, chang.seok.bae, tim.c.chen, x86, linux-kernel,
linux-arm-kernel, linux-mips
In-Reply-To: <ajvKkLw5bL-FT5JC@willie-the-truck>
On 6/24/2026 8:16 PM, Will Deacon wrote:
> On Wed, Jun 24, 2026 at 05:25:25PM +0800, Jinjie Ruan wrote:
>> Support for parallel secondary CPU bringup is already utilized by x86,
>> MIPS, and RISC-V. This patch brings this capability to the arm64
>> architecture.
>>
>> Introduce CONFIG_HOTPLUG_PARALLEL_SMT to avoid primary SMT threads
>> to boot first constraint.
>>
>> And add a 'cpu' parameter to update_cpu_boot_status() to allow updating
>> the boot status at a per-CPU granularity during parallel bringup.
>>
>> Rework the global `secondary_data` and `__early_cpu_boot_status` accessed
>> during early boot into per-CPU arrays to allow secondary CPUs to boot
>> in parallel.
>>
>> And reuse `__cpu_logical_map` array in the early boot code in head.S
>> to resolve each secondary CPU's logical ID concurrently.
>>
>> This series includes a subset of the refactoring patches proposed
>> by Will Deacon, with further adjustments.
>
> Sheesh, Jinjie, what are you doing?
>
> I said yesterday that I would dust off the old series after the merge
> window:
>
> https://lore.kernel.org/all/ajqYaklhIyvaNLlk@willie-the-truck/
>
> "Please just give me a week or so to rebase my changes and send them out
> for discussion"
>
> but instead, you've posted patches from me that are missing a bunch of
> fixes that need to be folded back in:
>
> https://web.git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/commit/?h=cpu-hotplug&id=2d5b8df5d4e2bbc142e3b4f21cabbca96e3da79d
>
Hi Will,
I am terribly sorry for my impatience and the confusion this has caused.
I completely misread the situation and shouldn't have posted those
incomplete patches, especially when you explicitly asked for a week to
rebase them properly.
> so now you're asking people to review incomplete patches from somebody
> else.
>
> Please just give me the time I asked for. If you want to help out in the
> meantime, there are plenty of patches that need reviewing...
It was a mistake on my part, and I sincerely apologize for wasting
community review resources and disrupting your schedule.
I will absolutely back off now and wait for your official series. Lesson
learned. Thanks for your patience and for calling me out on this.
Best regards,
Jinjie
>
> Will
>
^ permalink raw reply
* Re: [PATCH 6.1 337/522] arm64/mm: Enable batched TLB flush in unmap_hotplug_range()
From: Anshuman Khandual @ 2026-06-25 2:29 UTC (permalink / raw)
To: Greg Kroah-Hartman, Ryan Roberts
Cc: Will Deacon, Ben Hutchings, Catalin Marinas,
David Hildenbrand (Arm), patches, linux-arm-kernel, linux-kernel,
Sasha Levin, stable, mark.rutland
In-Reply-To: <2026062451-bluff-coherent-672d@gregkh>
On 24/06/26 9:59 PM, Greg Kroah-Hartman wrote:
> On Wed, Jun 24, 2026 at 04:05:01PM +0100, Ryan Roberts wrote:
>> On 23/06/2026 15:25, Will Deacon wrote:
>>> On Sun, Jun 21, 2026 at 05:02:27PM +0200, Ben Hutchings wrote:
>>>> On Tue, 2026-06-16 at 20:28 +0530, Greg Kroah-Hartman wrote:
>>>>> 6.1-stable review patch. If anyone has any objections, please let me know.
>>>>>
>>>>> ------------------
>>>>>
>>>>> From: Anshuman Khandual <anshuman.khandual@arm.com>
>>>>>
>>>>> [ Upstream commit 48478b9f791376b4b89018d7afdfd06865498f65 ]
>>>> [...]
>>>>> @@ -949,15 +953,14 @@ static void unmap_hotplug_pmd_range(pud_
>>>>> WARN_ON(!pmd_present(pmd));
>>>>> if (pmd_sect(pmd)) {
>>>>> pmd_clear(pmdp);
>>>>> -
>>>>> - /*
>>>>> - * One TLBI should be sufficient here as the PMD_SIZE
>>>>> - * range is mapped with a single block entry.
>>>>> - */
>>>>> - flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
>>>>> - if (free_mapped)
>>>>> + if (free_mapped) {
>>>>> + /* CONT blocks are not supported in the vmemmap */
>>>>> + WARN_ON(pmd_cont(pmd));
>>>>> + flush_tlb_kernel_range(addr, addr + PMD_SIZE);
>>>>
>>>> It wasn't clear to me from the commit message why this now adds PMD_SIZE
>>>> rather than PAGE_SIZE. It seems like this change is fine for Linux
>>>> 6.13+ with a CPU that supports TLB range flushing, but otherwise results
>>>> in unnecessarily executing multiple TLB invalidations at intervals of
>>>> the base page size.
>>>
>>> Hmm, the commit message also makes very little sense to me and so I don't
>>> understand why this patch has us doing multiple TLB invalidations when
>>> we run into a !cont, block mapping at the PMD level. The old comment
>>> (which this patch removes) should still apply afaict.
>>>
>>> Anshuman, Ryan, any ideas what's going on here?
>>
>> I think this change was probably my fault; Given the API is called
>> flush_tlb_kernel_range() it seemed like an abuse/hack to pretend we are only
>> flushing the first PAGE_SIZE of the range. But as I understand it, even if the
>> HW shatters a block mapping into multiple TLB entries, all of the entries
>> relating to the block mapping will be invalidated if just one of them intersects
>> the TLBI range/address. So it should be safe to reapply this hack.
>>
>> Although ideally I think it would be better if this API took a stride argument;
>> then intent is clear.
>>
>> What's the best way to handle this? Submit a patch for mainline that reverts
>> this part, then get it backported to stable (implying this current patch will
>> have been applied to stable)?
>
> yes, that's probably the best way.
Sure, will send out the change as suggested.
^ permalink raw reply
* [PATCH v2 0/4] phy: nuvoton: extend MA35D1 USB2 PHY driver for dual-port OTG support
From: Joey Lu @ 2026-06-25 2:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Catalin Marinas, Jacky Huang, Shan-Chun Hung, Hui-Ping Chen,
Joey Lu, linux-phy, devicetree, linux-arm-kernel, linux-kernel,
Joey Lu
The MA35D1 SoC has two USB PHY ports managed by a shared hardware block:
- PHY0 (USB0): OTG port shared between the DWC2 gadget controller and
the EHCI0/OHCI0 host controllers. A hardware mux automatically routes
USB0 signals to the correct controller based on the USB ID pin.
- PHY1 (USB1): dedicated host-only port for EHCI1/OHCI1.
A previous series [1] added a separate phy-ma35d1-otg.c driver for this.
Following reviewer suggestion to reuse the existing phy-ma35d1-usb2.c
driver rather than introduce a new one, that series has been dropped and
this series instead extends the existing driver.
Changes in this series:
Patch 1 (new) adds simple-mfd support to the nuvoton,ma35d1-reset
syscon binding. The sys node needs to act as an MFD parent so that
usb-phy@60 can be its DT child. This patch is a prerequisite for
patch 2 and has no functional impact on existing users of the syscon.
Patch 2 updates the nuvoton,ma35d1-usb2-phy binding: the PHY node
becomes a child of the syscon node (reg = <0x60 0x14>), nuvoton,sys
phandle and clocks are removed, and #phy-cells changes from 0 to 1
for per-port selection. Optional nuvoton,rcalcode and
nuvoton,oc-active-high properties are added.
Patch 3 updates the MA35D1 DTS: sys gains simple-mfd, usb-phy@60 is
added as a syscon child, and DWC2/EHCI0/EHCI1/OHCI0/OHCI1 nodes are
added. Board files enable the nodes and add pinctrl for the HSUSB
signals (VBUSVLD, PWREN, OVC).
Patch 4 extends phy-ma35d1-usb2.c: a loop creates two struct phy
objects; a unified .init handles both ports with parametric register
macros; clock management is removed (each controller gates its own
clock); a read-only USB role switch is registered for PHY0 reporting
the USB ID pin via PWRONOTP[16].
Changes since v1:
- New patch 1: nuvoton,ma35d1-reset binding extended for simple-mfd
and child node support; required as a prerequisite for the PHY
binding which places usb-phy@60 as a syscon child.
- Patch 2 (was patch 1): nuvoton,rcalcode description updated to
clarify that both PHY entries are individually optional; example
reg corrected from 4-cell to 2-cell format.
- Patch 3 (was patch 2): ehci1 node address corrected to lowercase
(401c0000).
- Patch 4 (was patch 3): register definition section header comments
added; HOST_READY and DEV_READY macro comments made more
descriptive; ma35_role_switch_exit() added to the PHY provider
registration error path to prevent a role switch leak.
Link: [1] https://lore.kernel.org/linux-phy/20260604101220.1092822-1-a0987203069@gmail.com/T/#t
Joey Lu (4):
dt-bindings: reset: nuvoton,ma35d1-reset: add simple-mfd and child
node support
dt-bindings: phy: nuvoton,ma35d1-usb2-phy: extend for dual-port OTG
support
arm64: dts: nuvoton: ma35d1: add USB controllers and dual-port PHY
node
phy: nuvoton: phy-ma35d1-usb2: extend to dual-port with OTG support
.../bindings/phy/nuvoton,ma35d1-usb2-phy.yaml | 62 +++-
.../bindings/reset/nuvoton,ma35d1-reset.yaml | 13 +-
.../boot/dts/nuvoton/ma35d1-iot-512m.dts | 36 +++
.../boot/dts/nuvoton/ma35d1-som-256m.dts | 36 +++
arch/arm64/boot/dts/nuvoton/ma35d1.dtsi | 68 ++++-
drivers/phy/nuvoton/phy-ma35d1-usb2.c | 267 +++++++++++++-----
6 files changed, 391 insertions(+), 91 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v2 1/4] dt-bindings: reset: nuvoton,ma35d1-reset: add simple-mfd and child node support
From: Joey Lu @ 2026-06-25 2:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Catalin Marinas, Jacky Huang, Shan-Chun Hung, Hui-Ping Chen,
Joey Lu, linux-phy, devicetree, linux-arm-kernel, linux-kernel,
Joey Lu
In-Reply-To: <20260625023958.569299-1-a0987203069@gmail.com>
The MA35D1 system-management syscon node hosts the USB PHY register
block at offset 0x60. To model usb-phy@60 as a DT child of the syscon
node the binding must allow:
- simple-mfd as an optional third compatible so the MFD core can
instantiate child platform devices.
- #address-cells and #size-cells (each const: 1) so child nodes can
carry a reg property.
- An open child-node pattern (patternProperties "^.*@[0-9a-f]+$")
to pass dt-schema validation.
Signed-off-by: Joey Lu <a0987203069@gmail.com>
---
.../bindings/reset/nuvoton,ma35d1-reset.yaml | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml b/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml
index 3ce7dcecd87a..1fda7e8f4b5d 100644
--- a/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml
@@ -19,6 +19,8 @@ properties:
items:
- const: nuvoton,ma35d1-reset
- const: syscon
+ - const: simple-mfd
+ minItems: 2
reg:
maxItems: 1
@@ -26,6 +28,16 @@ properties:
'#reset-cells':
const: 1
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+patternProperties:
+ "^.*@[0-9a-f]+$":
+ type: object
+
required:
- compatible
- reg
@@ -43,4 +55,3 @@ examples:
#reset-cells = <1>;
};
...
-
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/4] dt-bindings: phy: nuvoton,ma35d1-usb2-phy: extend for dual-port OTG support
From: Joey Lu @ 2026-06-25 2:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Catalin Marinas, Jacky Huang, Shan-Chun Hung, Hui-Ping Chen,
Joey Lu, linux-phy, devicetree, linux-arm-kernel, linux-kernel,
Joey Lu
In-Reply-To: <20260625023958.569299-1-a0987203069@gmail.com>
The MA35D1 has two USB PHY ports managed by the same hardware block:
- PHY0 (index 0): OTG port shared between the DWC2 gadget controller
and EHCI0/OHCI0 host controllers. A hardware mux follows the USB
ID pin automatically.
- PHY1 (index 1): dedicated host-only port for EHCI1/OHCI1.
Extend the existing binding to cover both ports:
- The PHY node is now a child of the system-management syscon node
with a reg property. The nuvoton,sys phandle and clocks properties
are removed; the driver derives the regmap from its parent, and
clock gating is owned by each individual USB controller.
- #phy-cells changes from 0 to 1: the cell selects the PHY port.
- Two optional board-tuning properties are added: nuvoton,rcalcode
for per-port resistor trim and nuvoton,oc-active-high for
over-current polarity.
Signed-off-by: Joey Lu <a0987203069@gmail.com>
---
.../bindings/phy/nuvoton,ma35d1-usb2-phy.yaml | 62 ++++++++++++++-----
1 file changed, 48 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml
index fff858c909a0..a20d03c80932 100644
--- a/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml
@@ -8,38 +8,72 @@ title: Nuvoton MA35D1 USB2 phy
maintainers:
- Hui-Ping Chen <hpchen0nvt@gmail.com>
+ - Joey Lu <yclu4@nuvoton.com>
+
+description:
+ USB 2.0 PHY for the Nuvoton MA35D1 SoC. The PHY node is a child of the
+ system-management syscon node and covers both PHY ports.
+
+ PHY0 (index 0) is the OTG port whose signals are routed to either the DWC2
+ gadget controller or the EHCI0/OHCI0 host controller by a hardware mux that
+ follows the USB ID pin automatically.
+
+ PHY1 (index 1) is a dedicated host-only port used by EHCI1/OHCI1.
properties:
compatible:
enum:
- nuvoton,ma35d1-usb2-phy
+ reg:
+ maxItems: 1
+
"#phy-cells":
- const: 0
+ const: 1
+ description:
+ The single cell selects the PHY port. 0 selects the OTG port (USB0,
+ shared with DWC2 gadget controller) and 1 selects the host-only port
+ (USB1).
- clocks:
- maxItems: 1
+ nuvoton,rcalcode:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 2
+ items:
+ minimum: 0
+ maximum: 15
+ description:
+ Resistor calibration trim codes for PHY0 and PHY1 respectively.
+ Each 4-bit value is written to the RCALCODE field in USBPMISCR and
+ adjusts the PHY's internal termination resistance. Both entries are
+ optional; when absent the hardware reset default is used.
- nuvoton,sys:
- $ref: /schemas/types.yaml#/definitions/phandle
+ nuvoton,oc-active-high:
+ type: boolean
description:
- phandle to syscon for checking the PHY clock status.
+ When present, the over-current detect input from the VBUS power switch
+ is treated as active-high. The default (property absent) is active-low.
+ This setting is shared by both USB host ports.
required:
- compatible
+ - reg
- "#phy-cells"
- - clocks
- - nuvoton,sys
additionalProperties: false
examples:
- |
- #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
+ system-management@40460000 {
+ compatible = "nuvoton,ma35d1-reset", "syscon", "simple-mfd";
+ reg = <0x40460000 0x200>;
+ #reset-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
- usb_phy: usb-phy {
- compatible = "nuvoton,ma35d1-usb2-phy";
- clocks = <&clk USBD_GATE>;
- nuvoton,sys = <&sys>;
- #phy-cells = <0>;
+ usb-phy@60 {
+ compatible = "nuvoton,ma35d1-usb2-phy";
+ reg = <0x60 0x14>;
+ #phy-cells = <1>;
+ };
};
--
2.43.0
^ 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