2014/1/3 Alexandre Courbot <gnu...@gmail.com>: > On Fri, Dec 20, 2013 at 5:40 PM, Jean-Jacques Hiblot > <jjhib...@traphandler.com> wrote: >> 2013/12/20 Alexandre Courbot <gnu...@gmail.com>: >>> On Thu, Dec 19, 2013 at 8:38 PM, Jean-Jacques Hiblot >>> <jjhib...@traphandler.com> wrote: >>>> 2013/12/19 Alexandre Courbot <gnu...@gmail.com>: >>>>> 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. I agree and to be honest I'm not comfortable with the hijacker's way. Maybe I should just stick to the proper way of requesting a GPIO. When this feature is used, it'll not be in the field after production but during the development when building a new kernel is not really an issue.
> -- > To unsubscribe from this list: send the line "unsubscribe linux-gpio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
