lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Thu, 5 Oct 2017 17:42:50 +0100
From:   Ed Blake <>
To:     James Hogan <>
Subject: Re: [PATCH 4/4] irqchip: imgpdc: Pass on peripheral mask/unmasks to
 the parent

On 05/10/17 16:43, Ed Blake wrote:
> On 05/10/17 16:26, James Hogan wrote:
>> On Thu, Oct 05, 2017 at 03:48:53PM +0100, Ed Blake wrote:
>>> I'm not sure how this is supposed to work, but the issue seems to be
>>> that without this patch the parent irq isn't being masked.  This is
>>> causing the parent handler (MIPS GIC in this case) to be called
>>> continuously.  This leads to the PDC irq being masked each time, but not
>>> the parent irq.  This is the callstack:
>>>     "irq-imgpdc.c"::perip_irq_mask
>>>     mask_ack_irq
>>>     handle_level_irq
>>>     generic_handle_irq_desc
>>>     generic_handle_irq
>>>     generic_handle_irq_desc
>>>     generic_handle_irq
>>>     gic_handle_shared_int
>>>     gic_handle_local_int
>>>     "irq-mips-gic.c"::gic_irq_dispatch
>>>     generic_handle_irq_desc
>>>     generic_handle_irq
>>>     do_IRQ
>>>     plat_irq_dispatch()
>> Right, yeh it shouldn't technically be masked by the parent (contrary to
>> what I said above) because its a chained handler, i.e. as far as the
>> kernel knows there could be other IRQs coming through that GIC pin that
>> would also get masked.
>> (though IIRC the perip IRQs can wake, but then they go straight out to
>> separate dedicated IRQ pins into the main IRQ chip, i.e. the GIC in this
>> case).
> That's right, each of the PDC peripherals (RTC, WD, IR) has a dedicated
> IRQ to the parent, and the sys wakes are muxed onto a single IRQ.
>> I think its worth understanding the root cause here though. Disabling
>> routing of an IRQ fundamentally should deassert it. Is it an actual
>> hardware bug that has reached silicon?
> So you think the PDC->parent IRQ must not be being de-asserted when
> IRQ_ROUTE is cleared?  I hadn't considered this and thought it was some
> persistence in the GIC due to not being masked / ack'd there.  Is that
> possible?  I'll discuss the possible IRQ_ROUTE issue with the hardware team.

OK, I've looked at the RTL and discussed it with the hardware team, and
yes it's a bug.  Clearing IRQ_ROUTE will not clear a PDC->GIC IRQ once
asserted, the only way is to clear the RTC->PDC IRQ, which we can't do
at this point as interrupts are disabled.  So I think this method of
propagating the mask to the parent is a reasonable workaround.  Is it ok
if I just modify the commit message and add comments to make it clear
it's a workaround for a h/w bug?


Powered by blists - more mailing lists