From: Tony Lindgren <tony@atomide.com>
To: Yi Zheng <goodmenzy@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
linux-kernel@vger.kernel.org, Jason Cooper <jason@lakedaemon.net>,
Sekhar Nori <nsekhar@ti.com>, Zheng Yi <yzheng@techyauld.com>
Subject: Re: Maybe a bug in kernel/irq/chip.c unmask_irq(), device IRQ masked unexpectedly. (re-formated the mail body, sorry)
Date: Wed, 9 Oct 2019 10:45:00 -0700 [thread overview]
Message-ID: <20191009174500.GM5610@atomide.com> (raw)
In-Reply-To: <CAJPHfYNx31=JjKiSEvihk_NszAWGuB-CKP84SAgx4EGsKrJxfA@mail.gmail.com>
Hi,
* Yi Zheng <goodmenzy@gmail.com> [191008 13:06]:
> NOTE: (1) My SoC is a single core ARM chip: TI-AM3352, so the raw
> spin-lock irq_desc->lock will be optimized to
> nothing. handle_level_irq() has no spin-lock protection, right?
Well not always, With CONFIG_SMP we modify only some of the SMP code on boot,
see arch/arm/kernel/head.S for smp_on_up and then the related macro usage.
> (2) In AM3352, INTC driver ACK the IRQ by write 0x01 into INTC Control
> Register(offset 0x48). The chip doc seems that bit[0] of
> INTC-Control Reg is only an enable/disable flag. The IRQ may
> generated even if no ACK action done. Any one can give me an
> clarification?
The TI INTC is probably better documented in dm3630 trm, it's the same
controller but with a different revision.
> (3) My analysis is not verified on the real machine. After some code
> change for debug(add counter to indicates the iteration level, save
> the IRQ mask status etc.), the device IRQ wrongly masked problem
> vanished. In fact, the original code can not re-produce the
> phenomena easily. In tens of machine, only one can get the bug. I
> have try my best to hacking the code, but the only verified result
> is here: when bug occur, the HW IRQ is masked, but the
> IRQD_IRQ_MASKED flag is cleared.
>
> My fixup is in the attachment, which remove the unexpected time window of
> IRQ iteration.
Let's see what Thomas has to say for that. Meanwhile, please take a
look at Documentation/process/submitting-patches.rst for getting things
right for sending out patches that can be applied without manual
editing :)
Cheers,
Tony
> --- kernel/irq/chip.c 2019-07-13 09:28:23.683787367 +0800
> +++ /tmp/chip.c 2019-10-08 11:32:35.082258572 +0800
> @@ -432,8 +432,8 @@ void unmask_irq(struct irq_desc *desc)
> return;
>
> if (desc->irq_data.chip->irq_unmask) {
> - desc->irq_data.chip->irq_unmask(&desc->irq_data);
> irq_state_clr_masked(desc);
> + desc->irq_data.chip->irq_unmask(&desc->irq_data);
> }
> }
>
next prev parent reply other threads:[~2019-10-09 17:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-08 13:04 Maybe a bug in kernel/irq/chip.c unmask_irq(), device IRQ masked unexpectedly. (re-formated the mail body, sorry) Yi Zheng
2019-10-09 17:45 ` Tony Lindgren [this message]
2019-10-10 6:20 ` Yi Zheng
2019-10-10 13:51 ` Tony Lindgren
2019-10-14 12:34 ` Thomas Gleixner
2019-10-14 14:51 ` Yi Zheng
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191009174500.GM5610@atomide.com \
--to=tony@atomide.com \
--cc=goodmenzy@gmail.com \
--cc=jason@lakedaemon.net \
--cc=linux-kernel@vger.kernel.org \
--cc=nsekhar@ti.com \
--cc=tglx@linutronix.de \
--cc=yzheng@techyauld.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.