Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp234035imu; Mon, 26 Nov 2018 20:19:00 -0800 (PST) X-Google-Smtp-Source: AFSGD/VRuvQjzYIqiXNebkuHZjf5x73/Cy9S3Q35arL1aJ5eS8RYG+eQcEwev39B0PxNowAjx9t4 X-Received: by 2002:a63:4d0e:: with SMTP id a14mr28061734pgb.408.1543292340020; Mon, 26 Nov 2018 20:19:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543292339; cv=none; d=google.com; s=arc-20160816; b=RVagT3hAjHuMNA3nVQ2M52c4cu0zJfKdtSHLhrMA2NmERRUrjuDGBG/wgeBuNNTy5j OoSJdeG12TEaTmo2C1Iq5vcSUBtczuIUQDHxy0Um3e/TKh2wsvs/87x6yU34U6C1VSJW 56N/QoqQoMwNlXcAxw+OAIJHqB+pnFlBttm0pl31mpC4dJCdoROvrQNXZck9S/xdsN0T /vMI9q1kzx2rjpRw5m66R5foDCa56fK+l5HPHjJLXMGMtIVRA+zDDJ0Rnpw3f6hFIrQX HlCqjoyVLCrJ41lsOKFNU4UTobe/lmXeQ7TFCPSOSsN48zS1hOWlsf7XyD8/OakO7uQF Wxxg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:content-transfer-encoding :content-disposition:mime-version:in-reply-to:references:subject:cc :to:from:date:message-id; bh=WyywXtPxkfm9Bsz6UIpDglrcVSGMHDu+B1FhcqXUH8I=; b=dbCgutyojG+f4T7w7umxEIhz9AdKZT/dLVfD1iFwWmYBtOFEeEt9YueRBhdjocOE5j 8abAVaUNBh4GWi0q3nEwziW7k4pDq05W8kzy7KUFlB3zxMPm2ONBT4YNHd55LGIMTmYu CeyeiPF3vIP7YwHgdkepmrcNZgi3w3lDi7/SmNBvp7IWWYjcQ9xL3x5XiXJA7QQRTBQO /KBS041oQXZlFc8NPyTFpajwLVOtU4wI1I17MbJyel+OdZrhPHTrwrYuBhX5a9Qp+Ffd TUuP6rEw27xMo3L3rkftGudkQwpZRKGzitV2r7weMwVBg4yPSkLQPMU2s69Rsgn0AnaC bxxw== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=aussec.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q20si2062282pll.255.2018.11.26.20.18.45; Mon, 26 Nov 2018 20:18:59 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=aussec.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728362AbeK0OyS (ORCPT + 99 others); Tue, 27 Nov 2018 09:54:18 -0500 Received: from csm1.csm-office.com.au ([165.228.118.109]:58120 "EHLO sleepy.aussec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727630AbeK0OyS (ORCPT ); Tue, 27 Nov 2018 09:54:18 -0500 X-Virus-Scanned: amavisd-new at aussec.com Received: from sneezy.aussec.com (sneezy.aussec.com [172.16.0.4]) by sleepy.aussec.com (8.15.2/8.15.2) with ESMTP id wAR3vYVn023150; Tue, 27 Nov 2018 14:57:39 +1100 Received: from csm3.csm-office.com.au (csm3.csm-office.com.au [172.16.0.11]) by aussec.com (Horde Framework) with HTTP; Tue, 27 Nov 2018 14:57:29 +1100 Message-ID: <20181127145729.128452ujmj4uhb55@aussec.com> Date: Tue, 27 Nov 2018 14:57:29 +1100 From: tom burkart To: Rob Herring Cc: "linux-kernel@vger.kernel.org" , devicetree@vger.kernel.org Subject: Re: [PATCH v7 1/4] dt-bindings: pps: descriptor-based gpio, capture-clear addition 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> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Tom