linux-kernel - [PATCH v2 3/5] [RFC] gpio: pca953x: hack to map LEVEL irqs to EDGE irqs (may loose interrupts/hang)

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed,  4 Apr 2018 21:00:22 +0200
From:   "H. Nikolaus Schaller" <hns@...delico.com>
To:     galak@...eaurora.org, andy.shevchenko@...il.com,
        Rob Herring <robh+dt@...nel.org>,
        Pawel Moll <pawel.moll@....com>,
        Mark Rutland <mark.rutland@....com>,
        Ian Campbell <ijc+devicetree@...lion.org.uk>,
        Linus Walleij <linus.walleij@...aro.org>,
        Alexandre Courbot <gnurou@...il.com>
Cc:     devicetree@...r.kernel.org, linux-gpio@...r.kernel.org,
        linux-kernel@...r.kernel.org, letux-kernel@...nphoenux.org,
        kernel@...a-handheld.com,
        "H. Nikolaus Schaller" <hns@...delico.com>
Subject: [PATCH v2 3/5] [RFC] gpio: pca953x: hack to map LEVEL irqs to EDGE irqs (may loose interrupts/hang)

So far the interrupt type from the DTS is ignored, i.e.

	interrupt-parent = <&pcal6524>
	interrupts = <10 IRQ_TYPE_EDGE_RISING>

does not overwrite a

	devm_request_threaded_irq(..., IRQ_TYPE_LEVEL_LOW, ...)

in driver code. Therefore, the pca953x driver rejects the
setup of the irq because it can only handle EDGE interrupts
so far.

This hack translates level interrupts to edge interrupts
for the pca953x chips. This is enough for initial testing,
but not a good solution since interrupts may be lost.

If for example the connected chip requests a IRQ_TYPE_LEVEL_LOW
this may have the reason that there may be multiple different
interrupt sources in the chip - wired-or together to the
input of the pca953x. Now if we do edge detecion only,
the first interrupt will generate an EDGE_FALLING, but a
second one won't ever if the first interrupt wasn't already
processed.

IMHO a better solution would be to make the pca953x interrupt
handler check if the irq input is still in the active
level and run the device specific handler again.

But this is a major rework that I must leave to others
with more knowledge and time to work on it. This RFC
patch is for having a reminder.

Not Signed-off-by: H. Nikolaus Schaller <hns@...delico.com>
---
 drivers/gpio/gpio-pca953x.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index c70acba710c7..c21cfdee2eb6 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -521,6 +521,11 @@ static int pca953x_irq_set_type(struct irq_data *d, unsigned int type)
 	int bank_nb = d->hwirq / BANK_SZ;
 	u8 mask = 1 << (d->hwirq % BANK_SZ);

+	if (type & IRQ_TYPE_LEVEL_LOW)
+		type |= IRQ_TYPE_EDGE_FALLING;
+	if (type & IRQ_TYPE_LEVEL_HIGH)
+		type |= IRQ_TYPE_EDGE_RISING;
+
 	if (!(type & IRQ_TYPE_EDGE_BOTH)) {
 		dev_err(&chip->client->dev, "irq %d: unsupported type %d\n",
 			d->irq, type);
-- 
2.12.2