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, 01 Aug 2017 21:23:39 +0200
From:   danilokrummrich@...develop.de
To:     Dmitry Torokhov <dmitry.torokhov@...il.com>
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 2017-08-01 21:07, Dmitry Torokhov wrote:
> 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.
> 
Thanks for clarification, didn't knew that. So,I will take this in 
advance.
>> >>+
>> >>+	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.
> 
Yes, I will do so.
> Thanks.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ