[05/11] mmc: core: Clarify sdio_irq_pending flag for MMC_CAP2_SDIO_IRQ_NOTHREAD

Message ID 20190903142207.5825-6-ulf.hansson@linaro.org
State Superseded
Headers show
Series
  • mmc: core: PM fixes/improvements for SDIO IRQs
Related show

Commit Message

Ulf Hansson Sept. 3, 2019, 2:22 p.m.
In the single SDIO IRQ handler case, the sdio_irq_pending flag is used to
avoid reading the SDIO_CCCR_INTx register and instead immediately call the
SDIO func's >irq_handler() callback.

To clarify the use behind the flag for the MMC_CAP2_SDIO_IRQ_NOTHREAD case,
let's set the flag from inside sdio_signal_irq(), rather from
sdio_run_irqs(). Moreover, let's also reset the flag when the SDIO IRQ have
been properly processed.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

---
 drivers/mmc/core/sdio_irq.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

-- 
2.17.1

Comments

Matthias Kaehlcke Sept. 5, 2019, 12:34 a.m. | #1
On Tue, Sep 03, 2019 at 04:22:01PM +0200, Ulf Hansson wrote:
> In the single SDIO IRQ handler case, the sdio_irq_pending flag is used to

> avoid reading the SDIO_CCCR_INTx register and instead immediately call the

> SDIO func's >irq_handler() callback.

> 

> To clarify the use behind the flag for the MMC_CAP2_SDIO_IRQ_NOTHREAD case,

> let's set the flag from inside sdio_signal_irq(), rather from

> sdio_run_irqs(). Moreover, let's also reset the flag when the SDIO IRQ have

> been properly processed.

> 

> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

> ---

>  drivers/mmc/core/sdio_irq.c | 9 ++++++---

>  1 file changed, 6 insertions(+), 3 deletions(-)

> 

> diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c

> index f75043266984..0962a4357d54 100644

> --- a/drivers/mmc/core/sdio_irq.c

> +++ b/drivers/mmc/core/sdio_irq.c

> @@ -59,6 +59,7 @@ static int process_sdio_pending_irqs(struct mmc_host *host)

>  {

>  	struct mmc_card *card = host->card;

>  	int i, ret, count;

> +	bool sdio_irq_pending = host->sdio_irq_pending;

>  	unsigned char pending;

>  	struct sdio_func *func;

>  

> @@ -66,13 +67,16 @@ static int process_sdio_pending_irqs(struct mmc_host *host)

>  	if (mmc_card_suspended(card))

>  		return 0;

>  

> +	/* Clear the flag to indicate that we have processed the IRQ. */

> +	host->sdio_irq_pending = false;

> +


It's not entirely true that we have processed the IRQ,
the sdio_get_pending_irqs() below could fail and we'd return. However
I guess if it comes to that we are in a pretty bad shape already and
the value of the flag doesn't really matter.

>  	/*

>  	 * Optimization, if there is only 1 function interrupt registered

>  	 * and we know an IRQ was signaled then call irq handler directly.

>  	 * Otherwise do the full probe.

>  	 */

>  	func = card->sdio_single_irq;

> -	if (func && host->sdio_irq_pending) {

> +	if (func && sdio_irq_pending) {

>  		func->irq_handler(func);

>  		return 1;

>  	}

> @@ -110,7 +114,6 @@ static void sdio_run_irqs(struct mmc_host *host)

>  {

>  	mmc_claim_host(host);

>  	if (host->sdio_irqs) {

> -		host->sdio_irq_pending = true;

>  		process_sdio_pending_irqs(host);

>  		if (host->ops->ack_sdio_irq)

>  			host->ops->ack_sdio_irq(host);

> @@ -128,6 +131,7 @@ void sdio_irq_work(struct work_struct *work)

>  

>  void sdio_signal_irq(struct mmc_host *host)

>  {

> +	host->sdio_irq_pending = true;

>  	queue_delayed_work(system_wq, &host->sdio_irq_work, 0);

>  }

>  EXPORT_SYMBOL_GPL(sdio_signal_irq);

> @@ -173,7 +177,6 @@ static int sdio_irq_thread(void *_host)

>  		if (ret)

>  			break;

>  		ret = process_sdio_pending_irqs(host);

> -		host->sdio_irq_pending = false;

>  		mmc_release_host(host);

>  

>  		/*


Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Ulf Hansson Sept. 5, 2019, 7:29 a.m. | #2
On Thu, 5 Sep 2019 at 02:34, Matthias Kaehlcke <mka@chromium.org> wrote:
>

> On Tue, Sep 03, 2019 at 04:22:01PM +0200, Ulf Hansson wrote:

> > In the single SDIO IRQ handler case, the sdio_irq_pending flag is used to

> > avoid reading the SDIO_CCCR_INTx register and instead immediately call the

> > SDIO func's >irq_handler() callback.

> >

> > To clarify the use behind the flag for the MMC_CAP2_SDIO_IRQ_NOTHREAD case,

> > let's set the flag from inside sdio_signal_irq(), rather from

> > sdio_run_irqs(). Moreover, let's also reset the flag when the SDIO IRQ have

> > been properly processed.

> >

> > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

> > ---

> >  drivers/mmc/core/sdio_irq.c | 9 ++++++---

> >  1 file changed, 6 insertions(+), 3 deletions(-)

> >

> > diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c

> > index f75043266984..0962a4357d54 100644

> > --- a/drivers/mmc/core/sdio_irq.c

> > +++ b/drivers/mmc/core/sdio_irq.c

> > @@ -59,6 +59,7 @@ static int process_sdio_pending_irqs(struct mmc_host *host)

> >  {

> >       struct mmc_card *card = host->card;

> >       int i, ret, count;

> > +     bool sdio_irq_pending = host->sdio_irq_pending;

> >       unsigned char pending;

> >       struct sdio_func *func;

> >

> > @@ -66,13 +67,16 @@ static int process_sdio_pending_irqs(struct mmc_host *host)

> >       if (mmc_card_suspended(card))

> >               return 0;

> >

> > +     /* Clear the flag to indicate that we have processed the IRQ. */

> > +     host->sdio_irq_pending = false;

> > +

>

> It's not entirely true that we have processed the IRQ,

> the sdio_get_pending_irqs() below could fail and we'd return. However

> I guess if it comes to that we are in a pretty bad shape already and

> the value of the flag doesn't really matter.


Yes, that's my view as well.

>

> >       /*

> >        * Optimization, if there is only 1 function interrupt registered

> >        * and we know an IRQ was signaled then call irq handler directly.

> >        * Otherwise do the full probe.

> >        */

> >       func = card->sdio_single_irq;

> > -     if (func && host->sdio_irq_pending) {

> > +     if (func && sdio_irq_pending) {

> >               func->irq_handler(func);

> >               return 1;

> >       }

> > @@ -110,7 +114,6 @@ static void sdio_run_irqs(struct mmc_host *host)

> >  {

> >       mmc_claim_host(host);

> >       if (host->sdio_irqs) {

> > -             host->sdio_irq_pending = true;

> >               process_sdio_pending_irqs(host);

> >               if (host->ops->ack_sdio_irq)

> >                       host->ops->ack_sdio_irq(host);

> > @@ -128,6 +131,7 @@ void sdio_irq_work(struct work_struct *work)

> >

> >  void sdio_signal_irq(struct mmc_host *host)

> >  {

> > +     host->sdio_irq_pending = true;

> >       queue_delayed_work(system_wq, &host->sdio_irq_work, 0);

> >  }

> >  EXPORT_SYMBOL_GPL(sdio_signal_irq);

> > @@ -173,7 +177,6 @@ static int sdio_irq_thread(void *_host)

> >               if (ret)

> >                       break;

> >               ret = process_sdio_pending_irqs(host);

> > -             host->sdio_irq_pending = false;

> >               mmc_release_host(host);

> >

> >               /*

>

> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>


Thanks!

Kind regards
Uffe
Doug Anderson Sept. 5, 2019, 11:47 p.m. | #3
Hi,

On Tue, Sep 3, 2019 at 7:22 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>

> In the single SDIO IRQ handler case, the sdio_irq_pending flag is used to

> avoid reading the SDIO_CCCR_INTx register and instead immediately call the

> SDIO func's >irq_handler() callback.

>

> To clarify the use behind the flag for the MMC_CAP2_SDIO_IRQ_NOTHREAD case,

> let's set the flag from inside sdio_signal_irq(), rather from

> sdio_run_irqs().


I'm having a hard time parsing the above statement...  Can you reword
and maybe I'll understand?


> Moreover, let's also reset the flag when the SDIO IRQ have

> been properly processed.

>

> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

> ---

>  drivers/mmc/core/sdio_irq.c | 9 ++++++---

>  1 file changed, 6 insertions(+), 3 deletions(-)


Nice!  This looks like it addresses some of the things that came up in
the previous discussion [1] and should be a nice improvement.  From
re-reading that discussion that will probably change the behvaior
slightly (hopefully for the better) in the single-function case where
we might actually poll CCCR_INTx sometimes now.


> diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c

> index f75043266984..0962a4357d54 100644

> --- a/drivers/mmc/core/sdio_irq.c

> +++ b/drivers/mmc/core/sdio_irq.c

> @@ -59,6 +59,7 @@ static int process_sdio_pending_irqs(struct mmc_host *host)

>  {

>         struct mmc_card *card = host->card;

>         int i, ret, count;

> +       bool sdio_irq_pending = host->sdio_irq_pending;

>         unsigned char pending;

>         struct sdio_func *func;

>

> @@ -66,13 +67,16 @@ static int process_sdio_pending_irqs(struct mmc_host *host)

>         if (mmc_card_suspended(card))

>                 return 0;

>

> +       /* Clear the flag to indicate that we have processed the IRQ. */

> +       host->sdio_irq_pending = false;

> +

>         /*

>          * Optimization, if there is only 1 function interrupt registered

>          * and we know an IRQ was signaled then call irq handler directly.

>          * Otherwise do the full probe.

>          */

>         func = card->sdio_single_irq;

> -       if (func && host->sdio_irq_pending) {

> +       if (func && sdio_irq_pending) {

>                 func->irq_handler(func);

>                 return 1;

>         }

> @@ -110,7 +114,6 @@ static void sdio_run_irqs(struct mmc_host *host)

>  {

>         mmc_claim_host(host);

>         if (host->sdio_irqs) {

> -               host->sdio_irq_pending = true;

>                 process_sdio_pending_irqs(host);

>                 if (host->ops->ack_sdio_irq)

>                         host->ops->ack_sdio_irq(host);

> @@ -128,6 +131,7 @@ void sdio_irq_work(struct work_struct *work)

>

>  void sdio_signal_irq(struct mmc_host *host)

>  {

> +       host->sdio_irq_pending = true;


Is this safe to do without claiming the host or any other type of
locking?  sdio_signal_irq() is called directly from the interrupt
handler on dw_mmc with no locks held at all.  Could we have races /
problems with weakly ordered memory?

Maybe I'm not understanding why this has to move.  It seems like it
would have been fine to leave this part in sdio_run_irqs() where it
was...


[1] https://lore.kernel.org/r/CAD=FV=XBVRsdiOD0vhgTvMXmqm=fzy9Bzd_x=E1TNPBsT_D-tQ@mail.gmail.com

-Doug

>         queue_delayed_work(system_wq, &host->sdio_irq_work, 0);

>  }

>  EXPORT_SYMBOL_GPL(sdio_signal_irq);

> @@ -173,7 +177,6 @@ static int sdio_irq_thread(void *_host)

>                 if (ret)

>                         break;

>                 ret = process_sdio_pending_irqs(host);

> -               host->sdio_irq_pending = false;

>                 mmc_release_host(host);

>

>                 /*

> --

> 2.17.1

>
Ulf Hansson Sept. 6, 2019, 9:19 a.m. | #4
On Fri, 6 Sep 2019 at 01:47, Doug Anderson <dianders@chromium.org> wrote:
>

> Hi,

>

> On Tue, Sep 3, 2019 at 7:22 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:

> >

> > In the single SDIO IRQ handler case, the sdio_irq_pending flag is used to

> > avoid reading the SDIO_CCCR_INTx register and instead immediately call the

> > SDIO func's >irq_handler() callback.

> >

> > To clarify the use behind the flag for the MMC_CAP2_SDIO_IRQ_NOTHREAD case,

> > let's set the flag from inside sdio_signal_irq(), rather from

> > sdio_run_irqs().

>

> I'm having a hard time parsing the above statement...  Can you reword

> and maybe I'll understand?


Sure, I admit, it's not very good. :-) How about the below.

The sdio_irq_pending flag is used to let host drivers indicate that it
has signaled an IRQ. If that is the case and we only have a single
SDIO func that have claimed an SDIO IRQ, our assumption is that we can
avoid reading the SDIO_CCCR_INTx register and just call the SDIO func
irq handler immediately. This makes sense, but the flag is set/cleared
in a somewhat messy order, let's fix that up according to below.

First, the flag is currently set in sdio_run_irqs(), which is executed
as a work that was scheduled from sdio_signal_irq(). To make it more
implicit that the host have signaled an IRQ, let's instead immediately
set the flag in sdio_signal_irq(). This also makes the behavior
consistent with host drivers that uses the legacy,
mmc_signal_sdio_irq() API. This have no functional impact, because we
don't expect host drivers to call sdio_signal_irq() until after the
work (sdio_run_irqs()) have been executed anyways.

Second, currently we never clears the flag when using the
sdio_run_irqs() work, but only when using the sdio_irq_thread(). Let
make the behavior consistent, by moving the flag to be cleared inside
the common process_sdio_pending_irqs() function. Additionally, tweak
the behavior of the flag slightly, by avoiding to clear it unless we
processed the SDIO IRQ. The purpose with this at this point, is to
keep the information about whether there have been an SDIO IRQ
signaled by the host, so at system resume we can decide to process it
without reading the SDIO_CCCR_INTx register.

>

>

> > Moreover, let's also reset the flag when the SDIO IRQ have

> > been properly processed.

> >

> > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

> > ---

> >  drivers/mmc/core/sdio_irq.c | 9 ++++++---

> >  1 file changed, 6 insertions(+), 3 deletions(-)

>

> Nice!  This looks like it addresses some of the things that came up in

> the previous discussion [1] and should be a nice improvement.  From

> re-reading that discussion that will probably change the behvaior

> slightly (hopefully for the better) in the single-function case where

> we might actually poll CCCR_INTx sometimes now.


Correct!

>

>

> > diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c

> > index f75043266984..0962a4357d54 100644

> > --- a/drivers/mmc/core/sdio_irq.c

> > +++ b/drivers/mmc/core/sdio_irq.c

> > @@ -59,6 +59,7 @@ static int process_sdio_pending_irqs(struct mmc_host *host)

> >  {

> >         struct mmc_card *card = host->card;

> >         int i, ret, count;

> > +       bool sdio_irq_pending = host->sdio_irq_pending;

> >         unsigned char pending;

> >         struct sdio_func *func;

> >

> > @@ -66,13 +67,16 @@ static int process_sdio_pending_irqs(struct mmc_host *host)

> >         if (mmc_card_suspended(card))

> >                 return 0;

> >

> > +       /* Clear the flag to indicate that we have processed the IRQ. */

> > +       host->sdio_irq_pending = false;

> > +

> >         /*

> >          * Optimization, if there is only 1 function interrupt registered

> >          * and we know an IRQ was signaled then call irq handler directly.

> >          * Otherwise do the full probe.

> >          */

> >         func = card->sdio_single_irq;

> > -       if (func && host->sdio_irq_pending) {

> > +       if (func && sdio_irq_pending) {

> >                 func->irq_handler(func);

> >                 return 1;

> >         }

> > @@ -110,7 +114,6 @@ static void sdio_run_irqs(struct mmc_host *host)

> >  {

> >         mmc_claim_host(host);

> >         if (host->sdio_irqs) {

> > -               host->sdio_irq_pending = true;

> >                 process_sdio_pending_irqs(host);

> >                 if (host->ops->ack_sdio_irq)

> >                         host->ops->ack_sdio_irq(host);

> > @@ -128,6 +131,7 @@ void sdio_irq_work(struct work_struct *work)

> >

> >  void sdio_signal_irq(struct mmc_host *host)

> >  {

> > +       host->sdio_irq_pending = true;

>

> Is this safe to do without claiming the host or any other type of

> locking?  sdio_signal_irq() is called directly from the interrupt

> handler on dw_mmc with no locks held at all.  Could we have races /

> problems with weakly ordered memory?


At this point, for $subject patch and @subject series, I don't see any
issues. But perhaps when we go forward and start using the flag
slightly differently.

>

> Maybe I'm not understanding why this has to move.  It seems like it

> would have been fine to leave this part in sdio_run_irqs() where it

> was...


The changes later in the series relies on this change, as we start
making use of the flag to understand if we should ack an SDIO IRQ.

>

>

> [1] https://lore.kernel.org/r/CAD=FV=XBVRsdiOD0vhgTvMXmqm=fzy9Bzd_x=E1TNPBsT_D-tQ@mail.gmail.com

>

> -Doug

>

> >         queue_delayed_work(system_wq, &host->sdio_irq_work, 0);

> >  }

> >  EXPORT_SYMBOL_GPL(sdio_signal_irq);

> > @@ -173,7 +177,6 @@ static int sdio_irq_thread(void *_host)

> >                 if (ret)

> >                         break;

> >                 ret = process_sdio_pending_irqs(host);

> > -               host->sdio_irq_pending = false;

> >                 mmc_release_host(host);

> >

> >                 /*

> > --

> > 2.17.1

> >


Kind regards
Uffe
Ulf Hansson Sept. 8, 2019, 9:11 a.m. | #5
On Fri, 6 Sep 2019 at 23:30, Doug Anderson <dianders@chromium.org> wrote:
>

> Hi,

>

> On Fri, Sep 6, 2019 at 2:20 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:

> >

> > On Fri, 6 Sep 2019 at 01:47, Doug Anderson <dianders@chromium.org> wrote:

> > >

> > > Hi,

> > >

> > > On Tue, Sep 3, 2019 at 7:22 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:

> > > >

> > > > In the single SDIO IRQ handler case, the sdio_irq_pending flag is used to

> > > > avoid reading the SDIO_CCCR_INTx register and instead immediately call the

> > > > SDIO func's >irq_handler() callback.

> > > >

> > > > To clarify the use behind the flag for the MMC_CAP2_SDIO_IRQ_NOTHREAD case,

> > > > let's set the flag from inside sdio_signal_irq(), rather from

> > > > sdio_run_irqs().

> > >

> > > I'm having a hard time parsing the above statement...  Can you reword

> > > and maybe I'll understand?

> >

> > Sure, I admit, it's not very good. :-) How about the below.

> >

> > The sdio_irq_pending flag is used to let host drivers indicate that it

> > has signaled an IRQ. If that is the case and we only have a single

> > SDIO func that have claimed an SDIO IRQ, our assumption is that we can

> > avoid reading the SDIO_CCCR_INTx register and just call the SDIO func

> > irq handler immediately. This makes sense, but the flag is set/cleared

> > in a somewhat messy order, let's fix that up according to below.

> >

> > First, the flag is currently set in sdio_run_irqs(), which is executed

> > as a work that was scheduled from sdio_signal_irq(). To make it more

> > implicit that the host have signaled an IRQ, let's instead immediately

> > set the flag in sdio_signal_irq(). This also makes the behavior

> > consistent with host drivers that uses the legacy,

> > mmc_signal_sdio_irq() API. This have no functional impact, because we

> > don't expect host drivers to call sdio_signal_irq() until after the

> > work (sdio_run_irqs()) have been executed anyways.

> >

> > Second, currently we never clears the flag when using the

> > sdio_run_irqs() work, but only when using the sdio_irq_thread(). Let

> > make the behavior consistent, by moving the flag to be cleared inside

> > the common process_sdio_pending_irqs() function. Additionally, tweak

> > the behavior of the flag slightly, by avoiding to clear it unless we

> > processed the SDIO IRQ. The purpose with this at this point, is to

> > keep the information about whether there have been an SDIO IRQ

> > signaled by the host, so at system resume we can decide to process it

> > without reading the SDIO_CCCR_INTx register.

> >

> > >

> > >

> > > > Moreover, let's also reset the flag when the SDIO IRQ have

> > > > been properly processed.

> > > >

> > > > Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>

> > > > ---

> > > >  drivers/mmc/core/sdio_irq.c | 9 ++++++---

> > > >  1 file changed, 6 insertions(+), 3 deletions(-)

> > >

> > > Nice!  This looks like it addresses some of the things that came up in

> > > the previous discussion [1] and should be a nice improvement.  From

> > > re-reading that discussion that will probably change the behvaior

> > > slightly (hopefully for the better) in the single-function case where

> > > we might actually poll CCCR_INTx sometimes now.

> >

> > Correct!

> >

> > >

> > >

> > > > diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c

> > > > index f75043266984..0962a4357d54 100644

> > > > --- a/drivers/mmc/core/sdio_irq.c

> > > > +++ b/drivers/mmc/core/sdio_irq.c

> > > > @@ -59,6 +59,7 @@ static int process_sdio_pending_irqs(struct mmc_host *host)

> > > >  {

> > > >         struct mmc_card *card = host->card;

> > > >         int i, ret, count;

> > > > +       bool sdio_irq_pending = host->sdio_irq_pending;

> > > >         unsigned char pending;

> > > >         struct sdio_func *func;

> > > >

> > > > @@ -66,13 +67,16 @@ static int process_sdio_pending_irqs(struct mmc_host *host)

> > > >         if (mmc_card_suspended(card))

> > > >                 return 0;

> > > >

> > > > +       /* Clear the flag to indicate that we have processed the IRQ. */

> > > > +       host->sdio_irq_pending = false;

> > > > +

> > > >         /*

> > > >          * Optimization, if there is only 1 function interrupt registered

> > > >          * and we know an IRQ was signaled then call irq handler directly.

> > > >          * Otherwise do the full probe.

> > > >          */

> > > >         func = card->sdio_single_irq;

> > > > -       if (func && host->sdio_irq_pending) {

> > > > +       if (func && sdio_irq_pending) {

> > > >                 func->irq_handler(func);

> > > >                 return 1;

> > > >         }

> > > > @@ -110,7 +114,6 @@ static void sdio_run_irqs(struct mmc_host *host)

> > > >  {

> > > >         mmc_claim_host(host);

> > > >         if (host->sdio_irqs) {

> > > > -               host->sdio_irq_pending = true;

> > > >                 process_sdio_pending_irqs(host);

> > > >                 if (host->ops->ack_sdio_irq)

> > > >                         host->ops->ack_sdio_irq(host);

> > > > @@ -128,6 +131,7 @@ void sdio_irq_work(struct work_struct *work)

> > > >

> > > >  void sdio_signal_irq(struct mmc_host *host)

> > > >  {

> > > > +       host->sdio_irq_pending = true;

> > >

> > > Is this safe to do without claiming the host or any other type of

> > > locking?  sdio_signal_irq() is called directly from the interrupt

> > > handler on dw_mmc with no locks held at all.  Could we have races /

> > > problems with weakly ordered memory?

> >

> > At this point, for $subject patch and @subject series, I don't see any

> > issues. But perhaps when we go forward and start using the flag

> > slightly differently.

>

> Lockless concurrency always makes my head hurt (especially when I try

> to consider weakly ordered memory) and I've learned that the only way

> I can reason about it and have any belief that I got it right is to

> always make sure I access values in a context where things are locked.

> :-P

>

> Let's see if I can figure out any actual problem, though...

>

> Certainly the queue_delayed_work() would act as a barrier so you don't

> have to worry about the worker not seeing the "= true".

>

> I suppose it's definitely possible that (if the worker is already

> running) that our "= true" will get clobbered by an "= false" from a

> previous instance of the worker running.  I guess that's unlikely

> because we can't get a second IRQ signaled until the "->ack_sdio_irq"

> ran and presumably there's enough stuff after the "= false" that one

> of them would have a barrier that made sure that the "= false" didn't

> affect us in a delayed way.

>

> So I guess we're fine...


Yeah, the trick is simply that we don't expect another IRQ being
signaled via sdio_signal_irq(), until the ->ack_sdio_irq() has been
invoked.

And even if that happens, the works case scenario would be that we
would skip the 1-func optimized pat and end up reading the poll
CCCR_INTx. This should be fine.

Kind regards
Uffe

Patch

diff --git a/drivers/mmc/core/sdio_irq.c b/drivers/mmc/core/sdio_irq.c
index f75043266984..0962a4357d54 100644
--- a/drivers/mmc/core/sdio_irq.c
+++ b/drivers/mmc/core/sdio_irq.c
@@ -59,6 +59,7 @@  static int process_sdio_pending_irqs(struct mmc_host *host)
 {
 	struct mmc_card *card = host->card;
 	int i, ret, count;
+	bool sdio_irq_pending = host->sdio_irq_pending;
 	unsigned char pending;
 	struct sdio_func *func;
 
@@ -66,13 +67,16 @@  static int process_sdio_pending_irqs(struct mmc_host *host)
 	if (mmc_card_suspended(card))
 		return 0;
 
+	/* Clear the flag to indicate that we have processed the IRQ. */
+	host->sdio_irq_pending = false;
+
 	/*
 	 * Optimization, if there is only 1 function interrupt registered
 	 * and we know an IRQ was signaled then call irq handler directly.
 	 * Otherwise do the full probe.
 	 */
 	func = card->sdio_single_irq;
-	if (func && host->sdio_irq_pending) {
+	if (func && sdio_irq_pending) {
 		func->irq_handler(func);
 		return 1;
 	}
@@ -110,7 +114,6 @@  static void sdio_run_irqs(struct mmc_host *host)
 {
 	mmc_claim_host(host);
 	if (host->sdio_irqs) {
-		host->sdio_irq_pending = true;
 		process_sdio_pending_irqs(host);
 		if (host->ops->ack_sdio_irq)
 			host->ops->ack_sdio_irq(host);
@@ -128,6 +131,7 @@  void sdio_irq_work(struct work_struct *work)
 
 void sdio_signal_irq(struct mmc_host *host)
 {
+	host->sdio_irq_pending = true;
 	queue_delayed_work(system_wq, &host->sdio_irq_work, 0);
 }
 EXPORT_SYMBOL_GPL(sdio_signal_irq);
@@ -173,7 +177,6 @@  static int sdio_irq_thread(void *_host)
 		if (ret)
 			break;
 		ret = process_sdio_pending_irqs(host);
-		host->sdio_irq_pending = false;
 		mmc_release_host(host);
 
 		/*