linux-kernel - [RFC PATCH 0/2] Expose the PIO

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1448660173-29214-1-git-send-email-peda@lysator.liu.se>
Date:	Fri, 27 Nov 2015 22:36:11 +0100
From:	Peter Rosin <peda@...ator.liu.se>
To:	linux-gpio@...r.kernel.org
Cc:	Linus Walleij <linus.walleij@...aro.org>,
	Alexandre Courbot <gnurou@...il.com>,
	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Peter Rosin <peda@...ator.liu.se>,
	Peter Rosin <peda@...ntia.se>
Subject: [RFC PATCH 0/2] Expose the PIO_ISR register on SAMA5D3

From: Peter Rosin <peda@...ntia.se>

Hi!

I have a signal connected to a gpio pin which is the output of
a comparator. By changing the level of one of the inputs to the
comparator, I can detect the envelope of the other input to
the comparator by using a series of measurements much in the
same maner a manual ADC works, but watching for changes on the
comparator over a period of time instead of only the immediate
output.

Now, the input signal to the comparator might have a high frequency,
which will cause the output from the comparator (and thus the GPIO
input) to change rapidly.

A common(?) idiom for this is to use the interrupt status register
to catch the glitches, but then not have any interrupt tied to
the pin as that could possibly generate pointless bursts of
(expensive) interrupts.

So, these two patches expose an interface to the PIO_ISR register
of the pio controllers on the platform I'm targetting. The first
patch adds some infrastructure to the gpio core and the second
patch hooks up "my" pin controller.

But hey, this seems like an old problem and I was surprised that
I had to touch the source to do it. Which makes me wonder what I'm
missing and what others needing to see short pulses on a pin but not
needing/wanting interrupts are doing?

Yes, there needs to be a way to select the interrupt edge w/o
actually arming the interrupt, that is missing. And probably
other things too, but I didn't want to do more work in case this
is a dead end for some reason...

Cheers,
Peter

Peter Rosin (2):
  gpio: Add isr property of gpio pins
  pinctrl: at91: expose the isr bit

 Documentation/gpio/sysfs.txt   |   12 ++++++++++
 drivers/gpio/gpiolib-sysfs.c   |   30 ++++++++++++++++++++++++
 drivers/gpio/gpiolib.c         |   15 ++++++++++++
 drivers/pinctrl/pinctrl-at91.c |   50 ++++++++++++++++++++++++++++++++++++----
 include/linux/gpio/consumer.h  |    1 +
 include/linux/gpio/driver.h    |    2 ++
 6 files changed, 106 insertions(+), 4 deletions(-)

-- 
1.7.10.4

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