All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Navon John Lukose" <navonjohnlukose@gmail.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH wireless v2 2/3] wifi: iwlwifi: pcie: deselect the product reset mode at probe
Date: Mon, 31 Aug 2026 13:13:15 +0000	[thread overview]
Message-ID: <20260831131316.20CBD1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260831130332.323549-3-navonjohnlukose@gmail.com>

> The mode that iwl_trans_pcie_set_product_reset() selects lives in the
> platform's ACPI namespace, not in the device, and nothing deselects it on
> the product-reset path. iwl_trans_pcie_removal_wk() selects it, evaluates
> _RST via _PRR and removes the device; the rescan re-probes, and probe only
> reads the mode back for the log rather than clearing it, so it is still
> selected. (A later removal with a lesser mode does pass enable=false, but
> that is the path that does not need it.) It is plain namespace state - on
> the platform I have it is a named integer written by the vendor DSM and
> read back by the reset method - so it survives S3 and s2idle. Neither the
> driver nor _RST clears it.
> 
> That has a consequence. _RST branches on the mode variable, does not
> clear it, and iwl_trans_pcie_reset() takes the caller's word for which
> reset to run. So after any product reset the next escalation can do the
> wrong thing: iwl_trans_determine_restart_mode() asks for
> [ ... ]
> cleared.
> 
> Cc: stable@vger.kernel.org
> Fixes: 9673c35486d4 ("wifi: iwlwifi: implement product reset for TOP errors")
> Signed-off-by: Navon John Lukose <navonjohnlukose@gmail.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260831130332.323549-1-navonjohnlukose@gmail.com?part=2


  reply	other threads:[~2026-08-31 13:13 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
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 [this message]
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=20260831131316.20CBD1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=navonjohnlukose@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.