Boot regression on Mackerel with current mainline

Boot regression on Mackerel with current mainline

[Rafael J. Wysocki]

Hi,

We seem to have a functional regression on Mackerel with 3.5-rc5 which
seems to be related to SDHI.  Namely, the SDHI driver appears to wait forever
for the devices to appear and commenting out all of the sdhi devices in the
board file works around the problem.

I can investigate some more later today if need be.

Thanks,
Rafael

Re: Boot regression on Mackerel with current mainline

[Guennadi Liakhovetski]

Hi Rafael

On Tue, 3 Jul 2012, Rafael J. Wysocki wrote:

> Hi,
> 
> We seem to have a functional regression on Mackerel with 3.5-rc5 which
> seems to be related to SDHI.  Namely, the SDHI driver appears to wait forever
> for the devices to appear and commenting out all of the sdhi devices in the
> board file works around the problem.
> 
> I can investigate some more later today if need be.

Have you checked the logs? Are you seeing any of these in the kernel log:

genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 

with an IRQ number at the end? If so, then this is a known problem, which 
I'd hoped would have been long fixed by now:

https://lkml.org/lkml/2012/6/12/151

We can nommit a fix for it in mmc, or we can try to re-ping Thomas - if 
this is indeed the bug, you're getting...

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: Boot regression on Mackerel with current mainline

[Rafael J. Wysocki]

On Tuesday, July 03, 2012, Guennadi Liakhovetski wrote:
> Hi Rafael
> 
> On Tue, 3 Jul 2012, Rafael J. Wysocki wrote:
> 
> > Hi,
> > 
> > We seem to have a functional regression on Mackerel with 3.5-rc5 which
> > seems to be related to SDHI.  Namely, the SDHI driver appears to wait forever
> > for the devices to appear and commenting out all of the sdhi devices in the
> > board file works around the problem.
> > 
> > I can investigate some more later today if need be.
> 
> Have you checked the logs? Are you seeing any of these in the kernel log:
> 
> genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 

I see this only once per boot, but then sh_mobile_sdhi is saying "timeout
waiting for hardware interrupt" pretty much continuously.

> with an IRQ number at the end? If so, then this is a known problem, which 
> I'd hoped would have been long fixed by now:
> 
> https://lkml.org/lkml/2012/6/12/151
> 
> We can nommit a fix for it in mmc, or we can try to re-ping Thomas - if 
> this is indeed the bug, you're getting...

I guess it is, but having reviewed the above e-mail thread I don't think any
fix from Thomas is going to appear.  So, please fix that in MMC, if possible.

Thanks,
Rafael

Re: Boot regression on Mackerel with current mainline

[Rafael J. Wysocki]

On Tuesday, July 03, 2012, Guennadi Liakhovetski wrote:
> Hi Rafael
> 
> On Tue, 3 Jul 2012, Rafael J. Wysocki wrote:
> 
> > Hi,
> > 
> > We seem to have a functional regression on Mackerel with 3.5-rc5 which
> > seems to be related to SDHI.  Namely, the SDHI driver appears to wait forever
> > for the devices to appear and commenting out all of the sdhi devices in the
> > board file works around the problem.
> > 
> > I can investigate some more later today if need be.
> 
> Have you checked the logs? Are you seeing any of these in the kernel log:
> 
> genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 

I see this only once per boot, but then sh_mobile_sdhi is saying "timeout
waiting for hardware interrupt" pretty much continuously.

> with an IRQ number at the end? If so, then this is a known problem, which 
> I'd hoped would have been long fixed by now:
> 
> https://lkml.org/lkml/2012/6/12/151
> 
> We can nommit a fix for it in mmc, or we can try to re-ping Thomas - if 
> this is indeed the bug, you're getting...

I guess it is, but having reviewed the above e-mail thread I don't think any
fix from Thomas is going to appear.  So, please fix that in MMC, if possible.

Thanks,
Rafael

Re: Boot regression on Mackerel with current mainline

[Guennadi Liakhovetski]

On Tue, 3 Jul 2012, Rafael J. Wysocki wrote:

> On Tuesday, July 03, 2012, Guennadi Liakhovetski wrote:
> > Hi Rafael
> > 
> > On Tue, 3 Jul 2012, Rafael J. Wysocki wrote:
> > 
> > > Hi,
> > > 
> > > We seem to have a functional regression on Mackerel with 3.5-rc5 which
> > > seems to be related to SDHI.  Namely, the SDHI driver appears to wait forever
> > > for the devices to appear and commenting out all of the sdhi devices in the
> > > board file works around the problem.
> > > 
> > > I can investigate some more later today if need be.
> > 
> > Have you checked the logs? Are you seeing any of these in the kernel log:
> > 
> > genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 
> 
> I see this only once per boot, but then sh_mobile_sdhi is saying "timeout
> waiting for hardware interrupt" pretty much continuously.

Yes, that's the one. Ok, let's fix it in the driver. In fact, a fix has 
already been submitted, but for 3.6. I hoped, 3.5 would resort to a softer 
form of the ONESHOT failing, so, I didn't push it for -rc. I think, the 
easiest would be to apply these two patches:

"mmc: tmio: use MMC opcode defines instead of numbers"
http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;hY8cd9cc217b0aa46089a3838a8b1c37b97aa08b

and

"mmc: extend and rename cd-gpio helpers to handle more slot GPIO functions"
http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;hØe60fb51effc83e6f53de191a8440f46e5a3f2c

The latter one looks big because of a rename, but with "-M" it's pretty 
trivial. Chris, do you agree?

Thanks
Guennadi

> > with an IRQ number at the end? If so, then this is a known problem, which 
> > I'd hoped would have been long fixed by now:
> > 
> > https://lkml.org/lkml/2012/6/12/151
> > 
> > We can nommit a fix for it in mmc, or we can try to re-ping Thomas - if 
> > this is indeed the bug, you're getting...
> 
> I guess it is, but having reviewed the above e-mail thread I don't think any
> fix from Thomas is going to appear.  So, please fix that in MMC, if possible.
> 
> Thanks,
> Rafael
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: Boot regression on Mackerel with current mainline

[Guennadi Liakhovetski]

On Tue, 3 Jul 2012, Rafael J. Wysocki wrote:

> On Tuesday, July 03, 2012, Guennadi Liakhovetski wrote:
> > Hi Rafael
> > 
> > On Tue, 3 Jul 2012, Rafael J. Wysocki wrote:
> > 
> > > Hi,
> > > 
> > > We seem to have a functional regression on Mackerel with 3.5-rc5 which
> > > seems to be related to SDHI.  Namely, the SDHI driver appears to wait forever
> > > for the devices to appear and commenting out all of the sdhi devices in the
> > > board file works around the problem.
> > > 
> > > I can investigate some more later today if need be.
> > 
> > Have you checked the logs? Are you seeing any of these in the kernel log:
> > 
> > genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 
> 
> I see this only once per boot, but then sh_mobile_sdhi is saying "timeout
> waiting for hardware interrupt" pretty much continuously.

Yes, that's the one. Ok, let's fix it in the driver. In fact, a fix has 
already been submitted, but for 3.6. I hoped, 3.5 would resort to a softer 
form of the ONESHOT failing, so, I didn't push it for -rc. I think, the 
easiest would be to apply these two patches:

"mmc: tmio: use MMC opcode defines instead of numbers"
http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=598cd9cc217b0aa46089a3838a8b1c37b97aa08b

and

"mmc: extend and rename cd-gpio helpers to handle more slot GPIO functions"
http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=d8e60fb51effc83e6f53de191a8440f46e5a3f2c

The latter one looks big because of a rename, but with "-M" it's pretty 
trivial. Chris, do you agree?

Thanks
Guennadi

> > with an IRQ number at the end? If so, then this is a known problem, which 
> > I'd hoped would have been long fixed by now:
> > 
> > https://lkml.org/lkml/2012/6/12/151
> > 
> > We can nommit a fix for it in mmc, or we can try to re-ping Thomas - if 
> > this is indeed the bug, you're getting...
> 
> I guess it is, but having reviewed the above e-mail thread I don't think any
> fix from Thomas is going to appear.  So, please fix that in MMC, if possible.
> 
> Thanks,
> Rafael
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: Boot regression on Mackerel with current mainline

[Chris Ball]

Hi Guennadi,

On Wed, Jul 04 2012, Guennadi Liakhovetski wrote:
> On Tue, 3 Jul 2012, Rafael J. Wysocki wrote:
>
>> On Tuesday, July 03, 2012, Guennadi Liakhovetski wrote:
>> > Hi Rafael
>> > 
>> > On Tue, 3 Jul 2012, Rafael J. Wysocki wrote:
>> > 
>> > > Hi,
>> > > 
>> > > We seem to have a functional regression on Mackerel with 3.5-rc5 which
>> > > seems to be related to SDHI.  Namely, the SDHI driver appears to wait forever
>> > > for the devices to appear and commenting out all of the sdhi devices in the
>> > > board file works around the problem.
>> > > 
>> > > I can investigate some more later today if need be.
>> > 
>> > Have you checked the logs? Are you seeing any of these in the kernel log:
>> > 
>> > genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 
>> 
>> I see this only once per boot, but then sh_mobile_sdhi is saying "timeout
>> waiting for hardware interrupt" pretty much continuously.
>
> Yes, that's the one. Ok, let's fix it in the driver. In fact, a fix has 
> already been submitted, but for 3.6. I hoped, 3.5 would resort to a softer 
> form of the ONESHOT failing, so, I didn't push it for -rc. I think, the 
> easiest would be to apply these two patches:
>
> "mmc: tmio: use MMC opcode defines instead of numbers"
> http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;hY8cd9cc217b0aa46089a3838a8b1c37b97aa08b
>
> and
>
> "mmc: extend and rename cd-gpio helpers to handle more slot GPIO functions"
> http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;hØe60fb51effc83e6f53de191a8440f46e5a3f2c
>
> The latter one looks big because of a rename, but with "-M" it's pretty 
> trivial. Chris, do you agree?

Is the minimal fix to just add "| IRQF_ONESHOT" to the request_threaded_irq
argument?  If so, I'd rather push just that for 3.5, and I can take care of
having that change appear simultaneously in linux-next so that there aren't
any conflicts.  Is that okay with you?

Thanks,

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

Re: Boot regression on Mackerel with current mainline

[Chris Ball]

Hi Guennadi,

On Wed, Jul 04 2012, Guennadi Liakhovetski wrote:
> On Tue, 3 Jul 2012, Rafael J. Wysocki wrote:
>
>> On Tuesday, July 03, 2012, Guennadi Liakhovetski wrote:
>> > Hi Rafael
>> > 
>> > On Tue, 3 Jul 2012, Rafael J. Wysocki wrote:
>> > 
>> > > Hi,
>> > > 
>> > > We seem to have a functional regression on Mackerel with 3.5-rc5 which
>> > > seems to be related to SDHI.  Namely, the SDHI driver appears to wait forever
>> > > for the devices to appear and commenting out all of the sdhi devices in the
>> > > board file works around the problem.
>> > > 
>> > > I can investigate some more later today if need be.
>> > 
>> > Have you checked the logs? Are you seeing any of these in the kernel log:
>> > 
>> > genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 
>> 
>> I see this only once per boot, but then sh_mobile_sdhi is saying "timeout
>> waiting for hardware interrupt" pretty much continuously.
>
> Yes, that's the one. Ok, let's fix it in the driver. In fact, a fix has 
> already been submitted, but for 3.6. I hoped, 3.5 would resort to a softer 
> form of the ONESHOT failing, so, I didn't push it for -rc. I think, the 
> easiest would be to apply these two patches:
>
> "mmc: tmio: use MMC opcode defines instead of numbers"
> http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=598cd9cc217b0aa46089a3838a8b1c37b97aa08b
>
> and
>
> "mmc: extend and rename cd-gpio helpers to handle more slot GPIO functions"
> http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=d8e60fb51effc83e6f53de191a8440f46e5a3f2c
>
> The latter one looks big because of a rename, but with "-M" it's pretty 
> trivial. Chris, do you agree?

Is the minimal fix to just add "| IRQF_ONESHOT" to the request_threaded_irq
argument?  If so, I'd rather push just that for 3.5, and I can take care of
having that change appear simultaneously in linux-next so that there aren't
any conflicts.  Is that okay with you?

Thanks,

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

Re: Boot regression on Mackerel with current mainline

[Guennadi Liakhovetski]

Hi Chris

On Tue, 10 Jul 2012, Chris Ball wrote:

> Hi Guennadi,
> 
> On Wed, Jul 04 2012, Guennadi Liakhovetski wrote:
> > On Tue, 3 Jul 2012, Rafael J. Wysocki wrote:
> >
> >> On Tuesday, July 03, 2012, Guennadi Liakhovetski wrote:
> >> > Hi Rafael
> >> > 
> >> > On Tue, 3 Jul 2012, Rafael J. Wysocki wrote:
> >> > 
> >> > > Hi,
> >> > > 
> >> > > We seem to have a functional regression on Mackerel with 3.5-rc5 which
> >> > > seems to be related to SDHI.  Namely, the SDHI driver appears to wait forever
> >> > > for the devices to appear and commenting out all of the sdhi devices in the
> >> > > board file works around the problem.
> >> > > 
> >> > > I can investigate some more later today if need be.
> >> > 
> >> > Have you checked the logs? Are you seeing any of these in the kernel log:
> >> > 
> >> > genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 
> >> 
> >> I see this only once per boot, but then sh_mobile_sdhi is saying "timeout
> >> waiting for hardware interrupt" pretty much continuously.
> >
> > Yes, that's the one. Ok, let's fix it in the driver. In fact, a fix has 
> > already been submitted, but for 3.6. I hoped, 3.5 would resort to a softer 
> > form of the ONESHOT failing, so, I didn't push it for -rc. I think, the 
> > easiest would be to apply these two patches:
> >
> > "mmc: tmio: use MMC opcode defines instead of numbers"
> > http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;hY8cd9cc217b0aa46089a3838a8b1c37b97aa08b
> >
> > and
> >
> > "mmc: extend and rename cd-gpio helpers to handle more slot GPIO functions"
> > http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;hØe60fb51effc83e6f53de191a8440f46e5a3f2c
> >
> > The latter one looks big because of a rename, but with "-M" it's pretty 
> > trivial. Chris, do you agree?
> 
> Is the minimal fix to just add "| IRQF_ONESHOT" to the request_threaded_irq
> argument?  If so, I'd rather push just that for 3.5, and I can take care of
> having that change appear simultaneously in linux-next so that there aren't
> any conflicts.  Is that okay with you?

For that you'd have to rebase -next, right? you'd like to do that? Because 
the patch

"mmc: extend and rename cd-gpio helpers to handle more slot GPIO functions"
http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;hØe60fb51effc83e6f53de191a8440f46e5a3f2c

obviously would conflict with adding "| IRQF_ONESHOT". Either would work 
with me, sure. Would you like me to submit this trivial ONESHOT fix and an 
updated version of the above patch, or would you prefer to do this 
yourself?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: Boot regression on Mackerel with current mainline

[Guennadi Liakhovetski]

Hi Chris

On Tue, 10 Jul 2012, Chris Ball wrote:

> Hi Guennadi,
> 
> On Wed, Jul 04 2012, Guennadi Liakhovetski wrote:
> > On Tue, 3 Jul 2012, Rafael J. Wysocki wrote:
> >
> >> On Tuesday, July 03, 2012, Guennadi Liakhovetski wrote:
> >> > Hi Rafael
> >> > 
> >> > On Tue, 3 Jul 2012, Rafael J. Wysocki wrote:
> >> > 
> >> > > Hi,
> >> > > 
> >> > > We seem to have a functional regression on Mackerel with 3.5-rc5 which
> >> > > seems to be related to SDHI.  Namely, the SDHI driver appears to wait forever
> >> > > for the devices to appear and commenting out all of the sdhi devices in the
> >> > > board file works around the problem.
> >> > > 
> >> > > I can investigate some more later today if need be.
> >> > 
> >> > Have you checked the logs? Are you seeing any of these in the kernel log:
> >> > 
> >> > genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 
> >> 
> >> I see this only once per boot, but then sh_mobile_sdhi is saying "timeout
> >> waiting for hardware interrupt" pretty much continuously.
> >
> > Yes, that's the one. Ok, let's fix it in the driver. In fact, a fix has 
> > already been submitted, but for 3.6. I hoped, 3.5 would resort to a softer 
> > form of the ONESHOT failing, so, I didn't push it for -rc. I think, the 
> > easiest would be to apply these two patches:
> >
> > "mmc: tmio: use MMC opcode defines instead of numbers"
> > http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=598cd9cc217b0aa46089a3838a8b1c37b97aa08b
> >
> > and
> >
> > "mmc: extend and rename cd-gpio helpers to handle more slot GPIO functions"
> > http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=d8e60fb51effc83e6f53de191a8440f46e5a3f2c
> >
> > The latter one looks big because of a rename, but with "-M" it's pretty 
> > trivial. Chris, do you agree?
> 
> Is the minimal fix to just add "| IRQF_ONESHOT" to the request_threaded_irq
> argument?  If so, I'd rather push just that for 3.5, and I can take care of
> having that change appear simultaneously in linux-next so that there aren't
> any conflicts.  Is that okay with you?

For that you'd have to rebase -next, right? you'd like to do that? Because 
the patch

"mmc: extend and rename cd-gpio helpers to handle more slot GPIO functions"
http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=d8e60fb51effc83e6f53de191a8440f46e5a3f2c

obviously would conflict with adding "| IRQF_ONESHOT". Either would work 
with me, sure. Would you like me to submit this trivial ONESHOT fix and an 
updated version of the above patch, or would you prefer to do this 
yourself?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: Boot regression on Mackerel with current mainline

[Chris Ball]

Hi Guennadi,

On Tue, Jul 10 2012, Guennadi Liakhovetski wrote:
>> > The latter one looks big because of a rename, but with "-M" it's pretty 
>> > trivial. Chris, do you agree?
>> 
>> Is the minimal fix to just add "| IRQF_ONESHOT" to the request_threaded_irq
>> argument?  If so, I'd rather push just that for 3.5, and I can take care of
>> having that change appear simultaneously in linux-next so that there aren't
>> any conflicts.  Is that okay with you?
>
> For that you'd have to rebase -next, right? you'd like to do that?

Yeah, I'm willing to rebase mmc-next for this -- I'd rather send the
simplest possible fix this late in 3.5-rc, and the rebase is simple.
Also, this fix is logically distinct from your rename patch.

I don't think I need you to send anything more, I'll add the initial
patch adding "| IRQF_ONESHOT", rebase your "extend and rename" patch on
top of that, push both to mmc-next, and then send the initial patch to
Linus in a few days.

Thanks,

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

Re: Boot regression on Mackerel with current mainline

[Chris Ball]

Hi Guennadi,

On Tue, Jul 10 2012, Guennadi Liakhovetski wrote:
>> > The latter one looks big because of a rename, but with "-M" it's pretty 
>> > trivial. Chris, do you agree?
>> 
>> Is the minimal fix to just add "| IRQF_ONESHOT" to the request_threaded_irq
>> argument?  If so, I'd rather push just that for 3.5, and I can take care of
>> having that change appear simultaneously in linux-next so that there aren't
>> any conflicts.  Is that okay with you?
>
> For that you'd have to rebase -next, right? you'd like to do that?

Yeah, I'm willing to rebase mmc-next for this -- I'd rather send the
simplest possible fix this late in 3.5-rc, and the rebase is simple.
Also, this fix is logically distinct from your rename patch.

I don't think I need you to send anything more, I'll add the initial
patch adding "| IRQF_ONESHOT", rebase your "extend and rename" patch on
top of that, push both to mmc-next, and then send the initial patch to
Linus in a few days.

Thanks,

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

Re: Boot regression on Mackerel with current mainline

[Guennadi Liakhovetski]

On Tue, 10 Jul 2012, Chris Ball wrote:

> Hi Guennadi,
> 
> On Tue, Jul 10 2012, Guennadi Liakhovetski wrote:
> >> > The latter one looks big because of a rename, but with "-M" it's pretty 
> >> > trivial. Chris, do you agree?
> >> 
> >> Is the minimal fix to just add "| IRQF_ONESHOT" to the request_threaded_irq
> >> argument?  If so, I'd rather push just that for 3.5, and I can take care of
> >> having that change appear simultaneously in linux-next so that there aren't
> >> any conflicts.  Is that okay with you?
> >
> > For that you'd have to rebase -next, right? you'd like to do that?
> 
> Yeah, I'm willing to rebase mmc-next for this -- I'd rather send the
> simplest possible fix this late in 3.5-rc, and the rebase is simple.
> Also, this fix is logically distinct from your rename patch.
> 
> I don't think I need you to send anything more, I'll add the initial
> patch adding "| IRQF_ONESHOT", rebase your "extend and rename" patch on
> top of that, push both to mmc-next, and then send the initial patch to
> Linus in a few days.

Great, thanks for taking care of this!

Regards
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: Boot regression on Mackerel with current mainline

[Guennadi Liakhovetski]

On Tue, 10 Jul 2012, Chris Ball wrote:

> Hi Guennadi,
> 
> On Tue, Jul 10 2012, Guennadi Liakhovetski wrote:
> >> > The latter one looks big because of a rename, but with "-M" it's pretty 
> >> > trivial. Chris, do you agree?
> >> 
> >> Is the minimal fix to just add "| IRQF_ONESHOT" to the request_threaded_irq
> >> argument?  If so, I'd rather push just that for 3.5, and I can take care of
> >> having that change appear simultaneously in linux-next so that there aren't
> >> any conflicts.  Is that okay with you?
> >
> > For that you'd have to rebase -next, right? you'd like to do that?
> 
> Yeah, I'm willing to rebase mmc-next for this -- I'd rather send the
> simplest possible fix this late in 3.5-rc, and the rebase is simple.
> Also, this fix is logically distinct from your rename patch.
> 
> I don't think I need you to send anything more, I'll add the initial
> patch adding "| IRQF_ONESHOT", rebase your "extend and rename" patch on
> top of that, push both to mmc-next, and then send the initial patch to
> Linus in a few days.

Great, thanks for taking care of this!

Regards
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/