* RE: [Intel-wired-lan] [PATCH 28/61] net/sched: Prefer IS_ERR_OR_NULL over manual NULL check
From: Loktionov, Aleksandr @ 2026-03-11 9:22 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx@lists.freedesktop.org,
apparmor@lists.ubuntu.com, bpf@vger.kernel.org,
ceph-devel@vger.kernel.org, cocci@inria.fr,
dm-devel@lists.linux.dev, dri-devel@lists.freedesktop.org,
gfs2@lists.linux.dev, intel-gfx@lists.freedesktop.org,
intel-wired-lan@lists.osuosl.org, iommu@lists.linux.dev,
kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-block@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-clk@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, linux-media@vger.kernel.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-nfs@vger.kernel.org, linux-omap@vger.kernel.org,
linux-phy@lists.infradead.org, linux-pm@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org,
linux-security-module@vger.kernel.org, linux-sh@vger.kernel.org,
linux-sound@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-trace-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
ntfs3@lists.linux.dev, samba-technical@lists.samba.org,
sched-ext@lists.linux.dev, target-devel@vger.kernel.org,
tipc-discussion@lists.sourceforge.net, v9fs@lists.linux.dev
Cc: Hadi Salim, Jamal, Jiri Pirko, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman
In-Reply-To: <20260310-b4-is_err_or_null-v1-28-bd63b656022d@avm.de>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Philipp Hahn
> Sent: Tuesday, March 10, 2026 12:49 PM
> To: amd-gfx@lists.freedesktop.org; apparmor@lists.ubuntu.com;
> bpf@vger.kernel.org; ceph-devel@vger.kernel.org; cocci@inria.fr; dm-
> devel@lists.linux.dev; dri-devel@lists.freedesktop.org;
> gfs2@lists.linux.dev; intel-gfx@lists.freedesktop.org; intel-wired-
> lan@lists.osuosl.org; iommu@lists.linux.dev; kvm@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-block@vger.kernel.org;
> linux-bluetooth@vger.kernel.org; linux-btrfs@vger.kernel.org; linux-
> cifs@vger.kernel.org; linux-clk@vger.kernel.org; linux-
> erofs@lists.ozlabs.org; linux-ext4@vger.kernel.org; linux-
> fsdevel@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> hyperv@vger.kernel.org; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-leds@vger.kernel.org; linux-
> media@vger.kernel.org; linux-mips@vger.kernel.org; linux-mm@kvack.org;
> linux-modules@vger.kernel.org; linux-mtd@lists.infradead.org; linux-
> nfs@vger.kernel.org; linux-omap@vger.kernel.org; linux-
> phy@lists.infradead.org; linux-pm@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-s390@vger.kernel.org; linux-
> scsi@vger.kernel.org; linux-sctp@vger.kernel.org; linux-security-
> module@vger.kernel.org; linux-sh@vger.kernel.org; linux-
> sound@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com;
> linux-trace-kernel@vger.kernel.org; linux-usb@vger.kernel.org; linux-
> wireless@vger.kernel.org; netdev@vger.kernel.org;
> ntfs3@lists.linux.dev; samba-technical@lists.samba.org; sched-
> ext@lists.linux.dev; target-devel@vger.kernel.org; tipc-
> discussion@lists.sourceforge.net; v9fs@lists.linux.dev; Philipp Hahn
> <phahn-oss@avm.de>
> Cc: Hadi Salim, Jamal <jhs@mojatatu.com>; Jiri Pirko
> <jiri@resnulli.us>; David S. Miller <davem@davemloft.net>; Eric
> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo
> Abeni <pabeni@redhat.com>; Simon Horman <horms@kernel.org>
> Subject: [Intel-wired-lan] [PATCH 28/61] net/sched: Prefer
> IS_ERR_OR_NULL over manual NULL check
>
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Jamal Hadi Salim <jhs@mojatatu.com>
> To: Jiri Pirko <jiri@resnulli.us>
> To: "David S. Miller" <davem@davemloft.net>
> To: Eric Dumazet <edumazet@google.com>
> To: Jakub Kicinski <kuba@kernel.org>
> To: Paolo Abeni <pabeni@redhat.com>
> To: Simon Horman <horms@kernel.org>
> Cc: netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> net/sched/cls_api.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c index
> 4829c27446e3369ad2ae9b3fcb285eca47d59933..4208225e7a4acaf0c331096ebf94
> 1f68cc2ed992 100644
> --- a/net/sched/cls_api.c
> +++ b/net/sched/cls_api.c
> @@ -2444,7 +2444,7 @@ static int tc_new_tfilter(struct sk_buff *skb,
> struct nlmsghdr *n,
> tcf_chain_tp_delete_empty(chain, tp, rtnl_held, NULL);
> errout_tp:
> if (chain) {
> - if (tp && !IS_ERR(tp))
> + if (!IS_ERR_OR_NULL(tp))
> tcf_proto_put(tp, rtnl_held, NULL);
> if (!tp_created)
> tcf_chain_put(chain);
> @@ -2612,7 +2612,7 @@ static int tc_del_tfilter(struct sk_buff *skb,
> struct nlmsghdr *n,
>
> errout:
> if (chain) {
> - if (tp && !IS_ERR(tp))
> + if (!IS_ERR_OR_NULL(tp))
> tcf_proto_put(tp, rtnl_held, NULL);
> tcf_chain_put(chain);
> }
> @@ -2741,7 +2741,7 @@ static int tc_get_tfilter(struct sk_buff *skb,
> struct nlmsghdr *n,
> tfilter_put(tp, fh);
> errout:
> if (chain) {
> - if (tp && !IS_ERR(tp))
> + if (!IS_ERR_OR_NULL(tp))
> tcf_proto_put(tp, rtnl_held, NULL);
> tcf_chain_put(chain);
> }
>
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH 30/61] net/sunrpc: Prefer IS_ERR_OR_NULL over manual NULL check
From: Loktionov, Aleksandr @ 2026-03-11 9:22 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx@lists.freedesktop.org,
apparmor@lists.ubuntu.com, bpf@vger.kernel.org,
ceph-devel@vger.kernel.org, cocci@inria.fr,
dm-devel@lists.linux.dev, dri-devel@lists.freedesktop.org,
gfs2@lists.linux.dev, intel-gfx@lists.freedesktop.org,
intel-wired-lan@lists.osuosl.org, iommu@lists.linux.dev,
kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-block@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-clk@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, linux-media@vger.kernel.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-nfs@vger.kernel.org, linux-omap@vger.kernel.org,
linux-phy@lists.infradead.org, linux-pm@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org,
linux-security-module@vger.kernel.org, linux-sh@vger.kernel.org,
linux-sound@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-trace-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
ntfs3@lists.linux.dev, samba-technical@lists.samba.org,
sched-ext@lists.linux.dev, target-devel@vger.kernel.org,
tipc-discussion@lists.sourceforge.net, v9fs@lists.linux.dev
Cc: Trond Myklebust, Anna Schumaker, Chuck Lever, Jeff Layton,
NeilBrown, Olga Kornievskaia, Dai Ngo, Tom Talpey,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
In-Reply-To: <20260310-b4-is_err_or_null-v1-30-bd63b656022d@avm.de>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Philipp Hahn
> Sent: Tuesday, March 10, 2026 12:49 PM
> To: amd-gfx@lists.freedesktop.org; apparmor@lists.ubuntu.com;
> bpf@vger.kernel.org; ceph-devel@vger.kernel.org; cocci@inria.fr; dm-
> devel@lists.linux.dev; dri-devel@lists.freedesktop.org;
> gfs2@lists.linux.dev; intel-gfx@lists.freedesktop.org; intel-wired-
> lan@lists.osuosl.org; iommu@lists.linux.dev; kvm@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-block@vger.kernel.org;
> linux-bluetooth@vger.kernel.org; linux-btrfs@vger.kernel.org; linux-
> cifs@vger.kernel.org; linux-clk@vger.kernel.org; linux-
> erofs@lists.ozlabs.org; linux-ext4@vger.kernel.org; linux-
> fsdevel@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> hyperv@vger.kernel.org; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-leds@vger.kernel.org; linux-
> media@vger.kernel.org; linux-mips@vger.kernel.org; linux-mm@kvack.org;
> linux-modules@vger.kernel.org; linux-mtd@lists.infradead.org; linux-
> nfs@vger.kernel.org; linux-omap@vger.kernel.org; linux-
> phy@lists.infradead.org; linux-pm@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-s390@vger.kernel.org; linux-
> scsi@vger.kernel.org; linux-sctp@vger.kernel.org; linux-security-
> module@vger.kernel.org; linux-sh@vger.kernel.org; linux-
> sound@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com;
> linux-trace-kernel@vger.kernel.org; linux-usb@vger.kernel.org; linux-
> wireless@vger.kernel.org; netdev@vger.kernel.org;
> ntfs3@lists.linux.dev; samba-technical@lists.samba.org; sched-
> ext@lists.linux.dev; target-devel@vger.kernel.org; tipc-
> discussion@lists.sourceforge.net; v9fs@lists.linux.dev; Philipp Hahn
> <phahn-oss@avm.de>
> Cc: Trond Myklebust <trondmy@kernel.org>; Anna Schumaker
> <anna@kernel.org>; Chuck Lever <chuck.lever@oracle.com>; Jeff Layton
> <jlayton@kernel.org>; NeilBrown <neil@brown.name>; Olga Kornievskaia
> <okorniev@redhat.com>; Dai Ngo <Dai.Ngo@oracle.com>; Tom Talpey
> <tom@talpey.com>; David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Simon Horman <horms@kernel.org>
> Subject: [Intel-wired-lan] [PATCH 30/61] net/sunrpc: Prefer
> IS_ERR_OR_NULL over manual NULL check
>
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Trond Myklebust <trondmy@kernel.org>
> To: Anna Schumaker <anna@kernel.org>
> To: Chuck Lever <chuck.lever@oracle.com>
> To: Jeff Layton <jlayton@kernel.org>
> To: NeilBrown <neil@brown.name>
> To: Olga Kornievskaia <okorniev@redhat.com>
> To: Dai Ngo <Dai.Ngo@oracle.com>
> To: Tom Talpey <tom@talpey.com>
> To: "David S. Miller" <davem@davemloft.net>
> To: Eric Dumazet <edumazet@google.com>
> To: Jakub Kicinski <kuba@kernel.org>
> To: Paolo Abeni <pabeni@redhat.com>
> To: Simon Horman <horms@kernel.org>
> Cc: linux-nfs@vger.kernel.org
> Cc: netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> net/sunrpc/xprtrdma/svc_rdma_transport.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/net/sunrpc/xprtrdma/svc_rdma_transport.c
> b/net/sunrpc/xprtrdma/svc_rdma_transport.c
> index
> 9b623849723ed0eb74b827881c6f32d3434c891b..b4d03e59a8202f20360cff1e2e79
> b1e325396517 100644
> --- a/net/sunrpc/xprtrdma/svc_rdma_transport.c
> +++ b/net/sunrpc/xprtrdma/svc_rdma_transport.c
> @@ -578,7 +578,7 @@ static struct svc_xprt *svc_rdma_accept(struct
> svc_xprt *xprt)
> errout:
> /* Take a reference in case the DTO handler runs */
> svc_xprt_get(&newxprt->sc_xprt);
> - if (newxprt->sc_qp && !IS_ERR(newxprt->sc_qp))
> + if (!IS_ERR_OR_NULL(newxprt->sc_qp))
> ib_destroy_qp(newxprt->sc_qp);
> rdma_destroy_id(newxprt->sc_cm_id);
> rpcrdma_rn_unregister(dev, &newxprt->sc_rn); @@ -608,7 +608,7
> @@ static void svc_rdma_free(struct svc_xprt *xprt)
> might_sleep();
>
> /* This blocks until the Completion Queues are empty */
> - if (rdma->sc_qp && !IS_ERR(rdma->sc_qp))
> + if (!IS_ERR_OR_NULL(rdma->sc_qp))
> ib_drain_qp(rdma->sc_qp);
> flush_workqueue(svcrdma_wq);
>
> @@ -619,16 +619,16 @@ static void svc_rdma_free(struct svc_xprt *xprt)
> svc_rdma_recv_ctxts_destroy(rdma);
>
> /* Destroy the QP if present (not a listener) */
> - if (rdma->sc_qp && !IS_ERR(rdma->sc_qp))
> + if (!IS_ERR_OR_NULL(rdma->sc_qp))
> ib_destroy_qp(rdma->sc_qp);
>
> - if (rdma->sc_sq_cq && !IS_ERR(rdma->sc_sq_cq))
> + if (!IS_ERR_OR_NULL(rdma->sc_sq_cq))
> ib_free_cq(rdma->sc_sq_cq);
>
> - if (rdma->sc_rq_cq && !IS_ERR(rdma->sc_rq_cq))
> + if (!IS_ERR_OR_NULL(rdma->sc_rq_cq))
> ib_free_cq(rdma->sc_rq_cq);
>
> - if (rdma->sc_pd && !IS_ERR(rdma->sc_pd))
> + if (!IS_ERR_OR_NULL(rdma->sc_pd))
> ib_dealloc_pd(rdma->sc_pd);
>
> /* Destroy the CM ID */
>
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH 38/61] net: Prefer IS_ERR_OR_NULL over manual NULL check
From: Loktionov, Aleksandr @ 2026-03-11 9:24 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx@lists.freedesktop.org,
apparmor@lists.ubuntu.com, bpf@vger.kernel.org,
ceph-devel@vger.kernel.org, cocci@inria.fr,
dm-devel@lists.linux.dev, dri-devel@lists.freedesktop.org,
gfs2@lists.linux.dev, intel-gfx@lists.freedesktop.org,
intel-wired-lan@lists.osuosl.org, iommu@lists.linux.dev,
kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-block@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-clk@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, linux-media@vger.kernel.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-nfs@vger.kernel.org, linux-omap@vger.kernel.org,
linux-phy@lists.infradead.org, linux-pm@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org,
linux-security-module@vger.kernel.org, linux-sh@vger.kernel.org,
linux-sound@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-trace-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
ntfs3@lists.linux.dev, samba-technical@lists.samba.org,
sched-ext@lists.linux.dev, target-devel@vger.kernel.org,
tipc-discussion@lists.sourceforge.net, v9fs@lists.linux.dev
Cc: Igor Russkikh, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Pavan Chebbi, Michael Chan,
Potnuri Bharat Teja, Nguyen, Anthony L, Kitszel, Przemyslaw,
Taras Chornyi, Maxime Coquelin, Alexandre Torgue,
Iyappan Subramanian, Keyur Chudgar, Quan Nguyen, Heiner Kallweit,
Russell King
In-Reply-To: <20260310-b4-is_err_or_null-v1-38-bd63b656022d@avm.de>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Philipp Hahn
> Sent: Tuesday, March 10, 2026 12:49 PM
> To: amd-gfx@lists.freedesktop.org; apparmor@lists.ubuntu.com;
> bpf@vger.kernel.org; ceph-devel@vger.kernel.org; cocci@inria.fr; dm-
> devel@lists.linux.dev; dri-devel@lists.freedesktop.org;
> gfs2@lists.linux.dev; intel-gfx@lists.freedesktop.org; intel-wired-
> lan@lists.osuosl.org; iommu@lists.linux.dev; kvm@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-block@vger.kernel.org;
> linux-bluetooth@vger.kernel.org; linux-btrfs@vger.kernel.org; linux-
> cifs@vger.kernel.org; linux-clk@vger.kernel.org; linux-
> erofs@lists.ozlabs.org; linux-ext4@vger.kernel.org; linux-
> fsdevel@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> hyperv@vger.kernel.org; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-leds@vger.kernel.org; linux-
> media@vger.kernel.org; linux-mips@vger.kernel.org; linux-mm@kvack.org;
> linux-modules@vger.kernel.org; linux-mtd@lists.infradead.org; linux-
> nfs@vger.kernel.org; linux-omap@vger.kernel.org; linux-
> phy@lists.infradead.org; linux-pm@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-s390@vger.kernel.org; linux-
> scsi@vger.kernel.org; linux-sctp@vger.kernel.org; linux-security-
> module@vger.kernel.org; linux-sh@vger.kernel.org; linux-
> sound@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com;
> linux-trace-kernel@vger.kernel.org; linux-usb@vger.kernel.org; linux-
> wireless@vger.kernel.org; netdev@vger.kernel.org;
> ntfs3@lists.linux.dev; samba-technical@lists.samba.org; sched-
> ext@lists.linux.dev; target-devel@vger.kernel.org; tipc-
> discussion@lists.sourceforge.net; v9fs@lists.linux.dev; Philipp Hahn
> <phahn-oss@avm.de>
> Cc: Igor Russkikh <irusskikh@marvell.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric
> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo
> Abeni <pabeni@redhat.com>; Pavan Chebbi <pavan.chebbi@broadcom.com>;
> Michael Chan <mchan@broadcom.com>; Potnuri Bharat Teja
> <bharat@chelsio.com>; Nguyen, Anthony L <anthony.l.nguyen@intel.com>;
> Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Taras Chornyi
> <taras.chornyi@plvision.eu>; Maxime Coquelin
> <mcoquelin.stm32@gmail.com>; Alexandre Torgue
> <alexandre.torgue@foss.st.com>; Iyappan Subramanian
> <iyappan@os.amperecomputing.com>; Keyur Chudgar
> <keyur@os.amperecomputing.com>; Quan Nguyen
> <quan@os.amperecomputing.com>; Heiner Kallweit <hkallweit1@gmail.com>;
> Russell King <linux@armlinux.org.uk>
> Subject: [Intel-wired-lan] [PATCH 38/61] net: Prefer IS_ERR_OR_NULL
> over manual NULL check
>
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Igor Russkikh <irusskikh@marvell.com>
> To: Andrew Lunn <andrew+netdev@lunn.ch>
> To: "David S. Miller" <davem@davemloft.net>
> To: Eric Dumazet <edumazet@google.com>
> To: Jakub Kicinski <kuba@kernel.org>
> To: Paolo Abeni <pabeni@redhat.com>
> To: Pavan Chebbi <pavan.chebbi@broadcom.com>
> To: Michael Chan <mchan@broadcom.com>
> To: Potnuri Bharat Teja <bharat@chelsio.com>
> To: Tony Nguyen <anthony.l.nguyen@intel.com>
> To: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> To: Taras Chornyi <taras.chornyi@plvision.eu>
> To: Maxime Coquelin <mcoquelin.stm32@gmail.com>
> To: Alexandre Torgue <alexandre.torgue@foss.st.com>
> To: Iyappan Subramanian <iyappan@os.amperecomputing.com>
> To: Keyur Chudgar <keyur@os.amperecomputing.com>
> To: Quan Nguyen <quan@os.amperecomputing.com>
> To: Heiner Kallweit <hkallweit1@gmail.com>
> To: Russell King <linux@armlinux.org.uk>
> Cc: netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: intel-wired-lan@lists.osuosl.org
> Cc: linux-stm32@st-md-mailman.stormreply.com
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-usb@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> drivers/net/ethernet/aquantia/atlantic/aq_ring.c | 2 +-
> drivers/net/ethernet/broadcom/tg3.c | 2 +-
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c | 3 +--
> drivers/net/ethernet/intel/ice/devlink/devlink.c | 2 +-
> drivers/net/ethernet/marvell/prestera/prestera_router.c | 2 +-
> drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 2 +-
> drivers/net/mdio/mdio-xgene.c | 2 +-
> drivers/net/usb/r8152.c | 2 +-
> 8 files changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
> b/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
> index
> e270327e47fd804cc8ee5cfd53ed1b993c955c41..43edef35c4b1ff606b2f1519a07f
> ad4c9a990ad4 100644
> --- a/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
> +++ b/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
> @@ -810,7 +810,7 @@ static int __aq_ring_xdp_clean(struct aq_ring_s
> *rx_ring,
> }
>
> skb = aq_xdp_run_prog(aq_nic, &xdp, rx_ring, buff);
> - if (IS_ERR(skb) || !skb)
> + if (IS_ERR_OR_NULL(skb))
> continue;
>
> if (ptp_hwtstamp_len > 0)
> diff --git a/drivers/net/ethernet/broadcom/tg3.c
> b/drivers/net/ethernet/broadcom/tg3.c
> index
> 2328fce336447eb4a796f9300ccc0ab536ff0a35..8ed79f34f03d81184dcc12e6eaff
> 009cb8f7756e 100644
> --- a/drivers/net/ethernet/broadcom/tg3.c
> +++ b/drivers/net/ethernet/broadcom/tg3.c
> @@ -7943,7 +7943,7 @@ static int tg3_tso_bug(struct tg3 *tp, struct
> tg3_napi *tnapi,
>
> segs = skb_gso_segment(skb, tp->dev->features &
> ~(NETIF_F_TSO | NETIF_F_TSO6));
> - if (IS_ERR(segs) || !segs) {
> + if (IS_ERR_OR_NULL(segs)) {
> tnapi->tx_dropped++;
> goto tg3_tso_bug_end;
> }
> diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
> b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
> index
> 3307e50426819087ad985178c4a5383f16b8e7b4..1c8a6445d4b2e3535d8f1b7908dd
> 02d8dd2f23fa 100644
> --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
> +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
> @@ -1032,8 +1032,7 @@ static void ch_flower_stats_handler(struct
> work_struct *work)
> do {
> rhashtable_walk_start(&iter);
>
> - while ((flower_entry = rhashtable_walk_next(&iter)) &&
> - !IS_ERR(flower_entry)) {
> + while (!IS_ERR_OR_NULL((flower_entry =
> rhashtable_walk_next(&iter))))
> +{
> ret = cxgb4_get_filter_counters(adap->port[0],
> flower_entry-
> >filter_id,
> &packets, &bytes,
> diff --git a/drivers/net/ethernet/intel/ice/devlink/devlink.c
> b/drivers/net/ethernet/intel/ice/devlink/devlink.c
> index
> 6c72bd15db6d75a1d4fa04ef8fefbd26fb6e84bd..3d08b9187fd76ca3198af28111b6
> f1c1765ea01e 100644
> --- a/drivers/net/ethernet/intel/ice/devlink/devlink.c
> +++ b/drivers/net/ethernet/intel/ice/devlink/devlink.c
> @@ -791,7 +791,7 @@ static void ice_traverse_tx_tree(struct devlink
> *devlink, struct ice_sched_node
> node->parent->rate_node);
> }
>
> - if (rate_node && !IS_ERR(rate_node))
> + if (!IS_ERR_OR_NULL(rate_node))
> node->rate_node = rate_node;
>
> traverse_children:
> diff --git a/drivers/net/ethernet/marvell/prestera/prestera_router.c
> b/drivers/net/ethernet/marvell/prestera/prestera_router.c
> index
> b036b173a308b5f994ad8538eb010fa27196988c..4492938e8a3da91d32efe8d45ccb
> e2eb437c0e49 100644
> --- a/drivers/net/ethernet/marvell/prestera/prestera_router.c
> +++ b/drivers/net/ethernet/marvell/prestera/prestera_router.c
> @@ -1061,7 +1061,7 @@ static void __prestera_k_arb_hw_state_upd(struct
> prestera_switch *sw,
> n = NULL;
> }
>
> - if (!IS_ERR(n) && n) {
> + if (!IS_ERR_OR_NULL(n)) {
> neigh_event_send(n, NULL);
> neigh_release(n);
> } else {
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index
> 6827c99bde8c22db42b363d2d36ad6f26075ed50..356a4e9ce04b1fcf8786d7274d31
> ace404be2cf6 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -1275,7 +1275,7 @@ static int stmmac_init_phy(struct net_device
> *dev)
> /* Some DT bindings do not set-up the PHY handle. Let's try to
> * manually parse it
> */
> - if (!phy_fwnode || IS_ERR(phy_fwnode)) {
> + if (IS_ERR_OR_NULL(phy_fwnode)) {
> int addr = priv->plat->phy_addr;
> struct phy_device *phydev;
>
> diff --git a/drivers/net/mdio/mdio-xgene.c b/drivers/net/mdio/mdio-
> xgene.c index
> a8f91a4b7fed0927ee14e408000cd3a2bfb9b09a..09b30b563295c6085dc1358ac361
> 301e5cf6b2a8 100644
> --- a/drivers/net/mdio/mdio-xgene.c
> +++ b/drivers/net/mdio/mdio-xgene.c
> @@ -265,7 +265,7 @@ struct phy_device *xgene_enet_phy_register(struct
> mii_bus *bus, int phy_addr)
> struct phy_device *phy_dev;
>
> phy_dev = get_phy_device(bus, phy_addr, false);
> - if (!phy_dev || IS_ERR(phy_dev))
> + if (IS_ERR_OR_NULL(phy_dev))
> return NULL;
>
> if (phy_device_register(phy_dev))
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c index
> 0c83bbbea2e7c322ee6339893e281237663bd3ae..73f17ebd7d40007eec5004f887a4
> 6249defd28ab 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -2218,7 +2218,7 @@ static void r8152_csum_workaround(struct r8152
> *tp, struct sk_buff *skb,
>
> features &= ~(NETIF_F_SG | NETIF_F_IPV6_CSUM |
> NETIF_F_TSO6);
> segs = skb_gso_segment(skb, features);
> - if (IS_ERR(segs) || !segs)
> + if (IS_ERR_OR_NULL(segs))
> goto drop;
>
> __skb_queue_head_init(&seg_list);
>
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH 39/61] irqchip: Prefer IS_ERR_OR_NULL over manual NULL check
From: Loktionov, Aleksandr @ 2026-03-11 9:24 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx@lists.freedesktop.org,
apparmor@lists.ubuntu.com, bpf@vger.kernel.org,
ceph-devel@vger.kernel.org, cocci@inria.fr,
dm-devel@lists.linux.dev, dri-devel@lists.freedesktop.org,
gfs2@lists.linux.dev, intel-gfx@lists.freedesktop.org,
intel-wired-lan@lists.osuosl.org, iommu@lists.linux.dev,
kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-block@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-clk@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, linux-media@vger.kernel.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-nfs@vger.kernel.org, linux-omap@vger.kernel.org,
linux-phy@lists.infradead.org, linux-pm@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org,
linux-security-module@vger.kernel.org, linux-sh@vger.kernel.org,
linux-sound@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-trace-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
ntfs3@lists.linux.dev, samba-technical@lists.samba.org,
sched-ext@lists.linux.dev, target-devel@vger.kernel.org,
tipc-discussion@lists.sourceforge.net, v9fs@lists.linux.dev
Cc: Marc Zyngier, Thomas Gleixner, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth
In-Reply-To: <20260310-b4-is_err_or_null-v1-39-bd63b656022d@avm.de>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Philipp Hahn
> Sent: Tuesday, March 10, 2026 12:49 PM
> To: amd-gfx@lists.freedesktop.org; apparmor@lists.ubuntu.com;
> bpf@vger.kernel.org; ceph-devel@vger.kernel.org; cocci@inria.fr; dm-
> devel@lists.linux.dev; dri-devel@lists.freedesktop.org;
> gfs2@lists.linux.dev; intel-gfx@lists.freedesktop.org; intel-wired-
> lan@lists.osuosl.org; iommu@lists.linux.dev; kvm@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-block@vger.kernel.org;
> linux-bluetooth@vger.kernel.org; linux-btrfs@vger.kernel.org; linux-
> cifs@vger.kernel.org; linux-clk@vger.kernel.org; linux-
> erofs@lists.ozlabs.org; linux-ext4@vger.kernel.org; linux-
> fsdevel@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> hyperv@vger.kernel.org; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-leds@vger.kernel.org; linux-
> media@vger.kernel.org; linux-mips@vger.kernel.org; linux-mm@kvack.org;
> linux-modules@vger.kernel.org; linux-mtd@lists.infradead.org; linux-
> nfs@vger.kernel.org; linux-omap@vger.kernel.org; linux-
> phy@lists.infradead.org; linux-pm@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-s390@vger.kernel.org; linux-
> scsi@vger.kernel.org; linux-sctp@vger.kernel.org; linux-security-
> module@vger.kernel.org; linux-sh@vger.kernel.org; linux-
> sound@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com;
> linux-trace-kernel@vger.kernel.org; linux-usb@vger.kernel.org; linux-
> wireless@vger.kernel.org; netdev@vger.kernel.org;
> ntfs3@lists.linux.dev; samba-technical@lists.samba.org; sched-
> ext@lists.linux.dev; target-devel@vger.kernel.org; tipc-
> discussion@lists.sourceforge.net; v9fs@lists.linux.dev; Philipp Hahn
> <phahn-oss@avm.de>
> Cc: Marc Zyngier <maz@kernel.org>; Thomas Gleixner <tglx@kernel.org>;
> Andrew Lunn <andrew@lunn.ch>; Gregory Clement
> <gregory.clement@bootlin.com>; Sebastian Hesselbarth
> <sebastian.hesselbarth@gmail.com>
> Subject: [Intel-wired-lan] [PATCH 39/61] irqchip: Prefer
> IS_ERR_OR_NULL over manual NULL check
>
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Marc Zyngier <maz@kernel.org>
> To: Thomas Gleixner <tglx@kernel.org>
> To: Andrew Lunn <andrew@lunn.ch>
> To: Gregory Clement <gregory.clement@bootlin.com>
> To: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> drivers/irqchip/irq-gic-v3.c | 2 +-
> drivers/irqchip/irq-mvebu-odmi.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-
> v3.c index
> 20f13b686ab22faf722dd2b24faf96af636a4bbd..6dc9827357a21ae05dd838fb7178
> 71c73f3c7562 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -2252,7 +2252,7 @@ static int __init gic_of_init(struct device_node
> *node, struct device_node *pare
>
> out_unmap_rdist:
> for (i = 0; i < nr_redist_regions; i++)
> - if (rdist_regs[i].redist_base &&
> !IS_ERR(rdist_regs[i].redist_base))
> + if (!IS_ERR_OR_NULL(rdist_regs[i].redist_base))
> iounmap(rdist_regs[i].redist_base);
> kfree(rdist_regs);
> out_unmap_dist:
> diff --git a/drivers/irqchip/irq-mvebu-odmi.c b/drivers/irqchip/irq-
> mvebu-odmi.c
> index
> b99ab9dcc14b3ba982876cf5525499d02bc1c997..94e7eda46e81833cfe0479b6fabb
> a715bf4ef6b8 100644
> --- a/drivers/irqchip/irq-mvebu-odmi.c
> +++ b/drivers/irqchip/irq-mvebu-odmi.c
> @@ -217,7 +217,7 @@ static int __init mvebu_odmi_init(struct
> device_node *node,
> for (i = 0; i < odmis_count; i++) {
> struct odmi_data *odmi = &odmis[i];
>
> - if (odmi->base && !IS_ERR(odmi->base))
> + if (!IS_ERR_OR_NULL(odmi->base))
> iounmap(odmis[i].base);
> }
> bitmap_free(odmis_bm);
>
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH 46/61] vfio: Prefer IS_ERR_OR_NULL over manual NULL check
From: Loktionov, Aleksandr @ 2026-03-11 9:25 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx@lists.freedesktop.org,
apparmor@lists.ubuntu.com, bpf@vger.kernel.org,
ceph-devel@vger.kernel.org, cocci@inria.fr,
dm-devel@lists.linux.dev, dri-devel@lists.freedesktop.org,
gfs2@lists.linux.dev, intel-gfx@lists.freedesktop.org,
intel-wired-lan@lists.osuosl.org, iommu@lists.linux.dev,
kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-block@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-clk@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, linux-media@vger.kernel.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-nfs@vger.kernel.org, linux-omap@vger.kernel.org,
linux-phy@lists.infradead.org, linux-pm@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org,
linux-security-module@vger.kernel.org, linux-sh@vger.kernel.org,
linux-sound@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-trace-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
ntfs3@lists.linux.dev, samba-technical@lists.samba.org,
sched-ext@lists.linux.dev, target-devel@vger.kernel.org,
tipc-discussion@lists.sourceforge.net, v9fs@lists.linux.dev
Cc: Alex Williamson
In-Reply-To: <20260310-b4-is_err_or_null-v1-46-bd63b656022d@avm.de>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Philipp Hahn
> Sent: Tuesday, March 10, 2026 12:49 PM
> To: amd-gfx@lists.freedesktop.org; apparmor@lists.ubuntu.com;
> bpf@vger.kernel.org; ceph-devel@vger.kernel.org; cocci@inria.fr; dm-
> devel@lists.linux.dev; dri-devel@lists.freedesktop.org;
> gfs2@lists.linux.dev; intel-gfx@lists.freedesktop.org; intel-wired-
> lan@lists.osuosl.org; iommu@lists.linux.dev; kvm@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-block@vger.kernel.org;
> linux-bluetooth@vger.kernel.org; linux-btrfs@vger.kernel.org; linux-
> cifs@vger.kernel.org; linux-clk@vger.kernel.org; linux-
> erofs@lists.ozlabs.org; linux-ext4@vger.kernel.org; linux-
> fsdevel@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> hyperv@vger.kernel.org; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-leds@vger.kernel.org; linux-
> media@vger.kernel.org; linux-mips@vger.kernel.org; linux-mm@kvack.org;
> linux-modules@vger.kernel.org; linux-mtd@lists.infradead.org; linux-
> nfs@vger.kernel.org; linux-omap@vger.kernel.org; linux-
> phy@lists.infradead.org; linux-pm@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-s390@vger.kernel.org; linux-
> scsi@vger.kernel.org; linux-sctp@vger.kernel.org; linux-security-
> module@vger.kernel.org; linux-sh@vger.kernel.org; linux-
> sound@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com;
> linux-trace-kernel@vger.kernel.org; linux-usb@vger.kernel.org; linux-
> wireless@vger.kernel.org; netdev@vger.kernel.org;
> ntfs3@lists.linux.dev; samba-technical@lists.samba.org; sched-
> ext@lists.linux.dev; target-devel@vger.kernel.org; tipc-
> discussion@lists.sourceforge.net; v9fs@lists.linux.dev; Philipp Hahn
> <phahn-oss@avm.de>
> Cc: Alex Williamson <alex@shazbot.org>
> Subject: [Intel-wired-lan] [PATCH 46/61] vfio: Prefer IS_ERR_OR_NULL
> over manual NULL check
>
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Alex Williamson <alex@shazbot.org>
> Cc: kvm@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> drivers/vfio/vfio_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c index
> 742477546b15d4dbaf9ebcfb2e67627db71521e0..d71922dfde5885967398deddec3e
> 9e04b05adfec 100644
> --- a/drivers/vfio/vfio_main.c
> +++ b/drivers/vfio/vfio_main.c
> @@ -923,7 +923,7 @@ vfio_ioctl_device_feature_mig_device_state(struct
> vfio_device *device,
>
> /* Handle the VFIO_DEVICE_FEATURE_SET */
> filp = device->mig_ops->migration_set_state(device,
> mig.device_state);
> - if (IS_ERR(filp) || !filp)
> + if (IS_ERR_OR_NULL(filp))
> goto out_copy;
>
> return vfio_ioct_mig_return_fd(filp, arg, &mig);
>
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH 49/61] media: Prefer IS_ERR_OR_NULL over manual NULL check
From: Loktionov, Aleksandr @ 2026-03-11 9:25 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx@lists.freedesktop.org,
apparmor@lists.ubuntu.com, bpf@vger.kernel.org,
ceph-devel@vger.kernel.org, cocci@inria.fr,
dm-devel@lists.linux.dev, dri-devel@lists.freedesktop.org,
gfs2@lists.linux.dev, intel-gfx@lists.freedesktop.org,
intel-wired-lan@lists.osuosl.org, iommu@lists.linux.dev,
kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-block@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-clk@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, linux-media@vger.kernel.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-nfs@vger.kernel.org, linux-omap@vger.kernel.org,
linux-phy@lists.infradead.org, linux-pm@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org,
linux-security-module@vger.kernel.org, linux-sh@vger.kernel.org,
linux-sound@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-trace-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
ntfs3@lists.linux.dev, samba-technical@lists.samba.org,
sched-ext@lists.linux.dev, target-devel@vger.kernel.org,
tipc-discussion@lists.sourceforge.net, v9fs@lists.linux.dev
Cc: Shuah Khan, Kieran Bingham, Mauro Carvalho Chehab
In-Reply-To: <20260310-b4-is_err_or_null-v1-49-bd63b656022d@avm.de>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Philipp Hahn
> Sent: Tuesday, March 10, 2026 12:49 PM
> To: amd-gfx@lists.freedesktop.org; apparmor@lists.ubuntu.com;
> bpf@vger.kernel.org; ceph-devel@vger.kernel.org; cocci@inria.fr; dm-
> devel@lists.linux.dev; dri-devel@lists.freedesktop.org;
> gfs2@lists.linux.dev; intel-gfx@lists.freedesktop.org; intel-wired-
> lan@lists.osuosl.org; iommu@lists.linux.dev; kvm@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-block@vger.kernel.org;
> linux-bluetooth@vger.kernel.org; linux-btrfs@vger.kernel.org; linux-
> cifs@vger.kernel.org; linux-clk@vger.kernel.org; linux-
> erofs@lists.ozlabs.org; linux-ext4@vger.kernel.org; linux-
> fsdevel@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> hyperv@vger.kernel.org; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-leds@vger.kernel.org; linux-
> media@vger.kernel.org; linux-mips@vger.kernel.org; linux-mm@kvack.org;
> linux-modules@vger.kernel.org; linux-mtd@lists.infradead.org; linux-
> nfs@vger.kernel.org; linux-omap@vger.kernel.org; linux-
> phy@lists.infradead.org; linux-pm@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-s390@vger.kernel.org; linux-
> scsi@vger.kernel.org; linux-sctp@vger.kernel.org; linux-security-
> module@vger.kernel.org; linux-sh@vger.kernel.org; linux-
> sound@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com;
> linux-trace-kernel@vger.kernel.org; linux-usb@vger.kernel.org; linux-
> wireless@vger.kernel.org; netdev@vger.kernel.org;
> ntfs3@lists.linux.dev; samba-technical@lists.samba.org; sched-
> ext@lists.linux.dev; target-devel@vger.kernel.org; tipc-
> discussion@lists.sourceforge.net; v9fs@lists.linux.dev; Philipp Hahn
> <phahn-oss@avm.de>
> Cc: Shuah Khan <skhan@linuxfoundation.org>; Kieran Bingham
> <kieran.bingham@ideasonboard.com>; Mauro Carvalho Chehab
> <mchehab@kernel.org>
> Subject: [Intel-wired-lan] [PATCH 49/61] media: Prefer IS_ERR_OR_NULL
> over manual NULL check
>
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Shuah Khan <skhan@linuxfoundation.org>
> To: Kieran Bingham <kieran.bingham@ideasonboard.com>
> To: Mauro Carvalho Chehab <mchehab@kernel.org>
> Cc: linux-media@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> drivers/media/test-drivers/vimc/vimc-streamer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/test-drivers/vimc/vimc-streamer.c
> b/drivers/media/test-drivers/vimc/vimc-streamer.c
> index
> 15d863f97cbf96b7ca7fbf3d7b6b6ec39fcc8ae3..da5aca50bcb4990c06f28e5a883e
> b398606991e9 100644
> --- a/drivers/media/test-drivers/vimc/vimc-streamer.c
> +++ b/drivers/media/test-drivers/vimc/vimc-streamer.c
> @@ -167,7 +167,7 @@ static int vimc_streamer_thread(void *data)
> for (i = stream->pipe_size - 1; i >= 0; i--) {
> frame = stream->ved_pipeline[i]->process_frame(
> stream->ved_pipeline[i], frame);
> - if (!frame || IS_ERR(frame))
> + if (IS_ERR_OR_NULL(frame))
> break;
> }
> //wait for 60hz
>
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH 50/61] iommu: Prefer IS_ERR_OR_NULL over manual NULL check
From: Loktionov, Aleksandr @ 2026-03-11 9:26 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx@lists.freedesktop.org,
apparmor@lists.ubuntu.com, bpf@vger.kernel.org,
ceph-devel@vger.kernel.org, cocci@inria.fr,
dm-devel@lists.linux.dev, dri-devel@lists.freedesktop.org,
gfs2@lists.linux.dev, intel-gfx@lists.freedesktop.org,
intel-wired-lan@lists.osuosl.org, iommu@lists.linux.dev,
kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-block@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-clk@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, linux-media@vger.kernel.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-nfs@vger.kernel.org, linux-omap@vger.kernel.org,
linux-phy@lists.infradead.org, linux-pm@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org,
linux-security-module@vger.kernel.org, linux-sh@vger.kernel.org,
linux-sound@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-trace-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
ntfs3@lists.linux.dev, samba-technical@lists.samba.org,
sched-ext@lists.linux.dev, target-devel@vger.kernel.org,
tipc-discussion@lists.sourceforge.net, v9fs@lists.linux.dev
Cc: Joerg Roedel, Will Deacon, Robin Murphy
In-Reply-To: <20260310-b4-is_err_or_null-v1-50-bd63b656022d@avm.de>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Philipp Hahn
> Sent: Tuesday, March 10, 2026 12:49 PM
> To: amd-gfx@lists.freedesktop.org; apparmor@lists.ubuntu.com;
> bpf@vger.kernel.org; ceph-devel@vger.kernel.org; cocci@inria.fr; dm-
> devel@lists.linux.dev; dri-devel@lists.freedesktop.org;
> gfs2@lists.linux.dev; intel-gfx@lists.freedesktop.org; intel-wired-
> lan@lists.osuosl.org; iommu@lists.linux.dev; kvm@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-block@vger.kernel.org;
> linux-bluetooth@vger.kernel.org; linux-btrfs@vger.kernel.org; linux-
> cifs@vger.kernel.org; linux-clk@vger.kernel.org; linux-
> erofs@lists.ozlabs.org; linux-ext4@vger.kernel.org; linux-
> fsdevel@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> hyperv@vger.kernel.org; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-leds@vger.kernel.org; linux-
> media@vger.kernel.org; linux-mips@vger.kernel.org; linux-mm@kvack.org;
> linux-modules@vger.kernel.org; linux-mtd@lists.infradead.org; linux-
> nfs@vger.kernel.org; linux-omap@vger.kernel.org; linux-
> phy@lists.infradead.org; linux-pm@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-s390@vger.kernel.org; linux-
> scsi@vger.kernel.org; linux-sctp@vger.kernel.org; linux-security-
> module@vger.kernel.org; linux-sh@vger.kernel.org; linux-
> sound@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com;
> linux-trace-kernel@vger.kernel.org; linux-usb@vger.kernel.org; linux-
> wireless@vger.kernel.org; netdev@vger.kernel.org;
> ntfs3@lists.linux.dev; samba-technical@lists.samba.org; sched-
> ext@lists.linux.dev; target-devel@vger.kernel.org; tipc-
> discussion@lists.sourceforge.net; v9fs@lists.linux.dev; Philipp Hahn
> <phahn-oss@avm.de>
> Cc: Joerg Roedel <joro@8bytes.org>; Will Deacon <will@kernel.org>;
> Robin Murphy <robin.murphy@arm.com>
> Subject: [Intel-wired-lan] [PATCH 50/61] iommu: Prefer IS_ERR_OR_NULL
> over manual NULL check
>
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Joerg Roedel <joro@8bytes.org>
> To: Will Deacon <will@kernel.org>
> To: Robin Murphy <robin.murphy@arm.com>
> Cc: iommu@lists.linux.dev
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> drivers/iommu/omap-iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
> index
> 8231d7d6bb6a9202025643639a6b28e6faa84659..500a42b57a997696ff37c76f028a
> 717ab71d01f9 100644
> --- a/drivers/iommu/omap-iommu.c
> +++ b/drivers/iommu/omap-iommu.c
> @@ -881,7 +881,7 @@ static int omap_iommu_attach(struct omap_iommu
> *obj, u32 *iopgd)
> **/
> static void omap_iommu_detach(struct omap_iommu *obj) {
> - if (!obj || IS_ERR(obj))
> + if (IS_ERR_OR_NULL(obj))
> return;
>
> spin_lock(&obj->iommu_lock);
>
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH 54/61] aoe: Prefer IS_ERR_OR_NULL over manual NULL check
From: Loktionov, Aleksandr @ 2026-03-11 9:26 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx@lists.freedesktop.org,
apparmor@lists.ubuntu.com, bpf@vger.kernel.org,
ceph-devel@vger.kernel.org, cocci@inria.fr,
dm-devel@lists.linux.dev, dri-devel@lists.freedesktop.org,
gfs2@lists.linux.dev, intel-gfx@lists.freedesktop.org,
intel-wired-lan@lists.osuosl.org, iommu@lists.linux.dev,
kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-block@vger.kernel.org, linux-bluetooth@vger.kernel.org,
linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org,
linux-clk@vger.kernel.org, linux-erofs@lists.ozlabs.org,
linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-hyperv@vger.kernel.org,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, linux-media@vger.kernel.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-mtd@lists.infradead.org,
linux-nfs@vger.kernel.org, linux-omap@vger.kernel.org,
linux-phy@lists.infradead.org, linux-pm@vger.kernel.org,
linux-rockchip@lists.infradead.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, linux-sctp@vger.kernel.org,
linux-security-module@vger.kernel.org, linux-sh@vger.kernel.org,
linux-sound@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-trace-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
ntfs3@lists.linux.dev, samba-technical@lists.samba.org,
sched-ext@lists.linux.dev, target-devel@vger.kernel.org,
tipc-discussion@lists.sourceforge.net, v9fs@lists.linux.dev
Cc: Justin Sanders, Jens Axboe
In-Reply-To: <20260310-b4-is_err_or_null-v1-54-bd63b656022d@avm.de>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Philipp Hahn
> Sent: Tuesday, March 10, 2026 12:49 PM
> To: amd-gfx@lists.freedesktop.org; apparmor@lists.ubuntu.com;
> bpf@vger.kernel.org; ceph-devel@vger.kernel.org; cocci@inria.fr; dm-
> devel@lists.linux.dev; dri-devel@lists.freedesktop.org;
> gfs2@lists.linux.dev; intel-gfx@lists.freedesktop.org; intel-wired-
> lan@lists.osuosl.org; iommu@lists.linux.dev; kvm@vger.kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-block@vger.kernel.org;
> linux-bluetooth@vger.kernel.org; linux-btrfs@vger.kernel.org; linux-
> cifs@vger.kernel.org; linux-clk@vger.kernel.org; linux-
> erofs@lists.ozlabs.org; linux-ext4@vger.kernel.org; linux-
> fsdevel@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> hyperv@vger.kernel.org; linux-input@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-leds@vger.kernel.org; linux-
> media@vger.kernel.org; linux-mips@vger.kernel.org; linux-mm@kvack.org;
> linux-modules@vger.kernel.org; linux-mtd@lists.infradead.org; linux-
> nfs@vger.kernel.org; linux-omap@vger.kernel.org; linux-
> phy@lists.infradead.org; linux-pm@vger.kernel.org; linux-
> rockchip@lists.infradead.org; linux-s390@vger.kernel.org; linux-
> scsi@vger.kernel.org; linux-sctp@vger.kernel.org; linux-security-
> module@vger.kernel.org; linux-sh@vger.kernel.org; linux-
> sound@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com;
> linux-trace-kernel@vger.kernel.org; linux-usb@vger.kernel.org; linux-
> wireless@vger.kernel.org; netdev@vger.kernel.org;
> ntfs3@lists.linux.dev; samba-technical@lists.samba.org; sched-
> ext@lists.linux.dev; target-devel@vger.kernel.org; tipc-
> discussion@lists.sourceforge.net; v9fs@lists.linux.dev; Philipp Hahn
> <phahn-oss@avm.de>
> Cc: Justin Sanders <justin@coraid.com>; Jens Axboe <axboe@kernel.dk>
> Subject: [Intel-wired-lan] [PATCH 54/61] aoe: Prefer IS_ERR_OR_NULL
> over manual NULL check
>
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Justin Sanders <justin@coraid.com>
> To: Jens Axboe <axboe@kernel.dk>
> Cc: linux-block@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> drivers/block/aoe/aoecmd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/block/aoe/aoecmd.c b/drivers/block/aoe/aoecmd.c
> index
> a4744a30a8af4ff05113f3234021eec728265b4f..b31e539a66433a0a5d6e81117a32
> d12735ffc1bc 100644
> --- a/drivers/block/aoe/aoecmd.c
> +++ b/drivers/block/aoe/aoecmd.c
> @@ -1268,7 +1268,7 @@ aoe_ktstart(struct ktstate *k)
>
> init_completion(&k->rendez);
> task = kthread_run(kthread, k, "%s", k->name);
> - if (task == NULL || IS_ERR(task))
> + if (IS_ERR_OR_NULL(task))
> return -ENOMEM;
> k->task = task;
> wait_for_completion(&k->rendez); /* allow kthread to start */
>
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* Re: [PATCH 41/61] pinctrl: Prefer IS_ERR_OR_NULL over manual NULL check
From: Linus Walleij @ 2026-03-11 9:32 UTC (permalink / raw)
To: Philipp Hahn
Cc: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs
In-Reply-To: <20260310-b4-is_err_or_null-v1-41-bd63b656022d@avm.de>
On Tue, Mar 10, 2026 at 12:55 PM Philipp Hahn <phahn-oss@avm.de> wrote:
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Linus Walleij <linusw@kernel.org>
> Cc: linux-gpio@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
Patch applied to the pinctrl tree as obviously correct.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH wireless-next v2] wifi: cfg80211: init S1G properly when creating chandef
From: Johannes Berg @ 2026-03-11 9:55 UTC (permalink / raw)
To: Lachlan Hodges; +Cc: linux-wireless, arien.judge
In-Reply-To: <20260311064339.524758-1-lachlan.hodges@morsemicro.com>
On Wed, 2026-03-11 at 17:43 +1100, Lachlan Hodges wrote:
> When creating a chandef, the initial width is determined by the
> chan_type argument leading to a default width of 20/20_NOHT/40 which
> does not make sense for S1G channels. Fix this by ensuring we default
> S1G chandefs to a width of 1MHz.
>
> Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
> ---
> v1 -> v2:
>
> - Remove the mac80211-based wording in the commit message and keep it
> simple.
Thanks :)
Now with more tea and all that, do we really want it to completely
ignore the width? Should that be documented? Almost feels like it should
WARN if you use it wrong, with an S1G channel but a regular width, and
mac80211 should be fixed?
johannes
^ permalink raw reply
* Re: [PATCH wireless-next v2] wifi: cfg80211: init S1G properly when creating chandef
From: Lachlan Hodges @ 2026-03-11 10:21 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, arien.judge
In-Reply-To: <791eaf8ab04dcbe01e2d71612d162f71c61e573a.camel@sipsolutions.net>
On Wed, Mar 11, 2026 at 10:55:46AM +0100, Johannes Berg wrote:
> On Wed, 2026-03-11 at 17:43 +1100, Lachlan Hodges wrote:
> > When creating a chandef, the initial width is determined by the
> > chan_type argument leading to a default width of 20/20_NOHT/40 which
> > does not make sense for S1G channels. Fix this by ensuring we default
> > S1G chandefs to a width of 1MHz.
> >
> > Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
> > ---
> > v1 -> v2:
> >
> > - Remove the mac80211-based wording in the commit message and keep it
> > simple.
>
> Thanks :)
>
> Now with more tea and all that, do we really want it to completely
> ignore the width? Should that be documented? Almost feels like it should
> WARN if you use it wrong, with an S1G channel but a regular width, and
> mac80211 should be fixed?
When you say "ignore the width" do you mean nothing checks it? If
that's the case we probably need to add something within
cfg80211_chandef_valid() to ensure if we have an S1G chan we don't
have a non-S1G width i.e > 16MHz. That would fix mac80211 from
giving it to the driver in the first place.
lachlan
^ permalink raw reply
* [PATCH v4] wifi: ath12k: fix endianness handling for SRNG ring pointer accesses
From: Alexander Wilhelm @ 2026-03-11 10:24 UTC (permalink / raw)
To: Jeff Johnson; +Cc: Baochen Qiang, ath12k, linux-wireless, linux-kernel
The SRNG head and tail ring pointers are stored in device memory as
little-endian values. On big-endian systems, direct dereferencing of these
pointers leads to incorrect values being read or written, causing ring
management issues and potentially breaking data flow.
This patch ensures all accesses to SRNG ring pointers use the appropriate
endianness conversions. This affects both read and write paths for source
and destination rings, as well as debug output. The changes guarantee
correct operation on both little- and big-endian architectures.
Signed-off-by: Alexander Wilhelm <alexander.wilhelm@westermo.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
---
Changes in v4:
- Rebase on latest 'ath' master
- Remove volatile from `hp_addr` due to the `checkpatch.pl` warning
- Fix opening braces at the end of line due to the `checkpatch.pl` error
- Fix `u32 *` cast in `wifi7/hal.c` due to the `sparse` error
Changes in v3:
- Rebase on latest 'ath' master
- Use always 'le32_to_cpu()' macro for conversions
Changes in v2:
- Set '__le32 *' type for 'hp_addr/tp_addr' in both 'dst_ring' and 'src_ring'
---
drivers/net/wireless/ath/ath12k/hal.c | 31 ++++++++++++---------
drivers/net/wireless/ath/ath12k/hal.h | 8 +++---
drivers/net/wireless/ath/ath12k/wifi7/hal.c | 14 ++++++----
3 files changed, 30 insertions(+), 23 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/hal.c b/drivers/net/wireless/ath/ath12k/hal.c
index a164563fff28..a9c9311538b0 100644
--- a/drivers/net/wireless/ath/ath12k/hal.c
+++ b/drivers/net/wireless/ath/ath12k/hal.c
@@ -355,7 +355,7 @@ int ath12k_hal_srng_dst_num_free(struct ath12k_base *ab, struct hal_srng *srng,
tp = srng->u.dst_ring.tp;
if (sync_hw_ptr) {
- hp = *srng->u.dst_ring.hp_addr;
+ hp = le32_to_cpu(*srng->u.dst_ring.hp_addr);
srng->u.dst_ring.cached_hp = hp;
} else {
hp = srng->u.dst_ring.cached_hp;
@@ -379,7 +379,7 @@ int ath12k_hal_srng_src_num_free(struct ath12k_base *ab, struct hal_srng *srng,
hp = srng->u.src_ring.hp;
if (sync_hw_ptr) {
- tp = *srng->u.src_ring.tp_addr;
+ tp = le32_to_cpu(*srng->u.src_ring.tp_addr);
srng->u.src_ring.cached_tp = tp;
} else {
tp = srng->u.src_ring.cached_tp;
@@ -501,9 +501,9 @@ void ath12k_hal_srng_access_begin(struct ath12k_base *ab, struct hal_srng *srng)
if (srng->ring_dir == HAL_SRNG_DIR_SRC) {
srng->u.src_ring.cached_tp =
- *(volatile u32 *)srng->u.src_ring.tp_addr;
+ le32_to_cpu(*srng->u.src_ring.tp_addr);
} else {
- hp = READ_ONCE(*srng->u.dst_ring.hp_addr);
+ hp = le32_to_cpu(READ_ONCE(*srng->u.dst_ring.hp_addr));
if (hp != srng->u.dst_ring.cached_hp) {
srng->u.dst_ring.cached_hp = hp;
@@ -529,24 +529,27 @@ void ath12k_hal_srng_access_end(struct ath12k_base *ab, struct hal_srng *srng)
*/
if (srng->ring_dir == HAL_SRNG_DIR_SRC) {
srng->u.src_ring.last_tp =
- *(volatile u32 *)srng->u.src_ring.tp_addr;
+ le32_to_cpu(*srng->u.src_ring.tp_addr);
/* Make sure descriptor is written before updating the
* head pointer.
*/
dma_wmb();
- WRITE_ONCE(*srng->u.src_ring.hp_addr, srng->u.src_ring.hp);
+ WRITE_ONCE(*srng->u.src_ring.hp_addr,
+ cpu_to_le32(srng->u.src_ring.hp));
} else {
- srng->u.dst_ring.last_hp = *srng->u.dst_ring.hp_addr;
+ srng->u.dst_ring.last_hp =
+ le32_to_cpu(*srng->u.dst_ring.hp_addr);
/* Make sure descriptor is read before updating the
* tail pointer.
*/
dma_mb();
- WRITE_ONCE(*srng->u.dst_ring.tp_addr, srng->u.dst_ring.tp);
+ WRITE_ONCE(*srng->u.dst_ring.tp_addr,
+ cpu_to_le32(srng->u.dst_ring.tp));
}
} else {
if (srng->ring_dir == HAL_SRNG_DIR_SRC) {
srng->u.src_ring.last_tp =
- *(volatile u32 *)srng->u.src_ring.tp_addr;
+ le32_to_cpu(*srng->u.src_ring.tp_addr);
/* Assume implementation use an MMIO write accessor
* which has the required wmb() so that the descriptor
* is written before the updating the head pointer.
@@ -556,7 +559,8 @@ void ath12k_hal_srng_access_end(struct ath12k_base *ab, struct hal_srng *srng)
(unsigned long)ab->mem,
srng->u.src_ring.hp);
} else {
- srng->u.dst_ring.last_hp = *srng->u.dst_ring.hp_addr;
+ srng->u.dst_ring.last_hp =
+ le32_to_cpu(*srng->u.dst_ring.hp_addr);
/* Make sure descriptor is read before updating the
* tail pointer.
*/
@@ -711,7 +715,7 @@ void ath12k_hal_srng_shadow_update_hp_tp(struct ath12k_base *ab,
* HP only when then ring isn't' empty.
*/
if (srng->ring_dir == HAL_SRNG_DIR_SRC &&
- *srng->u.src_ring.tp_addr != srng->u.src_ring.hp)
+ le32_to_cpu(*srng->u.src_ring.tp_addr) != srng->u.src_ring.hp)
ath12k_hal_srng_access_end(ab, srng);
}
@@ -810,14 +814,15 @@ void ath12k_hal_dump_srng_stats(struct ath12k_base *ab)
"src srng id %u hp %u, reap_hp %u, cur tp %u, cached tp %u last tp %u napi processed before %ums\n",
srng->ring_id, srng->u.src_ring.hp,
srng->u.src_ring.reap_hp,
- *srng->u.src_ring.tp_addr, srng->u.src_ring.cached_tp,
+ le32_to_cpu(*srng->u.src_ring.tp_addr),
+ srng->u.src_ring.cached_tp,
srng->u.src_ring.last_tp,
jiffies_to_msecs(jiffies - srng->timestamp));
else if (srng->ring_dir == HAL_SRNG_DIR_DST)
ath12k_err(ab,
"dst srng id %u tp %u, cur hp %u, cached hp %u last hp %u napi processed before %ums\n",
srng->ring_id, srng->u.dst_ring.tp,
- *srng->u.dst_ring.hp_addr,
+ le32_to_cpu(*srng->u.dst_ring.hp_addr),
srng->u.dst_ring.cached_hp,
srng->u.dst_ring.last_hp,
jiffies_to_msecs(jiffies - srng->timestamp));
diff --git a/drivers/net/wireless/ath/ath12k/hal.h b/drivers/net/wireless/ath/ath12k/hal.h
index bf4f7dbae866..d8dbcc846387 100644
--- a/drivers/net/wireless/ath/ath12k/hal.h
+++ b/drivers/net/wireless/ath/ath12k/hal.h
@@ -921,7 +921,7 @@ struct hal_srng {
u32 tp;
/* Shadow head pointer location to be updated by HW */
- volatile u32 *hp_addr;
+ __le32 *hp_addr;
/* Cached head pointer */
u32 cached_hp;
@@ -930,7 +930,7 @@ struct hal_srng {
* will be a register address and need not be
* accessed through SW structure
*/
- u32 *tp_addr;
+ __le32 *tp_addr;
/* Current SW loop cnt */
u32 loop_cnt;
@@ -950,7 +950,7 @@ struct hal_srng {
u32 reap_hp;
/* Shadow tail pointer location to be updated by HW */
- u32 *tp_addr;
+ __le32 *tp_addr;
/* Cached tail pointer */
u32 cached_tp;
@@ -959,7 +959,7 @@ struct hal_srng {
* will be a register address and need not be accessed
* through SW structure
*/
- u32 *hp_addr;
+ __le32 *hp_addr;
/* Low threshold - in number of ring entries */
u32 low_threshold;
diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hal.c b/drivers/net/wireless/ath/ath12k/wifi7/hal.c
index bd1753ca0db6..c05bfcffdf5c 100644
--- a/drivers/net/wireless/ath/ath12k/wifi7/hal.c
+++ b/drivers/net/wireless/ath/ath12k/wifi7/hal.c
@@ -320,7 +320,7 @@ void ath12k_wifi7_hal_set_umac_srng_ptr_addr(struct ath12k_base *ab,
if (srng->ring_dir == HAL_SRNG_DIR_SRC) {
if (!ab->hw_params->supports_shadow_regs) {
srng->u.src_ring.hp_addr =
- (u32 *)((unsigned long)ab->mem + reg_base);
+ (__le32 *)((unsigned long)ab->mem + reg_base);
} else {
ath12k_dbg(ab, ATH12K_DBG_HAL,
"hal reg_base 0x%x shadow 0x%lx\n",
@@ -331,7 +331,7 @@ void ath12k_wifi7_hal_set_umac_srng_ptr_addr(struct ath12k_base *ab,
} else {
if (!ab->hw_params->supports_shadow_regs) {
srng->u.dst_ring.tp_addr =
- (u32 *)((unsigned long)ab->mem + reg_base +
+ (__le32 *)((unsigned long)ab->mem + reg_base +
(HAL_REO1_RING_TP - HAL_REO1_RING_HP));
} else {
ath12k_dbg(ab, ATH12K_DBG_HAL,
@@ -384,11 +384,13 @@ void ath12k_wifi7_hal_srng_update_hp_tp_addr(struct ath12k_base *ab,
srng = &hal->srng_list[ring_id];
if (srng_config->ring_dir == HAL_SRNG_DIR_DST)
- srng->u.dst_ring.tp_addr = (u32 *)(HAL_SHADOW_REG(shadow_cfg_idx) +
- (unsigned long)ab->mem);
+ srng->u.dst_ring.tp_addr =
+ (__le32 *)(HAL_SHADOW_REG(shadow_cfg_idx) +
+ (unsigned long)ab->mem);
else
- srng->u.src_ring.hp_addr = (u32 *)(HAL_SHADOW_REG(shadow_cfg_idx) +
- (unsigned long)ab->mem);
+ srng->u.src_ring.hp_addr =
+ (__le32 *)(HAL_SHADOW_REG(shadow_cfg_idx) +
+ (unsigned long)ab->mem);
}
u32 ath12k_wifi7_hal_ce_get_desc_size(enum hal_ce_desc type)
base-commit: c2bcd89db970ee73cccfb9c619b7287d6da4bf88
--
2.43.0
^ permalink raw reply related
* Re: [PATCH wireless-next v2] wifi: cfg80211: init S1G properly when creating chandef
From: Johannes Berg @ 2026-03-11 10:56 UTC (permalink / raw)
To: Lachlan Hodges; +Cc: linux-wireless, arien.judge
In-Reply-To: <4dhrrbuvxdgve2doc7qvabzjancimtqpounngyrxspk4d4rbls@xnad5bwciz7c>
On Wed, 2026-03-11 at 21:21 +1100, Lachlan Hodges wrote:
> On Wed, Mar 11, 2026 at 10:55:46AM +0100, Johannes Berg wrote:
> > On Wed, 2026-03-11 at 17:43 +1100, Lachlan Hodges wrote:
> > > When creating a chandef, the initial width is determined by the
> > > chan_type argument leading to a default width of 20/20_NOHT/40 which
> > > does not make sense for S1G channels. Fix this by ensuring we default
> > > S1G chandefs to a width of 1MHz.
> > >
> > > Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
> > > ---
> > > v1 -> v2:
> > >
> > > - Remove the mac80211-based wording in the commit message and keep it
> > > simple.
> >
> > Thanks :)
> >
> > Now with more tea and all that, do we really want it to completely
> > ignore the width? Should that be documented? Almost feels like it should
> > WARN if you use it wrong, with an S1G channel but a regular width, and
> > mac80211 should be fixed?
>
> When you say "ignore the width"
Sorry, I meant the channel type (chantype argument).
> do you mean nothing checks it?
I meant for s1g the chantype argument would be ignored now, not that it
wasn't checked.
> If
> that's the case we probably need to add something within
> cfg80211_chandef_valid() to ensure if we have an S1G chan we don't
> have a non-S1G width i.e > 16MHz. That would fix mac80211 from
> giving it to the driver in the first place.
We don't have that? Seems like an oversight too, but I was thinking like
this (overall changes, not split to commits), since
cfg80211_chandef_create() really doesn't work for S1G since the chantype
is 20MHz-non-HT, 20MHz-HT, HT40+ or HT40-.
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index b0451f1c8e79..9a055dfb445a 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -1118,6 +1118,19 @@ ieee80211_ifcomb_check(const struct ieee80211_iface_combination *c, int n_comb)
return true;
}
+static void ieee80211_create_default_chandef(struct cfg80211_chan_def *chandef,
+ struct ieee80211_channel *chan)
+{
+ *chandef = (struct cfg80211_chan_def) {
+ .chan = chan,
+ .width = chan->band == NL80211_BAND_S1GHZ ?
+ NL80211_CHAN_WIDTH_1 :
+ NL80211_CHAN_WIDTH_20_NOHT,
+ .center_freq1 = chan->center_freq,
+ .freq1_offset = chan->freq_offset,
+ }
+}
+
int ieee80211_register_hw(struct ieee80211_hw *hw)
{
struct ieee80211_local *local = hw_to_local(hw);
@@ -1261,9 +1274,8 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
/* if none found then use the first anyway */
if (i == sband->n_channels)
i = 0;
- cfg80211_chandef_create(&dflt_chandef,
- &sband->channels[i],
- NL80211_CHAN_NO_HT);
+ ieee80211_create_default_chandef(&dflt_chandef,
+ &sband->channels[i]);
/* init channel we're on */
local->monitor_chanreq.oper = dflt_chandef;
if (local->emulate_chanctx) {
diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index d9d4e043bb39..4ae2f6ca0378 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -29,9 +29,10 @@ void cfg80211_chandef_create(struct cfg80211_chan_def *chandef,
*chandef = (struct cfg80211_chan_def) {
.chan = chan,
- .freq1_offset = chan->freq_offset,
};
+ WARN_ON(chan->band == NL80211_BAND_S1GHZ);
+
switch (chan_type) {
case NL80211_CHAN_NO_HT:
chandef->width = NL80211_CHAN_WIDTH_20_NOHT;
johannes
^ permalink raw reply related
* Re: [BUG] wifi: rtw88: Hard system freeze on RTL8821CE when power_save is enabled (LPS/ASPM conflict)
From: LB F @ 2026-03-11 11:00 UTC (permalink / raw)
To: Ping-Ke Shih; +Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <e6720993c8c14245981432cfa4ae902b@realtek.com>
Hi Ping-Ke,
Thank you for the incredibly fast turnaround and for providing the RFT
patch with the DMI quirk!
First, I want to mention that I am not an IT professional or a
programmer. I am just a regular Linux user who really wants to help
solve this problem. I am trying my best to verify everything
carefully, so please forgive me if my terminology or induction was
slightly off.
To answer your clarifying questions from the previous emails:
> Just want to clarify that these logs only appear in test 3, right?
> No these logs in test 1/2.
Yes, exactly. The `failed to send h2c command` errors only caused a
complete system freeze when no workarounds were active and the adapter
attempted to sleep (Test 3).
> I think this is your perspective and induction, right? Did you measure
> real hardware signals?
You are entirely correct. This is just my induction based solely on
the timing of the logs and system behavior. I do not have access to an
oscilloscope or any hardware diagnostic tools. Given this, I
completely agree that your approach of applying a platform-specific
quirk is the safest and best solution.
> Forgot to say. Could you share your full name for me as a reporter
> in commit message?
My full name is Oleksandr Havrylov. I would be honored to be included
as the reporter in the commit message.
### Recent Baseline Testing Before Your Patch
Before applying your patch today, we ran a few more controlled tests
to double-check our baseline. We verified that our local workaround
(`modprobe.d disable_aspm=y`) **does indeed keep the system completely
stable** and prevents the hard freeze, even when NetworkManager's
`wifi.powersave` is set to ON (default).
However, we noticed one interesting detail in the kernel logs: while
the system no longer freezes with `disable_aspm=y`, `dmesg` still
constantly logs `firmware failed to leave lps state` and `failed to
send h2c command` when the laptop is completely idle. It seems the
firmware still crashes during LPS, but because ASPM is disabled, the
PCIe bus ignores the crash and the system survives perfectly fine. I
just wanted to mention this for completeness!
### Testing Plan
I have **not** applied your RFT patch just yet. I wanted to make sure
our testing baseline was 100% clean and documented first.
I will compile your patch and perform rigorous testing this evening (I
am in the EET timezone, Ukraine). I will test it with the native
`power_save` fully enabled to ensure your patch successfully prevents
the hard lockups as intended.
I will stay in touch and reply back to this thread with a formal
`Tested-by` confirmation (and any logs if needed) as soon as my
testing is complete. Thank you again for all your help!
Best regards,
Oleksandr Havrylov
ср, 11 мар. 2026 г. в 04:22, Ping-Ke Shih <pkshih@realtek.com>:
>
> Ping-Ke Shih <pkshih@realtek.com> wrote:
> >
> > LB F <goainwo@gmail.com> wrote:
> > >
> > > Hi Ping-Ke,
> > >
> > > Thank you for the incredibly fast response and assistance!
> > >
> > > > Can you dig kernel log (by netconsole or ramoops) if something useful?
> > > > I'd like to know this is hardware level freeze or kernel can capture something
> > > wrong.
> > >
> > > I managed to pull a call trace from a historic journald log just
> > > before the system hung. The kernel gets trapped in an IRQ thread
> > > inside `rtw_pci_interrupt_threadfn`, calling up into `mac80211`
> > > `ieee80211_rx_list` before everything freezes. Here is the relevant
> > > snippet:
> > >
> > > ```text
> > > Call Trace:
> > > <IRQ>
> > > ? __alloc_skb+0x23a/0x2a0
> > > ? __alloc_skb+0x10c/0x2a0
> > > ? __pfx_irq_thread_fn+0x10/0x10
> > > [ ... truncated module list ... ]
> > > Tainted: G W I 6.19.6-2-cachyos #1 PREEMPT(full)
> > > Hardware name: HP HP Notebook/81F0, BIOS F.50 11/20/2020
> > > RIP: 0010:ieee80211_rx_list+0x1012/0x1020 [mac80211]
> > > CPU: 2 UID: 0 PID: 765 Comm: irq/56-rtw88_pc
> > > rtw_pci_interrupt_threadfn+0x239/0x310 [rtw88_pci]
> > > ```
> > >
> > > It behaves exactly like a PCIe bus deadlock or a hardware fault that
> > > eventually brings down the CPU handling the IRQ.
> >
> > I wonder if there is a malformed data, causing this trace and the leads
> > kernel freezes. If we can do validation on RX data before calling
> > ieee80211_rx_list(), maybe trace disappears and everything will be fine?
> > Even no need workaround.
> >
> > >
> > > > Are these totally needed to workaround the problem? Or disable_aspm is enough?
> > > > I'd list them in order of power consumption impact:
> > > > 1. disable_aspm=y
> > > > 2. disable_lps_deep=y
> > > > 3. disable WiFi power save
> > >
> > > To verify which parameters are strictly necessary, I performed
> > > isolated testing today. I ensured no other modprobe configs were
> > > active, rebuilt the initramfs, and manually enforced that
> > > `wifi.powersave` was active via `iw dev wlan0 set power_save on`
> > > during all tests (as the OS power management profiles were defaulting
> > > it to off, which initially masked the issue).
> > >
> > > I tested each workaround individually across multiple sleep/wake
> > > cycles and active usage:
> > >
> > > **Test 1 (ASPM Disabled, LPS Deep Enabled):**
> > > - Kernel parameters: `rtw88_pci disable_aspm=y` (and `rtw88_core
> > > disable_lps_deep=n`)
> > > - Result: Stable. No freezes were observed during usage or transitions
> > > into/out of S3 sleep while power saving was enforced.
> > >
> > > **Test 2 (ASPM Enabled, LPS Deep Disabled):**
> > > - Kernel parameters: `rtw88_core disable_lps_deep=y` (and `rtw88_pci
> > > disable_aspm=n`)
> > > - Result: Stable. No freezes were observed under the same forced power
> > > save conditions.
> > >
> > > **Conclusion:** It appears we do not need both workarounds
> > > simultaneously for this specific hardware. Using only `disable_aspm=y`
> > > seems to be sufficient to prevent the system freeze. Given your note
> > > about the power consumption impact ranking, this looks like the
> > > optimal path forward.
> >
> > Let's test my RFT patch to disable ASPM then.
> >
> > >
> > > > But what does 'deadlock' mean? As I know NAPI poll is scheduled by ISR,
> > > > and going to receive packets. The rx_no_aspm workaround is to forcely turn
> > > > off ASPM during this period.
> > >
> > > By "deadlock" I meant a hardware-level bus lockup. It seems the
> > > physical RTL8821CE chip itself crashes or hangs the system's PCIe bus
> > > when trying to negotiate waking up from ASPM L1 while simultaneously
> > > existing in `LPS_DEEP_MODE_LCLK`. The `rx_no_aspm` workaround in NAPI
> > > helps during active Rx decoding, but the laptop often freezes while
> > > completely idle, presumably when the AP sends a basic beacon, the chip
> > > attempts to leave LPS Deep + L1, and the hardware simply gives up and
> > > halts the system.
> >
> > I think this is your perspective and induction, right? Did you measure
> > real hardware signals?
> >
> > My point is that if this is a hardware-level bus lockup, let's apply
> > quirk. If some malformed data causing kernel hangs, I'd add sanity check
> > on RX data, but I don't actually know what we should check for now.
> >
> > >
> > > > We have not modified RTL8821CE for a long time, so I'd add workaround
> > > > to specific platform as mentioned above.
> > >
> > > Adding a DMI/platform quirk specifically for this laptop to disable
> > > ASPM would be wonderful and deeply appreciated. I agree it is safer
> > > than touching the global flags for hardware that is functioning
> > > correctly out in the wild.
> > >
> > > Here is the exact identifying information for my system:
> > >
> > > System Vendor: HP
> > > Product Name: HP Notebook
> > > SKU Number: P3S95EA#ACB
> > > Family: 103C_5335KV
> > > PCI ID: 10ec:c821
> > > Subsystem ID: 103c:831a
> > >
> > > I am completely ready to test any patch or quirk you send my way.
> > > Thank you so much for your time and helping track this down!
> >
> > I sent a RFT [1] for test. Please check if it works on your HP notebook.
> > If you check rtw88 log, you can see I added similar patch 5 years ago,
> > and replaced by preferred the change of "rtwpci->rx_no_aspm", which I
> > think it can only resolve problem on partial notebooks though....
> >
> > [1]
> > https://lore.kernel.org/linux-wireless/20260311020816.7065-1-pkshih@realtek.
> > com/T/#u
>
> Forgot to say. Could you share your full name for me as a reporter
> in commit message?
>
>
^ permalink raw reply
* Re: [PATCH wireless-next v2] wifi: cfg80211: init S1G properly when creating chandef
From: Johannes Berg @ 2026-03-11 11:07 UTC (permalink / raw)
To: Lachlan Hodges; +Cc: linux-wireless, arien.judge
In-Reply-To: <b725c0be05df1a9595c177aada4cc148bf555448.camel@sipsolutions.net>
On Wed, 2026-03-11 at 11:56 +0100, Johannes Berg wrote:
>
> +++ b/net/wireless/chan.c
> @@ -29,9 +29,10 @@ void cfg80211_chandef_create(struct cfg80211_chan_def *chandef,
>
> *chandef = (struct cfg80211_chan_def) {
> .chan = chan,
> - .freq1_offset = chan->freq_offset,
> };
>
> + WARN_ON(chan->band == NL80211_BAND_S1GHZ);
>
Hm, no, I guess that really should only allow 2.4, 5 and 6 GHz.
johannes
^ permalink raw reply
* Re: [PATCH wireless-next v2] wifi: cfg80211: init S1G properly when creating chandef
From: Lachlan Hodges @ 2026-03-11 11:48 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, arien.judge
In-Reply-To: <b725c0be05df1a9595c177aada4cc148bf555448.camel@sipsolutions.net>
On Wed, Mar 11, 2026 at 11:56:37AM +0100, Johannes Berg wrote:
> On Wed, 2026-03-11 at 21:21 +1100, Lachlan Hodges wrote:
> > On Wed, Mar 11, 2026 at 10:55:46AM +0100, Johannes Berg wrote:
> > > On Wed, 2026-03-11 at 17:43 +1100, Lachlan Hodges wrote:
> > > > When creating a chandef, the initial width is determined by the
> > > > chan_type argument leading to a default width of 20/20_NOHT/40 which
> > > > does not make sense for S1G channels. Fix this by ensuring we default
> > > > S1G chandefs to a width of 1MHz.
> > > >
> > > > Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
> > > > ---
> > > > v1 -> v2:
> > > >
> > > > - Remove the mac80211-based wording in the commit message and keep it
> > > > simple.
> > >
> > > Thanks :)
> > >
> > > Now with more tea and all that, do we really want it to completely
> > > ignore the width? Should that be documented? Almost feels like it should
> > > WARN if you use it wrong, with an S1G channel but a regular width, and
> > > mac80211 should be fixed?
> >
> > When you say "ignore the width"
>
> Sorry, I meant the channel type (chantype argument).
>
> > do you mean nothing checks it?
>
> I meant for s1g the chantype argument would be ignored now, not that it
> wasn't checked.
>
> > If
> > that's the case we probably need to add something within
> > cfg80211_chandef_valid() to ensure if we have an S1G chan we don't
> > have a non-S1G width i.e > 16MHz. That would fix mac80211 from
> > giving it to the driver in the first place.
>
> We don't have that? Seems like an oversight too,
Yea we have one way not the other, I will send a fix for that at
some point.
> but I was thinking like
> this (overall changes, not split to commits), since
> cfg80211_chandef_create() really doesn't work for S1G since the chantype
> is 20MHz-non-HT, 20MHz-HT, HT40+ or HT40-.
>
>
> diff --git a/net/mac80211/main.c b/net/mac80211/main.c
> index b0451f1c8e79..9a055dfb445a 100644
> --- a/net/mac80211/main.c
> +++ b/net/mac80211/main.c
> @@ -1118,6 +1118,19 @@ ieee80211_ifcomb_check(const struct ieee80211_iface_combination *c, int n_comb)
> return true;
> }
>
> +static void ieee80211_create_default_chandef(struct cfg80211_chan_def *chandef,
> + struct ieee80211_channel *chan)
> +{
> + *chandef = (struct cfg80211_chan_def) {
> + .chan = chan,
> + .width = chan->band == NL80211_BAND_S1GHZ ?
> + NL80211_CHAN_WIDTH_1 :
> + NL80211_CHAN_WIDTH_20_NOHT,
> + .center_freq1 = chan->center_freq,
> + .freq1_offset = chan->freq_offset,
> + }
> +}
> +
> int ieee80211_register_hw(struct ieee80211_hw *hw)
> {
> struct ieee80211_local *local = hw_to_local(hw);
> @@ -1261,9 +1274,8 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
> /* if none found then use the first anyway */
> if (i == sband->n_channels)
> i = 0;
> - cfg80211_chandef_create(&dflt_chandef,
> - &sband->channels[i],
> - NL80211_CHAN_NO_HT);
> + ieee80211_create_default_chandef(&dflt_chandef,
> + &sband->channels[i]);
> /* init channel we're on */
> local->monitor_chanreq.oper = dflt_chandef;
> if (local->emulate_chanctx) {
> diff --git a/net/wireless/chan.c b/net/wireless/chan.c
> index d9d4e043bb39..4ae2f6ca0378 100644
> --- a/net/wireless/chan.c
> +++ b/net/wireless/chan.c
> @@ -29,9 +29,10 @@ void cfg80211_chandef_create(struct cfg80211_chan_def *chandef,
>
> *chandef = (struct cfg80211_chan_def) {
> .chan = chan,
> - .freq1_offset = chan->freq_offset,
> };
>
> + WARN_ON(chan->band == NL80211_BAND_S1GHZ);
> +
> switch (chan_type) {
> case NL80211_CHAN_NO_HT:
> chandef->width = NL80211_CHAN_WIDTH_20_NOHT;
>
Initially reading this I was a bit concerned because it means any
path calling cfg80211_chandef_create() wouldn't work for S1G; But it's
actually only a couple of places now that call it and - being forward
looking - for example with channel switching we would probably have
an S1G specific path similar to processing a S1G connection anyway. No
important paths (will confirm this) call this function anyway they
seem to build the chandef locally.
I'll do some testing, if it seems OK will send a new patchset.
lachlan
^ permalink raw reply
* Re: [PATCH wireless-next v2] wifi: cfg80211: init S1G properly when creating chandef
From: Johannes Berg @ 2026-03-11 11:55 UTC (permalink / raw)
To: Lachlan Hodges; +Cc: linux-wireless, arien.judge
In-Reply-To: <6eitsqhsmmhwgd3cobhpdhhzn5m5siw4ser53g3ilvd7kdhy2u@rkilpa5ek26y>
On Wed, 2026-03-11 at 22:48 +1100, Lachlan Hodges wrote:
> Initially reading this I was a bit concerned because it means any
> path calling cfg80211_chandef_create() wouldn't work for S1G
Yes, I agree, but I tend to think it fundamentally doesn't work for S1G
anyway the way it's defined with 20 or 40 MHz width. Now you had
somewhat made it work by just ignoring the chantype, but that seems
confusing too, at least in the long run.
> But it's
> actually only a couple of places now that call it and - being forward
> looking - for example with channel switching we would probably have
> an S1G specific path similar to processing a S1G connection anyway.
Right, for mac80211: I don't know if you will have IBSS on S1G, if not
that's right out, TDLS might be an issue, mesh support is probably not
there, HT/HE operation elements (util.c) are irrelevant, which basically
leaves the one I patched, and CSA that you mentioned.
For cfg80211 it's a similar story, but maybe we need to look - but
anything that can hit 60 GHz today would already be invalid too...
> No
> important paths (will confirm this) call this function anyway they
> seem to build the chandef locally.
There are a lot of places calling it in drivers so I don't think we can
remove the function, but all existing drivers without S1G anyway. In
mac80211 there might be paths, but then with the warning I guess syzbot
can find them ;)
johannes
^ permalink raw reply
* Re: [PATCH 36/61] arch/sh: Prefer IS_ERR_OR_NULL over manual NULL check
From: Geert Uytterhoeven @ 2026-03-11 13:15 UTC (permalink / raw)
To: Philipp Hahn
Cc: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, Yoshinori Sato, Rich Felker,
John Paul Adrian Glaubitz
In-Reply-To: <20260310-b4-is_err_or_null-v1-36-bd63b656022d@avm.de>
On Tue, 10 Mar 2026 at 12:56, Philipp Hahn <phahn-oss@avm.de> wrote:
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Yoshinori Sato <ysato@users.sourceforge.jp>
> To: Rich Felker <dalias@libc.org>
> To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
> Cc: linux-sh@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 15/61] trace: Prefer IS_ERR_OR_NULL over manual NULL check
From: Steven Rostedt @ 2026-03-11 14:03 UTC (permalink / raw)
To: Masami Hiramatsu (Google)
Cc: Philipp Hahn, amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel,
dri-devel, gfs2, intel-gfx, intel-wired-lan, iommu, kvm,
linux-arm-kernel, linux-block, linux-bluetooth, linux-btrfs,
linux-cifs, linux-clk, linux-erofs, linux-ext4, linux-fsdevel,
linux-gpio, linux-hyperv, linux-input, linux-kernel, linux-leds,
linux-media, linux-mips, linux-mm, linux-modules, linux-mtd,
linux-nfs, linux-omap, linux-phy, linux-pm, linux-rockchip,
linux-s390, linux-scsi, linux-sctp, linux-security-module,
linux-sh, linux-sound, linux-stm32, linux-trace-kernel, linux-usb,
linux-wireless, netdev, ntfs3, samba-technical, sched-ext,
target-devel, tipc-discussion, v9fs, Mathieu Desnoyers
In-Reply-To: <20260311141332.b611237d36b61b2409e66cb3@kernel.org>
On Wed, 11 Mar 2026 14:13:32 +0900
Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
> Hmm, now IS_ERR_OR_NULL() is an inline function, so it is safe.
> But if you want to use IS_ERR_OR_NULL() here, it will be better something like
>
> node = rhashtable_walk_next(&iter);
> while (!IS_ERR_OR_NULL(node)) {
> fprobe_remove_node_in_module(mod, node, &alist);
> node = rhashtable_walk_next(&iter);
> }
But now you need to have a duplicate code in order to acquire "node"
I think the patch just makes the code worse.
-- Steve
^ permalink raw reply
* Re: [PATCH 15/61] trace: Prefer IS_ERR_OR_NULL over manual NULL check
From: Geert Uytterhoeven @ 2026-03-11 14:06 UTC (permalink / raw)
To: Steven Rostedt
Cc: Masami Hiramatsu (Google), Philipp Hahn, amd-gfx, apparmor, bpf,
ceph-devel, cocci, dm-devel, dri-devel, gfs2, intel-gfx,
intel-wired-lan, iommu, kvm, linux-arm-kernel, linux-block,
linux-bluetooth, linux-btrfs, linux-cifs, linux-clk, linux-erofs,
linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv, linux-input,
linux-kernel, linux-leds, linux-media, linux-mips, linux-mm,
linux-modules, linux-mtd, linux-nfs, linux-omap, linux-phy,
linux-pm, linux-rockchip, linux-s390, linux-scsi, linux-sctp,
linux-security-module, linux-sh, linux-sound, linux-stm32,
linux-trace-kernel, linux-usb, linux-wireless, netdev, ntfs3,
samba-technical, sched-ext, target-devel, tipc-discussion, v9fs,
Mathieu Desnoyers
In-Reply-To: <20260311100332.6a2ce4b1@gandalf.local.home>
Hi Steven,
On Wed, 11 Mar 2026 at 15:03, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Wed, 11 Mar 2026 14:13:32 +0900
> Masami Hiramatsu (Google) <mhiramat@kernel.org> wrote:
>
> > Hmm, now IS_ERR_OR_NULL() is an inline function, so it is safe.
> > But if you want to use IS_ERR_OR_NULL() here, it will be better something like
> >
> > node = rhashtable_walk_next(&iter);
> > while (!IS_ERR_OR_NULL(node)) {
> > fprobe_remove_node_in_module(mod, node, &alist);
> > node = rhashtable_walk_next(&iter);
> > }
>
> But now you need to have a duplicate code in order to acquire "node"
>
> I think the patch just makes the code worse.
Obviously we need a new for_each_*() helper hiding all the gory internals?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 01/61] Coccinelle: Prefer IS_ERR_OR_NULL over manual NULL check
From: Markus Elfring @ 2026-03-11 15:12 UTC (permalink / raw)
To: Philipp Hahn, cocci, Julia Lawall, Nicolas Palix
Cc: amd-gfx, apparmor, bpf, ceph-devel, dm-devel, dri-devel, gfs2,
intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-leds, linux-media, linux-mips, linux-mm,
linux-modules, linux-mtd, linux-nfs, linux-omap, linux-phy,
linux-pm, linux-rockchip, linux-s390, linux-scsi, linux-sctp,
linux-security-module, linux-sh, linux-sound, linux-stm32,
linux-trace-kernel, linux-usb, linux-wireless, netdev, ntfs3,
samba-technical, sched-ext, target-devel, tipc-discussion, v9fs,
LKML
In-Reply-To: <20260310-b4-is_err_or_null-v1-1-bd63b656022d@avm.de>
…
> +// Confidence: High
Some contributors presented discerning comments for this change approach.
Thus I became also curious how much they can eventually be taken better into account
by the means of the semantic patch language (Coccinelle software).
…
+@p1 depends on patch@
+expression E;
+@@
+(
> +- E != NULL && !IS_ERR(E)
> ++ !IS_ERR_OR_NULL(E)
> +|
> +- E == NULL || IS_ERR(E)
> ++ IS_ERR_OR_NULL(E)
> +|
> +- !IS_ERR(E) && E != NULL
> ++ !IS_ERR_OR_NULL(E)
> +|
> +- IS_ERR(E) || E == NULL
> ++ IS_ERR_OR_NULL(E)
> +)
Several detected expressions should refer to return values from function calls.
https://en.wikipedia.org/wiki/Return_statement
* Do any development challenges hinder still the determination of corresponding
failure predicates?
* How will interests evolve to improve data processing any further for such
use cases?
Regards,
Markus
^ permalink raw reply
* Re: [RFT rtw-next] wifi: rtw88: add quirks to disable PCI ASPM for HP P3S95EA#ACB
From: LB F @ 2026-03-11 15:19 UTC (permalink / raw)
To: Ping-Ke Shih; +Cc: linux-wireless
In-Reply-To: <20260311020816.7065-1-pkshih@realtek.com>
Hi Ping-Ke,
I successfully applied your patch out-of-tree and performed rigorous
testing on the host machine.
I can officially confirm that the patch works flawlessly. The DMI
quirk triggered correctly and successfully prevented the
hardware-level PCIe bus lockups on my HP P3S95EA#ACB.
Testing Environment & Methodology:
- Kernel: CachyOS Linux 6.19.6-2-cachyos x86_64
- Toolchain: Clang/LLVM 21.1.8 (`make CC=clang LLVM=1 modules`)
- Extraction: We fetched the strict
`drivers/net/wireless/realtek/rtw88` sub-tree out of the
torvalds/linux `v6.19` tree utilizing `git sparse-checkout` to cleanly
apply the patch without having to compile the entire 2.5GB+ kernel.
- The resulting `.ko` object files were compressed to `.zst` and
installed successfully over the generic CachyOS system driver objects.
Verification Conditions:
- Removed ALL local workarounds. `disable_aspm=Y` is no longer forced
via `/etc/modprobe.d/` overrides.
- Power saving remains natively ON `wifi.powersave = 3` (managed by
NetworkManager).
- Left the laptop in multiple 5-10 minute complete idle states to
enforce sleep modes.
Post-Boot Log Analysis & Potential Improvement Proposition:
The system remained 100% stable without any kernel panics or UI freezes.
However, I continuously monitored the `dmesg` ring buffer and noticed
an intriguing behavior. While the laptop sits completely idle
(NetworkManager connected, but no active traffic), the `rtw88` driver
starts flooded the logs with thousands of firmware errors:
[ 1084.746485] rtw88_8821ce 0000:13:00.0: firmware failed to leave lps state
[ 1084.749662] rtw88_8821ce 0000:13:00.0: failed to send h2c command
[ 1084.752895] rtw88_8821ce 0000:13:00.0: failed to send h2c command
If my understanding of this architecture is correct, previously, when
ASPM wasn't disabled, this exact failure of the adapter firmare inside
`LPS_DEEP_MODE_LCLK` would violently lock up the PCIe bus and crash
the host. Now, thanks to your DMI ASPM quirk at the `rtw88_pci` level,
the host PCIe controller doesn't enter `L1` and is perfectly shielded
from the adapter locking itself up! The OS handles the timeouts
gracefully and driver recovery prevents a hard freeze.
A question for your consideration: Given the immense volume of these
`h2c` timeout errors (and the underlying firmware's fundamental
inability to cleanly enter/exit its own sleep states without L1
participation on this HP model), do you think it would be beneficial
to *also* dynamically disable LPS Deep sleep when this specific ASPM
quirk is triggered?
For example, dynamically forcing `rtwdev->lps_conf.deep_mode =
LPS_DEEP_MODE_NONE` when the DMI ASPM flag is active, strictly to
prevent the firmware from attempting a sleep cycle that is doomed to
fail and polluting the queues and logs? Perhaps this might also save
microscopic CPU interrupts from continuous H2C polling timeouts?
If you believe that simply letting the driver recover and tolerating
the error spam in `dmesg` is the preferred/safer upstream approach, I
am perfectly happy. The patch functions as advertised and system
stability is unequivocally restored!
Thank you immensely for your rapid debugging and definitive patch for
this long-standing issue and for bringing stability to this model.
Tested-by: Oleksandr Havrylov <goainwo@gmail.com>
*(Note: I was a bit unsure which of the two active mailing list
threads was the most appropriate place for this final report — the
original bug discussion or the new RFT patch submission thread — so I
replied to both just to ensure it is correctly attached to the patch.
Apologies for the duplicate email!)*
Best regards,
Oleksandr Havrylov
ср, 11 мар. 2026 г. в 04:08, Ping-Ke Shih <pkshih@realtek.com>:
>
> On an HP laptop (P3S95EA#ACB) equipped with a Realtek RTL8821CE 802.11ac
> PCIe adapter (PCI ID: 10ec:c821), the system experiences a hard lockup
> (complete freeze of the UI and kernel, sysrq doesn't work, requires
> holding the power button) when the WiFi adapter enters the power
> saving state.
>
> Add a quirk to disable ASPM.
>
> Reported-by: LB F <goainwo@gmail.com>
> Closes: https://lore.kernel.org/linux-wireless/CALdGYqSQ1Ko2TTBhUizMu_FvLMUAuQfFrVwS10n_C-LSQJQQkQ@mail.gmail.com/
> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
> ---
> drivers/net/wireless/realtek/rtw88/pci.c | 30 ++++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/pci.c b/drivers/net/wireless/realtek/rtw88/pci.c
> index ec0a45bfb670..0b60a0ce96a1 100644
> --- a/drivers/net/wireless/realtek/rtw88/pci.c
> +++ b/drivers/net/wireless/realtek/rtw88/pci.c
> @@ -2,6 +2,7 @@
> /* Copyright(c) 2018-2019 Realtek Corporation
> */
>
> +#include <linux/dmi.h>
> #include <linux/module.h>
> #include <linux/pci.h>
> #include "main.h"
> @@ -1744,6 +1745,34 @@ const struct pci_error_handlers rtw_pci_err_handler = {
> };
> EXPORT_SYMBOL(rtw_pci_err_handler);
>
> +enum rtw88_quirk_dis_pci_caps {
> + QUIRK_DIS_PCI_CAP_ASPM,
> +};
> +
> +static int disable_pci_caps(const struct dmi_system_id *dmi)
> +{
> + uintptr_t dis_caps = (uintptr_t)dmi->driver_data;
> +
> + if (dis_caps & BIT(QUIRK_DIS_PCI_CAP_ASPM))
> + rtw_pci_disable_aspm = true;
> +
> + return 1;
> +}
> +
> +static const struct dmi_system_id rtw88_pci_quirks[] = {
> + {
> + .callback = disable_pci_caps,
> + .ident = "HP Notebook - P3S95EA#ACB",
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "HP"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "HP Notebook"),
> + DMI_MATCH(DMI_PRODUCT_SKU, "P3S95EA#ACB"),
> + },
> + .driver_data = (void *)BIT(QUIRK_DIS_PCI_CAP_ASPM),
> + },
> + {}
> +};
> +
> int rtw_pci_probe(struct pci_dev *pdev,
> const struct pci_device_id *id)
> {
> @@ -1808,6 +1837,7 @@ int rtw_pci_probe(struct pci_dev *pdev,
> bridge && bridge->vendor == PCI_VENDOR_ID_INTEL)
> rtwpci->rx_no_aspm = true;
>
> + dmi_check_system(rtw88_pci_quirks);
> rtw_pci_phy_cfg(rtwdev);
>
> ret = rtw_register_hw(rtwdev, hw);
> --
> 2.25.1
>
^ permalink raw reply
* Re: [BUG] wifi: rtw88: Hard system freeze on RTL8821CE when power_save is enabled (LPS/ASPM conflict)
From: LB F @ 2026-03-11 15:22 UTC (permalink / raw)
To: Ping-Ke Shih; +Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CALdGYqQn8GGXXjZTsL+a5Mfdmw5HRYB2Jyvqq5M5SUwxK9yd_g@mail.gmail.com>
Hi Ping-Ke,
I successfully applied your patch out-of-tree and performed rigorous
testing on the host machine.
I can officially confirm that the patch works flawlessly. The DMI
quirk triggered correctly and successfully prevented the
hardware-level PCIe bus lockups on my HP P3S95EA#ACB.
Testing Environment & Methodology:
- Kernel: CachyOS Linux 6.19.6-2-cachyos x86_64
- Toolchain: Clang/LLVM 21.1.8 (`make CC=clang LLVM=1 modules`)
- Extraction: We fetched the strict
`drivers/net/wireless/realtek/rtw88` sub-tree out of the
torvalds/linux `v6.19` tree utilizing `git sparse-checkout` to cleanly
apply the patch without having to compile the entire 2.5GB+ kernel.
- The resulting `.ko` object files were compressed to `.zst` and
installed successfully over the generic CachyOS system driver objects.
Verification Conditions:
- Removed ALL local workarounds. `disable_aspm=Y` is no longer forced
via `/etc/modprobe.d/` overrides.
- Power saving remains natively ON `wifi.powersave = 3` (managed by
NetworkManager).
- Left the laptop in multiple 5-10 minute complete idle states to
enforce sleep modes.
Post-Boot Log Analysis & Potential Improvement Proposition:
The system remained 100% stable without any kernel panics or UI freezes.
However, I continuously monitored the `dmesg` ring buffer and noticed
an intriguing behavior. While the laptop sits completely idle
(NetworkManager connected, but no active traffic), the `rtw88` driver
starts flooded the logs with thousands of firmware errors:
[ 1084.746485] rtw88_8821ce 0000:13:00.0: firmware failed to leave lps state
[ 1084.749662] rtw88_8821ce 0000:13:00.0: failed to send h2c command
[ 1084.752895] rtw88_8821ce 0000:13:00.0: failed to send h2c command
If my understanding of this architecture is correct, previously, when
ASPM wasn't disabled, this exact failure of the adapter firmare inside
`LPS_DEEP_MODE_LCLK` would violently lock up the PCIe bus and crash
the host. Now, thanks to your DMI ASPM quirk at the `rtw88_pci` level,
the host PCIe controller doesn't enter `L1` and is perfectly shielded
from the adapter locking itself up! The OS handles the timeouts
gracefully and driver recovery prevents a hard freeze.
A question for your consideration: Given the immense volume of these
`h2c` timeout errors (and the underlying firmware's fundamental
inability to cleanly enter/exit its own sleep states without L1
participation on this HP model), do you think it would be beneficial
to *also* dynamically disable LPS Deep sleep when this specific ASPM
quirk is triggered?
For example, dynamically forcing `rtwdev->lps_conf.deep_mode =
LPS_DEEP_MODE_NONE` when the DMI ASPM flag is active, strictly to
prevent the firmware from attempting a sleep cycle that is doomed to
fail and polluting the queues and logs? Perhaps this might also save
microscopic CPU interrupts from continuous H2C polling timeouts?
If you believe that simply letting the driver recover and tolerating
the error spam in `dmesg` is the preferred/safer upstream approach, I
am perfectly happy. The patch functions as advertised and system
stability is unequivocally restored!
Thank you immensely for your rapid debugging and definitive patch for
this long-standing issue and for bringing stability to this model.
Tested-by: Oleksandr Havrylov <goainwo@gmail.com>
*(Note: I was a bit unsure which of the two active mailing list
threads was the most appropriate place for this final report — the
original bug discussion or the new RFT patch submission thread — so I
replied to both just to ensure it is correctly attached to the patch.
Apologies for the duplicate email!)*
Best regards,
Oleksandr Havrylov
ср, 11 мар. 2026 г. в 13:00, LB F <goainwo@gmail.com>:
>
> Hi Ping-Ke,
>
> Thank you for the incredibly fast turnaround and for providing the RFT
> patch with the DMI quirk!
>
> First, I want to mention that I am not an IT professional or a
> programmer. I am just a regular Linux user who really wants to help
> solve this problem. I am trying my best to verify everything
> carefully, so please forgive me if my terminology or induction was
> slightly off.
>
> To answer your clarifying questions from the previous emails:
>
> > Just want to clarify that these logs only appear in test 3, right?
> > No these logs in test 1/2.
>
> Yes, exactly. The `failed to send h2c command` errors only caused a
> complete system freeze when no workarounds were active and the adapter
> attempted to sleep (Test 3).
>
> > I think this is your perspective and induction, right? Did you measure
> > real hardware signals?
>
> You are entirely correct. This is just my induction based solely on
> the timing of the logs and system behavior. I do not have access to an
> oscilloscope or any hardware diagnostic tools. Given this, I
> completely agree that your approach of applying a platform-specific
> quirk is the safest and best solution.
>
> > Forgot to say. Could you share your full name for me as a reporter
> > in commit message?
>
> My full name is Oleksandr Havrylov. I would be honored to be included
> as the reporter in the commit message.
>
> ### Recent Baseline Testing Before Your Patch
>
> Before applying your patch today, we ran a few more controlled tests
> to double-check our baseline. We verified that our local workaround
> (`modprobe.d disable_aspm=y`) **does indeed keep the system completely
> stable** and prevents the hard freeze, even when NetworkManager's
> `wifi.powersave` is set to ON (default).
>
> However, we noticed one interesting detail in the kernel logs: while
> the system no longer freezes with `disable_aspm=y`, `dmesg` still
> constantly logs `firmware failed to leave lps state` and `failed to
> send h2c command` when the laptop is completely idle. It seems the
> firmware still crashes during LPS, but because ASPM is disabled, the
> PCIe bus ignores the crash and the system survives perfectly fine. I
> just wanted to mention this for completeness!
>
> ### Testing Plan
>
> I have **not** applied your RFT patch just yet. I wanted to make sure
> our testing baseline was 100% clean and documented first.
>
> I will compile your patch and perform rigorous testing this evening (I
> am in the EET timezone, Ukraine). I will test it with the native
> `power_save` fully enabled to ensure your patch successfully prevents
> the hard lockups as intended.
>
> I will stay in touch and reply back to this thread with a formal
> `Tested-by` confirmation (and any logs if needed) as soon as my
> testing is complete. Thank you again for all your help!
>
> Best regards,
> Oleksandr Havrylov
>
> ср, 11 мар. 2026 г. в 04:22, Ping-Ke Shih <pkshih@realtek.com>:
> >
> > Ping-Ke Shih <pkshih@realtek.com> wrote:
> > >
> > > LB F <goainwo@gmail.com> wrote:
> > > >
> > > > Hi Ping-Ke,
> > > >
> > > > Thank you for the incredibly fast response and assistance!
> > > >
> > > > > Can you dig kernel log (by netconsole or ramoops) if something useful?
> > > > > I'd like to know this is hardware level freeze or kernel can capture something
> > > > wrong.
> > > >
> > > > I managed to pull a call trace from a historic journald log just
> > > > before the system hung. The kernel gets trapped in an IRQ thread
> > > > inside `rtw_pci_interrupt_threadfn`, calling up into `mac80211`
> > > > `ieee80211_rx_list` before everything freezes. Here is the relevant
> > > > snippet:
> > > >
> > > > ```text
> > > > Call Trace:
> > > > <IRQ>
> > > > ? __alloc_skb+0x23a/0x2a0
> > > > ? __alloc_skb+0x10c/0x2a0
> > > > ? __pfx_irq_thread_fn+0x10/0x10
> > > > [ ... truncated module list ... ]
> > > > Tainted: G W I 6.19.6-2-cachyos #1 PREEMPT(full)
> > > > Hardware name: HP HP Notebook/81F0, BIOS F.50 11/20/2020
> > > > RIP: 0010:ieee80211_rx_list+0x1012/0x1020 [mac80211]
> > > > CPU: 2 UID: 0 PID: 765 Comm: irq/56-rtw88_pc
> > > > rtw_pci_interrupt_threadfn+0x239/0x310 [rtw88_pci]
> > > > ```
> > > >
> > > > It behaves exactly like a PCIe bus deadlock or a hardware fault that
> > > > eventually brings down the CPU handling the IRQ.
> > >
> > > I wonder if there is a malformed data, causing this trace and the leads
> > > kernel freezes. If we can do validation on RX data before calling
> > > ieee80211_rx_list(), maybe trace disappears and everything will be fine?
> > > Even no need workaround.
> > >
> > > >
> > > > > Are these totally needed to workaround the problem? Or disable_aspm is enough?
> > > > > I'd list them in order of power consumption impact:
> > > > > 1. disable_aspm=y
> > > > > 2. disable_lps_deep=y
> > > > > 3. disable WiFi power save
> > > >
> > > > To verify which parameters are strictly necessary, I performed
> > > > isolated testing today. I ensured no other modprobe configs were
> > > > active, rebuilt the initramfs, and manually enforced that
> > > > `wifi.powersave` was active via `iw dev wlan0 set power_save on`
> > > > during all tests (as the OS power management profiles were defaulting
> > > > it to off, which initially masked the issue).
> > > >
> > > > I tested each workaround individually across multiple sleep/wake
> > > > cycles and active usage:
> > > >
> > > > **Test 1 (ASPM Disabled, LPS Deep Enabled):**
> > > > - Kernel parameters: `rtw88_pci disable_aspm=y` (and `rtw88_core
> > > > disable_lps_deep=n`)
> > > > - Result: Stable. No freezes were observed during usage or transitions
> > > > into/out of S3 sleep while power saving was enforced.
> > > >
> > > > **Test 2 (ASPM Enabled, LPS Deep Disabled):**
> > > > - Kernel parameters: `rtw88_core disable_lps_deep=y` (and `rtw88_pci
> > > > disable_aspm=n`)
> > > > - Result: Stable. No freezes were observed under the same forced power
> > > > save conditions.
> > > >
> > > > **Conclusion:** It appears we do not need both workarounds
> > > > simultaneously for this specific hardware. Using only `disable_aspm=y`
> > > > seems to be sufficient to prevent the system freeze. Given your note
> > > > about the power consumption impact ranking, this looks like the
> > > > optimal path forward.
> > >
> > > Let's test my RFT patch to disable ASPM then.
> > >
> > > >
> > > > > But what does 'deadlock' mean? As I know NAPI poll is scheduled by ISR,
> > > > > and going to receive packets. The rx_no_aspm workaround is to forcely turn
> > > > > off ASPM during this period.
> > > >
> > > > By "deadlock" I meant a hardware-level bus lockup. It seems the
> > > > physical RTL8821CE chip itself crashes or hangs the system's PCIe bus
> > > > when trying to negotiate waking up from ASPM L1 while simultaneously
> > > > existing in `LPS_DEEP_MODE_LCLK`. The `rx_no_aspm` workaround in NAPI
> > > > helps during active Rx decoding, but the laptop often freezes while
> > > > completely idle, presumably when the AP sends a basic beacon, the chip
> > > > attempts to leave LPS Deep + L1, and the hardware simply gives up and
> > > > halts the system.
> > >
> > > I think this is your perspective and induction, right? Did you measure
> > > real hardware signals?
> > >
> > > My point is that if this is a hardware-level bus lockup, let's apply
> > > quirk. If some malformed data causing kernel hangs, I'd add sanity check
> > > on RX data, but I don't actually know what we should check for now.
> > >
> > > >
> > > > > We have not modified RTL8821CE for a long time, so I'd add workaround
> > > > > to specific platform as mentioned above.
> > > >
> > > > Adding a DMI/platform quirk specifically for this laptop to disable
> > > > ASPM would be wonderful and deeply appreciated. I agree it is safer
> > > > than touching the global flags for hardware that is functioning
> > > > correctly out in the wild.
> > > >
> > > > Here is the exact identifying information for my system:
> > > >
> > > > System Vendor: HP
> > > > Product Name: HP Notebook
> > > > SKU Number: P3S95EA#ACB
> > > > Family: 103C_5335KV
> > > > PCI ID: 10ec:c821
> > > > Subsystem ID: 103c:831a
> > > >
> > > > I am completely ready to test any patch or quirk you send my way.
> > > > Thank you so much for your time and helping track this down!
> > >
> > > I sent a RFT [1] for test. Please check if it works on your HP notebook.
> > > If you check rtw88 log, you can see I added similar patch 5 years ago,
> > > and replaced by preferred the change of "rtwpci->rx_no_aspm", which I
> > > think it can only resolve problem on partial notebooks though....
> > >
> > > [1]
> > > https://lore.kernel.org/linux-wireless/20260311020816.7065-1-pkshih@realtek.
> > > com/T/#u
> >
> > Forgot to say. Could you share your full name for me as a reporter
> > in commit message?
> >
> >
^ permalink raw reply
* Re: [PATCH 2/2] wifi: mt76: mt792x: fix mt7925u USB WFSYS reset handling
From: Nick @ 2026-03-11 16:14 UTC (permalink / raw)
To: Sean Wang
Cc: nbd, lorenzo.bianconi, linux-wireless, linux-mediatek, Sean Wang,
stable, Satadru Pramanik
In-Reply-To: <20260311002825.15502-2-sean.wang@kernel.org>
> From: Sean Wang <sean.wang@mediatek.com>
>
> mt7925u uses different reset/status registers from mt7921u. Reusing the
> mt7921u register set causes the WFSYS reset to fail.
>
> Add a chip-specific descriptor in mt792xu_wfsys_reset() to select the
> correct registers and fix mt7925u failing to initialize after a warm
> reboot.
>
> Fixes: d28e1a48952e ("wifi: mt76: mt792x: introduce mt792x-usb module")
> Cc: stable@vger.kernel.org
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> ---
> drivers/net/wireless/mediatek/mt76/mt792x_regs.h | 4 ++++
> drivers/net/wireless/mediatek/mt76/mt792x_usb.c | 13 ++++++++++++-
> 2 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_regs.h b/drivers/net/wireless/mediatek/mt76/mt792x_regs.h
> index 7ddde9286861..d2a8b2b0df32 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt792x_regs.h
> +++ b/drivers/net/wireless/mediatek/mt76/mt792x_regs.h
> @@ -392,6 +392,10 @@
> #define MT_CBTOP_RGU_WF_SUBSYS_RST MT_CBTOP_RGU(0x600)
> #define MT_CBTOP_RGU_WF_SUBSYS_RST_WF_WHOLE_PATH BIT(0)
>
> +#define MT7925_CBTOP_RGU_WF_SUBSYS_RST 0x70028600
> +#define MT7925_WFSYS_INIT_DONE_ADDR 0x184c1604
> +#define MT7925_WFSYS_INIT_DONE 0x00001d1e
> +
> #define MT_HW_BOUND 0x70010020
> #define MT_HW_CHIPID 0x70010200
> #define MT_HW_REV 0x70010204
> diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_usb.c b/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
> index a92e872226cf..47827d1c5ccb 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
> @@ -224,6 +224,15 @@ static const struct mt792xu_wfsys_desc mt7921_wfsys_desc = {
> .need_status_sel = true,
> };
>
> +static const struct mt792xu_wfsys_desc mt7925_wfsys_desc = {
> + .rst_reg = MT7925_CBTOP_RGU_WF_SUBSYS_RST,
> + .done_reg = MT7925_WFSYS_INIT_DONE_ADDR,
> + .done_mask = U32_MAX,
> + .done_val = MT7925_WFSYS_INIT_DONE,
> + .delay_ms = 20,
> + .need_status_sel = false,
> +};
> +
> int mt792xu_dma_init(struct mt792x_dev *dev, bool resume)
> {
> int err;
> @@ -254,7 +263,9 @@ EXPORT_SYMBOL_GPL(mt792xu_dma_init);
>
> int mt792xu_wfsys_reset(struct mt792x_dev *dev)
> {
> - const struct mt792xu_wfsys_desc *desc = &mt7921_wfsys_desc;
> + const struct mt792xu_wfsys_desc *desc = is_mt7925(&dev->mt76) ?
> + &mt7925_wfsys_desc :
> + &mt7921_wfsys_desc;
> u32 val;
> int i;
>
> --
> 2.43.0
>
Sean, testing results from: Satadru Pramanik <satadru@gmail.com>
"The updated patches from
https://patchwork.kernel.org/project/linux-wireless/list/?series=1064695
do NOT work. I get the -110 error with them on a warm reboot.
Reverting to the kernel with the older patch restores my adapter
connection on a warm reboot."
You are welcome to stop by the Github issue where this issue is being discussed:
https://github.com/morrownr/USB-WiFi/issues/688#
Nick
^ permalink raw reply
* Re: [PATCH 2/2] wifi: mt76: mt792x: fix mt7925u USB WFSYS reset handling
From: Satadru Pramanik @ 2026-03-11 18:15 UTC (permalink / raw)
To: Nick
Cc: Sean Wang, nbd, lorenzo.bianconi, linux-wireless, linux-mediatek,
Sean Wang, stable
In-Reply-To: <CAFrh3J-PsVQ1u_hGFxTVKK0uOs6KxT=euK+jbGvWCueqvynAgw@mail.gmail.com>
After rebuilding the kernel with 7.0-rc3 and the two patches at
https://patchwork.kernel.org/project/linux-wireless/list/?series=1064695,
I can confirm that after a warm reboot booted from that kernel, the
mt7925u-based adapter is once again visible.
Thanks!
Regards,
Satadru Pramanik
On Wed, Mar 11, 2026 at 12:42 PM Satadru Pramanik <satadru@gmail.com> wrote:
>
> Hello all, I'm rebuilding this kernel one more time in case I mispatched, and will let you know shortly if a new kernel build works.
>
> Regards,
>
> Satadru
>
> On Wed, Mar 11, 2026 at 12:15 PM Nick <morrownr@gmail.com> wrote:
>>
>> > From: Sean Wang <sean.wang@mediatek.com>
>> >
>> > mt7925u uses different reset/status registers from mt7921u. Reusing the
>> > mt7921u register set causes the WFSYS reset to fail.
>> >
>> > Add a chip-specific descriptor in mt792xu_wfsys_reset() to select the
>> > correct registers and fix mt7925u failing to initialize after a warm
>> > reboot.
>> >
>> > Fixes: d28e1a48952e ("wifi: mt76: mt792x: introduce mt792x-usb module")
>> > Cc: stable@vger.kernel.org
>> > Signed-off-by: Sean Wang <sean.wang@mediatek.com>
>> > ---
>> > drivers/net/wireless/mediatek/mt76/mt792x_regs.h | 4 ++++
>> > drivers/net/wireless/mediatek/mt76/mt792x_usb.c | 13 ++++++++++++-
>> > 2 files changed, 16 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_regs.h b/drivers/net/wireless/mediatek/mt76/mt792x_regs.h
>> > index 7ddde9286861..d2a8b2b0df32 100644
>> > --- a/drivers/net/wireless/mediatek/mt76/mt792x_regs.h
>> > +++ b/drivers/net/wireless/mediatek/mt76/mt792x_regs.h
>> > @@ -392,6 +392,10 @@
>> > #define MT_CBTOP_RGU_WF_SUBSYS_RST MT_CBTOP_RGU(0x600)
>> > #define MT_CBTOP_RGU_WF_SUBSYS_RST_WF_WHOLE_PATH BIT(0)
>> >
>> > +#define MT7925_CBTOP_RGU_WF_SUBSYS_RST 0x70028600
>> > +#define MT7925_WFSYS_INIT_DONE_ADDR 0x184c1604
>> > +#define MT7925_WFSYS_INIT_DONE 0x00001d1e
>> > +
>> > #define MT_HW_BOUND 0x70010020
>> > #define MT_HW_CHIPID 0x70010200
>> > #define MT_HW_REV 0x70010204
>> > diff --git a/drivers/net/wireless/mediatek/mt76/mt792x_usb.c b/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
>> > index a92e872226cf..47827d1c5ccb 100644
>> > --- a/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
>> > +++ b/drivers/net/wireless/mediatek/mt76/mt792x_usb.c
>> > @@ -224,6 +224,15 @@ static const struct mt792xu_wfsys_desc mt7921_wfsys_desc = {
>> > .need_status_sel = true,
>> > };
>> >
>> > +static const struct mt792xu_wfsys_desc mt7925_wfsys_desc = {
>> > + .rst_reg = MT7925_CBTOP_RGU_WF_SUBSYS_RST,
>> > + .done_reg = MT7925_WFSYS_INIT_DONE_ADDR,
>> > + .done_mask = U32_MAX,
>> > + .done_val = MT7925_WFSYS_INIT_DONE,
>> > + .delay_ms = 20,
>> > + .need_status_sel = false,
>> > +};
>> > +
>> > int mt792xu_dma_init(struct mt792x_dev *dev, bool resume)
>> > {
>> > int err;
>> > @@ -254,7 +263,9 @@ EXPORT_SYMBOL_GPL(mt792xu_dma_init);
>> >
>> > int mt792xu_wfsys_reset(struct mt792x_dev *dev)
>> > {
>> > - const struct mt792xu_wfsys_desc *desc = &mt7921_wfsys_desc;
>> > + const struct mt792xu_wfsys_desc *desc = is_mt7925(&dev->mt76) ?
>> > + &mt7925_wfsys_desc :
>> > + &mt7921_wfsys_desc;
>> > u32 val;
>> > int i;
>> >
>> > --
>> > 2.43.0
>> >
>>
>> Sean, testing results from: Satadru Pramanik <satadru@gmail.com>
>>
>> "The updated patches from
>> https://patchwork.kernel.org/project/linux-wireless/list/?series=1064695
>> do NOT work. I get the -110 error with them on a warm reboot.
>> Reverting to the kernel with the older patch restores my adapter
>> connection on a warm reboot."
>>
>> You are welcome to stop by the Github issue where this issue is being discussed:
>>
>> https://github.com/morrownr/USB-WiFi/issues/688#
>>
>> Nick
^ 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;
as well as URLs for NNTP newsgroup(s).