[PATCH iwlwifi-next] wifi: iwlwifi: pcie: return a real errno from read_config32()

[PATCH iwlwifi-next] wifi: iwlwifi: pcie: return a real errno from read_config32()

[Yogesh Gaur]

pci_read_config_dword() can also return a positive PCIBIOS_* error code
(e.g. PCIBIOS_DEVICE_NOT_FOUND for a disconnected device), but
iwl_trans_pcie_read_config32() passes it through unchanged and
iwl_dump_ini_config_iter() only checks for ret < 0. The error is missed,
so the loop keeps reading and stores 0xffffffff in the dump.

Convert the return value with pcibios_err_to_errno().

Fixes: f696a7ee254f ("iwlwifi: yoyo: add PCI config space region type")
Signed-off-by: Yogesh Gaur <yogesh.gaur@intel.com>
---
 drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c
index 28b276c65952..cfaadddfe06a 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c
@@ -2562,8 +2562,12 @@ int iwl_trans_pcie_read_mem_no_grab(struct iwl_trans *trans, u32 addr,
 int iwl_trans_pcie_read_config32(struct iwl_trans *trans, u32 ofs,
 				 u32 *val)
 {
-	return pci_read_config_dword(IWL_TRANS_GET_PCIE_TRANS(trans)->pci_dev,
-				     ofs, val);
+	int ret;
+
+	ret = pci_read_config_dword(IWL_TRANS_GET_PCIE_TRANS(trans)->pci_dev,
+				    ofs, val);
+
+	return pcibios_err_to_errno(ret);
 }
 
 #define IWL_FLUSH_WAIT_MS	2000
-- 
2.34.1

Re: [PATCH iwlwifi-next] wifi: iwlwifi: pcie: return a real errno from read_config32()

[Johannes Berg]

On Wed, 2026-10-14 at 18:13 +0530, Yogesh Gaur wrote:
> pci_read_config_dword() can also return a positive PCIBIOS_* error code
> (e.g. PCIBIOS_DEVICE_NOT_FOUND for a disconnected device), but
> iwl_trans_pcie_read_config32() passes it through unchanged and
> iwl_dump_ini_config_iter() only checks for ret < 0. The error is missed,
> so the loop keeps reading and stores 0xffffffff in the dump.
> 
> Convert the return value with pcibios_err_to_errno().
> 

This isn't incorrect, but is it a good idea? I'm not convinced, we might
still get some other parts of the dump vs. just aborting the entire
section at that point?

IOW, _why_ are you doing this? Do you have a problem with it? What is
that problem? Is it just a static checker/LLM complaint that you want to
fix?

johannes

RE: [PATCH iwlwifi-next] wifi: iwlwifi: pcie: return a real errno from read_config32()

[Gaur, Yogesh]

> -----Original Message-----
> From: Johannes Berg <johannes@sipsolutions.net>
> Sent: Wednesday, October 14, 2026 6:26 PM
> To: Gaur, Yogesh <yogesh.gaur@intel.com>; Korenblit, Miriam Rachel
> <miriam.rachel.korenblit@intel.com>; linux-wireless@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Cc: Grumbach, Emmanuel <emmanuel.grumbach@intel.com>
> Subject: Re: [PATCH iwlwifi-next] wifi: iwlwifi: pcie: return a real errno from
> read_config32()
> 
> On Wed, 2026-10-14 at 18:13 +0530, Yogesh Gaur wrote:
> > pci_read_config_dword() can also return a positive PCIBIOS_* error
> > code (e.g. PCIBIOS_DEVICE_NOT_FOUND for a disconnected device), but
> > iwl_trans_pcie_read_config32() passes it through unchanged and
> > iwl_dump_ini_config_iter() only checks for ret < 0. The error is
> > missed, so the loop keeps reading and stores 0xffffffff in the dump.
> >
> > Convert the return value with pcibios_err_to_errno().
> >
> 
> This isn't incorrect, but is it a good idea? I'm not convinced, we might still get
> some other parts of the dump vs. just aborting the entire section at that
> point?
> 
> IOW, _why_ are you doing this? Do you have a problem with it? What is that
> problem? Is it just a static checker/LLM complaint that you want to fix?

No real-world problem. It came out of LLM-assisted code review that flagged the positive PCIBIOS_* return being missed by the ret < 0 check;
I haven't seen it cause a failure.

Yes current behaviour is the better one for a dump: a failed range makes iwl_dump_ini_mem() drop the whole region, whereas today a misaligned offset just records 0xffffffff for that word and the rest of the region is still collected. For a disconnected device every read returns all-ones either way.

Please drop this one. Thanks for the review.

Yogesh
> 
> johannes