Linux SPI subsystem development
 help / color / mirror / Atom feed
From: Praveen Talari <praveen.talari@oss.qualcomm.com>
To: Mark Brown <broonie@kernel.org>
Cc: konrad.dybcio@oss.qualcomm.com, mukesh.savaliya@oss.qualcomm.com,
	linux-arm-msm@vger.kernel.org, linux-spi@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	chandana.chiluveru@oss.qualcomm.com
Subject: Re: [PATCH 2/2] spi: qcom-geni: Add panic notifier to suspend controller during panic
Date: Tue, 18 Aug 2026 11:04:56 +0530	[thread overview]
Message-ID: <c9544d41-0782-4632-9d5f-a06c0314e90a@oss.qualcomm.com> (raw)
In-Reply-To: <92fc6c7b-ea87-4577-b200-2bb36388f387@sirena.org.uk>

Hi Mark,

On 11-08-2026 20:06, Mark Brown wrote:
> On Wed, Aug 05, 2026 at 04:12:10PM +0530, Praveen Talari wrote:
>> When a VM crashes with an active SPI DMA transfer in progress, the
>> SMMU raises context faults as the DMA engine continues to access
>> IOVAs that are invalidated when the VM's memory context is torn down.
>> These faults can affect other VMs sharing the same SMMU instance and
>> obscure the root cause of the crash.
>> +static int spi_geni_panic_notifier(struct notifier_block *nb,
>> +				   unsigned long action, void *data)
>> +{
>> +	struct spi_geni_master *mas = container_of(nb, struct spi_geni_master, panic_nb);
>> +	struct spi_controller *spi = dev_get_drvdata(mas->dev);
>> +
>> +	spi_controller_suspend(spi);
> This will take locks - are you sure that's OK in a panic handler?
Good point. I hadn't considered the locking requirements of
spi_controller_suspend(). Looking at the implementation, it can take
locks and is therefore not suitable for panic context.

I'll rework this to avoid invoking the SPI core suspend path from the
panic notifier and instead use a panic-safe mechanism that directly
quiesces the controller without taking sleeping locks.
>
>> -	return devm_spi_register_controller(dev, spi);
>> +	ret = devm_spi_register_controller(dev, spi);
>> +	if (ret)
>> +		return ret;
>> +
>> +	mas->panic_nb.notifier_call = spi_geni_panic_notifier;
>> +	ret = atomic_notifier_chain_register(&panic_notifier_list, &mas->panic_nb);
>> +	if (ret)
>> +		return ret;
>> +
>> +	return devm_add_action_or_reset(dev, spi_geni_unregister_notifiers, mas);
> Should we have the notifier in place before registation, what happens if
> we panic while probing a SPI device which is probing as a result of
> registering the controller?
You're right. There is a window between
devm_spi_register_controller() and notifier registration where a panic
could occur while a child SPI device is probing and issuing transfers.

I'll move the notifier registration before controller registration so
that panic handling is active before any client device can start using

the controller.


Thanks,

Praveen Talari

  reply	other threads:[~2026-08-18  5:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-05 10:42 [PATCH 0/2] spi: qcom-geni: Add shutdown and panic notifier support Praveen Talari
2026-08-05 10:42 ` [PATCH 1/2] spi: qcom-geni: Add shutdown callback to quiesce hardware on reboot Praveen Talari
2026-08-12  5:42   ` Mukesh Savaliya
2026-08-05 10:42 ` [PATCH 2/2] spi: qcom-geni: Add panic notifier to suspend controller during panic Praveen Talari
2026-08-11 14:36   ` Mark Brown
2026-08-18  5:34     ` Praveen Talari [this message]
2026-08-12  5:46   ` Mukesh Savaliya

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=c9544d41-0782-4632-9d5f-a06c0314e90a@oss.qualcomm.com \
    --to=praveen.talari@oss.qualcomm.com \
    --cc=broonie@kernel.org \
    --cc=chandana.chiluveru@oss.qualcomm.com \
    --cc=konrad.dybcio@oss.qualcomm.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=mukesh.savaliya@oss.qualcomm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox