* WITHDRAWN -RE: [PATCH net V2 0/2] Correct BD length masks and BQL accounting for multi-BD TX packets
From: Gupta, Suraj @ 2026-03-26 19:46 UTC (permalink / raw)
To: Gupta, Suraj, andrew+netdev@lunn.ch, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
Simek, Michal, sean.anderson@linux.dev, Pandey, Radhey Shyam,
horms@kernel.org
Cc: netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Katakam, Harini
In-Reply-To: <20260326185510.3840084-1-suraj.gupta2@amd.com>
[Public]
> -----Original Message-----
> From: Suraj Gupta <suraj.gupta2@amd.com>
> Sent: Friday, March 27, 2026 12:25 AM
> To: andrew+netdev@lunn.ch; davem@davemloft.net; edumazet@google.com;
> kuba@kernel.org; pabeni@redhat.com; Simek, Michal
> <michal.simek@amd.com>; sean.anderson@linux.dev; Pandey, Radhey Shyam
> <radhey.shyam.pandey@amd.com>; horms@kernel.org
> Cc: netdev@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Katakam, Harini <harini.katakam@amd.com>
> Subject: [PATCH net V2 0/2] Correct BD length masks and BQL accounting for
> multi-BD TX packets
>
Please ignore / withdraw this V2 series.
Due to a syncing issue in my outlook, I sent v2 prematurely. There is still ongoing discussion on v1 that needs to be concluded first. I'll follow up after the v1 feedback is resolved.
Thanks,
Suraj
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> This patch series fixes two issues in the Xilinx AXI Ethernet driver:
> 1. Corrects the BD length masks to match the AXIDMA IP spec.
> 2. Fixes BQL accounting for multi-BD TX packets.
>
> ---
> Changes in V2:
> Use GENMASK() to define the BD length masks.
> ---
> Suraj Gupta (2):
> net: xilinx: axienet: Correct BD length masks to match AXIDMA IP spec
> net: xilinx: axienet: Fix BQL accounting for multi-BD TX packets
>
> drivers/net/ethernet/xilinx/xilinx_axienet.h | 7 +++++--
> .../net/ethernet/xilinx/xilinx_axienet_main.c | 20 +++++++++----------
> 2 files changed, 15 insertions(+), 12 deletions(-)
>
> --
> 2.49.1
>
^ permalink raw reply
* Re: [PATCH v3 1/2] media: dt-bindings: rockchip,rk3568-mipi-csi2: add rk3588 compatible
From: Rob Herring @ 2026-03-26 19:42 UTC (permalink / raw)
To: Michael Riesch
Cc: Mauro Carvalho Chehab, Sakari Ailus, Laurent Pinchart, Frank Li,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, Kever Yang,
Collabora Kernel Team, linux-media, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <703bcf13-ab45-4e9a-b80c-80911d85d819@collabora.com>
On Wed, Mar 25, 2026 at 4:34 PM Michael Riesch
<michael.riesch@collabora.com> wrote:
>
> Hi Rob,
>
> On 3/25/26 22:06, Rob Herring wrote:
> > On Wed, Mar 25, 2026 at 11:25:34AM +0100, Michael Riesch wrote:
> >> The RK3588 MIPI CSI-2 receivers are compatible to the ones found in
> >> the RK3568.
> >> Introduce a list of compatible variants and add the RK3588 variant to
> >> it.
> >>
> >> Acked-by: Rob Herring (Arm) <robh@kernel.org>
>
> First of all, apologies for applying your Acked-by tag. I figured
> resolving the merged conflict was trivial and impossible to screw up, but...
No worries. I would have kept it too.
> >> Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
> >> ---
> >> .../devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml | 10 +++++++---
> >> 1 file changed, 7 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
> >> index 4ac4a3b6f406..3d3b3cd78884 100644
> >> --- a/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
> >> +++ b/Documentation/devicetree/bindings/media/rockchip,rk3568-mipi-csi2.yaml
> >> @@ -16,9 +16,13 @@ description:
> >>
> >> properties:
> >> compatible:
> >> - enum:
> >> - - fsl,imx93-mipi-csi2
> >> - - rockchip,rk3568-mipi-csi2
> >> + oneOf:
> >> + - const: fsl,imx93-mipi-csi2
> >> + - const: rockchip,rk3568-mipi-csi2
> >
> > These 2 should be a single enum as they were before.
>
> ... hm. Well.
>
> First, do you mean
>
> properties:
> compatible:
> oneOf:
> - enum:
> - fsl,imx93-mipi-csi2
> - rockchip,rk3568-mipi-csi2
> - items:
> - enum:
> - rockchip,rk3588-mipi-csi2
> - const: rockchip,rk3568-mipi-csi2
> ?
Yes.
> If so, what is the practical difference?
First, then you aren't changing what's already there. For validation,
there is no difference other than failures with 'oneOf' give poor
error messages. It wouldn't be much better, just one less oneOf entry.
Rob
^ permalink raw reply
* Re: [PATCH RESEND] drm/rockchip: cdn-dp: add missing check in cdn_dp_config_video()
From: Heiko Stuebner @ 2026-03-26 19:41 UTC (permalink / raw)
To: Sandy Huang, Andy Yan, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, dri-devel,
linux-rockchip, Sergey Shtylyov
Cc: Heiko Stuebner, linux-arm-kernel, stable
In-Reply-To: <adf6b313-f7db-4d8f-9000-8c65446ba041@auroraos.dev>
On Fri, 30 Jan 2026 23:35:42 +0300, Sergey Shtylyov wrote:
> The result of cdn_dp_reg_write() is checked everywhere (with the error
> being logged by the callers) except one place in cdn_dp_config_video().
> Add the missing result check, bailing out early on error...
>
> Found by Linux Verification Center (linuxtesting.org) with the Svace static
> analysis tool.
>
> [...]
Applied, thanks!
[1/1] drm/rockchip: cdn-dp: add missing check in cdn_dp_config_video()
commit: 46c31e1604d121221167cb09380de8c7d53290b9
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: (subset) [PATCH v2 0/8] Rockchip DRM use-after-free & null-ptr-deref fixes
From: Heiko Stuebner @ 2026-03-26 19:41 UTC (permalink / raw)
To: Sandy Huang, Andy Yan, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Dmitry Baryshkov,
Dmitry Baryshkov, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Cristian Ciocaltea
Cc: Heiko Stuebner, kernel, dri-devel, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260310-drm-rk-fixes-v2-0-645ecfb43f49@collabora.com>
On Tue, 10 Mar 2026 00:44:28 +0200, Cristian Ciocaltea wrote:
> The first three patches in the series are fixes for use-after-free &
> null-ptr-deref related issues found in dw_dp and inno-hdmi Rockchip DRM
> drivers.
>
> The following three patches provide a few minor improvements to dw_dp
> and dw_hdmi_qp, while the remaining two address use-after-free and
> memory allocation in DW DP core library.
>
> [...]
Applied, thanks!
[1/8] drm/rockchip: inno-hdmi: Switch to drmm_kzalloc()
commit: 3cc50e7f73fcf79f28660b9d91566b13cb62e520
[2/8] drm/rockchip: dw_dp: Switch to drmm_kzalloc()
commit: ed9da8d23020352ad24c528db09b5acdd78b81fd
[3/8] drm/rockchip: dw_dp: Fix null-ptr-deref in dw_dp_remove()
commit: 9456381d8b60bb7dd42f2f04afe5ee4ce6e0bc12
[4/8] drm/rockchip: dw_dp: Simplify error handling
commit: 26cb3e26efa7cc84289966cab871889f6ca93616
[5/8] drm/rockchip: dw_dp: Drop unnecessary #include
commit: 31a98842a11fcb52a2db9b1b498d5ac11793e35f
[6/8] drm/rockchip: dw_hdmi_qp: Switch to drmm_encoder_init()
commit: e1f7b7cbd74c6561944f5dda345dab59ad391acb
[8/8] drm/bridge: synopsys: dw-dp: Drop useless memory allocation
commit: 971a6d5d41315f3bfe1e1207f24da9a191c949ff
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* Re: [PATCH v2] drm/rockchip: analogix_dp: Add missing error check for platform_get_resource()
From: Heiko Stuebner @ 2026-03-26 19:41 UTC (permalink / raw)
To: dsimic, Chen Ni
Cc: Heiko Stuebner, airlied, andy.yan, damon.ding, dri-devel, hjc,
linux-arm-kernel, linux-kernel, linux-rockchip, maarten.lankhorst,
mripard, simona, tzimmermann, stable
In-Reply-To: <20260209033123.1089370-1-nichen@iscas.ac.cn>
On Mon, 09 Feb 2026 11:31:23 +0800, Chen Ni wrote:
> Add missing error check for platform_get_resource() return value to
> prevent NULL pointer dereference when memory resource is not available.
>
>
Applied, thanks!
[1/1] drm/rockchip: analogix_dp: Add missing error check for platform_get_resource()
commit: 45895f4d4d5f222d07412f90664f88b059627859
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply
* [PATCH] dmaengine: at_hdmac: Drop unnecessary parentheses
From: Claudiu @ 2026-03-26 19:35 UTC (permalink / raw)
To: ludovic.desroches, vkoul, Frank.Li
Cc: claudiu.beznea, linux-arm-kernel, dmaengine, linux-kernel
From: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Drop unnecessary parentheses.
Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
---
drivers/dma/at_hdmac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
index 9c8c0fea8003..060c3c868af4 100644
--- a/drivers/dma/at_hdmac.c
+++ b/drivers/dma/at_hdmac.c
@@ -816,7 +816,7 @@ static void atdma_handle_chan_done(struct at_dma_chan *atchan, u32 pending,
} else {
vchan_cookie_complete(&desc->vd);
atchan->desc = NULL;
- if (!(atc_chan_is_enabled(atchan)))
+ if (!atc_chan_is_enabled(atchan))
atc_dostart(atchan);
}
}
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 7/8] drm/bridge: synopsys: dw-dp: Unregister AUX channel on bridge detach
From: Heiko Stuebner @ 2026-03-26 19:28 UTC (permalink / raw)
To: Sandy Huang, Andy Yan, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Dmitry Baryshkov,
Dmitry Baryshkov, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Cristian Ciocaltea
Cc: kernel, dri-devel, linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20260310-drm-rk-fixes-v2-7-645ecfb43f49@collabora.com>
Am Montag, 9. März 2026, 23:44:35 Mitteleuropäische Normalzeit schrieb Cristian Ciocaltea:
> The DisplayPort AUX channel gets initialized and registered during
> dw_dp_bind(), but it is never unregistered, which may lead to resource
> leaks and/or use-after-free:
>
> [ 224.661371] BUG: KASAN: slab-use-after-free in device_is_dependent+0xe0/0x2b0
> [ 224.662015] Read of size 8 at addr ffff00011aee8550 by task modprobe/658
> ...
> [ 224.662796] device_is_dependent+0xe0/0x2b0
> [ 224.662802] device_is_dependent+0x108/0x2b0
> [ 224.662808] device_link_add+0x1f8/0x10b0
> [ 224.662813] devm_of_phy_get_by_index+0x120/0x200
> [ 224.662819] dw_dp_bind+0x34c/0xb10 [dw_dp]
> [ 224.662830] dw_dp_rockchip_bind+0x194/0x250 [rockchipdrm]
> [ 224.662864] component_bind_all+0x3a8/0x720
> [ 224.662869] rockchip_drm_bind+0x120/0x390 [rockchipdrm]
> [ 224.662899] try_to_bring_up_aggregate_device+0x76c/0x838
> [ 224.662904] component_master_add_with_match+0x1f4/0x230
> [ 224.662909] rockchip_drm_platform_probe+0x420/0x538 [rockchipdrm]
> [ 224.662939] platform_probe+0xe8/0x168
> [ 224.662945] really_probe+0x340/0x828
> [ 224.662950] __driver_probe_device+0x2e0/0x350
> [ 224.662954] driver_probe_device+0x80/0x140
> [ 224.662959] __driver_attach+0x398/0x460
> [ 224.662964] bus_for_each_dev+0xe0/0x198
> [ 224.662968] driver_attach+0x50/0x68
> [ 224.662972] bus_add_driver+0x2a0/0x4c0
> [ 224.662977] driver_register+0x294/0x360
> [ 224.662982] __platform_driver_register+0x7c/0x98
> [ 224.662987] rockchip_drm_init+0xc4/0xff8 [rockchipdrm]
> ...
>
> Unregister the AUX adapter on bridge detach.
that sounds sort of asymmetrical though. drm_bridge_funcs has attach and
detach callbacks and the component-framework also has bind and unbind
callbacks.
This might cause confusion later on I guess, especially as I don't know
if there could be a bridge attach, after the detach that unregisters the
aux adapter.
Looking at the AnalogixDP for example, it does the the register and
unregister in the bind/unbind callbacks of the core driver.
So I guess the in my eyes cleaner way would be to introduce a
dw_dp_unbind() function and put the aux unregister there?
At least that way, everything would be at the same "level".
Heiko
^ permalink raw reply
* Re: [PATCH 00/10] PCI: Improve head free space usage
From: Bjorn Helgaas @ 2026-03-26 19:25 UTC (permalink / raw)
To: Ilpo Järvinen
Cc: linux-pci, Bjorn Helgaas, Guenter Roeck, linux-alpha,
linux-arm-kernel, linux-m68k, linux-mips, linux-parisc,
linuxppc-dev, linux-s390, linux-sh, Russell King,
Geert Uytterhoeven, Thomas Bogendoerfer, James E.J. Bottomley,
Helge Deller, Michael Ellerman, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Chris Zankel,
Max Filippov, Madhavan Srinivasan, Yoshinori Sato, Rich Felker,
John Paul Adrian Glaubitz, linux-kernel, Xifer
In-Reply-To: <20260324165633.4583-1-ilpo.jarvinen@linux.intel.com>
[+cc Xifer; thanks very much for reporting and testing!]
On Tue, Mar 24, 2026 at 06:56:23PM +0200, Ilpo Järvinen wrote:
> Hi all,
>
> This series attempts to take advantage of free head space (the free
> space before the aligned start address) in order to generally produce a
> tighter packing of the resources/bridge windows.
>
> The recent changes to the resource fitting algorithm caused resource
> allocation failures in some cases where a bridge window that is sized
> to be gapless could no longer be assigned. The previous algorithm left
> a huge gaps which allowed it to place the remainder (non-aligning part
> of the size) before the start address of used for the gapless fit,
> whereas the new gapless approach always had to place the remainder
> after the aligning part of the resources. There is not always space
> for the remainder triggering those failures (e.g., when the aligning
> part must be placed at the top of the window).
>
> This series attempts to allow placing the remainder once again before
> the aligning part, but now without leaving huge gaps to retain the
> benefits of the gapless bridge windows. The approach is somewhat hacky
> but should work thanks to PCI resources fundamentally consisting only
> power-of-two atoms.
>
> There maybe cases where architecture would not want to do such
> relocation. This series adds the relocation to arch
> pcibios_align_resource() functions to allow all of them taking
> advantage of the better resource packing but if somebody objects doing
> this relocation for a particular arch, I can remove it, please just let
> me know (this relocation doesn't seem critical unless there are
> regressions).
>
> Ilpo Järvinen (10):
> resource: Add __resource_contains_unbound() for internal contains
> checks
> resource: Pass full extent of empty space to resource_alignf CB
> resource: Rename 'tmp' variable to 'full_avail'
> ARM/PCI: Remove unnecessary second application of align
> am68k/PCI: Remove unnecessary second application of align
> MIPS: PCI: Remove unnecessary second application of align
> parisc/PCI: Cleanup align handling
> PCI: Rename window_alignment() to pci_min_window_alignment()
> PCI: Align head space better
> PCI: Fix alignment calculation for resource size larger than align
>
> arch/alpha/kernel/pci.c | 1 +
> arch/arm/kernel/bios32.c | 9 ++++---
> arch/m68k/kernel/pcibios.c | 8 +++++--
> arch/mips/pci/pci-generic.c | 8 ++++---
> arch/mips/pci/pci-legacy.c | 3 +++
> arch/parisc/kernel/pci.c | 17 ++++++++------
> arch/powerpc/kernel/pci-common.c | 6 ++++-
> arch/s390/pci/pci.c | 1 +
> arch/sh/drivers/pci/pci.c | 6 ++++-
> arch/x86/pci/i386.c | 5 +++-
> arch/xtensa/kernel/pci.c | 3 +++
> drivers/pci/pci.h | 3 +++
> drivers/pci/setup-bus.c | 15 ++++++++----
> drivers/pci/setup-res.c | 40 +++++++++++++++++++++++++++++++-
> drivers/pcmcia/rsrc_nonstatic.c | 3 ++-
> include/linux/ioport.h | 22 +++++++++++++++---
> include/linux/pci.h | 12 +++++++---
> kernel/resource.c | 33 +++++++++++++-------------
> 18 files changed, 149 insertions(+), 46 deletions(-)
I added Xifer's tested-by, fixed the "am68k" and missing "if"
typos, and applied these to pci/resource for v7.1.
Ilpo, if you post a v2 with more changes, I'll update to it. I
applied the series now to get a head start on 0-day building and into
next.
^ permalink raw reply
* [PATCH net V2 2/2] net: xilinx: axienet: Fix BQL accounting for multi-BD TX packets
From: Suraj Gupta @ 2026-03-26 18:55 UTC (permalink / raw)
To: andrew+netdev, davem, edumazet, kuba, pabeni, michal.simek,
sean.anderson, radhey.shyam.pandey, horms
Cc: netdev, linux-arm-kernel, linux-kernel, harini.katakam
In-Reply-To: <20260326185510.3840084-1-suraj.gupta2@amd.com>
When a TX packet spans multiple buffer descriptors (scatter-gather),
the per-BD byte count is accumulated into a local variable that resets
on each NAPI poll. If the BDs for a single packet complete across
different polls, the earlier bytes are lost and never credited to BQL.
This causes BQL to think bytes are permanently in-flight, eventually
stalling the TX queue.
Fix this by replacing the local accumulator with a persistent counter
(tx_compl_bytes) that survives across polls and is reset only after
updating BQL and stats.
Fixes: c900e49d58eb ("net: xilinx: axienet: Implement BQL")
Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
---
drivers/net/ethernet/xilinx/xilinx_axienet.h | 3 +++
.../net/ethernet/xilinx/xilinx_axienet_main.c | 20 +++++++++----------
2 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet.h b/drivers/net/ethernet/xilinx/xilinx_axienet.h
index 602389843342..a4444c939451 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet.h
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet.h
@@ -509,6 +509,8 @@ struct skbuf_dma_descriptor {
* complete. Only updated at runtime by TX NAPI poll.
* @tx_bd_tail: Stores the index of the next Tx buffer descriptor in the ring
* to be populated.
+ * @tx_compl_bytes: Accumulates TX completion length until a full packet is
+ * reported to the stack.
* @tx_packets: TX packet count for statistics
* @tx_bytes: TX byte count for statistics
* @tx_stat_sync: Synchronization object for TX stats
@@ -592,6 +594,7 @@ struct axienet_local {
u32 tx_bd_num;
u32 tx_bd_ci;
u32 tx_bd_tail;
+ u32 tx_compl_bytes;
u64_stats_t tx_packets;
u64_stats_t tx_bytes;
struct u64_stats_sync tx_stat_sync;
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
index b06e4c37ff61..95bf61986cb7 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet_main.c
@@ -692,6 +692,8 @@ static void axienet_dma_stop(struct axienet_local *lp)
axienet_lock_mii(lp);
__axienet_device_reset(lp);
axienet_unlock_mii(lp);
+
+ lp->tx_compl_bytes = 0;
}
/**
@@ -770,8 +772,6 @@ static int axienet_device_reset(struct net_device *ndev)
* @first_bd: Index of first descriptor to clean up
* @nr_bds: Max number of descriptors to clean up
* @force: Whether to clean descriptors even if not complete
- * @sizep: Pointer to a u32 filled with the total sum of all bytes
- * in all cleaned-up descriptors. Ignored if NULL.
* @budget: NAPI budget (use 0 when not called from NAPI poll)
*
* Would either be called after a successful transmit operation, or after
@@ -780,7 +780,7 @@ static int axienet_device_reset(struct net_device *ndev)
* Return: The number of packets handled.
*/
static int axienet_free_tx_chain(struct axienet_local *lp, u32 first_bd,
- int nr_bds, bool force, u32 *sizep, int budget)
+ int nr_bds, bool force, int budget)
{
struct axidma_bd *cur_p;
unsigned int status;
@@ -819,8 +819,8 @@ static int axienet_free_tx_chain(struct axienet_local *lp, u32 first_bd,
cur_p->cntrl = 0;
cur_p->status = 0;
- if (sizep)
- *sizep += status & XAXIDMA_BD_STS_ACTUAL_LEN_MASK;
+ if (!force)
+ lp->tx_compl_bytes += status & XAXIDMA_BD_STS_ACTUAL_LEN_MASK;
}
if (!force) {
@@ -999,18 +999,18 @@ static int axienet_tx_poll(struct napi_struct *napi, int budget)
{
struct axienet_local *lp = container_of(napi, struct axienet_local, napi_tx);
struct net_device *ndev = lp->ndev;
- u32 size = 0;
int packets;
packets = axienet_free_tx_chain(lp, lp->tx_bd_ci, lp->tx_bd_num, false,
- &size, budget);
+ budget);
if (packets) {
- netdev_completed_queue(ndev, packets, size);
+ netdev_completed_queue(ndev, packets, lp->tx_compl_bytes);
u64_stats_update_begin(&lp->tx_stat_sync);
u64_stats_add(&lp->tx_packets, packets);
- u64_stats_add(&lp->tx_bytes, size);
+ u64_stats_add(&lp->tx_bytes, lp->tx_compl_bytes);
u64_stats_update_end(&lp->tx_stat_sync);
+ lp->tx_compl_bytes = 0;
/* Matches barrier in axienet_start_xmit */
smp_mb();
@@ -1115,7 +1115,7 @@ axienet_start_xmit(struct sk_buff *skb, struct net_device *ndev)
netdev_err(ndev, "TX DMA mapping error\n");
ndev->stats.tx_dropped++;
axienet_free_tx_chain(lp, orig_tail_ptr, ii + 1,
- true, NULL, 0);
+ true, 0);
dev_kfree_skb_any(skb);
return NETDEV_TX_OK;
}
--
2.49.1
^ permalink raw reply related
* [PATCH net V2 1/2] net: xilinx: axienet: Correct BD length masks to match AXIDMA IP spec
From: Suraj Gupta @ 2026-03-26 18:55 UTC (permalink / raw)
To: andrew+netdev, davem, edumazet, kuba, pabeni, michal.simek,
sean.anderson, radhey.shyam.pandey, horms
Cc: netdev, linux-arm-kernel, linux-kernel, harini.katakam
In-Reply-To: <20260326185510.3840084-1-suraj.gupta2@amd.com>
The XAXIDMA_BD_CTRL_LENGTH_MASK and XAXIDMA_BD_STS_ACTUAL_LEN_MASK
macros were defined as 0x007FFFFF (23 bits), but the AXI DMA IP
product guide (PG021) specifies the buffer length field as bits 25:0
(26 bits). Update both masks to match the IP documentation.
In practice this had no functional impact, since Ethernet frames are
far smaller than 2^23 bytes and the extra bits were always zero, but
the masks should still reflect the hardware specification.
Fixes: 8a3b7a252dca ("drivers/net/ethernet/xilinx: added Xilinx AXI Ethernet driver")
Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
---
drivers/net/ethernet/xilinx/xilinx_axienet.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/xilinx/xilinx_axienet.h b/drivers/net/ethernet/xilinx/xilinx_axienet.h
index 5ff742103beb..602389843342 100644
--- a/drivers/net/ethernet/xilinx/xilinx_axienet.h
+++ b/drivers/net/ethernet/xilinx/xilinx_axienet.h
@@ -105,7 +105,7 @@
#define XAXIDMA_BD_HAS_DRE_MASK 0xF00 /* Whether has DRE mask */
#define XAXIDMA_BD_WORDLEN_MASK 0xFF /* Whether has DRE mask */
-#define XAXIDMA_BD_CTRL_LENGTH_MASK 0x007FFFFF /* Requested len */
+#define XAXIDMA_BD_CTRL_LENGTH_MASK GENMASK(25, 0) /* Requested len */
#define XAXIDMA_BD_CTRL_TXSOF_MASK 0x08000000 /* First tx packet */
#define XAXIDMA_BD_CTRL_TXEOF_MASK 0x04000000 /* Last tx packet */
#define XAXIDMA_BD_CTRL_ALL_MASK 0x0C000000 /* All control bits */
@@ -130,7 +130,7 @@
#define XAXIDMA_BD_CTRL_TXEOF_MASK 0x04000000 /* Last tx packet */
#define XAXIDMA_BD_CTRL_ALL_MASK 0x0C000000 /* All control bits */
-#define XAXIDMA_BD_STS_ACTUAL_LEN_MASK 0x007FFFFF /* Actual len */
+#define XAXIDMA_BD_STS_ACTUAL_LEN_MASK GENMASK(25, 0) /* Actual len */
#define XAXIDMA_BD_STS_COMPLETE_MASK 0x80000000 /* Completed */
#define XAXIDMA_BD_STS_DEC_ERR_MASK 0x40000000 /* Decode error */
#define XAXIDMA_BD_STS_SLV_ERR_MASK 0x20000000 /* Slave error */
--
2.49.1
^ permalink raw reply related
* [PATCH net V2 0/2] Correct BD length masks and BQL accounting for multi-BD TX packets
From: Suraj Gupta @ 2026-03-26 18:55 UTC (permalink / raw)
To: andrew+netdev, davem, edumazet, kuba, pabeni, michal.simek,
sean.anderson, radhey.shyam.pandey, horms
Cc: netdev, linux-arm-kernel, linux-kernel, harini.katakam
This patch series fixes two issues in the Xilinx AXI Ethernet driver:
1. Corrects the BD length masks to match the AXIDMA IP spec.
2. Fixes BQL accounting for multi-BD TX packets.
---
Changes in V2:
Use GENMASK() to define the BD length masks.
---
Suraj Gupta (2):
net: xilinx: axienet: Correct BD length masks to match AXIDMA IP spec
net: xilinx: axienet: Fix BQL accounting for multi-BD TX packets
drivers/net/ethernet/xilinx/xilinx_axienet.h | 7 +++++--
.../net/ethernet/xilinx/xilinx_axienet_main.c | 20 +++++++++----------
2 files changed, 15 insertions(+), 12 deletions(-)
--
2.49.1
^ permalink raw reply
* Re: [PATCH v4 3/7] pinctrl: extract pinctrl_generic_to_map() from pinctrl_generic_pins_function_dt_node_to_map()
From: Conor Dooley @ 2026-03-26 18:55 UTC (permalink / raw)
To: Frank Li
Cc: Peter Rosin, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rafał Miłecki, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-kernel, linux-gpio,
devicetree, imx, linux-arm-kernel, Haibo Chen
In-Reply-To: <20260326-concur-eel-3e0b3d91e00a@spud>
[-- Attachment #1: Type: text/plain, Size: 4792 bytes --]
On Thu, Mar 26, 2026 at 06:52:12PM +0000, Conor Dooley wrote:
> On Wed, Mar 25, 2026 at 07:04:12PM -0400, Frank Li wrote:
>
> > diff --git a/drivers/pinctrl/pinctrl-generic.c b/drivers/pinctrl/pinctrl-generic.c
> > index efb39c6a670331775855efdc8566102b5c6202ef..20a216ae63e91b69985ea4cfcd0b57103c6ca950 100644
> > --- a/drivers/pinctrl/pinctrl-generic.c
> > +++ b/drivers/pinctrl/pinctrl-generic.c
> > @@ -17,29 +17,18 @@
> > #include "pinctrl-utils.h"
> > #include "pinmux.h"
> >
> > -static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *pctldev,
>
> > +int
> > +pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent,
>
> Can you drop this stylistic change please? The
Whoops, cut myself off. To be clear, what I am asking for is to keep the
"int" etc on the same line as the function name. This function is new,
but you did it for the existing function too and the comparison is here.
>
> > + struct device_node *np, struct pinctrl_map **maps,
> > + unsigned int *num_maps, unsigned int *num_reserved_maps,
> > + const char **group_names, unsigned int ngroups,
> > + const char **functions, unsigned int *pins)
> > {
> > struct device *dev = pctldev->dev;
> > - const char **functions;
> > + int npins, ret, reserve = 1;
> > + unsigned int num_configs;
> > const char *group_name;
> > unsigned long *configs;
> > - unsigned int num_configs, pin, *pins;
> > - int npins, ret, reserve = 1;
> > -
> > - npins = of_property_count_u32_elems(np, "pins");
> > -
> > - if (npins < 1) {
> > - dev_err(dev, "invalid pinctrl group %pOFn.%pOFn %d\n",
> > - parent, np, npins);
> > - return npins;
> > - }
> >
> > group_name = devm_kasprintf(dev, GFP_KERNEL, "%pOFn.%pOFn", parent, np);
> > if (!group_name)
> > @@ -51,22 +40,6 @@ static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *p
> > if (!pins)
> > return -ENOMEM;
>
> This looks suspect. You've left the pins allocation behind:
> pins = devm_kcalloc(dev, npins, sizeof(*pins), GFP_KERNEL);
> if (!pins)
> return -ENOMEM;
> but pinctrl_generic_pins_function_dt_subnode_to_map() has already
> populated this array before calling the function.
>
> Also, this should probably be
> Suggested-by: Conor Dooley <conor.dooley@microchip.com>
>
> Cheers,
> Conor.
>
> >
> > - functions = devm_kcalloc(dev, npins, sizeof(*functions), GFP_KERNEL);
> > - if (!functions)
> > - return -ENOMEM;
> > -
> > - for (int i = 0; i < npins; i++) {
> > - ret = of_property_read_u32_index(np, "pins", i, &pin);
> > - if (ret)
> > - return ret;
> > -
> > - pins[i] = pin;
> > -
> > - ret = of_property_read_string(np, "function", &functions[i]);
> > - if (ret)
> > - return ret;
> > - }
> > -
> > ret = pinctrl_utils_reserve_map(pctldev, maps, num_reserved_maps, num_maps, reserve);
> > if (ret)
> > return ret;
> > @@ -103,6 +76,54 @@ static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *p
> > return 0;
> > };
> >
> > +static int
> > +pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *pctldev,
> > + struct device_node *parent,
> > + struct device_node *np,
> > + struct pinctrl_map **maps,
> > + unsigned int *num_maps,
> > + unsigned int *num_reserved_maps,
> > + const char **group_names,
> > + unsigned int ngroups)
> > +{
> > + struct device *dev = pctldev->dev;
> > + unsigned int pin, *pins;
> > + const char **functions;
> > + int npins, ret;
> > +
> > + npins = of_property_count_u32_elems(np, "pins");
> > +
> > + if (npins < 1) {
> > + dev_err(dev, "invalid pinctrl group %pOFn.%pOFn %d\n",
> > + parent, np, npins);
> > + return npins;
> > + }
> > +
> > + pins = devm_kcalloc(dev, npins, sizeof(*pins), GFP_KERNEL);
> > + if (!pins)
> > + return -ENOMEM;
> > +
> > + functions = devm_kcalloc(dev, npins, sizeof(*functions), GFP_KERNEL);
> > + if (!functions)
> > + return -ENOMEM;
> > +
> > + for (int i = 0; i < npins; i++) {
> > + ret = of_property_read_u32_index(np, "pins", i, &pin);
> > + if (ret)
> > + return ret;
> > +
> > + pins[i] = pin;
> > +
> > + ret = of_property_read_string(np, "function", &functions[i]);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + return pinctrl_generic_to_map(pctldev, parent, np, maps, num_maps,
> > + num_reserved_maps, group_names, ngroups,
> > + functions, pins);
> > +}
> > +
> > /*
> > * For platforms that do not define groups or functions in the driver, but
> > * instead use the devicetree to describe them. This function will, unlike
> >
> > --
> > 2.43.0
> >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 3/7] pinctrl: extract pinctrl_generic_to_map() from pinctrl_generic_pins_function_dt_node_to_map()
From: Conor Dooley @ 2026-03-26 18:52 UTC (permalink / raw)
To: Frank Li
Cc: Peter Rosin, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rafał Miłecki, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-kernel, linux-gpio,
devicetree, imx, linux-arm-kernel, Haibo Chen
In-Reply-To: <20260325-pinctrl-mux-v4-3-043c2c82e623@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 4227 bytes --]
On Wed, Mar 25, 2026 at 07:04:12PM -0400, Frank Li wrote:
> diff --git a/drivers/pinctrl/pinctrl-generic.c b/drivers/pinctrl/pinctrl-generic.c
> index efb39c6a670331775855efdc8566102b5c6202ef..20a216ae63e91b69985ea4cfcd0b57103c6ca950 100644
> --- a/drivers/pinctrl/pinctrl-generic.c
> +++ b/drivers/pinctrl/pinctrl-generic.c
> @@ -17,29 +17,18 @@
> #include "pinctrl-utils.h"
> #include "pinmux.h"
>
> -static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *pctldev,
> +int
> +pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent,
Can you drop this stylistic change please? The
> + struct device_node *np, struct pinctrl_map **maps,
> + unsigned int *num_maps, unsigned int *num_reserved_maps,
> + const char **group_names, unsigned int ngroups,
> + const char **functions, unsigned int *pins)
> {
> struct device *dev = pctldev->dev;
> - const char **functions;
> + int npins, ret, reserve = 1;
> + unsigned int num_configs;
> const char *group_name;
> unsigned long *configs;
> - unsigned int num_configs, pin, *pins;
> - int npins, ret, reserve = 1;
> -
> - npins = of_property_count_u32_elems(np, "pins");
> -
> - if (npins < 1) {
> - dev_err(dev, "invalid pinctrl group %pOFn.%pOFn %d\n",
> - parent, np, npins);
> - return npins;
> - }
>
> group_name = devm_kasprintf(dev, GFP_KERNEL, "%pOFn.%pOFn", parent, np);
> if (!group_name)
> @@ -51,22 +40,6 @@ static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *p
> if (!pins)
> return -ENOMEM;
This looks suspect. You've left the pins allocation behind:
pins = devm_kcalloc(dev, npins, sizeof(*pins), GFP_KERNEL);
if (!pins)
return -ENOMEM;
but pinctrl_generic_pins_function_dt_subnode_to_map() has already
populated this array before calling the function.
Also, this should probably be
Suggested-by: Conor Dooley <conor.dooley@microchip.com>
Cheers,
Conor.
>
> - functions = devm_kcalloc(dev, npins, sizeof(*functions), GFP_KERNEL);
> - if (!functions)
> - return -ENOMEM;
> -
> - for (int i = 0; i < npins; i++) {
> - ret = of_property_read_u32_index(np, "pins", i, &pin);
> - if (ret)
> - return ret;
> -
> - pins[i] = pin;
> -
> - ret = of_property_read_string(np, "function", &functions[i]);
> - if (ret)
> - return ret;
> - }
> -
> ret = pinctrl_utils_reserve_map(pctldev, maps, num_reserved_maps, num_maps, reserve);
> if (ret)
> return ret;
> @@ -103,6 +76,54 @@ static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *p
> return 0;
> };
>
> +static int
> +pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *pctldev,
> + struct device_node *parent,
> + struct device_node *np,
> + struct pinctrl_map **maps,
> + unsigned int *num_maps,
> + unsigned int *num_reserved_maps,
> + const char **group_names,
> + unsigned int ngroups)
> +{
> + struct device *dev = pctldev->dev;
> + unsigned int pin, *pins;
> + const char **functions;
> + int npins, ret;
> +
> + npins = of_property_count_u32_elems(np, "pins");
> +
> + if (npins < 1) {
> + dev_err(dev, "invalid pinctrl group %pOFn.%pOFn %d\n",
> + parent, np, npins);
> + return npins;
> + }
> +
> + pins = devm_kcalloc(dev, npins, sizeof(*pins), GFP_KERNEL);
> + if (!pins)
> + return -ENOMEM;
> +
> + functions = devm_kcalloc(dev, npins, sizeof(*functions), GFP_KERNEL);
> + if (!functions)
> + return -ENOMEM;
> +
> + for (int i = 0; i < npins; i++) {
> + ret = of_property_read_u32_index(np, "pins", i, &pin);
> + if (ret)
> + return ret;
> +
> + pins[i] = pin;
> +
> + ret = of_property_read_string(np, "function", &functions[i]);
> + if (ret)
> + return ret;
> + }
> +
> + return pinctrl_generic_to_map(pctldev, parent, np, maps, num_maps,
> + num_reserved_maps, group_names, ngroups,
> + functions, pins);
> +}
> +
> /*
> * For platforms that do not define groups or functions in the driver, but
> * instead use the devicetree to describe them. This function will, unlike
>
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] regulator: dt-bindings: mt6315: Add regulator supplies
From: Conor Dooley @ 2026-03-26 18:35 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Mark Brown, Liam Girdwood, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
linux-kernel, linux-arm-kernel, linux-mediatek, devicetree
In-Reply-To: <20260326081050.1115201-2-wenst@chromium.org>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] arm64/entry: Fix involuntary preemption exception masking
From: Thomas Gleixner @ 2026-03-26 18:32 UTC (permalink / raw)
To: Mark Rutland
Cc: vladimir.murzin, peterz, catalin.marinas, ruanjinjie,
linux-kernel, luto, will, linux-arm-kernel
In-Reply-To: <acV2552t5X4OlNYi@J2N7QTR9R3>
Mark!
On Thu, Mar 26 2026 at 18:11, Mark Rutland wrote:
>
> I've pushed a (very early, WIP) draft to
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/entry/rework
>
> ... which is missing commit messages, comments, etc, but seems to work.
>
> I'll see about getting that tested, cleaned up, and on-list.
I've pulled it and looked at the v7.0-rc3.. diff.
That looks really good! Thanks for taking care of that.
As a related side note. Seeing that even more of the generic entry code
is moving to include/linux/, I'm pondering to move the content back into
kernel/entry and include those "local" headers from the
include/linux/... so that everything is to find in one place, but that's
a purely cosmetic problem :)
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH v9 1/5] PCI: Add pcie_get_link_speed() helper for safe array access
From: Manivannan Sadhasivam @ 2026-03-26 18:32 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Hans Zhang, lpieralisi, jingoohan1, kwilczynski, bhelgaas,
florian.fainelli, jim2101024, robh, ilpo.jarvinen, linux-arm-msm,
linux-arm-kernel, linux-renesas-soc, claudiu.beznea.uj,
linux-mediatek, linux-tegra, linux-omap, bcm-kernel-feedback-list,
linux-pci, linux-kernel, shawn.lin
In-Reply-To: <20260326181624.GA1331242@bhelgaas>
On Thu, Mar 26, 2026 at 01:16:24PM -0500, Bjorn Helgaas wrote:
> On Sat, Mar 14, 2026 at 12:55:18AM +0800, Hans Zhang wrote:
> > The pcie_link_speed[] array is indexed by PCIe generation numbers
> > (1 = 2.5 GT/s, 2 = 5 GT/s, ...). Several drivers use it directly,
> > which can lead to out-of-bounds accesses if an invalid generation
> > number is used.
> >
> > Introduce a helper function pcie_get_link_speed() that returns the
> > corresponding enum pci_bus_speed value for a given generation number,
> > or PCI_SPEED_UNKNOWN if the generation is out of range. This will
> > allow us to safely handle invalid values after the range check is
> > removed from of_pci_get_max_link_speed().
> >
> > Signed-off-by: Hans Zhang <18255117159@163.com>
> > ---
> > drivers/pci/pci.h | 2 ++
> > drivers/pci/probe.c | 16 ++++++++++++++++
> > 2 files changed, 18 insertions(+)
> >
> > diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> > index 13d998fbacce..409aca7d737a 100644
> > --- a/drivers/pci/pci.h
> > +++ b/drivers/pci/pci.h
> > @@ -108,6 +108,8 @@ struct pcie_tlp_log;
> > PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE)
> >
> > extern const unsigned char pcie_link_speed[];
> > +unsigned char pcie_get_link_speed(unsigned int speed);
> > +
> > extern bool pci_early_dump;
> >
> > extern struct mutex pci_rescan_remove_lock;
> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > index bccc7a4bdd79..d6592898330c 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -783,6 +783,22 @@ const unsigned char pcie_link_speed[] = {
> > };
> > EXPORT_SYMBOL_GPL(pcie_link_speed);
> >
> > +/**
> > + * pcie_link_speed_value - Get speed value from PCIe generation number
>
> Wrong name here (pcie_link_speed_value vs pcie_get_link_speed)
> (pointed out by Sashiko).
>
Noticed this one while applying.
> > + * @speed: PCIe speed (1-based: 1 = 2.5GT, 2 = 5GT, ...)
> > + *
> > + * Returns the speed value (e.g., PCIE_SPEED_2_5GT) if @speed is valid,
> > + * otherwise returns PCI_SPEED_UNKNOWN.
> > + */
> > +unsigned char pcie_get_link_speed(unsigned int speed)
>
> Sashiko also pointed out that the commit log says this returns "enum
> pci_bus_speed", while here we return unsigned char (which is also the
> type of pcie_link_speed[x]).
>
> https://sashiko.dev/#/patchset/20260313165522.123518-1-18255117159%40163.com
>
This one I didn't, but fixed now, thanks!
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v9 0/5] PCI: of: Remove max-link-speed generation validation
From: Manivannan Sadhasivam @ 2026-03-26 18:29 UTC (permalink / raw)
To: lpieralisi, jingoohan1, kwilczynski, bhelgaas, helgaas,
florian.fainelli, jim2101024, Hans Zhang
Cc: robh, ilpo.jarvinen, linux-arm-msm, linux-arm-kernel,
linux-renesas-soc, claudiu.beznea.uj, linux-mediatek, linux-tegra,
linux-omap, bcm-kernel-feedback-list, linux-pci, linux-kernel,
shawn.lin
In-Reply-To: <20260313165522.123518-1-18255117159@163.com>
On Sat, 14 Mar 2026 00:55:17 +0800, Hans Zhang wrote:
> This series moves the validation from the common OF function to the
> individual PCIe controller drivers. To protect against out-of-bounds
> accesses to the pcie_link_speed[] array, we first introduce a helper
> function pcie_get_link_speed() that safely returns the speed value
> (or PCI_SPEED_UNKNOWN) for a given generation number.
>
> Then all direct uses of pcie_link_speed[] as an array are converted to
> use the new helper, ensuring that even if an invalid generation number
> reaches those code paths, no out-of-bounds access occurs.
>
> [...]
Applied, thanks!
[1/5] PCI: Add pcie_get_link_speed() helper for safe array access
commit: df61f4732adf9de5ad1f5e71b7670710c1597d18
[2/5] PCI: dwc: Use pcie_get_link_speed() helper for safe array access
commit: d884b0e51459175f17ddc52759ea4533bb752130
[3/5] PCI: j721e: Validate max-link-speed from DT
commit: 1542ac6d83d0b5706f45e2937de7b4f7b8c4831d
[4/5] PCI: controller: Validate max-link-speed
commit: d0cc5918a1d539344190cbb19fa3ae0e7b0dca1e
[5/5] PCI: of: Remove max-link-speed generation validation
commit: 15217c7015c0e1804925693c55d721aad8987e32
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 3/3] KVM: arm64: Don't pass host_debug_state to BRBE world-switch routines
From: Will Deacon @ 2026-03-26 18:21 UTC (permalink / raw)
To: kvmarm
Cc: mark.rutland, linux-arm-kernel, Marc Zyngier, Oliver Upton,
James Clark, Leo Yan, Suzuki K Poulose, Fuad Tabba,
Alexandru Elisei, Yabin Cui
In-Reply-To: <20260326141214.18990-4-will@kernel.org>
On Thu, Mar 26, 2026 at 02:12:13PM +0000, Will Deacon wrote:
> Now that the SPE and BRBE nVHE world-switch routines operate on the
> host_debug_state directly, tweak the BRBE code to do the same for
> consistency.
>
> This is purely cosmetic.
>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Oliver Upton <oupton@kernel.org>
> Cc: James Clark <james.clark@linaro.org>
> Cc: Leo Yan <leo.yan@arm.com>
> Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
> Cc: Fuad Tabba <tabba@google.com>
> Cc: Alexandru Elisei <alexandru.elisei@arm.com>
> Tested-by: Fuad Tabba <tabba@google.com>
> Reviewed-by: Fuad Tabba <tabba@google.com>
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
> arch/arm64/kvm/hyp/nvhe/debug-sr.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/debug-sr.c b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> index 84bc80f4e36b..50413171bd1a 100644
> --- a/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> +++ b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
> @@ -156,9 +156,9 @@ static void __trace_switch_to_host(void)
> *host_data_ptr(host_debug_state.trfcr_el1));
> }
>
> -static void __debug_save_brbe(u64 *brbcr_el1)
> +static void __debug_save_brbe(void)
> {
> - *brbcr_el1 = 0;
> + u64 *brbcr_el1 = host_data_ptr(host_debug_state.brbcr_el1);
Oh no, I've been sashiko'd!
The above is definitely not "purely cosmetic" and I should retain the
'*brbcr_el1 = 0; ' line.
Will
^ permalink raw reply
* Re: [PATCH v9 1/5] PCI: Add pcie_get_link_speed() helper for safe array access
From: Bjorn Helgaas @ 2026-03-26 18:16 UTC (permalink / raw)
To: Hans Zhang
Cc: lpieralisi, jingoohan1, mani, kwilczynski, bhelgaas,
florian.fainelli, jim2101024, robh, ilpo.jarvinen, linux-arm-msm,
linux-arm-kernel, linux-renesas-soc, claudiu.beznea.uj,
linux-mediatek, linux-tegra, linux-omap, bcm-kernel-feedback-list,
linux-pci, linux-kernel, shawn.lin
In-Reply-To: <20260313165522.123518-2-18255117159@163.com>
On Sat, Mar 14, 2026 at 12:55:18AM +0800, Hans Zhang wrote:
> The pcie_link_speed[] array is indexed by PCIe generation numbers
> (1 = 2.5 GT/s, 2 = 5 GT/s, ...). Several drivers use it directly,
> which can lead to out-of-bounds accesses if an invalid generation
> number is used.
>
> Introduce a helper function pcie_get_link_speed() that returns the
> corresponding enum pci_bus_speed value for a given generation number,
> or PCI_SPEED_UNKNOWN if the generation is out of range. This will
> allow us to safely handle invalid values after the range check is
> removed from of_pci_get_max_link_speed().
>
> Signed-off-by: Hans Zhang <18255117159@163.com>
> ---
> drivers/pci/pci.h | 2 ++
> drivers/pci/probe.c | 16 ++++++++++++++++
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index 13d998fbacce..409aca7d737a 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -108,6 +108,8 @@ struct pcie_tlp_log;
> PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE)
>
> extern const unsigned char pcie_link_speed[];
> +unsigned char pcie_get_link_speed(unsigned int speed);
> +
> extern bool pci_early_dump;
>
> extern struct mutex pci_rescan_remove_lock;
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index bccc7a4bdd79..d6592898330c 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -783,6 +783,22 @@ const unsigned char pcie_link_speed[] = {
> };
> EXPORT_SYMBOL_GPL(pcie_link_speed);
>
> +/**
> + * pcie_link_speed_value - Get speed value from PCIe generation number
Wrong name here (pcie_link_speed_value vs pcie_get_link_speed)
(pointed out by Sashiko).
> + * @speed: PCIe speed (1-based: 1 = 2.5GT, 2 = 5GT, ...)
> + *
> + * Returns the speed value (e.g., PCIE_SPEED_2_5GT) if @speed is valid,
> + * otherwise returns PCI_SPEED_UNKNOWN.
> + */
> +unsigned char pcie_get_link_speed(unsigned int speed)
Sashiko also pointed out that the commit log says this returns "enum
pci_bus_speed", while here we return unsigned char (which is also the
type of pcie_link_speed[x]).
https://sashiko.dev/#/patchset/20260313165522.123518-1-18255117159%40163.com
> +{
> + if (speed >= ARRAY_SIZE(pcie_link_speed))
> + return PCI_SPEED_UNKNOWN;
> +
> + return pcie_link_speed[speed];
> +}
> +EXPORT_SYMBOL_GPL(pcie_get_link_speed);
> +
> const char *pci_speed_string(enum pci_bus_speed speed)
> {
> /* Indexed by the pci_bus_speed enum */
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: stmmac: remove axi_kbbe, axi_mb and axi_rb members
From: Russell King (Oracle) @ 2026-03-26 18:15 UTC (permalink / raw)
To: Simon Horman
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, Conor Dooley,
David S. Miller, devicetree, Eric Dumazet, Giuseppe Cavallaro,
Jakub Kicinski, Jose Abreu, Krzysztof Kozlowski, linux-arm-kernel,
linux-stm32, netdev, Paolo Abeni, Rob Herring, Yao Zi
In-Reply-To: <acVxNBLE8Ck2qfjc@shell.armlinux.org.uk>
On Thu, Mar 26, 2026 at 05:47:32PM +0000, Russell King (Oracle) wrote:
> On Thu, Mar 26, 2026 at 05:29:43PM +0000, Simon Horman wrote:
> > On Tue, Mar 24, 2026 at 10:05:40AM +0000, Russell King (Oracle) wrote:
> > > axi_kbbe, axi_mb and axi_rb are all written, but nothing ever reads
> > > their values. Remove the code that sets these and the struct members.
> > >
> > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> >
> > Hi Russell,
> >
> > FYI, AI review suggests that these fields should also be removed from
> > Documentation/networking/device_drivers/ethernet/stmicro/stmmac.rst
>
> I noticed. I've prepared an update if netdev folk want that to happen
> as I've noticed that that documentation is fairly out of date now.
There's another reason I haven't submitted an update, and that's
because netdev is fairly backlogged at the moment - currently there's
381 patches in patchwork - four pages of patchwork, with the oldest
"new" patch dated 21st March. I don't think netdev patchwork needs
more patches at the moment!
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v1 1/3] dt-bindings: arm: fsl: add Variscite DART-MX93 Boards
From: Conor Dooley @ 2026-03-26 18:12 UTC (permalink / raw)
To: Stefano Radaelli
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Shawn Guo, Dario Binacchi, Alexander Stein, Maud Spierings,
Josua Mayer, Markus Niebel, Francesco Dolcini, Primoz Fiser
In-Reply-To: <b7b243c9c3931e8d7ddd984b654e7ef493e84690.1774539301.git.stefano.r@variscite.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 03/15] net: stmmac: qcom-ethqos: eliminate configure_func
From: Russell King (Oracle) @ 2026-03-26 18:12 UTC (permalink / raw)
To: Simon Horman
Cc: Andrew Lunn, Alexandre Torgue, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-arm-msm,
linux-stm32, Mohd Ayaan Anwar, netdev, Paolo Abeni
In-Reply-To: <20260326180453.GU111839@horms.kernel.org>
On Thu, Mar 26, 2026 at 06:04:53PM +0000, Simon Horman wrote:
> On Tue, Mar 24, 2026 at 01:11:44PM +0000, Russell King (Oracle) wrote:
> > Since ethqos_fix_mac_speed() is called via a function pointer, and only
> > indirects via the configure_func function pointer, eliminate this
> > unnecessary indirection.
> >
> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
>
> ...
>
> > @@ -623,14 +627,6 @@ static void ethqos_configure_sgmii(struct qcom_ethqos *ethqos,
> > ethqos_pcs_set_inband(ethqos, interface == PHY_INTERFACE_MODE_SGMII);
> > }
> >
> > -static void ethqos_fix_mac_speed(void *priv, phy_interface_t interface,
> > - int speed, unsigned int mode)
> > -{
> > - struct qcom_ethqos *ethqos = priv;
> > -
> > - ethqos->configure_func(ethqos, interface, speed);
> > -}
> > -
> > static int qcom_ethqos_serdes_powerup(struct net_device *ndev, void *priv)
> > {
> > struct qcom_ethqos *ethqos = priv;
>
> Hi Russell,
>
> FYI, AI generated review reports that the comment in ethqos_clks_config()
> that references ethqos_fix_mac_speed() should also be updated.
Also already noted (yesterday).
I do keep an eye on patchwork for my own patches - I have a firefox tab
permanently open for my patches in patchwork:
https://patchwork.kernel.org/project/netdevbpf/list/?submitter=165511
Thanks anyway.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH 1/2] arm64/entry: Fix involuntary preemption exception masking
From: Mark Rutland @ 2026-03-26 18:11 UTC (permalink / raw)
To: Thomas Gleixner
Cc: vladimir.murzin, peterz, catalin.marinas, ruanjinjie,
linux-kernel, luto, will, linux-arm-kernel
In-Reply-To: <87ecl7gbeu.ffs@tglx>
On Wed, Mar 25, 2026 at 04:46:01PM +0100, Thomas Gleixner wrote:
> On Wed, Mar 25 2026 at 11:03, Mark Rutland wrote:
> > On Sun, Mar 22, 2026 at 12:25:06AM +0100, Thomas Gleixner wrote:
> > I *think* what would work for us is we could split some of the exit
> > handling (including involuntary preemption) into a "prepare" step, as we
> > have for return to userspace. That way, arm64 could handle exiting
> > something like:
> >
> > local_irq_disable();
> > irqentry_exit_prepare(); // new, all generic logic
> > local_daif_mask();
> > arm64_exit_to_kernel_mode() {
> > ...
> > irqentry_exit(); // ideally irqentry_exit_to_kernel_mode().
> > ...
> > }
> >
> > ... and other architectures can use a combined exit_to_kernel_mode() (or
> > whatever we call that), which does both, e.g.
> >
> > // either noinstr, __always_inline, or a macro
> > void irqentry_prepare_and_exit(void)
>
> That's a bad idea as that would require to do a full kernel rename of
> all existing irqentry_exit() users.
>
> > {
> > irqentry_exit_prepare();
> > irqentry_exit();
> > }
>
> Aside of the naming that should work.
Thanks for confirming!
I've pushed a (very early, WIP) draft to
https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/log/?h=arm64/entry/rework
... which is missing commit messages, comments, etc, but seems to work.
I'll see about getting that tested, cleaned up, and on-list.
Mark.
^ permalink raw reply
* Re: [PATCH net-next v4 1/2] net: stmmac: provide flag to disable EEE
From: Russell King (Oracle) @ 2026-03-26 18:10 UTC (permalink / raw)
To: Kieran Bingham
Cc: Laurent Pinchart, imx, netdev, Andrew Lunn, David S. Miller,
Eric Dumazet, Fabio Estevam, Francesco Dolcini, Frank Li,
Jakub Kicinski, Joy Zou, Marco Felsch, Paolo Abeni,
Pengutronix Kernel Team, Stefan Klug, linux-arm-kernel
In-Reply-To: <177454628933.1078312.13488207016388509694@ping.linuxembedded.co.uk>
On Thu, Mar 26, 2026 at 05:31:29PM +0000, Kieran Bingham wrote:
> This one has been a roller coaster, but I'm glad we got to the bottom of
> it.
>
> I hope someone from synopsis takes note and and documents this for
> future silicon integrations.
I would say that it _is_ clearly documented in the databook. v3.74a
4.3.4. LPI Interrupt already states that this signal is generated in
the receive clock domain, and is not cleared immediately after the LPI
control and status register is read.
It goes on to state that this is because the signal to clear it has to
cross from the CSR clock domain to the receive clock domain to clear
the signal - and states that it is at least _four_ receive clock
cycles.
So, if the dwmac core is operating at 10Mbps, that means its receive
clock is running at 2.5MHz which has a period of 400ns. In this case,
the four receive clock cycles to clear this interrupt is 1.6us,
assuming that the receive clock is running.
However, if EEE is enabled, the receive clock comes from the PHY,
which may gate off when the link re-enters LPI - and this event is
under the control of the remote end, not the local end. So, what this
means is that even though it states four receive clocks to clear the
lpi_intr_o signal, that doesn't necessarily mean it will clear in
1.6us as the receive clock may be stopped.
So, I think it is clearly stated in the databook already, but as it's
just two paragraphs buried in around 1500 pages, that may explain why
it has been missed on iMX.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v9 1/5] PCI: Add pcie_get_link_speed() helper for safe array access
From: Bjorn Helgaas @ 2026-03-26 18:09 UTC (permalink / raw)
To: Hans Zhang
Cc: lpieralisi, jingoohan1, mani, kwilczynski, bhelgaas,
florian.fainelli, jim2101024, robh, ilpo.jarvinen, linux-arm-msm,
linux-arm-kernel, linux-renesas-soc, claudiu.beznea.uj,
linux-mediatek, linux-tegra, linux-omap, bcm-kernel-feedback-list,
linux-pci, linux-kernel, shawn.lin
In-Reply-To: <20260313165522.123518-2-18255117159@163.com>
On Sat, Mar 14, 2026 at 12:55:18AM +0800, Hans Zhang wrote:
> The pcie_link_speed[] array is indexed by PCIe generation numbers
> (1 = 2.5 GT/s, 2 = 5 GT/s, ...). Several drivers use it directly,
> which can lead to out-of-bounds accesses if an invalid generation
> number is used.
>
> Introduce a helper function pcie_get_link_speed() that returns the
> corresponding enum pci_bus_speed value for a given generation number,
> or PCI_SPEED_UNKNOWN if the generation is out of range. This will
> allow us to safely handle invalid values after the range check is
> removed from of_pci_get_max_link_speed().
>
> Signed-off-by: Hans Zhang <18255117159@163.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
> ---
> drivers/pci/pci.h | 2 ++
> drivers/pci/probe.c | 16 ++++++++++++++++
> 2 files changed, 18 insertions(+)
>
> diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
> index 13d998fbacce..409aca7d737a 100644
> --- a/drivers/pci/pci.h
> +++ b/drivers/pci/pci.h
> @@ -108,6 +108,8 @@ struct pcie_tlp_log;
> PCI_EXP_DEVCTL_FERE | PCI_EXP_DEVCTL_URRE)
>
> extern const unsigned char pcie_link_speed[];
> +unsigned char pcie_get_link_speed(unsigned int speed);
> +
> extern bool pci_early_dump;
>
> extern struct mutex pci_rescan_remove_lock;
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index bccc7a4bdd79..d6592898330c 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -783,6 +783,22 @@ const unsigned char pcie_link_speed[] = {
> };
> EXPORT_SYMBOL_GPL(pcie_link_speed);
>
> +/**
> + * pcie_link_speed_value - Get speed value from PCIe generation number
> + * @speed: PCIe speed (1-based: 1 = 2.5GT, 2 = 5GT, ...)
> + *
> + * Returns the speed value (e.g., PCIE_SPEED_2_5GT) if @speed is valid,
> + * otherwise returns PCI_SPEED_UNKNOWN.
> + */
> +unsigned char pcie_get_link_speed(unsigned int speed)
> +{
> + if (speed >= ARRAY_SIZE(pcie_link_speed))
> + return PCI_SPEED_UNKNOWN;
> +
> + return pcie_link_speed[speed];
> +}
> +EXPORT_SYMBOL_GPL(pcie_get_link_speed);
> +
> const char *pci_speed_string(enum pci_bus_speed speed)
> {
> /* Indexed by the pci_bus_speed enum */
> --
> 2.34.1
>
^ 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