Re: [PATCH] Tracing events with GPIOs

On Fri, Dec 20, 2013 at 5:40 PM, Jean-Jacques Hiblot
[off-list ref] wrote:

2013/12/20 Alexandre Courbot [off-list ref]:

quoted

On Thu, Dec 19, 2013 at 8:38 PM, Jean-Jacques Hiblot
[off-list ref] wrote:

quoted

2013/12/19 Alexandre Courbot [off-list ref]:

quoted

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.

This is something I was wondering about for another reason. In many
cases the GPIOs that are physically available for probing will be
limited to the GPIOs already assigned a function (backlight control
for example), others are usually not routed except in eval boards or
early prototypes. And consequently those GPIOs will be requested by a
driver long before a probe is set.
It would be nice not to have to remove the driver to be able to use
this GPIO  as a probe. Maybe a gpiod_steal() interface and a flag
indicating that the GPIO can be safely stolen?

Mmm an explicit way to hijack a GPIO does not sound very safe. Do you
have concrete cases where you need to do so? I guess most boards you
may want to use this patch with would have at least some spare GPIOs
with pins somewhere on the board for this kind of purpose.

It's not always true. There are quite a few platforms where GPIOs is a
scarce resource (ppc for example). For example, the board I'm working
on at the moment is built around a APM powerpc which has only 16
GPIOs. Of those 16 GPIOS, some are not routed and most of the others
are hidden by the shielding so that I can probe only those that go to
external connectors.
IMHO it's probably the case for most of the boards that go into a
final product where EMI and space constraints are tight.
But I agree that's not safe. I thought that maybe a flag indicating
when it is safe would help (on my board that would be : ok to use the
GPIO that turns on or off the backlight, not ok to use the GPIO that
controls the power supply)

Rather than a flag per GPIO or board (my definition of "safe" is
rather strict ; I'd consider being able to mess with the backlight as
unsafe), I think I'd be more comfortable with having this as a kernel
config option, defaulting to 'n', and clearly stating that this can
potentially allow any GPIO to be hijacked (which is, apart for the
last point, what you already did). That way people can make an
informed decision about whether to enable it or not (disabled for
distro kernels, enabled for the occasional hacker who wants to use
this feature).

But before doing this, I'd like to make sure we explore every
possibility to make this safer by design.