* [PATCH] ARM: setup: NUL-terminate the fpe emulator type
From: Pengpeng Hou @ 2026-04-17 7:28 UTC (permalink / raw)
To: Russell King, Jiri Bohac
Cc: Andrew Morton, linux-arm-kernel, linux-kernel, Pengpeng Hou,
stable
fpe_setup() copies up to 8 bytes from the boot command line into the
fixed fpe_type[8] buffer with memcpy() and leaves the array without a
terminating NUL when the parameter is exactly 8 bytes long.
fpe_init() later compares that buffer against "nwfpe" with strcmp(),
which can read past the end of fpe_type.
Use strscpy() so the boot parameter stays NUL-terminated before it is
used as a C string.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
arch/arm/kernel/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 0bfd66c7ada0..c07bc6a380c5 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -69,7 +69,7 @@ char fpe_type[8];
static int __init fpe_setup(char *line)
{
- memcpy(fpe_type, line, 8);
+ strscpy(fpe_type, line, sizeof(fpe_type));
return 1;
}
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH net-next 5/6] net: stmmac: move PHY handling out of __stmmac_open()/release()
From: Maxime Chevallier @ 2026-04-17 7:11 UTC (permalink / raw)
To: Russell King (Oracle), Alexander Stein
Cc: Andrew Lunn, Heiner Kallweit, Alexandre Torgue, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, linux-arm-kernel,
linux-stm32, Maxime Coquelin, netdev, Paolo Abeni
In-Reply-To: <aeDSTIS9-TDSihbX@shell.armlinux.org.uk>
Hi,
On 16/04/2026 14:13, Russell King (Oracle) wrote:
> On Thu, Apr 16, 2026 at 02:02:53PM +0200, Alexander Stein wrote:
>> Hi Russel,
>>
>> Am Donnerstag, 16. April 2026, 12:49:25 CEST schrieb Russell King (Oracle):
>>> On Thu, Apr 16, 2026 at 08:20:13AM +0200, Alexander Stein wrote:
>>>> Am Mittwoch, 15. April 2026, 14:59:32 CEST schrieb Russell King (Oracle):
>>>>> On Wed, Apr 15, 2026 at 08:08:40AM +0200, Alexander Stein wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Am Dienstag, 23. September 2025, 13:26:19 CEST schrieb Russell King (Oracle):
>>>>>>> Move the PHY attachment/detachment from the network driver out of
>>>>>>> __stmmac_open() and __stmmac_release() into stmmac_open() and
>>>>>>> stmmac_release() where these actions will only happen when the
>>>>>>> interface is administratively brought up or down. It does not make
>>>>>>> sense to detach and re-attach the PHY during a change of MTU.
>>>>>>
>>>>>> Sorry for coming up now. But I recently noticed this commit breaks changing
>>>>>> the MTU on i.MX8MP. Once I simply change the MTU I run into some DMA error:
>>>>>> $ ip link set dev end1 mtu 1400
>>>>>> imx-dwmac 30bf0000.ethernet end1: Register MEM_TYPE_PAGE_POOL RxQ-0
>>>>>> imx-dwmac 30bf0000.ethernet end1: Register MEM_TYPE_PAGE_POOL RxQ-1
>>>>>> imx-dwmac 30bf0000.ethernet end1: Register MEM_TYPE_PAGE_POOL RxQ-2
>>>>>> imx-dwmac 30bf0000.ethernet end1: Register MEM_TYPE_PAGE_POOL RxQ-3
>>>>>> imx-dwmac 30bf0000.ethernet end1: Register MEM_TYPE_PAGE_POOL RxQ-4
>>>>>> imx-dwmac 30bf0000.ethernet end1: Link is Down
>>>>>> imx-dwmac 30bf0000.ethernet end1: Failed to reset the dma
>>>>>> imx-dwmac 30bf0000.ethernet end1: stmmac_hw_setup: DMA engine initialization failed
>>>>>
>>>>> This basically means that a clock is missing. Please provide more
>>>>> information:
>>>>>
>>>>> - what kernel version are you using?
>>>>
>>>> Currently I am using v6.18.22.
>>>> $ ethtool -i end1
>>>> driver: st_gmac
>>>> version: 6.18.22
>>>> firmware-version:
>>>> expansion-rom-version:
>>>> bus-info: 30bf0000.ethernet
>>>> supports-statistics: yes
>>>> supports-test: no
>>>> supports-eeprom-access: no
>>>> supports-register-dump: yes
>>>> supports-priv-flags: no
>>>>
>>>>> - has EEE been negotiated?
>>>>
>>>> No. It is marked as not supported
>>>>
>>>> $ ethtool --show-eee end1
>>>> EEE settings for end1:
>>>> EEE status: not supported
>>>>
>>>>> - does the problem persist when EEE is disabled?
>>>>
>>>> As EEE is not supported the problem occurs even with EEE disabled.
>>>>
>>>>> - which PHY is attached to stmmac?
>>>>
>>>> It is a TI DP83867.
>>>>
>>>> imx-dwmac 30bf0000.ethernet eth1: PHY [stmmac-1:03] driver [TI DP83867] (irq=136)
>>>>
>>>>> - which PHY interface mode is being used to connect the PHY to stmmac?
>>>>
>>>> For this interface
>>>>> phy-mode = "rgmii-id";
>>>> is set.
>>>>
>>>> In case it is helpful. My platform is arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
>>>> Thanks for assisting. If there a further questions, don't hesitate to ask.
>>>
>>> Thanks.
>>>
>>> So, as best I can determine at the moment, we end up with the following
>>> sequence:
>>>
>>> stmmac_change_mtu()
>>> __stmmac_release()
>>> phylink_stop()
>>> phy_stop()
>>> phy->state = PHY_HALTED
>>> _phy_state_machine() returns PHY_STATE_WORK_SUSPEND
>>> _phy_state_machine_post_work()
>>> phy_suspend()
>>> genphy_suspend()
>>> phy_set_bits(phydev, MII_BMCR, BMCR_PDOWN)
>>>
>>> With the DP83867, this causes most of the PHY to be powered down, thus
>>> stopping the clocks, and this causes the stmmac reset to time out.
>>>
>>> Prior to this commit, we would have called phylink_disconnect_phy()
>>> immediately after phylink_stop(), but I can see nothing that would
>>> be affected by this change there (since that also calls
>>> phy_suspend(), but as the PHY is already suspended, this becomes a
>>> no-op.)
>>>
>>> However, __stmmac_open() would have called stmmac_init_phy(), which
>>> would reattach the PHY. This would have called phy_init_hw(),
>>> resetting the PHY, and phy_resume() which would ensure that the
>>> PDOWN bit is clear - thus clocks would be running.
>>>
>>> As a hack, please can you try calling phylink_prepare_resume()
>>> between the __stmmac_release() and __stmmac_open() in
>>> stmmac_change_mtu(). This should resume the PHY, thus restoring the
>>> clocks necessary for stmmac to reset.
>>
>> I tried the following patch. This works as you suspected.
>
> Brilliant, thanks for proving the theory why it broke.
>
> I'll have a think about the best way to solve this, because
> phylink_prepare_resume() is supposed to be paired with phylink_resume()
> and that isn't the case here.
>
> Please bear with me as my availability for looking at the kernel is
> very unpredictable at present (family health issues.)
FWIW I am able to reproduce this with imx8mp + ksz9131
I can give this a try as Russell isn't available.
Maxime
>
^ permalink raw reply
* Re: [PATCH 0/3] mm: split the file's i_mmap tree for NUMA
From: Huang Shijie @ 2026-04-17 6:59 UTC (permalink / raw)
To: Mateusz Guzik
Cc: akpm, viro, brauner, linux-mm, linux-kernel, linux-arm-kernel,
linux-fsdevel, muchun.song, osalvador, linux-trace-kernel,
linux-perf-users, linux-parisc, nvdimm, zhongyuan, fangbaoshun,
yingzhiwei
In-Reply-To: <76pfiwabdgsej6q2yxfh3efuqvsyg7mt7rvl5itzzjyhdrto5r@53viaxsackzv>
On Mon, Apr 13, 2026 at 05:33:21PM +0200, Mateusz Guzik wrote:
> On Mon, Apr 13, 2026 at 02:20:39PM +0800, Huang Shijie wrote:
> > In NUMA, there are maybe many NUMA nodes and many CPUs.
> > For example, a Hygon's server has 12 NUMA nodes, and 384 CPUs.
> > In the UnixBench tests, there is a test "execl" which tests
> > the execve system call.
> >
> > When we test our server with "./Run -c 384 execl",
> > the test result is not good enough. The i_mmap locks contended heavily on
> > "libc.so" and "ld.so". For example, the i_mmap tree for "libc.so" can have
> > over 6000 VMAs, all the VMAs can be in different NUMA mode.
> > The insert/remove operations do not run quickly enough.
> >
> > patch 1 & patch 2 are try to hide the direct access of i_mmap.
> > patch 3 splits the i_mmap into sibling trees, and we can get better
> > performance with this patch set:
> > we can get 77% performance improvement(10 times average)
> >
>
> To my reading you kept the lock as-is and only distributed the protected
> state.
>
> While I don't doubt the improvement, I'm confident should you take a
> look at the profile you are going to find this still does not scale with
> rwsem being one of the problems (there are other global locks, some of
> which have experimental patches for).
>
> Apart from that this does nothing to help high core systems which are
> all one node, which imo puts another question mark on this specific
> proposal.
>
> Of course one may question whether a RB tree is the right choice here,
> it may be the lock-protected cost can go way down with merely a better
> data structure.
>
> Regardless of that, for actual scalability, there will be no way around
> decentralazing locking around this and partitioning per some core count
> (not just by numa awareness).
>
> Decentralizing locking is definitely possible, but I have not looked
> into specifics of how problematic it is. Best case scenario it will
> merely with separate locks. Worst case scenario something needs a fully
> stabilized state for traversal, in that case another rw lock can be
> slapped around this, creating locking order read lock -> per-subset
> write lock -- this will suffer scalability due to the read locking, but
> it will still scale drastically better as apart from that there will be
> no serialization. In this setting the problematic consumer will write
> lock the new thing to stabilize the state.
For your proposal in no-numa, I hope you can create a patch set for it.
I can test it in our machine.
Thanks
Huang Shijie
^ permalink raw reply
* [PATCH] ARM: dts: aspeed: anacapa: add interrupt properties for PDB PCA9555
From: Rex Fu via B4 Relay @ 2026-04-17 6:41 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel, Rex Fu
From: Rex Fu <Rex.Fu@amd.com>
Add interrupt-parent and interrupts properties to the PDB PCA9555
nodes in the anacapa DTS.
Signed-off-by: Rex Fu <Rex.Fu@amd.com>
---
Single DTS update for the PDB PCA9555 interrupt wiring on anacapa.
---
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
index 2cb7bd128d24..7319f2319bb7 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-anacapa.dts
@@ -481,6 +481,9 @@ gpio@22 {
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <174 IRQ_TYPE_LEVEL_LOW>;
+
gpio-line-names =
"RPDB_FAN_FULL_SPEED_R_N", "RPDB_I2C_TEMP75_U8_ALERT_R_N",
"RPDB_I2C_TMP432_U29_ALERT_R_N", "RPDB_GLOBAL_WP",
@@ -500,6 +503,9 @@ gpio@24 {
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <174 IRQ_TYPE_LEVEL_LOW>;
+
gpio-line-names =
"RPDB_EAM2_PRSNT_MOS_N_R", "RPDB_EAM3_PRSNT_MOS_N_R",
"RPDB_PWRGD_P50V_HSC4_SYS_R",
@@ -529,6 +535,9 @@ gpio@22 {
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <174 IRQ_TYPE_LEVEL_LOW>;
+
gpio-line-names =
"LPDB_FAN_FULL_SPEED_R_N","LPDB_I2C_TEMP75_U8_ALERT_R_N",
"LPDB_I2C_TMP432_U29_ALERT_R_N","LPDB_GLOBAL_WP",
@@ -546,6 +555,9 @@ gpio@24 {
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <174 IRQ_TYPE_LEVEL_LOW>;
+
gpio-line-names =
"LPDB_P50V_FAN1_R2_PG","LPDB_P50V_FAN2_R2_PG",
"LPDB_P50V_FAN3_R2_PG","LPDB_P50V_FAN4_R2_PG",
---
base-commit: 76b4ec8efdc3887cdbf730da2e55881fc1a18770
change-id: 20260417-anacapa-pca9555-irq-3090d4120270
Best regards,
--
Rex Fu <Rex.Fu@amd.com>
^ permalink raw reply related
* [PATCH net v4 2/2] net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()
From: Lorenzo Bianconi @ 2026-04-17 6:36 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260417-airoha_qdma_cleanup_tx_queue-fix-net-v4-0-e04bcc2c9642@kernel.org>
Similar to airoha_qdma_cleanup_rx_queue(), reset DMA TX descriptors in
airoha_qdma_cleanup_tx_queue routine. Moreover, reset TX_DMA_IDX to
TX_CPU_IDX to notify the NIC the QDMA TX ring is empty.
Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 32 ++++++++++++++++++++++++++++++--
1 file changed, 30 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 690bfaf8d7d9..6d9f82c677a0 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1039,12 +1039,15 @@ static int airoha_qdma_init_tx(struct airoha_qdma *qdma)
static void airoha_qdma_cleanup_tx_queue(struct airoha_queue *q)
{
- struct airoha_eth *eth = q->qdma->eth;
- int i;
+ struct airoha_qdma *qdma = q->qdma;
+ struct airoha_eth *eth = qdma->eth;
+ int i, qid = q - &qdma->q_tx[0];
+ u16 index = 0;
spin_lock_bh(&q->lock);
for (i = 0; i < q->ndesc; i++) {
struct airoha_queue_entry *e = &q->entry[i];
+ struct airoha_qdma_desc *desc = &q->desc[i];
if (!e->dma_addr)
continue;
@@ -1055,8 +1058,33 @@ static void airoha_qdma_cleanup_tx_queue(struct airoha_queue *q)
e->dma_addr = 0;
e->skb = NULL;
list_add_tail(&e->list, &q->tx_list);
+
+ /* Reset DMA descriptor */
+ WRITE_ONCE(desc->ctrl, 0);
+ WRITE_ONCE(desc->addr, 0);
+ WRITE_ONCE(desc->data, 0);
+ WRITE_ONCE(desc->msg0, 0);
+ WRITE_ONCE(desc->msg1, 0);
+ WRITE_ONCE(desc->msg2, 0);
+
q->queued--;
}
+
+ if (!list_empty(&q->tx_list)) {
+ struct airoha_queue_entry *e;
+
+ e = list_first_entry(&q->tx_list, struct airoha_queue_entry,
+ list);
+ index = e - q->entry;
+ }
+ /* Set TX_DMA_IDX to TX_CPU_IDX to notify the hw the QDMA TX ring is
+ * empty.
+ */
+ airoha_qdma_rmw(qdma, REG_TX_CPU_IDX(qid), TX_RING_CPU_IDX_MASK,
+ FIELD_PREP(TX_RING_CPU_IDX_MASK, index));
+ airoha_qdma_rmw(qdma, REG_TX_DMA_IDX(qid), TX_RING_DMA_IDX_MASK,
+ FIELD_PREP(TX_RING_DMA_IDX_MASK, index));
+
spin_unlock_bh(&q->lock);
}
--
2.53.0
^ permalink raw reply related
* [PATCH net v4 1/2] net: airoha: Move ndesc initialization at end of airoha_qdma_init_tx()
From: Lorenzo Bianconi @ 2026-04-17 6:36 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260417-airoha_qdma_cleanup_tx_queue-fix-net-v4-0-e04bcc2c9642@kernel.org>
If queue entry list allocation fails in airoha_qdma_init_tx_queue routine,
airoha_qdma_cleanup_tx_queue() will trigger a NULL pointer dereference
accessing the queue entry array. The issue is due to the early ndesc
initialization in airoha_qdma_init_tx_queue(). Fix the issue moving ndesc
initialization at end of airoha_qdma_init_tx routine.
Fixes: 3f47e67dff1f7 ("net: airoha: Add the capability to consume out-of-order DMA tx descriptors")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index e1ab15f1ee7d..690bfaf8d7d9 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -954,27 +954,27 @@ static int airoha_qdma_init_tx_queue(struct airoha_queue *q,
dma_addr_t dma_addr;
spin_lock_init(&q->lock);
- q->ndesc = size;
q->qdma = qdma;
q->free_thr = 1 + MAX_SKB_FRAGS;
INIT_LIST_HEAD(&q->tx_list);
- q->entry = devm_kzalloc(eth->dev, q->ndesc * sizeof(*q->entry),
+ q->entry = devm_kzalloc(eth->dev, size * sizeof(*q->entry),
GFP_KERNEL);
if (!q->entry)
return -ENOMEM;
- q->desc = dmam_alloc_coherent(eth->dev, q->ndesc * sizeof(*q->desc),
+ q->desc = dmam_alloc_coherent(eth->dev, size * sizeof(*q->desc),
&dma_addr, GFP_KERNEL);
if (!q->desc)
return -ENOMEM;
- for (i = 0; i < q->ndesc; i++) {
+ for (i = 0; i < size; i++) {
u32 val = FIELD_PREP(QDMA_DESC_DONE_MASK, 1);
list_add_tail(&q->entry[i].list, &q->tx_list);
WRITE_ONCE(q->desc[i].ctrl, cpu_to_le32(val));
}
+ q->ndesc = size;
/* xmit ring drop default setting */
airoha_qdma_set(qdma, REG_TX_RING_BLOCKING(qid),
--
2.53.0
^ permalink raw reply related
* [PATCH net v4 0/2] net: airoha: Fix airoha_qdma_cleanup_tx_queue() processing
From: Lorenzo Bianconi @ 2026-04-17 6:36 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev
Add missing bits in airoha_qdma_cleanup_tx_queue routine.
Fix airoha_qdma_cleanup_tx_queue processing errors intorduced in commit
'3f47e67dff1f7 ("net: airoha: Add the capability to consume out-of-order
DMA tx descriptors")'.
---
Changes in v4:
- Drop patch 2/3 to move entries to queue head in case of DMA mapping
failure in airoha_dev_xmit().
- Link to v3: https://lore.kernel.org/r/20260416-airoha_qdma_cleanup_tx_queue-fix-net-v3-0-2b69f5788580@kernel.org
Changes in v3:
- Move ndesc initialization fix in a dedicated patch.
- Add patch 2/3 to move entries to queue head in case of DMA mapping
failure in airoha_dev_xmit().
- Cosmetics.
- Link to v2: https://lore.kernel.org/r/20260414-airoha_qdma_cleanup_tx_queue-fix-net-v2-1-875de57cc022@kernel.org
Changes in v2:
- Move q->ndesc initialization at end of airoha_qdma_init_tx routine in
order to avoid any possible NULL pointer dereference in
airoha_qdma_cleanup_tx_queue()
- Check if q->tx_list is empty in airoha_qdma_cleanup_tx_queue()
- Link to v1: https://lore.kernel.org/r/20260410-airoha_qdma_cleanup_tx_queue-fix-net-v1-1-b7171c8f1e78@kernel.org
---
Lorenzo Bianconi (2):
net: airoha: Move ndesc initialization at end of airoha_qdma_init_tx()
net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()
drivers/net/ethernet/airoha/airoha_eth.c | 40 +++++++++++++++++++++++++++-----
1 file changed, 34 insertions(+), 6 deletions(-)
---
base-commit: 82c21069028c5db3463f851ae8ac9cc2e38a3827
change-id: 20260410-airoha_qdma_cleanup_tx_queue-fix-net-93375f5ee80f
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/3] pinctrl: mediatek: Add gpio-range record in pinctrl driver
From: andriy.shevchenko @ 2026-04-17 6:36 UTC (permalink / raw)
To: Deep Pani
Cc: Fred-WY Chen (陳威宇),
Lei Xue (薛磊), Mandeep S,
Qingliang Li (黎晴亮), sean.wang@kernel.org,
Yaoy Wang (王瑶瑶), AngeloGioacchino Del Regno,
Yong Mao (毛勇), linux-gpio@vger.kernel.org,
linux-kernel@vger.kernel.org, linus.walleij@linaro.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com,
Cathy Xu (许华婷),
Shunxi Zhang (章顺喜),
Ye Wang (王叶)
In-Reply-To: <892cb5455b0306edfb98b3c7df99b88c58e303a9.camel@mediatek.com>
On Fri, Apr 17, 2026 at 06:02:34AM +0000, Deep Pani wrote:
> Any updates from your side?
Sorry for the delayed answer and thanks for pinging me.
Since it was a bit old thread, can you refresh the series (addressing what you
agree with) and send a v2 for review?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/3] pinctrl: mediatek: Add gpio-range record in pinctrl driver
From: andriy.shevchenko @ 2026-04-17 6:35 UTC (permalink / raw)
To: Deep Pani
Cc: Fred-WY Chen (陳威宇),
Lei Xue (薛磊), Mandeep S,
Qingliang Li (黎晴亮), sean.wang@kernel.org,
Yaoy Wang (王瑶瑶), AngeloGioacchino Del Regno,
Yong Mao (毛勇), linux-gpio@vger.kernel.org,
linux-kernel@vger.kernel.org, linus.walleij@linaro.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com,
Cathy Xu (许华婷),
Shunxi Zhang (章顺喜),
Ye Wang (王叶)
In-Reply-To: <9e802950ae47071bb34bb373419dc89c9add9d0b.camel@mediatek.com>
On Fri, Mar 27, 2026 at 01:33:09PM +0000, Deep Pani wrote:
> Hi Andy,
>
> You mean gpiochip_add_pin_range(), correct?
>
> IIRC, that adds to gpiochip's range, not the range we are using for our
> pinctrl driver.
>
> The range we are utilizing inside our hardware is of the type struct
> pinctrl_gpio_range. There is no callback in gpiochip that handles this
> type of range
I see, thanks for elaboration.
> I also recall that gpiochip_add_data() doesn't initialize the hw but
> rather initializes the gpiochip from the hw data we will provide in
> mtk_build_gpiochip().
It does for IRQ if one specifies an IRQ chip.
> Thus we need a function which will help
> initialize the pinctrl_gpio_range inside our pinctrl driver structure.
> This is why we make the mtk_pinctrl_gpio_range_init function here.
But this sounds like the solution from other end of a stick.
OTOH there are a few drivers that use this approach.
> For the second question, we are keeping it because before ACPI is
> invoked we still need some other pins to be configured, especially if
> different pins have different styles of pull configuration. The method
> we use is to define those configurations in the pinctrl-mt8901.c file
> which determines the gpio ranges and maps pinctrl device to acpi, one
> set of gpio ranges per configuration, for different type of pull
> configurations we have different gpio ranges, this callback helps add
> them into the pinctrl subsystem such that other device maintainers can
> easily leverage that subsystem to add their resources in their _CRS
> calls using the common interfaces.
>
> Thus we need to keep both the functions.
OK.
> On Thu, 2026-03-26 at 12:33 +0000, Fred-WY Chen (陳威宇) wrote:
> > On Wed, 2025-11-26 at 19:06 +0100, Andy Shevchenko wrote:
> > >
> > > External email : Please do not click links or open attachments
> > > until
> > > you have verified the sender or the content.
Please, get rid of this header, it's not compatible with OSS development
process.
> > > On Tue, Nov 25, 2025 at 10:36:34AM +0800, Lei Xue wrote:
> > > > Kernel GPIO subsystem mapping hardware pin number to a different
> > > > range of gpio number. Add gpio-range structure to hold
> > > > the mapped gpio range in pinctrl driver. That enables the kernel
> > > > to search a range of mapped gpio range against a pinctrl device.
> > >
> > > ...
> > >
> > > > static int mtk_build_gpiochip(struct mtk_pinctrl *hw)
> > > > {
> > > > struct gpio_chip *chip = &hw->chip;
> > >
> > > > if (ret < 0)
> > > > return ret;
> > > >
> > > > + mtk_pinctrl_gpio_range_init(hw, chip);
> > > > +
> > > > return 0;
> > >
> > > We have a callback for that in struct gpio_chip. Any reason not to
> > > use it?
> > >
> > > > }
> > >
> > > ...
> > >
> > > > + pinctrl_add_gpio_range(hw->pctrl, &hw->range);
> > >
> > > Not sure if this is needed.
> >
> > Could you please check this and feedback?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH net v3 0/3] net: airoha: Fix airoha_qdma_cleanup_tx_queue() processing
From: Lorenzo Bianconi @ 2026-04-17 6:26 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260416-airoha_qdma_cleanup_tx_queue-fix-net-v3-0-2b69f5788580@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]
> Add missing bits in airoha_qdma_cleanup_tx_queue routine.
> Fix airoha_qdma_cleanup_tx_queue processing errors intorduced in commit
> '3f47e67dff1f7 ("net: airoha: Add the capability to consume out-of-order
> DMA tx descriptors")'.
>
> ---
> Changes in v3:
> - Move ndesc initialization fix in a dedicated patch.
> - Add patch 2/3 to move entries to queue head in case of DMA mapping
> failure in airoha_dev_xmit().
> - Cosmetics.
> - Link to v2: https://lore.kernel.org/r/20260414-airoha_qdma_cleanup_tx_queue-fix-net-v2-1-875de57cc022@kernel.org
>
> Changes in v2:
> - Move q->ndesc initialization at end of airoha_qdma_init_tx routine in
> order to avoid any possible NULL pointer dereference in
> airoha_qdma_cleanup_tx_queue()
> - Check if q->tx_list is empty in airoha_qdma_cleanup_tx_queue()
> - Link to v1: https://lore.kernel.org/r/20260410-airoha_qdma_cleanup_tx_queue-fix-net-v1-1-b7171c8f1e78@kernel.org
>
> ---
> Lorenzo Bianconi (3):
> net: airoha: Move ndesc initialization at end of airoha_qdma_init_tx()
> net: airoha: Move entries to queue head in case of DMA mapping failure in airoha_dev_xmit()
> net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()
Please drop this version, I will send a new one dropping patch 2/3.
Regards,
Lorenzo
>
> drivers/net/ethernet/airoha/airoha_eth.c | 42 ++++++++++++++++++++++++++------
> 1 file changed, 35 insertions(+), 7 deletions(-)
> ---
> base-commit: 3f20012a3964f487ae1e9ff942e2f35d4e9595bf
> change-id: 20260410-airoha_qdma_cleanup_tx_queue-fix-net-93375f5ee80f
>
> Best regards,
> --
> Lorenzo Bianconi <lorenzo@kernel.org>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/3] pinctrl: mediatek: Add acpi support
From: Andy Shevchenko @ 2026-04-17 6:26 UTC (permalink / raw)
To: Lorenzo Pieralisi
Cc: Linus Walleij, Lei Xue, Hanjun Guo, Sudeep Holla, Sean Wang,
Linus Walleij, Matthias Brugger, AngeloGioacchino Del Regno,
linux-kernel, linux-mediatek, linux-gpio, linux-arm-kernel,
yong.mao, qingliang.li, Fred-WY.Chen, ot_cathy.xu,
ot_shunxi.zhang, ot_yaoy.wang, ot_ye.wang, linux-acpi, robh
In-Reply-To: <aSh0EyGm9ZHAc3dN@lpieralisi>
On Thu, Nov 27, 2025 at 04:53:55PM +0100, Lorenzo Pieralisi wrote:
> On Thu, Nov 27, 2025 at 04:29:54PM +0200, Andy Shevchenko wrote:
> > On Thu, Nov 27, 2025 at 11:06:29AM +0100, Lorenzo Pieralisi wrote:
> > > On Wed, Nov 26, 2025 at 08:06:51PM +0200, Andy Shevchenko wrote:
[...]
> > > > > I also assume/hope that we don't want to add a "reg-names" _DSD property either
> > > > > in ACPI to deal with this seamlessly in DT/ACPI (that was done for
> > > > > "interrupt-names"):
> > > > >
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/firmware-guide/acpi/enumeration.rst?h=v6.18-rc7#n188
> > > >
> > > > Hmm... Why not?
> > >
> > > What's the policy there ?
> >
> > > Half of the ACPI bindings for an interrupt
> > > descriptor are defined in the ACPI specs (ie _CRS) and the other half
> > > (ie "interrupt-names") is documented in the Linux kernel (or are we
> > > documenting this elsewhere ?) ?
> >
> > Yeah, nobody pursued ACPI specification updates / addendum to make it fully
> > official. _De facto_ we have established practice for GPIOs enumeration
> > (as most used resources in the OSes), Linux official for PWM, I²C muxes,
> > multi-functional HW (such as Diolan DLN-2, LJCA), Microsoft defined for
> > so called "USB hardwired" devices, Linux defined for LEDs and GPIO keys,
> > sensor mount matrix as per "most used" cases + DT analogue works just
> > because we have agnostic APIs in IIO to retrieve that. There are maybe
> > more, but don't remember
> >
> > So, I think the practical "policies" are that:
> > - if it's defined in ACPI spec, we use the spec
> > - if there is Microsoft addendum, we rely on what Windows does
> > - WMI, EFI, and other "windoze"-like vendor defined cases
> > - if it makes sense, we establish practice from Linux perspective
> > - the rest, every vendor does what it does
> >
> > That said, for the first two we expect OEMs to follow, for the third one
> > depends, but there are established WMI calls and other more or less "standard"
> > interfaces, so like the first two.
> >
> > For the fourth one (Linux) we do, but living in the expectation that some or
> > more vendors fall to the fifth category and we might need to support that if
> > we want their HW work in Linux.
> >
> > > Or we are saying that "interrupt-names" properties are added by kernel
> > > code _only_ (through software nodes, to make parsing seamless between DT
> > > and ACPI) based on hardcoded name values in drivers ?
> >
> > No, the idea behind software nodes is to "fix" the FW nodes in case the FW
> > description can not be modified (and that might well happen to even DT in some
> > cases AFAIH). So, if some driver hard codes "interrupt-names" we expect that
> > new versions of the FW that support the HW that needs the property will be
> > amended accordingly.
> >
> > "interrupt-names" has been established for ACPI to support a separate SMB alert
> > interrupt. However, I haven't heard any development of that IRL (for real
> > devices in ACPI environment).
> >
> > > I don't think I can grok any example of the latter in the mainline.
> > >
> > > I am asking because I'd need to add something similar shortly to make parsing
> > > of platform devices created out of ACPI static tables easier (I guess we
> > > can postpone discussion till I post the code but I thought I'd ask).
> >
> > Oh, I can go ahead and tell you, try to avoid that. Why?! Whatever,
> > indeed, please Cc me to that, I will be glad to study the case and
> > try to be helpful.
> >
> > (Have you considered DT overlays instead? There is a big pending support for
> > that for _ACPI_ platforms.)
>
> Long story short: we do need to create platform devices out of static
> table (eg ARM64 IORT) entries. Current code parses the table entries and
> try to map the devices IRQs (ie acpi_register_gsi()) when the platform
> device is created. Now, the interrupt controller that device IRQ's is
> routed to might not have probed yet. We have to defer probing and later,
> when the platform driver probes, map the IRQ.
>
> Issue is: for OF nodes and ACPI devices, behind the platform device
> firmware node there is a standard firmware object, so implementing
> fwnode_irq_get() is trivial. For the devices I am talking about,
> the data providing GSI info (hwirq, trigger/polarity) is static
> table specific, so the idea was to stash that data and embed it in
> fwnode_static along with a irq_get() fwnode_operations function
> specific to that piece of data so that device drivers can actually do:
>
> fwnode_irq_get()
>
> on the fwnode _seamlessly_ (if you still do wonder: those platform
> devices created out of static table entries in ACPI in OF are
> of_node(s)).
>
> There is a less convoluted solution (that is what some platform
> drivers in ACPI do today), that is, we pass the static table
> data in pdev->dev.platform_data and each platform_driver parses it differently.
>
> That works but that also means the in the respective device drivers
> OF and ACPI IRQ (and MMIO) parsing differ (which is not necessarily
> a problem I just have to rewrite them all).
Hmm... The parsing inside drivers is quite a custom case. I would avoid doing
it if it's not device specific (I mean if it's not related to the very unique
device or family of the devices which most likely won't appear again in the
future). In other words, I prefer agnostic solutions over custom ones.
> Now - when it comes to "interrupt-names". Some of the device drivers
> I mention do:
>
> eg platform_get_irq_byname_optional()
>
> that expects the IRQ to be mapped and stored in a named platform device resource.
>
> That's easy in DT - for two reasons:
>
> (1) "interrupt-names"
> (2) standard properties behind the of_node
>
> how to do that for fwnodes that aren't backed by either OF nodes or ACPI
> devices (that do use "interrupt-names" _DSD property) is a question.
>
> Mind, the "interrupt-names" thing is a detail in the whole mechanism.
>
> DT overlays to represent in ACPI those static table entries ?
>
> I vividly remember the days ACPI for ARM64 was being merged - that's what
> our crystal ball predicted :)
So, the idea is to translate ACPI static table entries (which comes from IORT)
to the IRQ fwnodes at initialisation (parsing) time?
> This delayed IRQ mapping notwithstanding, I read what you wrote and took
> note. The worry is, this fwnode_*() (on ACPI nodes) interface trickling
> into subsystems where it should not (ie PCI, clocks, regulators) - hopefully
> the respective maintainers are keeping an eye on it.
>
> > > Are we going to do the same for "reg-names" ?
> >
> > If it makes sense and we expect some vendor to follow that _in ACPI_,
> > why not?
> >
> > > Most importantly, what is DT maintainers stance on the matter ?
> >
> > AFAIK They don't care as long as there is a schema provided, accepted and
> > used in DT, if it's ACPI-only thing, then it most likely should be done
> > in ACPI-like way (see above the first two / three items: spec, MS, WMI/EFI).
> >
> > > > > I am sorry I have got more questions than answers here - it would be good
> > > > > to understand where the line is drawn when it comes to OF/ACPI and fwnode
> > > > > heuristics compatibility.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 3/3] pinctrl: mediatek: mt8901: Add pinctrl driver for MT8901
From: Deep Pani @ 2026-04-17 6:04 UTC (permalink / raw)
To: linus.walleij@linaro.org, Fred-WY Chen (陳威宇),
AngeloGioacchino Del Regno, sean.wang@kernel.org,
matthias.bgg@gmail.com, Mandeep S, Lei Xue (薛磊)
Cc: Qingliang Li (黎晴亮),
Ye Wang (王叶), Yaoy Wang (王瑶瑶),
Yong Mao (毛勇), linux-gpio@vger.kernel.org,
Shunxi Zhang (章顺喜),
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
Cathy Xu (许华婷)
In-Reply-To: <666207716ac5021e81736c30e802ba2febfed081.camel@mediatek.com>
Hi Angelo,
Are there any updates from your side?
Thanks and Regards,
Deep Pani
On Fri, 2026-03-27 at 21:41 +0800, Deep Pani wrote:
> Hi Angelo,
>
> MT8901 doesn't use devicetree for gpio pin configuration. ACPI ASL
> macros are declared in the device's _CRS methods to define exact
> configuration for the gpio pins.
>
> We have and will always make sure ACPI is all good on this platform.
>
> Thanks and Regards,
> Deep Pani
>
> On Thu, 2026-03-26 at 12:36 +0000, Fred-WY Chen (陳威宇) wrote:
> > On Tue, 2025-11-25 at 10:56 +0100, AngeloGioacchino Del Regno
> > wrote:
> > >
> > > External email : Please do not click links or open attachments
> > > until
> > > you have verified the sender or the content.
> > >
> > >
> > > Il 25/11/25 03:36, Lei Xue ha scritto:
> > > > Add mt8901 pinctrl, gpio and eint driver implementation.
> > > >
> > > > Signed-off-by: Lei Xue <lei.xue@mediatek.com>
> > > > ---
> > > > drivers/pinctrl/mediatek/Kconfig | 12 +
> > > > drivers/pinctrl/mediatek/Makefile | 1 +
> > > > drivers/pinctrl/mediatek/mtk-eint.c | 4 +
> > > > drivers/pinctrl/mediatek/mtk-eint.h | 1 +
> > > > drivers/pinctrl/mediatek/pinctrl-mt8901.c | 1460
> > > > +++++++++++
> > > > drivers/pinctrl/mediatek/pinctrl-mtk-mt8901.h | 2130
> > > > +++++++++++++++++
> > > > 6 files changed, 3608 insertions(+)
> > > > create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt8901.c
> > > > create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-
> > > > mt8901.h
> > > >
> > > > diff --git a/drivers/pinctrl/mediatek/Kconfig
> > > > b/drivers/pinctrl/mediatek/Kconfig
> > > > index 4819617d9368..4820ae5197a0 100644
> > > > --- a/drivers/pinctrl/mediatek/Kconfig
> > > > +++ b/drivers/pinctrl/mediatek/Kconfig
> > > > @@ -321,6 +321,18 @@ config PINCTRL_MT8516
> > > > default ARM64 && ARCH_MEDIATEK
> > > > select PINCTRL_MTK
> > > >
> > > > +config PINCTRL_MT8901
> > > > + bool "MediaTek MT8901 pin control"
> > > > + depends on ACPI
> > > > + depends on ARM64 || COMPILE_TEST
> > > > + default ARM64 && ARCH_MEDIATEK
> > > > + select PINCTRL_MTK_PARIS
> > > > + help
> > > > + Say yes here to support pin controller and gpio driver
> > > > + on MediaTek MT8901 SoC.
> > > > + In MTK platform, we support virtual gpio and use it to
> > > > + map specific eint which doesn't have real gpio pin.
> > > > +
> > > > # For PMIC
> > > > config PINCTRL_MT6397
> > > > bool "MediaTek MT6397 pin control"
> > > > diff --git a/drivers/pinctrl/mediatek/Makefile
> > > > b/drivers/pinctrl/mediatek/Makefile
> > > > index ae765bd99965..57c69b1e5c2d 100644
> > > > --- a/drivers/pinctrl/mediatek/Makefile
> > > > +++ b/drivers/pinctrl/mediatek/Makefile
> > > > @@ -43,3 +43,4 @@ obj-$(CONFIG_PINCTRL_MT8196)
> > > > +=
> > > > pinctrl-mt8196.o
> > > > obj-$(CONFIG_PINCTRL_MT8365) += pinctrl-
> > > > mt8365.o
> > > > obj-$(CONFIG_PINCTRL_MT8516) += pinctrl-
> > > > mt8516.o
> > > > obj-$(CONFIG_PINCTRL_MT6397) += pinctrl-
> > > > mt6397.o
> > > > +obj-$(CONFIG_PINCTRL_MT8901) += pinctrl-mt8901.o
> > > > diff --git a/drivers/pinctrl/mediatek/mtk-eint.c
> > > > b/drivers/pinctrl/mediatek/mtk-eint.c
> > > > index c8c5097c11c4..b5a5beebf9cd 100644
> > > > --- a/drivers/pinctrl/mediatek/mtk-eint.c
> > > > +++ b/drivers/pinctrl/mediatek/mtk-eint.c
> > > > @@ -71,6 +71,10 @@ const unsigned int debounce_time_mt6878[] =
> > > > {
> > > > };
> > > > EXPORT_SYMBOL_GPL(debounce_time_mt6878);
> > > >
> > > > +const unsigned int debounce_time_mt8901[] = {
> > > > + 156, 313, 625, 1250, 20000, 40000, 80000, 160000, 320000,
> > > > 640000, 0};
> > > > +EXPORT_SYMBOL_GPL(debounce_time_mt8901);
> > > > +
> > > > static void __iomem *mtk_eint_get_offset(struct mtk_eint
> > > > *eint,
> > > > unsigned int eint_num,
> > > > unsigned int offset)
> > > > diff --git a/drivers/pinctrl/mediatek/mtk-eint.h
> > > > b/drivers/pinctrl/mediatek/mtk-eint.h
> > > > index 3cdd6f6310cd..1b185f660aff 100644
> > > > --- a/drivers/pinctrl/mediatek/mtk-eint.h
> > > > +++ b/drivers/pinctrl/mediatek/mtk-eint.h
> > > > @@ -53,6 +53,7 @@ extern const unsigned int
> > > > debounce_time_mt2701[];
> > > > extern const unsigned int debounce_time_mt6765[];
> > > > extern const unsigned int debounce_time_mt6795[];
> > > > extern const unsigned int debounce_time_mt6878[];
> > > > +extern const unsigned int debounce_time_mt8901[];
> > > >
> > > > struct mtk_eint;
> > > >
> > > > diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8901.c
> > > > b/drivers/pinctrl/mediatek/pinctrl-mt8901.c
> > > > new file mode 100644
> > > > index 000000000000..77dec85fe29b
> > > > --- /dev/null
> > > > +++ b/drivers/pinctrl/mediatek/pinctrl-mt8901.c
> > > > @@ -0,0 +1,1460 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * Copyright (C) 2025 MediaTek Inc.
> > > > + *
> > > > + */
> > > > +
> > > > +#include <linux/acpi.h>
> > > > +#include <linux/module.h>
> > > > +#include "pinctrl-mtk-mt8901.h"
> > > > +#include "pinctrl-paris.h"
> > > > +
> > >
> > > ..snip..
> > >
> > > > +static const char * const mt8901_pinctrl_register_base_name[]
> > > > =
> > > > {
> > > > + "iocfg0", "iocfg_lt2", "iocfg_lt3", "iocfg_rt1",
> > > > "iocfg_rt2",
> > > > "iocfg_rt3",
> > > > + "iocfg_tr", "iocfg_rt0", "iocfg_lt1", "iocfg_lb",
> > > > "iocfg_rb",
> > > > +};
> > > > +
> > > > +static const struct mtk_eint_hw mt8901_eint_hw = {
> > > > + .port_mask = 0xf,
> > > > + .ports = 7,
> > > > + .ap_num = 209,
> > > > + .db_cnt = 32,
> > > > + .db_time = debounce_time_mt8901,
> > > > +};
> > > > +
> > > > +static const struct mtk_pin_soc mt8901_data = {
> > > > + .reg_cal = mt8901_reg_cals,
> > > > + .pins = mtk_pins_mt8901,
> > > > + .npins = ARRAY_SIZE(mtk_pins_mt8901),
> > > > + .ngrps = ARRAY_SIZE(mtk_pins_mt8901),
> > > > + .eint_hw = &mt8901_eint_hw,
> > > > + .eint_pin = eint_pins_mt8901,
> > > > + .nfuncs = 8,
> > > > + .gpio_m = 0,
> > > > + .base_names = mt8901_pinctrl_register_base_name,
> > > > + .nbase_names =
> > > > ARRAY_SIZE(mt8901_pinctrl_register_base_name),
> > > > + .pull_type = mt8901_pull_type,
> > > > + .pin_rsel = mt8901_pin_rsel_val_range,
> > > > + .npin_rsel = ARRAY_SIZE(mt8901_pin_rsel_val_range),
> > > > /*numsel*/
> > > > + .bias_set_combo = mtk_pinconf_bias_set_combo,
> > > > + .bias_get_combo = mtk_pinconf_bias_get_combo,
> > > > + .drive_set = mtk_pinconf_drive_set_rev1,
> > > > + .drive_get = mtk_pinconf_drive_get_rev1,
> > > > + .adv_drive_set = mtk_pinconf_adv_drive_set_raw,
> > > > + .adv_drive_get = mtk_pinconf_adv_drive_get_raw,
> > > > +};
> > > > +
> > > > +static const struct acpi_device_id mt8901_pinctrl_acpi_match[]
> > > > =
> > > > {
> > > > + {"NVDA9221", (kernel_ulong_t)&mt8901_data },
> > > > + { }
> > > > +};
> > > > +MODULE_DEVICE_TABLE(acpi, mt8901_pinctrl_acpi_match);
> > > > +
> > > > +static struct platform_driver mt8901_pinctrl_driver = {
> > > > + .driver = {
> > > > + .name = "mt8901-pinctrl",
> > > > + .acpi_match_table =
> > > > ACPI_PTR(mt8901_pinctrl_acpi_match),
> > >
> > > Please also add support for devicetree - I have a hunch (and I'm
> > > sure
> > > that I am
> > > not the only one) that ACPI may give some issues at the end of
> > > the
> > > day, on ARM64.
> > >
> > > Of course, I'd hope that ACPI is all good on this platform, but
> > > still.... :-)
> > >
> > > static const struct of_device_id mt8901_pinctrl_of_match[] = {
> > > { .compatible = "mediatek,mt8901-pinctrl", .data =
> > > &mt8901_data },
> > > { /* sentinel */ }
> > > };
> > >
> > > .of_match_table = mt8901_pinctrl_of_match,
> > >
> > > > + .pm = pm_sleep_ptr(&mtk_paris_pinctrl_pm_ops)
> > > > + },
> > > > + .probe = mtk_paris_pinctrl_probe,
> > > > +};
> > >
> >
> > Hi Deep,
> >
> > Could you please check and feedback to Angelo?
> >
> > Regards,
> > Fred-WY Chen
> >
> > > Cheers,
> > > Angelo
> > >
> > > > +
> > > > +static int __init mt8901_pinctrl_init(void)
> > > > +{
> > > > + return platform_driver_register(&mt8901_pinctrl_driver);
> > > > +}
> > > > +
> > > > +arch_initcall(mt8901_pinctrl_init);
> > > > +
> > > > +MODULE_LICENSE("GPL");
> > > > +MODULE_DESCRIPTION("MediaTek MT8901 Pinctrl Driver");
> >
>
^ permalink raw reply
* Re: [PATCH 1/3] pinctrl: mediatek: Add gpio-range record in pinctrl driver
From: Deep Pani @ 2026-04-17 6:02 UTC (permalink / raw)
To: Fred-WY Chen (陳威宇),
andriy.shevchenko@intel.com, Lei Xue (薛磊),
Mandeep S
Cc: Qingliang Li (黎晴亮), sean.wang@kernel.org,
Yaoy Wang (王瑶瑶), AngeloGioacchino Del Regno,
Yong Mao (毛勇), linux-gpio@vger.kernel.org,
linux-kernel@vger.kernel.org, linus.walleij@linaro.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com,
Cathy Xu (许华婷),
Shunxi Zhang (章顺喜),
Ye Wang (王叶)
In-Reply-To: <9e802950ae47071bb34bb373419dc89c9add9d0b.camel@mediatek.com>
Hi Andy,
Any updates from your side?
Thanks and Regards,
Deep Pani
On Fri, 2026-03-27 at 21:33 +0800, Deep Pani wrote:
> Hi Andy,
>
> You mean gpiochip_add_pin_range(), correct?
>
> IIRC, that adds to gpiochip's range, not the range we are using for
> our
> pinctrl driver.
>
> The range we are utilizing inside our hardware is of the type struct
> pinctrl_gpio_range. There is no callback in gpiochip that handles
> this
> type of range
>
> I also recall that gpiochip_add_data() doesn't initialize the hw but
> rather initializes the gpiochip from the hw data we will provide in
> mtk_build_gpiochip(). Thus we need a function which will help
> initialize the pinctrl_gpio_range inside our pinctrl driver
> structure.
> This is why we make the mtk_pinctrl_gpio_range_init function here.
>
> For the second question, we are keeping it because before ACPI is
> invoked we still need some other pins to be configured, especially if
> different pins have different styles of pull configuration. The
> method
> we use is to define those configurations in the pinctrl-mt8901.c file
> which determines the gpio ranges and maps pinctrl device to acpi, one
> set of gpio ranges per configuration, for different type of pull
> configurations we have different gpio ranges, this callback helps add
> them into the pinctrl subsystem such that other device maintainers
> can
> easily leverage that subsystem to add their resources in their _CRS
> calls using the common interfaces.
>
> Thus we need to keep both the functions.
>
> Thanks and Regards,
> Deep Pani
>
>
>
> On Thu, 2026-03-26 at 12:33 +0000, Fred-WY Chen (陳威宇) wrote:
> > On Wed, 2025-11-26 at 19:06 +0100, Andy Shevchenko wrote:
> > >
> > > External email : Please do not click links or open attachments
> > > until
> > > you have verified the sender or the content.
> > >
> > >
> > > On Tue, Nov 25, 2025 at 10:36:34AM +0800, Lei Xue wrote:
> > > > Kernel GPIO subsystem mapping hardware pin number to a
> > > > different
> > > > range of gpio number. Add gpio-range structure to hold
> > > > the mapped gpio range in pinctrl driver. That enables the
> > > > kernel
> > > > to search a range of mapped gpio range against a pinctrl
> > > > device.
> > >
> > > ...
> > >
> > > > static int mtk_build_gpiochip(struct mtk_pinctrl *hw)
> > > > {
> > > > struct gpio_chip *chip = &hw->chip;
> > >
> > > > if (ret < 0)
> > > > return ret;
> > > >
> > > > + mtk_pinctrl_gpio_range_init(hw, chip);
> > > > +
> > > > return 0;
> > >
> > > We have a callback for that in struct gpio_chip. Any reason not
> > > to
> > > use it?
> > >
> > > > }
> > >
> > > ...
> > >
> > > > + pinctrl_add_gpio_range(hw->pctrl, &hw->range);
> > >
> > > Not sure if this is needed.
> > >
> >
> > Hi Deep,
> >
> > Could you please check this and feedback?
> >
> > Regards,
> > Fred-WY Chen
> >
> > > --
> > > With Best Regards,
> > > Andy Shevchenko
> > >
> > >
> >
>
^ permalink raw reply
* Re: [GIT PULL 4/4] soc: ARM code changes for 7.1
From: pr-tracker-bot @ 2026-04-17 4:10 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Linus Torvalds, soc, linux-kernel, linux-arm-kernel
In-Reply-To: <2af6e914-7d5f-4976-8b18-0a98ad3a427c@app.fastmail.com>
The pull request you sent on Fri, 17 Apr 2026 00:31:18 +0200:
> https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/soc-arm-7.1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8242c709d4ba858c483ef7ef3cc2dc1280f5383c
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: Re: [GIT PULL 2/4] soc: drivers for 7.1
From: pr-tracker-bot @ 2026-04-17 4:10 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Linus Torvalds, soc, linux-kernel, linux-arm-kernel
In-Reply-To: <d80b4370-3d20-4d7c-b91f-455797c52b39@app.fastmail.com>
The pull request you sent on Fri, 17 Apr 2026 00:28:45 +0200:
> https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/soc-drivers-7.1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/31b43c079f9aa55754c20404a42bca9a49e01f60
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL 3/4] soc: defconfig updates for 7.1
From: pr-tracker-bot @ 2026-04-17 4:10 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Linus Torvalds, soc, linux-kernel, linux-arm-kernel
In-Reply-To: <704b8a79-4fe5-4815-82aa-026de29dcf1a@app.fastmail.com>
The pull request you sent on Fri, 17 Apr 2026 00:30:16 +0200:
> https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/soc-defconfig-7.1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/231d703058b2e2ee59884c8531e02c60a2a109ab
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [GIT PULL 1/4] soc: dt changes for 7.1
From: pr-tracker-bot @ 2026-04-17 4:10 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Linus Torvalds, soc, linux-kernel, linux-arm-kernel
In-Reply-To: <b3203b1d-4c1d-49b8-924e-c17cf6be7ec0@app.fastmail.com>
The pull request you sent on Fri, 17 Apr 2026 00:22:48 +0200:
> https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/soc-dt-7.1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e65f4718a577fcc84d40431f022985898b6dbf2e
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* [PATCH net] net: dsa: mt7530: fix .get_stats64 sleeping in atomic context
From: Daniel Golle @ 2026-04-17 3:55 UTC (permalink / raw)
To: Chester A. Unal, Daniel Golle, Andrew Lunn, Vladimir Oltean,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Matthias Brugger, AngeloGioacchino Del Regno, Russell King,
Christian Marangi, netdev, linux-kernel, linux-arm-kernel,
linux-mediatek
Cc: Frank Wunderlich, John Crispin
The .get_stats64 callback runs in atomic context, but on
MDIO-connected switches every register read acquires the MDIO bus
mutex, which can sleep:
[ 12.645973] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:609
[ 12.654442] in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 759, name: grep
[ 12.663377] preempt_count: 0, expected: 0
[ 12.667410] RCU nest depth: 1, expected: 0
[ 12.671511] INFO: lockdep is turned off.
[ 12.675441] CPU: 0 UID: 0 PID: 759 Comm: grep Tainted: G S W 7.0.0+ #0 PREEMPT
[ 12.675453] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN
[ 12.675456] Hardware name: Bananapi BPI-R64 (DT)
[ 12.675459] Call trace:
[ 12.675462] show_stack+0x14/0x1c (C)
[ 12.675477] dump_stack_lvl+0x68/0x8c
[ 12.675487] dump_stack+0x14/0x1c
[ 12.675495] __might_resched+0x14c/0x220
[ 12.675504] __might_sleep+0x44/0x80
[ 12.675511] __mutex_lock+0x50/0xb10
[ 12.675523] mutex_lock_nested+0x20/0x30
[ 12.675532] mt7530_get_stats64+0x40/0x2ac
[ 12.675542] dsa_user_get_stats64+0x2c/0x40
[ 12.675553] dev_get_stats+0x44/0x1e0
[ 12.675564] dev_seq_printf_stats+0x24/0xe0
[ 12.675575] dev_seq_show+0x14/0x3c
[ 12.675583] seq_read_iter+0x37c/0x480
[ 12.675595] seq_read+0xd0/0xec
[ 12.675605] proc_reg_read+0x94/0xe4
[ 12.675615] vfs_read+0x98/0x29c
[ 12.675625] ksys_read+0x54/0xdc
[ 12.675633] __arm64_sys_read+0x18/0x20
[ 12.675642] invoke_syscall.constprop.0+0x54/0xec
[ 12.675653] do_el0_svc+0x3c/0xb4
[ 12.675662] el0_svc+0x38/0x200
[ 12.675670] el0t_64_sync_handler+0x98/0xdc
[ 12.675679] el0t_64_sync+0x158/0x15c
For MDIO-connected switches, poll MIB counters asynchronously using a
delayed workqueue every second and let .get_stats64 return the cached
values under a per-port spinlock. A mod_delayed_work() call on each
read triggers an immediate refresh so counters stay responsive when
queried more frequently.
MMIO-connected switches (MT7988, EN7581, AN7583) are not affected
because their regmap does not sleep, so they continue to read MIB
counters directly in .get_stats64.
Fixes: 88c810f35ed5 ("net: dsa: mt7530: implement .get_stats64")
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
This bug highlights a bigger problem and the actual cause:
Locking in the mt7530 driver deserves a cleanup, and refactoring
towards cleanly and directly using the regmap API.
I've prepared this already and am going to submit a series doing
most of that using Coccinelle semantic patches once net-next opens
again.
drivers/net/dsa/mt7530.c | 54 +++++++++++++++++++++++++++++++++++++---
drivers/net/dsa/mt7530.h | 6 +++++
2 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c
index b9423389c2ef0..786d3a8492bcb 100644
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -25,6 +25,8 @@
#include "mt7530.h"
+#define MT7530_STATS_POLL_INTERVAL (1 * HZ)
+
static struct mt753x_pcs *pcs_to_mt753x_pcs(struct phylink_pcs *pcs)
{
return container_of(pcs, struct mt753x_pcs, pcs);
@@ -906,10 +908,9 @@ static void mt7530_get_rmon_stats(struct dsa_switch *ds, int port,
*ranges = mt7530_rmon_ranges;
}
-static void mt7530_get_stats64(struct dsa_switch *ds, int port,
- struct rtnl_link_stats64 *storage)
+static void mt7530_read_port_stats64(struct mt7530_priv *priv, int port,
+ struct rtnl_link_stats64 *storage)
{
- struct mt7530_priv *priv = ds->priv;
uint64_t data;
/* MIB counter doesn't provide a FramesTransmittedOK but instead
@@ -951,6 +952,43 @@ static void mt7530_get_stats64(struct dsa_switch *ds, int port,
&storage->rx_crc_errors);
}
+static void mt7530_stats_poll(struct work_struct *work)
+{
+ struct mt7530_priv *priv = container_of(work, struct mt7530_priv,
+ stats_work.work);
+ struct rtnl_link_stats64 stats = {};
+ struct dsa_port *dp;
+ int port;
+
+ dsa_switch_for_each_user_port(dp, priv->ds) {
+ port = dp->index;
+
+ mt7530_read_port_stats64(priv, port, &stats);
+
+ spin_lock(&priv->stats_lock);
+ priv->ports[port].stats = stats;
+ spin_unlock(&priv->stats_lock);
+ }
+
+ schedule_delayed_work(&priv->stats_work,
+ MT7530_STATS_POLL_INTERVAL);
+}
+
+static void mt7530_get_stats64(struct dsa_switch *ds, int port,
+ struct rtnl_link_stats64 *storage)
+{
+ struct mt7530_priv *priv = ds->priv;
+
+ if (priv->bus) {
+ spin_lock(&priv->stats_lock);
+ *storage = priv->ports[port].stats;
+ spin_unlock(&priv->stats_lock);
+ mod_delayed_work(system_wq, &priv->stats_work, 0);
+ } else {
+ mt7530_read_port_stats64(priv, port, storage);
+ }
+}
+
static void mt7530_get_eth_ctrl_stats(struct dsa_switch *ds, int port,
struct ethtool_eth_ctrl_stats *ctrl_stats)
{
@@ -3137,6 +3175,13 @@ mt753x_setup(struct dsa_switch *ds)
if (ret && priv->irq_domain)
mt7530_free_mdio_irq(priv);
+ if (!ret && priv->bus) {
+ spin_lock_init(&priv->stats_lock);
+ INIT_DELAYED_WORK(&priv->stats_work, mt7530_stats_poll);
+ schedule_delayed_work(&priv->stats_work,
+ MT7530_STATS_POLL_INTERVAL);
+ }
+
return ret;
}
@@ -3404,6 +3449,9 @@ EXPORT_SYMBOL_GPL(mt7530_probe_common);
void
mt7530_remove_common(struct mt7530_priv *priv)
{
+ if (priv->bus)
+ cancel_delayed_work_sync(&priv->stats_work);
+
if (priv->irq_domain)
mt7530_free_mdio_irq(priv);
diff --git a/drivers/net/dsa/mt7530.h b/drivers/net/dsa/mt7530.h
index 3e0090bed298d..44c1dc75baea8 100644
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -796,6 +796,7 @@ struct mt7530_fdb {
* @pvid: The VLAN specified is to be considered a PVID at ingress. Any
* untagged frames will be assigned to the related VLAN.
* @sgmii_pcs: Pointer to PCS instance for SerDes ports
+ * @stats: Cached port statistics for MDIO-connected switches
*/
struct mt7530_port {
bool enable;
@@ -803,6 +804,7 @@ struct mt7530_port {
u32 pm;
u16 pvid;
struct phylink_pcs *sgmii_pcs;
+ struct rtnl_link_stats64 stats;
};
/* Port 5 mode definitions of the MT7530 switch */
@@ -875,6 +877,8 @@ struct mt753x_info {
* @create_sgmii: Pointer to function creating SGMII PCS instance(s)
* @active_cpu_ports: Holding the active CPU ports
* @mdiodev: The pointer to the MDIO device structure
+ * @stats_lock: Protects cached per-port stats from concurrent access
+ * @stats_work: Delayed work for polling MIB counters on MDIO switches
*/
struct mt7530_priv {
struct device *dev;
@@ -900,6 +904,8 @@ struct mt7530_priv {
int (*create_sgmii)(struct mt7530_priv *priv);
u8 active_cpu_ports;
struct mdio_device *mdiodev;
+ spinlock_t stats_lock; /* protects cached stats counters */
+ struct delayed_work stats_work;
};
struct mt7530_hw_vlan_entry {
--
2.53.0
^ permalink raw reply related
* [PATCH] gpio: drop bitmap_complement() where feasible
From: Yury Norov @ 2026-04-17 3:34 UTC (permalink / raw)
To: Linus Walleij, Andy Shevchenko, Bartosz Golaszewski,
Shubhrajyoti Datta, Srinivas Neeli, Michal Simek, linux-gpio,
linux-kernel, linux-arm-kernel
Cc: Yury Norov
The gpio drivers reproduce the following pattern:
bitmap_complement(tmp, data1, nbits);
bitmap_and(dst, data2, tmp, nbits);
This can be done in a single pass:
bitmap_andnot(dst, data2, data1t, nbits);
Signed-off-by: Yury Norov <ynorov@nvidia.com>
---
drivers/gpio/gpio-pca953x.c | 7 ++-----
drivers/gpio/gpio-xilinx.c | 6 ++----
2 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 52e96cc5f67b..1fef733fe1f0 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -877,11 +877,9 @@ static void pca953x_irq_bus_sync_unlock(struct irq_data *d)
bitmap_or(irq_mask, chip->irq_trig_fall, chip->irq_trig_raise, gc->ngpio);
bitmap_or(irq_mask, irq_mask, chip->irq_trig_level_high, gc->ngpio);
bitmap_or(irq_mask, irq_mask, chip->irq_trig_level_low, gc->ngpio);
- bitmap_complement(reg_direction, reg_direction, gc->ngpio);
- bitmap_and(irq_mask, irq_mask, reg_direction, gc->ngpio);
/* Look for any newly setup interrupt */
- for_each_set_bit(level, irq_mask, gc->ngpio)
+ for_each_andnot_bit(level, irq_mask, reg_direction, gc->ngpio)
pca953x_gpio_direction_input(&chip->gpio_chip, level);
mutex_unlock(&chip->irq_lock);
@@ -1005,8 +1003,7 @@ static bool pca953x_irq_pending(struct pca953x_chip *chip, unsigned long *pendin
bitmap_and(cur_stat, cur_stat, chip->irq_mask, gc->ngpio);
bitmap_or(pending, pending, cur_stat, gc->ngpio);
- bitmap_complement(cur_stat, new_stat, gc->ngpio);
- bitmap_and(cur_stat, cur_stat, reg_direction, gc->ngpio);
+ bitmap_andnot(cur_stat, reg_direction, new_stat, gc->ngpio);
bitmap_and(old_stat, cur_stat, chip->irq_trig_level_low, gc->ngpio);
bitmap_and(old_stat, old_stat, chip->irq_mask, gc->ngpio);
bitmap_or(pending, pending, old_stat, gc->ngpio);
diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
index be4b4d730547..532205175827 100644
--- a/drivers/gpio/gpio-xilinx.c
+++ b/drivers/gpio/gpio-xilinx.c
@@ -495,13 +495,11 @@ static void xgpio_irqhandler(struct irq_desc *desc)
xgpio_read_ch_all(chip, XGPIO_DATA_OFFSET, hw);
- bitmap_complement(rising, chip->last_irq_read, 64);
- bitmap_and(rising, rising, hw, 64);
+ bitmap_andnot(rising, hw, chip->last_irq_read, 64);
bitmap_and(rising, rising, chip->enable, 64);
bitmap_and(rising, rising, chip->rising_edge, 64);
- bitmap_complement(falling, hw, 64);
- bitmap_and(falling, falling, chip->last_irq_read, 64);
+ bitmap_andnot(falling, chip->last_irq_read, hw, 64);
bitmap_and(falling, falling, chip->enable, 64);
bitmap_and(falling, falling, chip->falling_edge, 64);
--
2.51.0
^ permalink raw reply related
* RE: [PATCH V13 02/12] PCI: host-generic: Add common helpers for parsing Root Port properties
From: Sherry Sun @ 2026-04-17 3:17 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
mani@kernel.org, bhelgaas@google.com, Hongxing Zhu,
l.stach@pengutronix.de, imx@lists.linux.dev,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260416203905.GA29913@bhelgaas>
> On Thu, Apr 16, 2026 at 07:14:12PM +0800, Sherry Sun wrote:
> > Introduce generic helper functions to parse Root Port device tree
> > nodes and extract common properties like reset GPIOs. This allows
> > multiple PCI host controller drivers to share the same parsing logic.
> >
> > Define struct pci_host_port to hold common Root Port properties
> > (currently only reset GPIO descriptor) and add
> > pci_host_common_parse_ports() to parse Root Port nodes from device
> tree.
>
> Are the Root Port and the RC the only possible places for 'reset' GPIO
> descriptions in DT? I think PERST# routing is outside the PCIe spec, so it
> seems like a system could provide a PERST# GPIO routed to any Switch
> Upstream Port or Endpoint (I assume a PERST# connected to a switch would
> apply to both the upstream port and the downstream ports).
Hi Bjorn,
Thanks for the feedback. You're right that PERST# routing could theoretically be
connected to any device in the hierarchy. However, for this patch series, I've focused
on the most common use case in practice: use Root Port level PERST# instead of the
legacy Root Complex level PERST#.
Root Port level PERST# - This is the primary target, where each Root Port has individual
control over devices connected to it.
RC level PERST# - Legacy binding support, where a single GPIO controls all ports.
We can extend this framework later if real hardware emerges that needs Switch or
EP-level PERST# control. I can add a comment documenting this limitation if needed.
BTW, Mani and Rob had some great discussions in dt-schema about PERST# and WAKE#
sideband signals settings.
You can check here:
https://github.com/devicetree-org/dt-schema/issues/168
https://github.com/devicetree-org/dt-schema/pull/126
https://github.com/devicetree-org/dt-schema/pull/170
Best Regards
Sherry
^ permalink raw reply
* Re: [PATCH v2 net 0/2] net: enetc: fix command BD ring issues
From: patchwork-bot+netdevbpf @ 2026-04-17 2:40 UTC (permalink / raw)
To: Wei Fang
Cc: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, chleroy, netdev, linux-kernel, imx,
linuxppc-dev, linux-arm-kernel
In-Reply-To: <20260415060833.2303846-1-wei.fang@nxp.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 15 Apr 2026 14:08:31 +0800 you wrote:
> Currently, the implementation of command BD ring has two issues, one is
> that the driver may obtain wrong consumer index of the ring, because the
> driver does not mask out the SBE bit of the CIR value, so a wrong index
> will be obtained when a SBE error ouccrs. The other one is that the DMA
> buffer may be used after free. If netc_xmit_ntmp_cmd() times out and
> returns an error, the pending command is not explicitly aborted, while
> ntmp_free_data_mem() unconditionally frees the DMA buffer. If the buffer
> has already been reallocated elsewhere, this may lead to silent memory
> corruption. Because the hardware eventually processes the pending command
> and perform a DMA write of the response to the physical address of the
> freed buffer. So this patch set is to fix these two issues.
>
> [...]
Here is the summary with links:
- [v2,net,1/2] net: enetc: correct the command BD ring consumer index
https://git.kernel.org/netdev/net/c/759a32900b6f
- [v2,net,2/2] net: enetc: fix NTMP DMA use-after-free issue
https://git.kernel.org/netdev/net/c/3cade698881e
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 v7 1/3] dt-bindings: pinctrl: Add aspeed,ast2700-soc0-pinctrl
From: Billy Tsai @ 2026-04-17 2:20 UTC (permalink / raw)
To: Conor Dooley
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Linus Walleij, Bartosz Golaszewski,
Ryan Chen, Andrew Jeffery, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, linux-gpio@vger.kernel.org,
linux-clk@vger.kernel.org
In-Reply-To: <20260416-brutishly-saga-ba7168a4cd14@spud>
> > + properties:
> > + function:
> > + enum:
> > + - EMMC
> > + - JTAGDDR
> > + - JTAGM0
> > + - JTAGPCIEA
> > + - JTAGPCIEB
> > + - JTAGPSP
> > + - JTAGSSP
> > + - JTAGTSP
> > + - JTAGUSB3A
> > + - JTAGUSB3B
> > + - PCIERC0PERST
> > + - PCIERC1PERST
> > + - TSPRSTN
> > + - UFSCLKI
> > + - USB2AD0
> > + - USB2AD1
> > + - USB2AH
> > + - USB2AHP
> > + - USB2AHPD0
> > + - USB2AXH
> > + - USB2AXH2B
> > + - USB2AXHD1
> > + - USB2AXHP
> > + - USB2AXHP2B
> > + - USB2AXHPD1
> > + - USB2BD0
> > + - USB2BD1
> > + - USB2BH
> > + - USB2BHP
> > + - USB2BHPD0
> > + - USB2BXH
> > + - USB2BXH2A
> > + - USB2BXHD1
> > + - USB2BXHP
> > + - USB2BXHP2A
> > + - USB2BXHPD1
> > + - USB3AXH
> > + - USB3AXH2B
> > + - USB3AXHD
> > + - USB3AXHP
> > + - USB3AXHP2B
> > + - USB3AXHPD
> > + - USB3BXH
> > + - USB3BXH2A
> > + - USB3BXHD
> > + - USB3BXHP
> > + - USB3BXHP2A
> > + - USB3BXHPD
> > + - VB
> > + - VGADDC
> > +
> > + groups:
> > + enum:
> > + - EMMCCDN
> > + - EMMCG1
> > + - EMMCG4
> > + - EMMCG8
> > + - EMMCWPN
> > + - JTAG0
> > + - PCIERC0PERST
> > + - PCIERC1PERST
> > + - TSPRSTN
> > + - UFSCLKI
> > + - USB2A
> > + - USB2AAP
> > + - USB2ABP
> > + - USB2ADAP
> > + - USB2AH
> > + - USB2AHAP
> > + - USB2B
> > + - USB2BAP
> > + - USB2BBP
> > + - USB2BDBP
> > + - USB2BH
> > + - USB2BHBP
> > + - USB3A
> > + - USB3AAP
> > + - USB3ABP
> > + - USB3B
> > + - USB3BAP
> > + - USB3BBP
> > + - VB0
> > + - VB1
> > + - VGADDC
> > + pins:
> > + enum:
> > + - AB13
> > + - AB14
> > + - AC13
> > + - AC14
> > + - AD13
> > + - AD14
> > + - AE13
> > + - AE14
> > + - AE15
> > + - AF13
> > + - AF14
> > + - AF15
> Why do you have groups and pins?
> Is it valid in your device to have groups and pins in the same node?
The intent is to support both group-based mux selection and
configuration, as well as per-pin configuration.
In our hardware:
- `function` + `groups` are used for pinmux selection.
- `pins` is used for per-pin configuration (e.g. drive strength,
bias settings).
- `groups` may also be used for group-level configuration.
As a result, both `groups` and `pins` may appear in the same node,
but they serve different purposes and do not conflict:
- `groups` selects the mux function and may apply configuration to
the entire group.
- `pins` allows overriding or specifying configuration for individual
pins.
In most cases, only one of them is needed, but both are allowed when
both group-level and per-pin configuration are required.
Thanks
Billy Tsai
^ permalink raw reply
* [PATCH] dt-bindings: Remove the redundant 'type: boolean'
From: phucduc.bui @ 2026-04-17 2:18 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt
Cc: nick, dmitry.torokhov, nicolas.ferre, alexandre.belloni,
claudiu.beznea, lee, heiko, gregkh, linusw, zyw, zhangqing,
gene_chen, linux-input, devicetree, linux-arm-kernel, linux-usb,
bui duc phuc
From: bui duc phuc <phucduc.bui@gmail.com>
The 'wakeup-source' property already has its type defined in the core
schema. Remove the redundant 'type: boolean' from the binding file to
clean up the binding files.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
---
Documentation/devicetree/bindings/input/atmel,maxtouch.yaml | 3 +--
Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml | 3 +--
Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml | 3 +--
3 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
index 9bf07acea599..26ea78df27c4 100644
--- a/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
+++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.yaml
@@ -88,8 +88,7 @@ properties:
- 2 # ATMEL_MXT_WAKEUP_GPIO
default: 0
- wakeup-source:
- type: boolean
+ wakeup-source: true
required:
- compatible
diff --git a/Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml b/Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml
index 0676890f101e..a58d9455a1a5 100644
--- a/Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml
+++ b/Documentation/devicetree/bindings/mfd/rockchip,rk816.yaml
@@ -44,8 +44,7 @@ properties:
description:
Telling whether or not this PMIC is controlling the system power.
- wakeup-source:
- type: boolean
+ wakeup-source: true
vcc1-supply:
description:
diff --git a/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml b/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml
index ae611f7e57ca..ec0d83220527 100644
--- a/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml
+++ b/Documentation/devicetree/bindings/usb/richtek,rt1711h.yaml
@@ -33,8 +33,7 @@ properties:
vbus-supply:
description: VBUS power supply
- wakeup-source:
- type: boolean
+ wakeup-source: true
connector:
type: object
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net v2] net: airoha: Wait for NPU PPE configuration to complete in airoha_ppe_offload_setup()
From: patchwork-bot+netdevbpf @ 2026-04-17 2:10 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, linux-arm-kernel,
linux-mediatek, netdev
In-Reply-To: <20260414-airoha-wait-for-npu-config-offload-setup-v2-1-5a9bf6d43aee@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 14 Apr 2026 16:08:52 +0200 you wrote:
> In order to properly enable flowtable hw offloading, poll
> REG_PPE_FLOW_CFG register in airoha_ppe_offload_setup routine and
> wait for NPU PPE configuration triggered by ppe_init callback to complete
> before running airoha_ppe_hw_init().
>
> Fixes: 00a7678310fe3 ("net: airoha: Introduce flowtable offload support")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> [...]
Here is the summary with links:
- [net,v2] net: airoha: Wait for NPU PPE configuration to complete in airoha_ppe_offload_setup()
https://git.kernel.org/netdev/net/c/f3206328bb52
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: arm64: Supporting DYNAMIC_FTRACE_WITH_CALL_OPS with CLANG_CFI
From: Clayton Craft @ 2026-04-17 1:10 UTC (permalink / raw)
To: Puranjay Mohan, catalin.marinas, ast, daniel, mark.rutland,
broonie, linux-arm-kernel, linux-kernel, bpf
Cc: craftyguy
In-Reply-To: <mb61pedcvxdhw.fsf@gmail.com>
On Thu Feb 29, 2024 at 11:43 AM PST, Puranjay Mohan wrote:
> puranjay12@gmail.com writes:
> I hacked some patches and tried the above approach:
>
> Here are the patches(RFC) that I created:
>
> LLVM Patch:
Hi Puranjay,
Did this LLVM patch ever make it upstream? I'd like to use CFI together
with BPF LSM on arm64 and wondering what the current state of this
effort is.
Thanks,
Clayton
^ 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