From: Bjorn Helgaas <helgaas@kernel.org>
To: Navon John Lukose <navonjohnlukose@gmail.com>
Cc: Miri Korenblit <miriam.rachel.korenblit@intel.com>,
linux-wireless@vger.kernel.org,
Johannes Berg <johannes@sipsolutions.net>,
Emmanuel Grumbach <emmanuel.grumbach@intel.com>,
Nika Krasnova <nika@nikableh.moe>,
Mark Pearson <mpearson-lenovo@squebb.ca>,
Mark Pearson <markpearson@lenovo.com>,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH wireless v2 1/3] wifi: iwlwifi: pcie: don't infer CSME presence from a failed read
Date: Tue, 1 Sep 2026 10:48:28 -0500 [thread overview]
Message-ID: <20260901154828.GA1879052@bhelgaas> (raw)
In-Reply-To: <20260831130332.323549-2-navonjohnlukose@gmail.com>
On Mon, Aug 31, 2026 at 06:33:30PM +0530, Navon John Lukose wrote:
> iwl_pcie_check_me_status() decides whether WiAMT/CSME is present from two
> register reads, without checking that either read reached the device.
>
> iwl_read_prph() returns 0x5a5a5a5a when it cannot grab NIC access, and
> that value has CNVI_SCU_REG_FOR_ECO_1_WIAMT_KNOWN set and
> CNVI_SCU_REG_FOR_ECO_1_WIAMT_PRESENT clear. A read that never reached
> the hardware is therefore taken as a positive statement that there is no
> CSME, and the function returns without scheduling the recheck. That is
> reachable at probe: iwl_pci_gen1_2_probe() carries on when
> iwl_pcie_prepare_card_hw() fails, and iwl_pcie_check_me_status() then
> runs against a card it cannot talk to.
>
> The second read has the mirror-image problem: an all-ones
> CSR_HW_IF_CONFIG_REG has both ME_OWN and IAMT_UP set, so a device that
> has fallen off the bus latches me_present to 1. So does the one in
> iwl_pcie_recheck_me_status(), which runs a second after probe with no
> guarantee that the device is still answering.
>
> me_present is never recomputed after that, and any non-zero value makes
> iwl_trans_pcie_reset() downgrade IWL_RESET_MODE_PROD_RESET to
> IWL_RESET_MODE_FUNC_RESET, so one bad read permanently weakens the
> recovery. In the 0x5a5a5a5a case it goes the other way and permits a
> product reset on a machine that may well have CSME.
>
> Don't take those values as data. iwl_trans_is_hw_error_value() matches
> 0x5a5a5a5[0-f] and 0xa5a5a5a[0-f] but not ~0, so the prph read in
> iwl_pcie_check_me_status() needs both tests, the way
> iwl_pcie_irq_handler() does; the two CSR reads only need the ~0 one. At
> probe that leaves me_present at -1 (unknown) and still schedules the
> recheck; in the recheck it keeps the previous value.
>
> This does change the reset ladder in the poisoned-read case, and -1 is
> truthy: a product reset that iwl_trans_pcie_reset() used to allow -
> because 0x5a5a5a5a had been read as me_present = 0 - is now downgraded
> to a function level reset. That is the conservative direction, and the 0
> was never a reading, but it is a behaviour change and not a no-op.
>
> Cc: stable@vger.kernel.org
> Fixes: 41fff83fe6cd ("wifi: iwlwifi: pcie: check for WiAMT/CSME presence")
> Signed-off-by: Navon John Lukose <navonjohnlukose@gmail.com>
> ---
> Backport note: the bug arrived in v6.14, so the affected branches that are
> still supported are 6.18.y, 7.1.y and 7.2.y. All three have the code in
> pcie/gen1_2/trans.c as trans_pcie->me_present, so this applies as posted
> with no rewrite.
>
> Only if you care about anything older that has the bug - v6.14 through
> v6.17, all EOL now: v6.16 and below have both functions in pcie/drv.c
> (377edee91b89 "wifi: iwlwifi: pcie move gen1_2 probe to gen1_2/trans.c"
> moved them), and v6.15 and below spell the field trans->me_present
> (cd6d6de694e2 "wifi: iwlwifi: pcie: move ME check data to pcie" renamed
> it). The hunks are otherwise identical; iwl_trans_is_hw_error_value()
> exists in every affected release.
>
> .../net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 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 28b276c..c6a771e 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/trans.c
> @@ -4194,7 +4194,8 @@ static void iwl_pcie_recheck_me_status(struct work_struct *wk)
> u32 val;
>
> val = iwl_read32(trans_pcie->trans, CSR_HW_IF_CONFIG_REG);
> - trans_pcie->me_present = !!(val & CSR_HW_IF_CONFIG_REG_IAMT_UP);
> + if (val != ~0U)
Consider using PCI_POSSIBLE_ERROR() for these tests.
> + trans_pcie->me_present = !!(val & CSR_HW_IF_CONFIG_REG_IAMT_UP);
> }
>
> static void iwl_pcie_check_me_status(struct iwl_trans *trans)
> @@ -4212,15 +4213,19 @@ static void iwl_pcie_check_me_status(struct iwl_trans *trans)
> return;
>
> val = iwl_read_prph(trans, CNVI_SCU_REG_FOR_ECO_1);
> - if (val & CNVI_SCU_REG_FOR_ECO_1_WIAMT_KNOWN) {
> + /* iwl_read_prph() returns 0x5a5a5a5a if it never reached the NIC, and
> + * that value has WIAMT_KNOWN set and WIAMT_PRESENT clear
> + */
> + if (val != ~0U && !iwl_trans_is_hw_error_value(val) &&
> + (val & CNVI_SCU_REG_FOR_ECO_1_WIAMT_KNOWN)) {
> trans_pcie->me_present =
> !!(val & CNVI_SCU_REG_FOR_ECO_1_WIAMT_PRESENT);
> return;
> }
>
> val = iwl_read32(trans, CSR_HW_IF_CONFIG_REG);
> - if (val & (CSR_HW_IF_CONFIG_REG_ME_OWN |
> - CSR_HW_IF_CONFIG_REG_IAMT_UP)) {
> + if (val != ~0U && (val & (CSR_HW_IF_CONFIG_REG_ME_OWN |
> + CSR_HW_IF_CONFIG_REG_IAMT_UP))) {
> trans_pcie->me_present = 1;
> return;
> }
> --
> 2.55.0
>
next prev parent reply other threads:[~2026-09-01 15:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 13:03 [PATCH wireless v2 0/3] wifi: iwlwifi: recover a device that lost power in D3cold Navon John Lukose
2026-08-31 13:03 ` [PATCH wireless v2 1/3] wifi: iwlwifi: pcie: don't infer CSME presence from a failed read Navon John Lukose
2026-08-31 13:15 ` sashiko-bot
2026-08-31 13:44 ` Navon John Lukose
2026-09-01 15:48 ` Bjorn Helgaas [this message]
2026-09-01 16:17 ` Bjorn Helgaas
2026-09-01 17:02 ` Johannes Berg
2026-09-06 23:00 ` Navon John Lukose
2026-09-07 6:30 ` Johannes Berg
2026-09-08 3:41 ` Navon John Lukose
2026-08-31 13:03 ` [PATCH wireless v2 2/3] wifi: iwlwifi: pcie: deselect the product reset mode at probe Navon John Lukose
2026-08-31 13:13 ` sashiko-bot
2026-08-31 13:03 ` [PATCH wireless v2 3/3] wifi: iwlwifi: pcie: recover a device that lost power in D3cold Navon John Lukose
2026-08-31 13:20 ` sashiko-bot
2026-08-31 17:08 ` Ilpo Järvinen
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=20260901154828.GA1879052@bhelgaas \
--to=helgaas@kernel.org \
--cc=emmanuel.grumbach@intel.com \
--cc=johannes@sipsolutions.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=markpearson@lenovo.com \
--cc=miriam.rachel.korenblit@intel.com \
--cc=mpearson-lenovo@squebb.ca \
--cc=navonjohnlukose@gmail.com \
--cc=nika@nikableh.moe \
--cc=stable@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.