On 3/14/2018 5:40 PM, Bjorn Andersson wrote:
On Wed 14 Mar 13:05 PDT 2018, Christ, Austin wrote:
This patch is designed to address a possible issue where an interrupt is
fired but not yet handled by the i2c-qup driver and the kernel goes down as
kexec prepares to start a secondary kernel. In this case it is possible the
interrupt will be left unhandled.
What's the problem with not handling this IRQ? Does the hardware end up
in some funky state? Are you worried that the kexec kernel will not
function because there's a pending I2C interrupt?
The potential issue is that if an IRQ is left high, the secondary kernel
driver for I2C may enter a bad state trying to handle an interrupt that
does not apply to its context. In the QUP driver case, it may be less of
an issue because the probe does a soft reset of the core.
This is not unique to the i2c-qup driver, similar patches have gone into
other drivers such as the following for the arm-smmu-v3 driver.
The only similarity I can see here is that the SMMU is shut down in
order for any ongoing memory transaction to stop, which could be analog
to ongoing BAM operations in the QUP driver. But in that case I think
the shutdown should go in the BAM, to stop any ongoing transactions.
My point wasn't that the shutdown was addressing the same issues between
these drivers, but that registering a shutdown function is the standard
code path for exposing clean tear down for kexec. Kexec does not call
remove on active drivers; it calls shutdown.
Is there any negative impact for adding this function?
Regards,
Bjorn
commit 7aa8619a66aea52b145e04cbab4f8d6a4e5f3f3b
Author: Nate Watterson <nwatters@xxxxxxxxxxxxxx>
Date: Thu Jun 29 18:18:15 2017 -0400
iommu/arm-smmu-v3: Implement shutdown method
The shutdown method disables the SMMU to avoid corrupting a new kernel
started with kexec.
Signed-off-by: Nate Watterson <nwatters@xxxxxxxxxxxxxx>
Signed-off-by: Will Deacon <will.deacon@xxxxxxx>
On 2/2/2018 4:36 PM, Bjorn Andersson wrote:
On Tue 16 Jan 13:35 PST 2018, Austin Christ wrote:
This shutdown method disables I2C to avoid corrupting a new kernel
started with kexec.
Can you elaborate on the issue you're seeing here? In what way is the
i2c-qup driver special, will there be similar patches for all other
drivers in the system?
Regards,
Bjorn
--
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies,
Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
--
Qualcomm Datacenter Technologies as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
