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

[Johannes Berg <johannes@sipsolutions.net>]

On Mon, 2026-09-07 at 04:30 +0530, Navon John Lukose wrote:
> 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.
> 

I'm not your remote prompt engineer, so as far as I'm concerned this
thread ends here.

johannes