lists.openwall.net   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-next>] [day] [month] [year] [list]
Message-ID: <CAK=oMXftjqjoM2gCrgyc+YkznCOz-V=McEx74xPbxZ2O-UFmFQ@mail.gmail.com>
Date:	Thu, 19 Jun 2014 20:34:12 +0800
From:	Yi Zhang <yizhang.mrvl@...il.com>
To:	Mark Brown <broonie@...nel.org>
Cc:	linux-kernel@...r.kernel.org, Yi Zhang <yizhang@...vell.com>,
	zhangwm@...vell.com, shayp@...vell.com, zhouqiao@...vell.com
Subject: [Question] is it a race condition in acking PMIC sub-interrupt?

Hi, Mark:

Sorry to trouble you, I met a question related the interrupt ack
sequence in regmap framework; could you please share your advice on
this? thank you very much;

1) the following is the connection related to PMIC on my development board:

     PMIC ---> GPIO --> GIC

     the GPIO is edge triggered interrupt controller, while GIC is
level triggered;
2)  there are several interrupt ack registers in PMIC; in
regmap_irq_thread(), we acked them one by one; but if before we finish
acking all the registers, another interrupt on the "has-been-acked
register" is triggered, the interrupt line will be pulled up or down,
in the 1) case, because GPIO is edge triggered, it cannot "see" this
interrupt, then GIC cannot know either; while in regmap_irq_thread(),
the software thinks it has acked all the interrupt, then goes on; but
actually the interrupt is missed and cannot be resumed in the 1)
scenario;

Please point out what I'm wrong; thanks;

So if this is true, what about using the following methods to fix it?
a) disable all the interrupts just before ack, then enable them after
ack finished; the cons are a) the interrupt is ignored in the process;
b) we need to manipulate the registers more frequently, after all, I2C
is a slow bus;
b) polling until the interrupts are acked; but I think it's hard to
guarantee that because the interrupt is asynchronous;

and one more question:
Seems we shouldn't connect an interrupt controller as PMIC with an
edge triggered interrupt controller? Could you please share your
opinion? we can modify the hardware connection accordingly;

thank you very much; :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ