[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=Nsqwc2YwoEvvAFJd-QBKsP75vjqbCcAjB=k2s5=oYL7AtgA@mail.gmail.com>
Date: Mon, 20 Mar 2023 12:07:31 +0100
From: Kornel Dulęba <korneld@...omium.org>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
Basavaraj Natikar <Basavaraj.Natikar@....com>,
Shyam Sundar S K <Shyam-sundar.S-k@....com>,
upstream@...ihalf.com, rad@...ihalf.com, mattedavis@...gle.com
Subject: Re: [PATCH] pinctrl: amd: Disable and mask interrupts on resume
On Mon, Mar 20, 2023 at 11:05 AM Linus Walleij <linus.walleij@...aro.org> wrote:
>
> On Mon, Mar 20, 2023 at 10:33 AM Kornel Dulęba <korneld@...omium.org> wrote:
>
> > This fixes a similar problem to the one observed in:
> > commit 4e5a04be88fe ("pinctrl: amd: disable and mask interrupts on probe").
> >
> > On some systems, during suspend/resume cycle firmware leaves
> > an interrupt enabled on a pin that is not used by the kernel.
> > This confuses the AMD pinctrl driver and causes spurious interrupts.
> >
> > The driver already has logic to detect if a pin is used by the kernel.
> > Leverage it to re-initialize interrupt fields of a pin only if it's not
> > used by us.
> >
> > Signed-off-by: Kornel Dulęba <korneld@...omium.org>
>
> Uh oh this looks serious.
> Do we need a Fixes: tag and Cc: stable on this patch?
I suppose so.
I didn't add them since I'm not sure what commit Fixes: should point to.
This issue seems to have always been there, so probably the first
commit of this driver?
Regards
Kornel Dulęba
Powered by blists - more mailing lists