From: Simon Horman <horms@kernel.org>
To: Potnuri Bharat Teja <bharat@chelsio.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org,
edumazet@google.com, pabeni@redhat.com, andrew+netdev@lunn.ch
Subject: Re: [PATCH net-next v3 02/12] cxgb4: rework the interrupt handling framework
Date: Fri, 9 Oct 2026 14:56:13 +0100 [thread overview]
Message-ID: <20261009135613.GC83879@horms.kernel.org> (raw)
In-Reply-To: <20261005224830.377752-3-bharat@chelsio.com>
On Mon, Oct 05, 2026 at 06:48:20PM -0400, Potnuri Bharat Teja wrote:
> The slow interrupt path used a per module handler that walked a table
> of (mask, message) pairs with t4_handle_intr_status() and printed a
> message for every bit it found set. Each module handler open coded
> the read, report and clear sequence, and there was no way to express
> that a cause bit should be handled by inspecting a sub-register, or
> that a bit is only fatal when it is also enabled.
>
> Replace it with a data driven framework:
>
> struct intr_info describes one cause register: its name, the cause
> and enable register offsets, the mask of fatal bits, a table of
> struct intr_details for decoding individual bits, and an optional
> table of struct intr_action entries naming a function to call for a
> given cause bit.
>
> t4_handle_intr() implements the common read, report, dispatch and
> clear sequence once, so a module handler reduces to describing its
> registers and any nested cause registers it owns.
>
> The module interrupt handlers now return bool rather than void so a
> fatal condition propagates back to t4_slow_intr_handler() instead of
> being signalled out of band, and t4_slow_intr_handler() takes a
> verbose flag controlling whether individual cause bits are decoded
> and logged.
>
> This changes the interrupt path for all supported adapters. No
> functional change is intended for T4, T5 or T6 beyond the wording of
> the messages emitted.
>
> Signed-off-by: Potnuri Bharat Teja <bharat@chelsio.com>
Hi Potnuri,
Thanks for your patch.
x86_64 allmodconfig W=1 builds with clang 22.1.8 warn that:
.../t4_hw.c:6959:3: warning: variable 'fatal' is uninitialized when used here [-Wuninitialized]
6959 | fatal |= t4_handle_intr(adap, &ii, 0, verbose);
| ^~~~~
.../t4_hw.c:6945:12: note: initialize the variable 'fatal' to silence this warning
6945 | bool fatal;
| ^
| = 0
1 warning generated.
Warning: .../t4_hw.c:7956 function parameter 'adap' not described in 't4_slow_intr_handler'
Warning: .../t4_hw.c:7956 Excess function parameter 'adapter' description in 't4_slow_intr_handler' (did you mean one of: 'adap')
Warning: .../t4_hw.c:8209 function parameter 'adap' not described in 't4_intr_enable'
Warning: .../t4_hw.c:8209 Excess function parameter 'adapter' description in 't4_intr_enable' (did you mean one of: 'adap')
Warning: .../t4_hw.c:7956 function parameter 'adap' not described in 't4_slow_intr_handler'
Warning: .../t4_hw.c:7956 Excess function parameter 'adapter' description in 't4_slow_intr_handler' (did you mean one of: 'adap')
Warning: .../t4_hw.c:8209 function parameter 'adap' not described in 't4_intr_enable'
Warning: .../t4_hw.c:8209 Excess function parameter 'adapter' description in 't4_intr_enable' (did you mean one of: 'adap')
Similarly building patch 3/12, 5/12, 10/12, and 11/12,
seem to add new warnings reported by gcc 16.2.1 or clang.
Please make sure your patch compiles for x86_64 allmodconfig W=1
with out new warnings emitted by either gcc or clang.
The following functions added in .c files use the inline keyword.
static inline char intr_alert_char(u32 cause, u32 enable, u32 fatal)
static inline u32 t7_tlstx_reg(u8 instance, u8 channel, u32 reg)
static inline uint32_t
Please don't use inline like that, instead please let the compiler
choose to inline functions (or not).
inline functions in .h files are of course fine.
And checkpatch reports the following errors for patch 4/12.
ERROR: missing sentinel in ID array
#1734: FILE: drivers/net/ethernet/chelsio/cxgb4/cxgb4_pci.c:289:
+static const struct pci_device_id cxgb4_pci_tbl[] = {
#define CH_PCI_DEVICE_ID_FUNCTION CXGB4_UNIFIED_PF
#define CH_PCI_DEVICE_ID_FUNCTION2 0x0
#define CH_PCI_ID_TABLE_ENTRY(devid) \
{ PCI_VDEVICE(CHELSIO, (devid)), CXGB4_UNIFIED_PF }
#define CH_PCI_DEVICE_ID_TABLE_DEFINE_END \
{ 0, } \
}
ERROR: Macros with complex values should be enclosed in parentheses
#1741: FILE: drivers/net/ethernet/chelsio/cxgb4/cxgb4_pci.c:296:
+#define CH_PCI_DEVICE_ID_TABLE_DEFINE_END \
+ { 0, } \
+}
Please make sure the patchset does not add checkpatch errors.
...
--
pw-bot: changes-requested
next prev parent reply other threads:[~2026-10-09 13:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-05 22:48 [PATCH net-next v3 00/12] cxgb4: Add T7 adapter support Potnuri Bharat Teja
2026-10-05 22:48 ` [PATCH net-next v3 01/12] cxgb4: add T7 hardware definitions and firmware interfaces Potnuri Bharat Teja
2026-10-05 22:48 ` [PATCH net-next v3 02/12] cxgb4: rework the interrupt handling framework Potnuri Bharat Teja
2026-10-09 13:56 ` Simon Horman [this message]
2026-10-05 22:48 ` [PATCH net-next v3 03/12] cxgb4: add T7 hardware management support Potnuri Bharat Teja
2026-10-05 22:48 ` [PATCH net-next v3 04/12] cxgb4: move PCI device management into cxgb4_pci.c and rework driver helpers Potnuri Bharat Teja
2026-10-05 22:48 ` [PATCH net-next v3 05/12] cxgb4: add T7 support to the main driver Potnuri Bharat Teja
2026-10-05 22:48 ` [PATCH net-next v3 06/12] cxgb4: update PTP register access for T7 Potnuri Bharat Teja
2026-10-05 22:48 ` [PATCH net-next v3 07/12] cxgb4: extend ethtool support for T7 adapters Potnuri Bharat Teja
2026-10-05 22:48 ` [PATCH net-next v3 08/12] cxgb4: Add T7 support to the filter infrastructure Potnuri Bharat Teja
2026-10-05 22:48 ` [PATCH net-next v3 09/12] cxgb4: Add indirect register definitions for T7 Potnuri Bharat Teja
2026-10-05 22:48 ` [PATCH net-next v3 10/12] cxgb4: extend CUDBG support for T7 adapters Potnuri Bharat Teja
2026-10-05 22:48 ` [PATCH net-next v3 11/12] cxgb4: extend debugfs " Potnuri Bharat Teja
2026-10-05 22:48 ` [PATCH net-next v3 12/12] cxgb4: select ULD Tx and control queues by TID on T7 Potnuri Bharat Teja
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261009135613.GC83879@horms.kernel.org \
--to=horms@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=bharat@chelsio.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox