linux-kernel - Re: [PATCH 0/6 v8] gpio: Add block GPIO

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

Message-ID: <50BFC664.8080708@antcom.de>
Date:	Wed, 05 Dec 2012 23:10:44 +0100
From:	Roland Stigge <stigge@...com.de>
To:	Wolfgang Grandegger <wg@...ndegger.com>
CC:	gregkh@...uxfoundation.org, grant.likely@...retlab.ca,
	linus.walleij@...aro.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, w.sang@...gutronix.de,
	jbe@...gutronix.de, plagnioj@...osoft.com, highguy@...il.com,
	broonie@...nsource.wolfsonmicro.com, daniel-gl@....net,
	rmallon@...il.com, tru@...k-microwave.de, sr@...x.de
Subject: Re: [PATCH 0/6 v8] gpio: Add block GPIO

Hi Wolfgang,

On 05/12/12 19:44, Wolfgang Grandegger wrote:
>> * There is probably an explicit interrupt configuration necessary (via
>> struct gpio_block, and devicetree, respectively) since there are
>> constellations where gpio_to_irq() isn't working. E.g., in contrast to
>> controllers which are aware of their IRQs and providing to_irq(), there
>> is typically independent wiring from GPIO expander chips' interrupt line
>> to individual IRQ inputs on SoCs/CPUs. Or should all this be solved via
>> devicetree and drivers (which should support IRQ config where possible)?
> 
> Yes, I think it's up to the device tree or platform code to properly setup
> the interrupt... like for defining the GPIO block.

OK, sounds reasonable. Luckily, in reality it already works fine in this
regard with many current drivers.

>> * For the same reason, the IRQ flags are currently IRQF_TRIGGER_FALLING,
>> which isn't flexible. Instead, either preset by board setup/firmware, or
>> via interrupts config in devicetree (optional property of a GPIO block?)
> 
> Yes, and it did fail on my setup.

OK, will replace the flags with 0 (and need to fix my own board setup ;-) ).

>> * Some GPIOs' IRQs are not suitable for GPI input change detection. E.g.
>> on LPC32xx, I can configure the IRQ which is controlled directly by the
>> GPI's values as FALLING, RISING, HIGH /exclusive/ or LOW. I.e., this way
>> it's not possible to detect both 0->1 and 1->0 changes without
>> reconfiguring the GPIO controller inbetween. Other controllers provide a
>> dedicated interrupt on all values changes.
> 
> Hm.

For now, we are expecting IRQs to fire on "changes". Otherwise, the user
needs to handle the issue manually, using busy polling, manual
reconfiguration of the GPIO controller etc.

>> * Would IRQF_SHARED be appropriate to enable opening IRQ enabled GPIO
>> blocks multiple times?
> 
> Sounds reasonable for me. Some more comments in the patch mails...

OK, will do in the next update.

Thanks for your feedback,

Roland
--
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/