mbox series

[0/3] gpiolib: cdev: allow edge event timestamps to be configured as REALTIME

Message ID 20201014062740.78977-1-warthog618@gmail.com
Headers show
Series gpiolib: cdev: allow edge event timestamps to be configured as REALTIME | expand

Message

Kent Gibson Oct. 14, 2020, 6:27 a.m. UTC
This patch set adds the option to select CLOCK_REALTIME as the source
clock for line events.

The first patch is the core of the change, while the remaining two update
the GPIO tools to make use of the new option.

Kent Gibson (3):
  gpiolib: cdev: allow edge event timestamps to be configured as
    REALTIME
  tools: gpio: add support for reporting realtime event clock to lsgpio
  tools: gpio: add option to report wall-clock time to gpio-event-mon

 drivers/gpio/gpiolib-cdev.c | 21 ++++++++++++++++++---
 drivers/gpio/gpiolib.h      |  1 +
 include/uapi/linux/gpio.h   | 12 +++++++++---
 tools/gpio/gpio-event-mon.c |  6 +++++-
 tools/gpio/lsgpio.c         |  4 ++++
 5 files changed, 37 insertions(+), 7 deletions(-)

Comments

Bartosz Golaszewski Oct. 14, 2020, 7:59 a.m. UTC | #1
On Wed, Oct 14, 2020 at 8:28 AM Kent Gibson <warthog618@gmail.com> wrote:
>
> This patch set adds the option to select CLOCK_REALTIME as the source
> clock for line events.
>
> The first patch is the core of the change, while the remaining two update
> the GPIO tools to make use of the new option.
>
> Kent Gibson (3):
>   gpiolib: cdev: allow edge event timestamps to be configured as
>     REALTIME
>   tools: gpio: add support for reporting realtime event clock to lsgpio
>   tools: gpio: add option to report wall-clock time to gpio-event-mon
>
>  drivers/gpio/gpiolib-cdev.c | 21 ++++++++++++++++++---
>  drivers/gpio/gpiolib.h      |  1 +
>  include/uapi/linux/gpio.h   | 12 +++++++++---
>  tools/gpio/gpio-event-mon.c |  6 +++++-
>  tools/gpio/lsgpio.c         |  4 ++++
>  5 files changed, 37 insertions(+), 7 deletions(-)
>
> --
> 2.28.0
>

The entire series looks good to me.

Reviewed-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>

Linus: do you think this can still make it into v5.10 as an
improvement to the new uAPI or do we have to wait until the next merge
window? Will you send another PR in this cycle?

Bartosz