Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3281398imu; Sat, 24 Nov 2018 01:47:16 -0800 (PST) X-Google-Smtp-Source: AFSGD/Vpc5+wOn+MSuZoYt0KGsmwwzCbSbr2y9qoadbgmxQW6qceV86dXVthq3DvoBvo1sWItuA5 X-Received: by 2002:a63:f111:: with SMTP id f17mr17402100pgi.236.1543052836445; Sat, 24 Nov 2018 01:47:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543052836; cv=none; d=google.com; s=arc-20160816; b=ctFV2CKysW/6FhxlB/IOQAlMRuA1lVW1ZiBgnJDFMpdqHxTVHZN56jDMLhco7kf+wj MxVRRyXhNQK3Rl4kiC9mtyqWZK1bZ1i2NAz2o8ZuOIN4eYyIiARDx2nYsQD5fbl85nNn 6J6Dj9GweYkNgSu5YRV31NOqPWBGie9sowv4fEQ/992lUJc3PwWyhlmIS6JiyURx+CDr xGW1vhrBQS/nh9qvYpPUU3qdbZGY2RrlhsIPpwt1hKpwyqP3D6N0sLv14vV387DJidDg 3ipO13NQiHjiA93TXvBq+14xjJ3nor4Bl4+yjqaoMxOevmERUe5Vr6M8kBD+OAD+rPah 7axA== 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=G34JM/yw/0rs9Lhwm89nXjTUO23eoEHs3veclgb8vi0=; b=WHBXXWXbYa7IYkUGaEg71bMMRBLSnRrThiDIWtrnkIgokCLdd7fCttgL6ArUEIi6pI gtF7jByxhsiamSU+kz8HZVMfOwMVS861X6aTM66FhnLROYlAkdbIDegqvqjTOIhkJlXO KRyzkAkxeAgVmHO4kTFiCeUZnnG7guHGF/MNkr4xnz1Tb2yIkQH21i1iEiiFc7ciqRpv 9XLO+Fii2n4VPejgwoaJbg20fHGuXOOhzardnALCpgB+iHOb7+FuoRNG8+lzuyTGR065 c0mmX6uQpZMpggFXL6PsixgIq6lfAw9mqKy6Us/0Y9odYb+qU04WujeFNBq/Fkf+jvW7 nDRQ== 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 187si36778581pfv.238.2018.11.24.01.46.59; Sat, 24 Nov 2018 01:47:16 -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 S1726052AbeKXUeW (ORCPT + 99 others); Sat, 24 Nov 2018 15:34:22 -0500 Received: from csm1.csm-office.com.au ([165.228.118.109]:44136 "EHLO sleepy.aussec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725878AbeKXUeW (ORCPT ); Sat, 24 Nov 2018 15:34:22 -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 wAO9k5is006959; Sat, 24 Nov 2018 20:46:11 +1100 Received: from c110-21-61-29.farfl4.nsw.optusnet.com.au (c110-21-61-29.farfl4.nsw.optusnet.com.au [110.21.61.29]) by www.aussec.com (Horde Framework) with HTTP; Sat, 24 Nov 2018 20:46:00 +1100 Message-ID: <20181124204600.176178e9k4t04sm0@www.aussec.com> Date: Sat, 24 Nov 2018 20:46:00 +1100 From: tom burkart To: Philipp Zabel Cc: LKML Subject: Re: [PATCH v8 2/4] pps: descriptor-based gpio, capture-clear addition References: <20181117130337.5856-1-tom@aussec.com> <20181117130337.5856-2-tom@aussec.com> <20181117130337.5856-3-tom@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 Philipp, Quoting Philipp Zabel : > On Sat, Nov 17, 2018 at 2:07 PM Tom Burkart wrote: >> >> This patch changes the GPIO access for the pps-gpio driver from the >> integer based ABI to the descriptor based ABI. It also adds the >> extraction of the device tree capture-clear option. > > Is the capture-clear property documented in > Documentation/devicetree/bindings/pps/pps-gpio.txt? > If not, you should add a binding documentation patch. Yes, that is in patch 1/4 >> Signed-off-by: Tom Burkart >> --- >> drivers/pps/clients/pps-gpio.c | 80 >> +++++++++++++++++++++--------------------- >> include/linux/pps-gpio.h | 3 +- >> 2 files changed, 41 insertions(+), 42 deletions(-) >> >> diff --git a/drivers/pps/clients/pps-gpio.c b/drivers/pps/clients/pps-gpio.c >> index 333ad7d5b45b..d2fbc91dc8fc 100644 >> --- a/drivers/pps/clients/pps-gpio.c >> +++ b/drivers/pps/clients/pps-gpio.c >> @@ -31,7 +31,7 @@ >> #include >> #include >> #include >> -#include >> +#include >> #include >> #include >> #include >> @@ -41,9 +41,9 @@ struct pps_gpio_device_data { >> int irq; /* IRQ used as PPS source */ >> struct pps_device *pps; /* PPS source device */ >> struct pps_source_info info; /* PPS source information */ >> + struct gpio_desc *gpio_pin; /* GPIO port descriptors */ >> bool assert_falling_edge; >> bool capture_clear; >> - unsigned int gpio_pin; >> }; >> >> /* >> @@ -61,18 +61,49 @@ static irqreturn_t pps_gpio_irq_handler(int >> irq, void *data) >> >> info = data; >> >> - rising_edge = gpio_get_value(info->gpio_pin); >> + rising_edge = gpiod_get_value(info->gpio_pin); >> if ((rising_edge && !info->assert_falling_edge) || >> (!rising_edge && info->assert_falling_edge)) >> pps_event(info->pps, &ts, PPS_CAPTUREASSERT, NULL); >> else if (info->capture_clear && >> ((rising_edge && info->assert_falling_edge) || >> - (!rising_edge && !info->assert_falling_edge))) >> + (!rising_edge && !info->assert_falling_edge))) >> pps_event(info->pps, &ts, PPS_CAPTURECLEAR, NULL); >> >> return IRQ_HANDLED; >> } >> >> +static int pps_gpio_setup(struct platform_device *pdev) >> +{ >> + struct pps_gpio_device_data *data = platform_get_drvdata(pdev); >> + const struct pps_gpio_platform_data *pdata = >> pdev->dev.platform_data; >> + struct device_node *np = pdev->dev.of_node; >> + int ret; > > Unused variable? Oops, yes, in this patch (2/4), but not in patch 4/4 >> + >> + if (pdata) { >> + data->gpio_pin = pdata->gpio_pin; >> + >> + data->assert_falling_edge = pdata->assert_falling_edge; >> + data->capture_clear = pdata->capture_clear; > > This is just a matter of personal taste, so feel free to ignore: > I would keep the pdata branch in pps_gpio_probe and call this function > pps_gpio_dt_setup, to reduce indentation of the OF branch. Ok, I am happy to agree as it makes sense. >> + } else { >> + data->gpio_pin = devm_gpiod_get(&pdev->dev, >> + NULL, /* request "gpios" */ >> + GPIOD_IN); >> + if (IS_ERR(data->gpio_pin)) { >> + dev_err(&pdev->dev, >> + "failed to request PPS GPIO\n"); >> + return PTR_ERR(data->gpio_pin); >> + } >> + >> + if (of_get_property(np, "assert-falling-edge", NULL)) >> + data->assert_falling_edge = true; >> + >> + if (of_get_property(np, "capture-clear", NULL)) >> + data->capture_clear = true; > > Those two should use the of_property_read_bool wrapper. Thanks. >> + } >> + return 0; >> +} >> + >> static unsigned long >> get_irqf_trigger_flags(const struct pps_gpio_device_data *data) >> { >> @@ -90,53 +121,23 @@ get_irqf_trigger_flags(const struct >> pps_gpio_device_data *data) >> static int pps_gpio_probe(struct platform_device *pdev) >> { >> struct pps_gpio_device_data *data; >> - const char *gpio_label; >> int ret; >> int pps_default_params; >> - const struct pps_gpio_platform_data *pdata = >> pdev->dev.platform_data; >> - struct device_node *np = pdev->dev.of_node; >> >> /* allocate space for device info */ >> data = devm_kzalloc(&pdev->dev, sizeof(struct pps_gpio_device_data), > > Could use sizeof(*data) here. Otherwise, Fine with me. > Reviewed-by: Philipp Zabel Is this for patch 2/4 only or the others as well? Will generate v10 of the patch and post it again.