linux-kernel - Re: [PATCH v3] serio: PS/2 gpio bit banging driver for the serio bus

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:   Tue, 1 Aug 2017 12:07:44 -0700
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     danilokrummrich@...develop.de
Cc:     linux-kernel@...r.kernel.org, linux-input@...r.kernel.org,
        linus.walleij@...aro.org, rdunlap@...radead.org
Subject: Re: [PATCH v3] serio: PS/2 gpio bit banging driver for the serio bus

On Tue, Aug 01, 2017 at 08:51:40PM +0200, danilokrummrich@...develop.de wrote:
> On 2017-08-01 19:32, Dmitry Torokhov wrote:
> >On Tue, Aug 01, 2017 at 06:26:14AM +0200, Danilo Krummrich wrote:
> >>+	irq = gpio_to_irq(drvdata->gpio_clk);
> >>+	if (!irq) {
> >>+		dev_err(dev, "cannot get irq from gpio %u\n",
> >>+			drvdata->gpio_clk);
> >>+		error = -ENXIO;
> >>+		goto err_free_serio;
> >>+	}
> >
> >
> >IRQ line does not have to be the same as GPIO pin. Describe it
> >separately in device properties and just do:
> >
> >	irq = platform_get_irq(pdev, 0);
> >
> >and use it in the request below.
> >
> In which constellation can they be different?

IIRC there are controllers that may not let you re-configure GPIO that
is reserved for interrupt, for output. So you could have a bit of
hardware logic that splits and isolates GPIO and interrupt line.

Also have the trigger come from the interrupt description as well in
case you happen to have inverter logic there.

> >>+
> >>+	error = devm_request_irq(dev, irq, ps2_gpio_irq, IRQF_NO_THREAD |
> >>+			IRQF_TRIGGER_FALLING, DRIVER_NAME, drvdata);
> >
> >This will not work if GPIO is behind I2C or other slow bus. Is it
> >essential that there is no scheduling delay here?
> >
> Yes it is. You are right, this wouldn't work. Was this the scenario
> you had in mind while
> writing the comment above?

No, that was just a general comment about GPIO on slow busses. You might
need to check gpiod_can_sleep() and abort driver load if gpio is
sleeping.

Thanks.

-- 
Dmitry