| Message ID | 20200301121945.3604-1-afzal.mohd.ma@gmail.com (mailing list archive) |
|---|---|
| State | Mainlined |
| Commit | 0d53cc8b3319fc6d0d9656c428d03a3c1628c19f |
| Headers | show |
| Series | [v3] ARM: OMAP: replace setup_irq() by request_irq() | expand |
* afzal mohammed <afzal.mohd.ma@gmail.com> [200301 04:20]: > request_irq() is preferred over setup_irq(). Invocations of setup_irq() > occur after memory allocators are ready. > > Per tglx[1], setup_irq() existed in olden days when allocators were not > ready by the time early interrupts were initialized. > > Hence replace setup_irq() by request_irq(). > > [1] https://lkml.kernel.org/r/alpine.DEB.2.20.1710191609480.1971@nanos > > Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com> > --- > Hi sub-arch maintainers, > > If the patch is okay, please take it thr' your tree. Thanks applied into omap-for-v5.7/omap1. Regards, Tony
Hi Arnd, On Wed, Mar 25, 2020 at 05:13:32PM +0530, afzal mohammed wrote: > On Tue, Mar 17, 2020 at 10:07:02AM +0530, afzal mohammed wrote: > > On Fri, Mar 13, 2020 at 09:15:20PM +0530, afzal mohammed wrote: > > > Can you please include the patches 6-10 directly into the armsoc tree ?, > > > Let me know if anything needs to be done from my side. > > Can you please consider for inclusion the above 5 patches. > > Sorry for pestering, i understand that none of the ARM SoC pull requests > has been picked up as opposed to what happens normally by this time of > development cycle. i think you have pulled the ARM SoC pull requests, but above changes doesn't seem to be applied, can you please respond on how to proceed ? (of all the tree-wide changes, the above are the only ones in limbo) Regards afzal
On Fri, Mar 27, 2020 at 11:46 AM afzal mohammed <afzal.mohd.ma@gmail.com> wrote: > > Hi Arnd, > > On Wed, Mar 25, 2020 at 05:13:32PM +0530, afzal mohammed wrote: > > On Tue, Mar 17, 2020 at 10:07:02AM +0530, afzal mohammed wrote: > > > On Fri, Mar 13, 2020 at 09:15:20PM +0530, afzal mohammed wrote: > > > > > Can you please include the patches 6-10 directly into the armsoc tree ?, > > > > Let me know if anything needs to be done from my side. > > > > Can you please consider for inclusion the above 5 patches. > > > > Sorry for pestering, i understand that none of the ARM SoC pull requests > > has been picked up as opposed to what happens normally by this time of > > development cycle. > > i think you have pulled the ARM SoC pull requests, but above changes > doesn't seem to be applied, can you please respond on how to proceed ? > (of all the tree-wide changes, the above are the only ones in limbo) Hi afzal, To make sure I get the right ones, could you bounce all the patches that are still missing to soc@kernel.org to let them show up in patchwork? I'll apply them right away after that. Sorry I forgot about them as I went through the patchwork backlog. Arnd
Hi Arnd, On Fri, Mar 27, 2020 at 11:55:36AM +0100, Arnd Bergmann wrote: > To make sure I get the right ones, could you bounce all the patches that are > still missing to soc@kernel.org to let them show up in patchwork? Done. If it helps, i can send the same patches w/ tags received as well. Regards afzal
Hi Arnd, On Fri, Mar 27, 2020 at 04:40:12PM +0530, afzal mohammed wrote: > On Fri, Mar 27, 2020 at 11:55:36AM +0100, Arnd Bergmann wrote: > > To make sure I get the right ones, could you bounce all the patches that are > > still missing to soc@kernel.org to let them show up in patchwork? > > Done. Sorry, i first forwarded, after that i bounced all, but not able to see the bounced ones in patchwork, only the forwarded ones. > If it helps, i can send the same patches w/ tags received as well. Let me know if if anything more needs to be done from my side. Regards afzal
On Fri, Mar 27, 2020 at 12:29 PM afzal mohammed <afzal.mohd.ma@gmail.com> wrote: > > Hi Arnd, > > On Fri, Mar 27, 2020 at 04:40:12PM +0530, afzal mohammed wrote: > > On Fri, Mar 27, 2020 at 11:55:36AM +0100, Arnd Bergmann wrote: > > > > To make sure I get the right ones, could you bounce all the patches that are > > > still missing to soc@kernel.org to let them show up in patchwork? > > > > Done. > > Sorry, i first forwarded, after that i bounced all, but not able to > see the bounced ones in patchwork, only the forwarded ones. Right, I see the same thing. Unfortunately, the version I have now doesn't work easily in git-am. > > If it helps, i can send the same patches w/ tags received as well. > > Let me know if if anything more needs to be done from my side. I can probably fix it up here, but it would help if you can resend the remaining patches using git-send-email with all the tags added in and the normal subject lines. Arnd
Hi, On Fri, Mar 27, 2020 at 12:58:57PM +0100, Arnd Bergmann wrote: > I can probably fix it up here, but it would help if you can resend the > remaining patches using git-send-email with all the tags added in > and the normal subject lines. i have sent the remaining patches using git send-email w/ all the tags collected and with normal subject lines, as a reply to your mail. They look okay in patchwork, let me know in case of any problems. Regards afzal
diff --git a/arch/arm/mach-omap1/pm.c b/arch/arm/mach-omap1/pm.c index d068958d6f8a..2c1e2b32b9b3 100644 --- a/arch/arm/mach-omap1/pm.c +++ b/arch/arm/mach-omap1/pm.c @@ -596,11 +596,6 @@ static irqreturn_t omap_wakeup_interrupt(int irq, void *dev) return IRQ_HANDLED; } -static struct irqaction omap_wakeup_irq = { - .name = "peripheral wakeup", - .handler = omap_wakeup_interrupt -}; - static const struct platform_suspend_ops omap_pm_ops = { @@ -613,6 +608,7 @@ static const struct platform_suspend_ops omap_pm_ops = { static int __init omap_pm_init(void) { int error = 0; + int irq; if (!cpu_class_is_omap1()) return -ENODEV; @@ -656,9 +652,12 @@ static int __init omap_pm_init(void) arm_pm_idle = omap1_pm_idle; if (cpu_is_omap7xx()) - setup_irq(INT_7XX_WAKE_UP_REQ, &omap_wakeup_irq); + irq = INT_7XX_WAKE_UP_REQ; else if (cpu_is_omap16xx()) - setup_irq(INT_1610_WAKE_UP_REQ, &omap_wakeup_irq); + irq = INT_1610_WAKE_UP_REQ; + if (request_irq(irq, omap_wakeup_interrupt, 0, "peripheral wakeup", + NULL)) + pr_err("Failed to request irq %d (peripheral wakeup)\n", irq); /* Program new power ramp-up time * (0 for most boards since we don't lower voltage when in deep sleep) diff --git a/arch/arm/mach-omap1/time.c b/arch/arm/mach-omap1/time.c index 524977a31a49..de590a85a42b 100644 --- a/arch/arm/mach-omap1/time.c +++ b/arch/arm/mach-omap1/time.c @@ -155,15 +155,11 @@ static irqreturn_t omap_mpu_timer1_interrupt(int irq, void *dev_id) return IRQ_HANDLED; } -static struct irqaction omap_mpu_timer1_irq = { - .name = "mpu_timer1", - .flags = IRQF_TIMER | IRQF_IRQPOLL, - .handler = omap_mpu_timer1_interrupt, -}; - static __init void omap_init_mpu_timer(unsigned long rate) { - setup_irq(INT_TIMER1, &omap_mpu_timer1_irq); + if (request_irq(INT_TIMER1, omap_mpu_timer1_interrupt, + IRQF_TIMER | IRQF_IRQPOLL, "mpu_timer1", NULL)) + pr_err("Failed to request irq %d (mpu_timer1)\n", INT_TIMER1); omap_mpu_timer_start(0, (rate / HZ) - 1, 1); clockevent_mpu_timer1.cpumask = cpumask_of(0); diff --git a/arch/arm/mach-omap1/timer32k.c b/arch/arm/mach-omap1/timer32k.c index 0ae6c52a7d70..780fdf03c3ce 100644 --- a/arch/arm/mach-omap1/timer32k.c +++ b/arch/arm/mach-omap1/timer32k.c @@ -148,15 +148,11 @@ static irqreturn_t omap_32k_timer_interrupt(int irq, void *dev_id) return IRQ_HANDLED; } -static struct irqaction omap_32k_timer_irq = { - .name = "32KHz timer", - .flags = IRQF_TIMER | IRQF_IRQPOLL, - .handler = omap_32k_timer_interrupt, -}; - static __init void omap_init_32k_timer(void) { - setup_irq(INT_OS_TIMER, &omap_32k_timer_irq); + if (request_irq(INT_OS_TIMER, omap_32k_timer_interrupt, + IRQF_TIMER | IRQF_IRQPOLL, "32KHz timer", NULL)) + pr_err("Failed to request irq %d(32KHz timer)\n", INT_OS_TIMER); clockevent_32k_timer.cpumask = cpumask_of(0); clockevents_config_and_register(&clockevent_32k_timer, diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c index 0d0a731cb476..8b09cdacc30d 100644 --- a/arch/arm/mach-omap2/timer.c +++ b/arch/arm/mach-omap2/timer.c @@ -91,12 +91,6 @@ static irqreturn_t omap2_gp_timer_interrupt(int irq, void *dev_id) return IRQ_HANDLED; } -static struct irqaction omap2_gp_timer_irq = { - .name = "gp_timer", - .flags = IRQF_TIMER | IRQF_IRQPOLL, - .handler = omap2_gp_timer_interrupt, -}; - static int omap2_gp_timer_set_next_event(unsigned long cycles, struct clock_event_device *evt) { @@ -382,8 +376,9 @@ static void __init omap2_gp_clockevent_init(int gptimer_id, &clockevent_gpt.name, OMAP_TIMER_POSTED); BUG_ON(res); - omap2_gp_timer_irq.dev_id = &clkev; - setup_irq(clkev.irq, &omap2_gp_timer_irq); + if (request_irq(clkev.irq, omap2_gp_timer_interrupt, + IRQF_TIMER | IRQF_IRQPOLL, "gp_timer", &clkev)) + pr_err("Failed to request irq %d (gp_timer)\n", clkev.irq); __omap_dm_timer_int_enable(&clkev, OMAP_TIMER_INT_OVERFLOW);
request_irq() is preferred over setup_irq(). Invocations of setup_irq() occur after memory allocators are ready. Per tglx[1], setup_irq() existed in olden days when allocators were not ready by the time early interrupts were initialized. Hence replace setup_irq() by request_irq(). [1] https://lkml.kernel.org/r/alpine.DEB.2.20.1710191609480.1971@nanos Signed-off-by: afzal mohammed <afzal.mohd.ma@gmail.com> --- Hi sub-arch maintainers, If the patch is okay, please take it thr' your tree. Regards afzal v3: * Split out from series, also create subarch level patch as Thomas suggested to take it thr' respective maintainers * Modify string displayed in case of error as suggested by Thomas * Re-arrange code as required to improve readability * Remove irrelevant parts from commit message & improve v2: * Replace pr_err("request_irq() on %s failed" by pr_err("%s: request_irq() failed" * Commit message massage arch/arm/mach-omap1/pm.c | 13 ++++++------- arch/arm/mach-omap1/time.c | 10 +++------- arch/arm/mach-omap1/timer32k.c | 10 +++------- arch/arm/mach-omap2/timer.c | 11 +++-------- 4 files changed, 15 insertions(+), 29 deletions(-)