All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3] i2c: i801: Fix interrupt storm from SMB_ALERT signal
@ 2021-11-10 14:10 Jarkko Nikula
  2021-11-10 17:16 ` Andy Shevchenko
  0 siblings, 1 reply; 6+ messages in thread
From: Jarkko Nikula @ 2021-11-10 14:10 UTC (permalink / raw)
  To: linux-i2c
  Cc: Jean Delvare, Wolfram Sang, Andy Shevchenko, Jarkko Nikula,
	ck+kernelbugzilla, stephane.poignant

Currently interrupt storm will occur from i2c-i801 after first
transaction if SMB_ALERT signal is enabled and ever asserted. It is
enough if the signal is asserted once even before the driver is loaded
and does not recover because that interrupt is not acknowledged.

This fix aims to fix it by two ways:
- Add acknowledging for the SMB_ALERT interrupt status
- Disable the SMB_ALERT interrupt on platforms where possible since the
  driver currently does not make use for it

Acknowledging resets the SMB_ALERT interrupt status on all platforms and
also should help to avoid interrupt storm on older platforms where the
SMB_ALERT interrupt disabling is not available.

For simplicity this fix reuses the host notify feature for disabling and
restoring original register value.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=177311
Reported-by: ck+kernelbugzilla@bl4ckb0x.de
Reported-by: stephane.poignant@protonmail.com
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
---
v3: Add comment from Jean Delvare why SMB_ALERT interrupt is blocked for
    now. Simplify comment about SMB_ALERT status clearing
v2: More verbose commenting around interrupt acknowledging, reporting
    and SMB_ALERT disabling. Fix typo in commit log and split the first
    sentence.
v1:
Hi Conrad and Stephane. This patch is otherwise the same than the one I
had in bugzilla but this adds also acknowledging for the SMB_ALERT
interrupt. There is short time window during driver load and unload
where interrupt storm will still occur if signal was asserted. Also
interrupt disabling is possible only on ICH3 and later so interrupt
acknowledging should also help those old platforms.
---
 drivers/i2c/busses/i2c-i801.c | 25 +++++++++++++++++++------
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index ed271274250b..21be28b7955f 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -191,6 +191,7 @@
 #define SMBSLVSTS_HST_NTFY_STS	BIT(0)
 
 /* Host Notify Command register bits */
+#define SMBSLVCMD_SMBALERT_DISABLE	BIT(2)
 #define SMBSLVCMD_HST_NTFY_INTREN	BIT(0)
 
 #define STATUS_ERROR_FLAGS	(SMBHSTSTS_FAILED | SMBHSTSTS_BUS_ERR | \
@@ -642,12 +643,20 @@ static irqreturn_t i801_isr(int irq, void *dev_id)
 		i801_isr_byte_done(priv);
 
 	/*
-	 * Clear irq sources and report transaction result.
+	 * Clear remaining irq sources: Completion of last command, errors
+	 * and the SMB_ALERT signal. SMB_ALERT status is set after signal
+	 * assertion independently is the interrupt generation blocked or not
+	 * so clear it always when the status is set.
+	 */
+	status &= SMBHSTSTS_INTR | STATUS_ERROR_FLAGS | SMBHSTSTS_SMBALERT_STS;
+	if (status)
+		outb_p(status, SMBHSTSTS(priv));
+	status &= ~SMBHSTSTS_SMBALERT_STS; /* SMB_ALERT not reported */
+	/*
+	 * Report transaction result.
 	 * ->status must be cleared before the next transaction is started.
 	 */
-	status &= SMBHSTSTS_INTR | STATUS_ERROR_FLAGS;
 	if (status) {
-		outb_p(status, SMBHSTSTS(priv));
 		priv->status = status;
 		complete(&priv->done);
 	}
@@ -975,9 +984,13 @@ static void i801_enable_host_notify(struct i2c_adapter *adapter)
 	if (!(priv->features & FEATURE_HOST_NOTIFY))
 		return;
 
-	if (!(SMBSLVCMD_HST_NTFY_INTREN & priv->original_slvcmd))
-		outb_p(SMBSLVCMD_HST_NTFY_INTREN | priv->original_slvcmd,
-		       SMBSLVCMD(priv));
+	/*
+	 * Enable host notify interrupt and block the generation of interrupt
+	 * from the SMB_ALERT signal because the driver does not support
+	 * SMBus Alert yet.
+	 */
+	outb_p(SMBSLVCMD_HST_NTFY_INTREN | SMBSLVCMD_SMBALERT_DISABLE |
+	       priv->original_slvcmd, SMBSLVCMD(priv));
 
 	/* clear Host Notify bit to allow a new notification */
 	outb_p(SMBSLVSTS_HST_NTFY_STS, SMBSLVSTS(priv));
-- 
2.33.0


^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: [PATCH v3] i2c: i801: Fix interrupt storm from SMB_ALERT signal
  2021-11-10 14:10 [PATCH v3] i2c: i801: Fix interrupt storm from SMB_ALERT signal Jarkko Nikula
@ 2021-11-10 17:16 ` Andy Shevchenko
  2021-11-11 14:39   ` Jarkko Nikula
  0 siblings, 1 reply; 6+ messages in thread
From: Andy Shevchenko @ 2021-11-10 17:16 UTC (permalink / raw)
  To: Jarkko Nikula
  Cc: linux-i2c, Jean Delvare, Wolfram Sang, ck+kernelbugzilla,
	stephane.poignant

On Wed, Nov 10, 2021 at 04:10:32PM +0200, Jarkko Nikula wrote:
> Currently interrupt storm will occur from i2c-i801 after first
> transaction if SMB_ALERT signal is enabled and ever asserted. It is
> enough if the signal is asserted once even before the driver is loaded
> and does not recover because that interrupt is not acknowledged.
> 
> This fix aims to fix it by two ways:
> - Add acknowledging for the SMB_ALERT interrupt status
> - Disable the SMB_ALERT interrupt on platforms where possible since the
>   driver currently does not make use for it
> 
> Acknowledging resets the SMB_ALERT interrupt status on all platforms and
> also should help to avoid interrupt storm on older platforms where the
> SMB_ALERT interrupt disabling is not available.
> 
> For simplicity this fix reuses the host notify feature for disabling and
> restoring original register value.

With proposed modification (to the text) below, FWIW,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

> Link: https://bugzilla.kernel.org/show_bug.cgi?id=177311
> Reported-by: ck+kernelbugzilla@bl4ckb0x.de
> Reported-by: stephane.poignant@protonmail.com
> Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
> ---
> v3: Add comment from Jean Delvare why SMB_ALERT interrupt is blocked for
>     now. Simplify comment about SMB_ALERT status clearing
> v2: More verbose commenting around interrupt acknowledging, reporting
>     and SMB_ALERT disabling. Fix typo in commit log and split the first
>     sentence.
> v1:
> Hi Conrad and Stephane. This patch is otherwise the same than the one I
> had in bugzilla but this adds also acknowledging for the SMB_ALERT
> interrupt. There is short time window during driver load and unload
> where interrupt storm will still occur if signal was asserted. Also
> interrupt disabling is possible only on ICH3 and later so interrupt
> acknowledging should also help those old platforms.
> ---
>  drivers/i2c/busses/i2c-i801.c | 25 +++++++++++++++++++------
>  1 file changed, 19 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
> index ed271274250b..21be28b7955f 100644
> --- a/drivers/i2c/busses/i2c-i801.c
> +++ b/drivers/i2c/busses/i2c-i801.c
> @@ -191,6 +191,7 @@
>  #define SMBSLVSTS_HST_NTFY_STS	BIT(0)
>  
>  /* Host Notify Command register bits */
> +#define SMBSLVCMD_SMBALERT_DISABLE	BIT(2)
>  #define SMBSLVCMD_HST_NTFY_INTREN	BIT(0)
>  
>  #define STATUS_ERROR_FLAGS	(SMBHSTSTS_FAILED | SMBHSTSTS_BUS_ERR | \
> @@ -642,12 +643,20 @@ static irqreturn_t i801_isr(int irq, void *dev_id)
>  		i801_isr_byte_done(priv);
>  
>  	/*
> -	 * Clear irq sources and report transaction result.
> +	 * Clear remaining irq sources: Completion of last command, errors

irq --> IRQ
of last --> of the last

> +	 * and the SMB_ALERT signal. SMB_ALERT status is set after signal
> +	 * assertion independently is the interrupt generation blocked or not

is --> if ?

> +	 * so clear it always when the status is set.
> +	 */
> +	status &= SMBHSTSTS_INTR | STATUS_ERROR_FLAGS | SMBHSTSTS_SMBALERT_STS;
> +	if (status)
> +		outb_p(status, SMBHSTSTS(priv));
> +	status &= ~SMBHSTSTS_SMBALERT_STS; /* SMB_ALERT not reported */
> +	/*
> +	 * Report transaction result.
>  	 * ->status must be cleared before the next transaction is started.
>  	 */
> -	status &= SMBHSTSTS_INTR | STATUS_ERROR_FLAGS;
>  	if (status) {
> -		outb_p(status, SMBHSTSTS(priv));
>  		priv->status = status;
>  		complete(&priv->done);
>  	}
> @@ -975,9 +984,13 @@ static void i801_enable_host_notify(struct i2c_adapter *adapter)
>  	if (!(priv->features & FEATURE_HOST_NOTIFY))
>  		return;
>  
> -	if (!(SMBSLVCMD_HST_NTFY_INTREN & priv->original_slvcmd))
> -		outb_p(SMBSLVCMD_HST_NTFY_INTREN | priv->original_slvcmd,
> -		       SMBSLVCMD(priv));
> +	/*
> +	 * Enable host notify interrupt and block the generation of interrupt
> +	 * from the SMB_ALERT signal because the driver does not support
> +	 * SMBus Alert yet.

does not support ... yet -->
  has not supported ... yet
  does not support

?

> +	 */
> +	outb_p(SMBSLVCMD_HST_NTFY_INTREN | SMBSLVCMD_SMBALERT_DISABLE |
> +	       priv->original_slvcmd, SMBSLVCMD(priv));
>  
>  	/* clear Host Notify bit to allow a new notification */
>  	outb_p(SMBSLVSTS_HST_NTFY_STS, SMBSLVSTS(priv));
> -- 
> 2.33.0
> 

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v3] i2c: i801: Fix interrupt storm from SMB_ALERT signal
  2021-11-10 17:16 ` Andy Shevchenko
@ 2021-11-11 14:39   ` Jarkko Nikula
  2021-11-16 10:18     ` Jean Delvare
  0 siblings, 1 reply; 6+ messages in thread
From: Jarkko Nikula @ 2021-11-11 14:39 UTC (permalink / raw)
  To: Andy Shevchenko
  Cc: linux-i2c, Jean Delvare, Wolfram Sang, ck+kernelbugzilla,
	stephane.poignant

Hi

On 11/10/21 7:16 PM, Andy Shevchenko wrote:
> On Wed, Nov 10, 2021 at 04:10:32PM +0200, Jarkko Nikula wrote:
>>   	/*
>> -	 * Clear irq sources and report transaction result.
>> +	 * Clear remaining irq sources: Completion of last command, errors
> 
> irq --> IRQ
> of last --> of the last
> 
Ah, worth of changing while changing the line.

>> +	 * and the SMB_ALERT signal. SMB_ALERT status is set after signal
>> +	 * assertion independently is the interrupt generation blocked or not
> 
> is --> if ?
> 
hmm, I don't know which one is correct or neither. Or should it be 
something like "independently of whether the interrupt generation is 
blocked or not"? Grammar polices, please help me :-)

>> @@ -975,9 +984,13 @@ static void i801_enable_host_notify(struct i2c_adapter *adapter)
>>   	if (!(priv->features & FEATURE_HOST_NOTIFY))
>>   		return;
>>   
>> -	if (!(SMBSLVCMD_HST_NTFY_INTREN & priv->original_slvcmd))
>> -		outb_p(SMBSLVCMD_HST_NTFY_INTREN | priv->original_slvcmd,
>> -		       SMBSLVCMD(priv));
>> +	/*
>> +	 * Enable host notify interrupt and block the generation of interrupt
>> +	 * from the SMB_ALERT signal because the driver does not support
>> +	 * SMBus Alert yet.
> 
> does not support ... yet -->
>    has not supported ... yet
>    does not support
> 
> ?
yeah, yet is speculative, perhaps better to drop.

Jarkko

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v3] i2c: i801: Fix interrupt storm from SMB_ALERT signal
  2021-11-11 14:39   ` Jarkko Nikula
@ 2021-11-16 10:18     ` Jean Delvare
  2021-11-16 10:42       ` Andy Shevchenko
  0 siblings, 1 reply; 6+ messages in thread
From: Jean Delvare @ 2021-11-16 10:18 UTC (permalink / raw)
  To: Jarkko Nikula
  Cc: Andy Shevchenko, linux-i2c, Wolfram Sang, ck+kernelbugzilla,
	stephane.poignant

On Thu, 11 Nov 2021 16:39:28 +0200, Jarkko Nikula wrote:
> On 11/10/21 7:16 PM, Andy Shevchenko wrote:
> > On Wed, Nov 10, 2021 at 04:10:32PM +0200, Jarkko Nikula wrote:  
> >>  	/*
> >> -	 * Clear irq sources and report transaction result.
> >> +	 * Clear remaining irq sources: Completion of last command, errors  
> >> +	 * and the SMB_ALERT signal. SMB_ALERT status is set after signal
> >> +	 * assertion independently is the interrupt generation blocked or not  
> > 
> > is --> if ?
>
> hmm, I don't know which one is correct or neither. Or should it be 
> something like "independently of whether the interrupt generation is 
> blocked or not"? Grammar polices, please help me :-)

... independently of the interrupt generation being blocked or not.

Sounds better?

(I think your "of whether" variant is grammatically correct too, if you
prefer that.)

-- 
Jean Delvare
SUSE L3 Support

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v3] i2c: i801: Fix interrupt storm from SMB_ALERT signal
  2021-11-16 10:18     ` Jean Delvare
@ 2021-11-16 10:42       ` Andy Shevchenko
  2021-11-16 10:43         ` Andy Shevchenko
  0 siblings, 1 reply; 6+ messages in thread
From: Andy Shevchenko @ 2021-11-16 10:42 UTC (permalink / raw)
  To: Jean Delvare
  Cc: Jarkko Nikula, linux-i2c, Wolfram Sang, ck+kernelbugzilla,
	stephane.poignant

On Tue, Nov 16, 2021 at 11:18:21AM +0100, Jean Delvare wrote:
> On Thu, 11 Nov 2021 16:39:28 +0200, Jarkko Nikula wrote:
> > On 11/10/21 7:16 PM, Andy Shevchenko wrote:
> > > On Wed, Nov 10, 2021 at 04:10:32PM +0200, Jarkko Nikula wrote:  
> > >>  	/*
> > >> -	 * Clear irq sources and report transaction result.
> > >> +	 * Clear remaining irq sources: Completion of last command, errors  
> > >> +	 * and the SMB_ALERT signal. SMB_ALERT status is set after signal
> > >> +	 * assertion independently is the interrupt generation blocked or not  
> > > 
> > > is --> if ?
> >
> > hmm, I don't know which one is correct or neither. Or should it be 
> > something like "independently of whether the interrupt generation is 
> > blocked or not"? Grammar polices, please help me :-)
> 
> ... independently of the interrupt generation being blocked or not.
> 
> Sounds better?
> 
> (I think your "of whether" variant is grammatically correct too, if you
> prefer that.)

For the sake of bikeshedding :-) I lean to "whether" variant, because I think
the determiner usage is decreasing over time, while its presence makes language
richer.

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v3] i2c: i801: Fix interrupt storm from SMB_ALERT signal
  2021-11-16 10:42       ` Andy Shevchenko
@ 2021-11-16 10:43         ` Andy Shevchenko
  0 siblings, 0 replies; 6+ messages in thread
From: Andy Shevchenko @ 2021-11-16 10:43 UTC (permalink / raw)
  To: Jean Delvare
  Cc: Jarkko Nikula, linux-i2c, Wolfram Sang, ck+kernelbugzilla,
	stephane.poignant

On Tue, Nov 16, 2021 at 12:42:30PM +0200, Andy Shevchenko wrote:
> On Tue, Nov 16, 2021 at 11:18:21AM +0100, Jean Delvare wrote:
> > On Thu, 11 Nov 2021 16:39:28 +0200, Jarkko Nikula wrote:
> > > On 11/10/21 7:16 PM, Andy Shevchenko wrote:
> > > > On Wed, Nov 10, 2021 at 04:10:32PM +0200, Jarkko Nikula wrote:  

...

> > > >> +	 * Clear remaining irq sources: Completion of last command, errors  
> > > >> +	 * and the SMB_ALERT signal. SMB_ALERT status is set after signal
> > > >> +	 * assertion independently is the interrupt generation blocked or not  
> > > > 
> > > > is --> if ?
> > >
> > > hmm, I don't know which one is correct or neither. Or should it be 
> > > something like "independently of whether the interrupt generation is 
> > > blocked or not"? Grammar polices, please help me :-)
> > 
> > ... independently of the interrupt generation being blocked or not.
> > 
> > Sounds better?
> > 
> > (I think your "of whether" variant is grammatically correct too, if you
> > prefer that.)
> 
> For the sake of bikeshedding :-) I lean to "whether" variant, because I think

s/"whether"/"of whether"/

> the determiner usage is decreasing over time, while its presence makes language
> richer.

-- 
With Best Regards,
Andy Shevchenko



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2021-11-16 10:44 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-11-10 14:10 [PATCH v3] i2c: i801: Fix interrupt storm from SMB_ALERT signal Jarkko Nikula
2021-11-10 17:16 ` Andy Shevchenko
2021-11-11 14:39   ` Jarkko Nikula
2021-11-16 10:18     ` Jean Delvare
2021-11-16 10:42       ` Andy Shevchenko
2021-11-16 10:43         ` Andy Shevchenko

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.