linux-kernel - Re: [PATCH] Tracing events with GPIOs

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]

Message-ID: <CAAVeFuKAGfnnsbtBg=zfmciyMdZHgrX_EpecqPjG=oO6rZdWag@mail.gmail.com>
Date:	Thu, 19 Dec 2013 15:52:47 +0900
From:	Alexandre Courbot <gnurou@...il.com>
To:	Jean-Jacques Hiblot <jjhiblot@...phandler.com>,
	Linus Walleij <linus.walleij@...aro.org>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	masami.hiramatsu.pt@...achi.com,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] Tracing events with GPIOs

On Tue, Dec 17, 2013 at 9:22 AM, Jean-Jacques Hiblot
<jjhiblot@...phandler.com> wrote:
>
> This patch implements a new tracing mechanism based on kprobes and using GPIO.
> Debugging with GPIO is very common in the embedded world. At least for those of us
> fortunate enough to have an oscilloscope or a logic analyzer on their bench...
> This is especially true if the issue results of a hardware/sofware interaction.
>
> Typical use cases are :
> * mixed software/hardware debugging. For example when the software detects a
>   situation of interest (typically an error) it toggles a GPIO to trigger the
>   oscilloscope acquisition.
> * direct latency/duration measurements.
>
> examples:
> To trig the oscilloscope whenever a mmc command error:
>   echo "p:my_mmc_blk_error mmc_blk_cmd_error gpiopulse@13" > /sys/kernel/debug/tracing/kprobe_events
>   echo 1 > /sys/kernel/debug/tracing/events/kprobes/my_mmc_blk_error/enable

I do like this idea, however I wonder if you could try and make it use
the new gpio descriptor API (see Documentation/gpio/) instead of the
GPIO integers we are trying to deprecate (well ok, we just *started*
claiming they are deprecated).

This would probably make things a little bit more complicated on your
side, due to the fact the gpiod API is new and probably does not cover
all your needs. But it would also make your approach safer and more
future proof, on top of helping us refine gpiod for various use cases.

The problems I can see so far:

- Using gpiod, GPIOs are not specified as integers, but are typically
mapped to a given (device, function) pair (device can be NULL) using
device tree/platform data/ACPI and obtained by the corresponding
device driver through gpiod_get(). You would need to find a different
way to specify GPIOs, maybe using the gpio_chip's label and the GPIO
hardware number.

- Even if you do so, there is currently no way to arbitrarily obtain a
GPIO that has not been explicitly mapped to a (device, function), and
IIUC you need to specify the tracing GPIO freely from user-space. This
hints that we will need to add a function that is sensibly the same as
gpio_request_one() to the gpiod API, but I wonder if that does not
defeats the purpose somehow.

So using gpiod we would have the dual problem of how to represent the
GPIO you need from user-space, and how you can safely obtain it. It
would be interesting to hear what Linus thinks about it, and if he has
better ideas about how we could solve these issues (as he usually has
;) ).

(note that it is *not* a hard requirement to use gpiod over the legacy
integer API, but considering this is the direction we are taking, it
would be nice to consider it and see how we could solve the issues
mentioned above)

Thanks,
Alex.
--
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/