Re: [PATCH wireless v2 1/3] wifi: iwlwifi: pcie: don't infer CSME presence from a failed read

[Navon John Lukose]

On Tue, 2026-09-01 at 19:02 +0200, Johannes Berg wrote:
> I believe the hardware itself never generates ~0, so yes, it probably
> should use that.

I'll switch the tests this series adds to PCI_POSSIBLE_ERROR(); drv.c and
trans.c already include linux/pci.h. There's no non-PCI transport to
worry about: Kconfig depends on PCI, and iwl_trans_ops went away in
0d91a2bfc3dc.

I'd be more careful with the helper itself. iwl_trans_pcie_read_mem() and
its _no_grab variant run it over dwords they're copying out of SRAM, and
~0 is a value the driver writes as data (FW_CTXT_INVALID fills unused
binding and quota slots). iwl_dump_ini_dbgi_sram_iter() is the sharp
case: it gives up on a single hit, so one all-ones dword fails a whole
region. I haven't seen it happen, it's just what the value means.
Widening the helper and taking the SRAM paths off it would work, but
that's more churn than belongs here. Your call.

Separately, the test at the top of iwl_pcie_irq_handler() (rx.c:1948)
looks unreachable: inta has just been masked with at most
CSR_INI_SET_MASK (0xBA00008F). I'd move it above the mask, unless you'd
rather drop it. I'll send that and the PCI_POSSIBLE_ERROR() conversions
separately.

Thanks,
Navon