From: Alexander Usyskin alexander.usyskin@intel.com
This fixes regression introduced by commit 8d52af6795c0 ("mei: speed up the power down flow")
In power down or suspend flow a message can still be received from the FW because the clients fake disconnection. In normal case we interpret messages w/o destination as corrupted and link reset is performed in order to clean the channel, but during power down link reset is already in progress resulting in endless loop. To resolve the issue under power down flow we discard messages silently.
Cc: stable@vger.kernel.org 4.16+ Fixes: 8d52af6795c0 ("mei: speed up the power down flow") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199541 Signed-off-by: Alexander Usyskin alexander.usyskin@intel.com Signed-off-by: Tomas Winkler tomas.winkler@intel.com --- drivers/misc/mei/interrupt.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/mei/interrupt.c b/drivers/misc/mei/interrupt.c index b0b8f18a85e3..6649f0d56d2f 100644 --- a/drivers/misc/mei/interrupt.c +++ b/drivers/misc/mei/interrupt.c @@ -310,8 +310,11 @@ int mei_irq_read_handler(struct mei_device *dev, if (&cl->link == &dev->file_list) { /* A message for not connected fixed address clients * should be silently discarded + * On power down client may be force cleaned, + * silently discard such messages */ - if (hdr_is_fixed(mei_hdr)) { + if (hdr_is_fixed(mei_hdr) || + dev->dev_state == MEI_DEV_POWER_DOWN) { mei_irq_discard_msg(dev, mei_hdr); ret = 0; goto reset_slots;
On Tue, May 29, 2018 at 11:56:16AM +0300, Martin Peres wrote:
From: Alexander Usyskin alexander.usyskin@intel.com
This fixes regression introduced by commit 8d52af6795c0 ("mei: speed up the power down flow")
In power down or suspend flow a message can still be received from the FW because the clients fake disconnection. In normal case we interpret messages w/o destination as corrupted and link reset is performed in order to clean the channel, but during power down link reset is already in progress resulting in endless loop. To resolve the issue under power down flow we discard messages silently.
Cc: stable@vger.kernel.org 4.16+ Fixes: 8d52af6795c0 ("mei: speed up the power down flow") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199541 Signed-off-by: Alexander Usyskin alexander.usyskin@intel.com Signed-off-by: Tomas Winkler tomas.winkler@intel.com
drivers/misc/mei/interrupt.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
Shouldn't this patch go through the char/misc maintainer?
confused,
greg k-h
On 29/05/18 12:04, Greg KH wrote:
On Tue, May 29, 2018 at 11:56:16AM +0300, Martin Peres wrote:
From: Alexander Usyskin alexander.usyskin@intel.com
This fixes regression introduced by commit 8d52af6795c0 ("mei: speed up the power down flow")
In power down or suspend flow a message can still be received from the FW because the clients fake disconnection. In normal case we interpret messages w/o destination as corrupted and link reset is performed in order to clean the channel, but during power down link reset is already in progress resulting in endless loop. To resolve the issue under power down flow we discard messages silently.
Cc: stable@vger.kernel.org 4.16+ Fixes: 8d52af6795c0 ("mei: speed up the power down flow") Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=199541 Signed-off-by: Alexander Usyskin alexander.usyskin@intel.com Signed-off-by: Tomas Winkler tomas.winkler@intel.com
drivers/misc/mei/interrupt.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
Shouldn't this patch go through the char/misc maintainer?
confused,
Sorry for the confusion. I actually tried to avoid this situation by not Cc:ing everyone, but git send-email did not prompt me to validate the final email after setting some of the --no-*-cc. Next time, I'll add --dry-run just to be sure...
Anyway, what I was trying to do is submit this patch to our CI system since we were the ones reporting the bug. If successful, we will then apply this patch as a temporary workaround (our core-for-CI branch) to gather better statistics (reproducing rate is ~5% of our CI runs), and allow it to land upstream. We'll then drop our workaround when upstream with the fix gets backmerged in drm-tip.
Sorry again for the noise!
Martin
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Martin Peres