Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1418825imu; Wed, 28 Nov 2018 09:15:31 -0800 (PST) X-Google-Smtp-Source: AJdET5dYA2R1G8OxB2nnDuMQciww0+RNZncmQ6szj+OeeB8yMXY7TjBzKAepeuDXUe34A5Dm/QfD X-Received: by 2002:a62:113:: with SMTP id 19mr37589856pfb.176.1543425331774; Wed, 28 Nov 2018 09:15:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543425331; cv=none; d=google.com; s=arc-20160816; b=ktfv77AysjcVJZ+m/X8hHaNE9UPzwnEPEk7vnR/WMyu8qSmTq7QC5xi1gSOwdtQ2vl MLsFbYgpOSDCNEoZBRYMJba/+84aHxcaSqINpOsAVpqHiaTiPC/5ZQAAdZoTcWi6RI5k R6B3/cj8IuHR/iuI5OKRFDygUpBPRlvqE0C2ttI5KtSEdcIJaVUNjienCuxVk7BNXhU4 wlegqt5tQSh3m9EDMp3hF/JVBp+Y5hAb0vGi/gAceEbsX/WHnx34VslG+k6+UmtDgX+Y GxDSKc0g4eMWGiQsbSyXC8IInyBy2+nMA6VGPjdgiYIUi8JnRflRqbmwz0bLONr4tHMV kmBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=qoO3gHrM3UirCDMyT3LGOe9h2x4o7E6s54uFu9azkrc=; b=xVW634y/WVR8adTQzmcr3pephU6Qu5fJbAEO9E6GB+PRlyaCziJkk1SL6nVfR+HVY9 iCIxdIcwGgrbENFfMoVdMvsebS07zqfZLH6JYtBZ7t0V4CC7lEsqXpeHRiMTpooW7kxg pl+RY1SmkVl13GTVP3rcymUfiOo03pMMLkIa6TkMd8klBtE9Ewr3JvfJymor4tWtWJtM ROggI8brRT1KZeXtveXJ56E9kNLfutvicyAz2pWvqXlllpZE2eKl1ElgIwfVRO3wvCPf E5fRhjaUdUkjspOJ7aGU2TtC9OUI/W7H+2H+j4IuI2fkjQb+UdlWcC6YWQws5qf2JWCS UYaA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=SwQOGN5e; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i5si7059991pgg.279.2018.11.28.09.14.42; Wed, 28 Nov 2018 09:15:31 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=SwQOGN5e; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729143AbeK2EPu (ORCPT + 99 others); Wed, 28 Nov 2018 23:15:50 -0500 Received: from mail.kernel.org ([198.145.29.99]:38010 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728807AbeK2EPu (ORCPT ); Wed, 28 Nov 2018 23:15:50 -0500 Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 98B622086B; Wed, 28 Nov 2018 17:13:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1543425208; bh=m/j00d5/eO1GZ0ZOKqZAB9gyiMitG6wsBNb1kQywdvQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=SwQOGN5eppXKUKFsV4ifBAUtbinacfPX+/UjC776nHKrga3I3BpdBkYcAfZ3665Xr 5ZWXyOE7ytcQgFPU0yH/heKVKqhNbfvpUSb9+Hfu+BSWCjupg/Lnu4/YiEUCSe83LF gp6KR/VmrQfsAkiXkBx3WKExnXFLzwqg+zfudn+M= Received: by mail-qk1-f179.google.com with SMTP id m5so17203962qka.9; Wed, 28 Nov 2018 09:13:28 -0800 (PST) X-Gm-Message-State: AA+aEWYC0rc7aLVKzNCJ4ABUDiZVlhkqCfkJhICNkM8jqstsNxQv5zzw VKsqLU4iv4Z9NUHj3edFfuDy6uH2OtVOgIIZoQ== X-Received: by 2002:a37:b646:: with SMTP id g67mr34617688qkf.326.1543425207789; Wed, 28 Nov 2018 09:13:27 -0800 (PST) MIME-Version: 1.0 References: <20181114125432.16044-1-tom@aussec.com> <20181114125432.16044-2-tom@aussec.com> <20181116224919.GA18008@bogus> <20181117213522.12672utznrvpbn56@www.aussec.com> <20181118113502.55634v85ybgkt586@www.aussec.com> <20181127145729.128452ujmj4uhb55@aussec.com> In-Reply-To: <20181127145729.128452ujmj4uhb55@aussec.com> From: Rob Herring Date: Wed, 28 Nov 2018 11:13:16 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v7 1/4] dt-bindings: pps: descriptor-based gpio, capture-clear addition To: Tom Burkart Cc: "linux-kernel@vger.kernel.org" , devicetree@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 26, 2018 at 9:57 PM tom burkart wrote: > > Hi Rob, > > Quoting Rob Herring : > > > On Sat, Nov 17, 2018 at 6:35 PM tom burkart wrote: > >> > >> Quoting Rob Herring : > >> > >> > On Sat, Nov 17, 2018 at 4:35 AM tom burkart wrote: > >> >> > >> >> Quoting Rob Herring : > >> >> > >> >> > On Wed, Nov 14, 2018 at 11:54:29PM +1100, Tom Burkart wrote: > >> >> >> This patch changes the devicetree bindings for the pps-gpio driver > >> >> >> from the integer based ABI to the descriptor based ABI. > >> >> > ? That has nothing to do with DT. > >> >> > >> >> I believe it does, as the change in ABI forces a rename in the DT > >> >> naming convention. > >> >> This is due to the descriptor based ABI appending "-gpio" or > >> "-gpios" (see > >> >> Documentation/gpio/base.txt.) > >> >> Admittedly, I may have called it by the wrong name due to ignorance, > >> >> my apologies. > >> > > >> > If what you say is correct, then you can't change this driver. You'll > >> > break compatibility with any existing DT. > >> > > >> > Changing the binding reasoning should purely be that this is the > >> > preferred form. Bindings must be independent from changing kernel > >> > APIs. > >> > >> See comments from Philip Zabel. I misread the documentation and this > >> has now been corrected in v8 of the patch. I hope that eliminates all > >> comments made above. > >> > >> >> >> It also adds > >> >> >> documentation for the device tree capture-clear option. The legacy > >> >> >> device tree entry for the GPIO pin is supported. > >> >> >> > >> >> >> Signed-off-by: Tom Burkart > >> >> >> --- > >> >> >> Documentation/devicetree/bindings/pps/pps-gpio.txt | 8 ++++++-- > >> >> >> 1 file changed, 6 insertions(+), 2 deletions(-) > >> >> >> > >> >> >> diff --git a/Documentation/devicetree/bindings/pps/pps-gpio.txt > >> >> >> b/Documentation/devicetree/bindings/pps/pps-gpio.txt > >> >> >> index 3683874832ae..6c9fc0998d94 100644 > >> >> >> --- a/Documentation/devicetree/bindings/pps/pps-gpio.txt > >> >> >> +++ b/Documentation/devicetree/bindings/pps/pps-gpio.txt > >> >> >> @@ -5,19 +5,23 @@ a GPIO pin. > >> >> >> > >> >> >> Required properties: > >> >> >> - compatible: should be "pps-gpio" > >> >> >> -- gpios: one PPS GPIO in the format described by ../gpio/gpio.txt > >> >> >> +- pps-gpios: one PPS GPIO in the format described by ../gpio/gpio.txt > >> >> >> +Alternatively (DEPRECATED), instead of pps-gpios above, it may have: > >> >> >> +- gpios: one PPS GPIO as above > >> >> >> > >> >> >> Optional properties: > >> >> >> - assert-falling-edge: when present, assert is indicated by a > >> >> falling edge > >> >> >> (instead of by a rising edge) > >> >> >> +- capture-clear: when present, also capture the PPS clear event > >> >> > > >> >> > Is this a h/w thing? or driver configuration? > >> >> > >> >> Driver configuration. Most of the code was present in the driver, yet > >> >> it was not documented, or usable due to a two line (code) omission > >> >> (the value was not being fetched from DT). > >> > > >> > So what determines how you want to configure this? If the user will > >> > want to change it, then it should be a sysfs attr and exposed to > >> > userspace. If it depends on h/w config for a board then it can be in > >> > DT. > >> > >> Sorry, I misled you somewhat. If the PPS pulse active transition from > >> the hardware is on the falling edge, this flag is required to get the > >> OS to use that as the active transition. This would not change at the > >> user's whim but rather it is dependent on connected hardware. > > > > This description sounds more like 'assert-falling-edge' than 'capture-clear'. > > > > I'm still not clear on what 'capture-clear' is. > > Ignoring my patch for a minute, the pps_gpio_irq_handler will only > report a pps PPS_CAPTURECLEAR event if 'capture-clear' is set. As the > current pps-gpio driver is not able to set this flag, it cannot ever > report a PPS_CAPTURECLEAR event. > > My patch adds the ability to set this flag and adds the documentation > to go with it. > Admittedly, I do not require this functionality for what I want, but > working with the code, I noticed the omission and decided to add it > for someone else to use it, if they need it. > > I am happy to remove this out of my patch, if you feel this to be the > best way forward. I found this prior discussion on adding this[1]. Seems to me this should be userspace configurable if the GPIO line can interrupt on both edges. We shouldn't need a DT property to determine that. Rob [1] https://lore.kernel.org/patchwork/patch/557781/