Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp2346160imd; Sun, 28 Oct 2018 08:09:48 -0700 (PDT) X-Google-Smtp-Source: AJdET5f0+D30IwH4NlGBm6Xsx01VjVZxyf2CfotK8WlcgqlGDUn193vPGIJiUvfXVHG5T/MiYERr X-Received: by 2002:a63:8d44:: with SMTP id z65mr10571681pgd.57.1540739388043; Sun, 28 Oct 2018 08:09:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1540739388; cv=none; d=google.com; s=arc-20160816; b=ijIjSyO5VlKJwyosL0WQtT9uEqLTU5nJCg2iudCC9obI9AFXfp0up+l7Vu/4S0hxOv uAB/GoBoVt1W40SIS7qhHp2lQq3ApHYf3GRR959RxJyzyrPCk4kEaZZ0BaHORlojWSZm WJyOvHEHmZu60ZEgZ8v7NVlQH5KgXN1737zgcnv1OxYd0u4/Y7mL8fPUeB44B9p5m4P9 bTwcCMmeA1JoLKTGoYp6bIw+facffHTqFb2L5xcEBevYSbteItqNmq/swY8ObakWHJH8 CDsJhUia8tS2wiyveQfsMAKPay/pw+prcU0rp7UZOln92cgudZl7s6iyrX34bcePYrma iGTw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=fBAAE35NZwVa2eS2y3cxHfWNC5HHkiDwmclApWKFo+k=; b=O11hOsY0rALDu9F+D4yX/IkUMPv7mZIGWwwyOKZYSqutlrIxNoleoV260eUc1esw9j j+2zET0b8zESTU4x9njfhedQF1yDSPeBZiMtJUNjaKZdnj91RE44uYrwH3UWee+V9B/U OdIYY4YpdvnrXjUF5q1eUwkc3vtZM/urj8L8v3Kzg86NvklUWU/RBm7lCTAaP4BwLiGy MRD3ChS35PItRTTwtul6UdEYuAPTa73uePiYwiMvjCMvesrGS3hvAJ6Fqd4tMEsyZWZP H7O6AgjZeRLYHq+AYGku445uQ8sRJtZffVqWKUAwu+wEtp0V49/SUwrIoQNezuOfxzHK 31kQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="Cwk/SSTq"; 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 s17-v6si17205098pgm.317.2018.10.28.08.09.30; Sun, 28 Oct 2018 08:09:47 -0700 (PDT) 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="Cwk/SSTq"; 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 S1727346AbeJ1XgD (ORCPT + 99 others); Sun, 28 Oct 2018 19:36:03 -0400 Received: from mail.kernel.org ([198.145.29.99]:35808 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726492AbeJ1XgD (ORCPT ); Sun, 28 Oct 2018 19:36:03 -0400 Received: from archlinux (cpc91196-cmbg18-2-0-cust659.5-4.cable.virginm.net [81.96.234.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 31A8E20831; Sun, 28 Oct 2018 14:51:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1540738272; bh=jpeDS3UBLrt7HQLsNJuXO8hWu+vyTx8gxG5wNh32/vA=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Cwk/SSTqamTOyi62rr8gRn11UgnCOAEpq6hLp7JzGQy4iLcpEhN7mErn95TPmeezi Ws8XYKWG/KCMJcFEhdoI4JPN/jRI49tWIMy2TznmaPXcwncdjluRxvzWkFPk7RJrq9 AadgPEOdDSg+D9fjAQWkxs0G7Qb1Lhc/ytf8CTqQ= Date: Sun, 28 Oct 2018 14:51:08 +0000 From: Jonathan Cameron To: Nishad Kamdar Cc: Slawomir Stepien , Lars-Peter Clausen , Michael Hennerich , Hartmut Knaack , Peter Meerwald-Stadler , Greg Kroah-Hartman , linux-iio@vger.kernel.org, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v6 3/3] staging: iio: ad2s1210: Add device tree support. Message-ID: <20181028145108.1079227f@archlinux> In-Reply-To: <473e6abfe959e1ac78fe65bf8dc53ad25ad3b358.1540712249.git.nishadkamdar@gmail.com> References: <473e6abfe959e1ac78fe65bf8dc53ad25ad3b358.1540712249.git.nishadkamdar@gmail.com> X-Mailer: Claws Mail 3.17.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 28 Oct 2018 13:23:23 +0530 Nishad Kamdar wrote: > Replace platform data with device tree support. > > Signed-off-by: Nishad Kamdar The whole gpio in or out thing makes less and less sense to me and seems to contradict the datasheet. If I'm not missing something I would just get rid of the option. If I am missing something (not hard in the datasheet which, whilst fairly clear, is a rather long ;) Jonathan > --- > drivers/staging/iio/resolver/Kconfig | 1 + > drivers/staging/iio/resolver/ad2s1210.c | 17 ++++++++--------- > drivers/staging/iio/resolver/ad2s1210.h | 17 ----------------- > 3 files changed, 9 insertions(+), 26 deletions(-) > > diff --git a/drivers/staging/iio/resolver/Kconfig b/drivers/staging/iio/resolver/Kconfig > index 6a469ee6101f..cc1202ff813d 100644 > --- a/drivers/staging/iio/resolver/Kconfig > +++ b/drivers/staging/iio/resolver/Kconfig > @@ -15,6 +15,7 @@ config AD2S90 > > config AD2S1210 > tristate "Analog Devices ad2s1210 driver" > + depends on OF > depends on SPI > depends on GPIOLIB || COMPILE_TEST > help > diff --git a/drivers/staging/iio/resolver/ad2s1210.c b/drivers/staging/iio/resolver/ad2s1210.c > index 0234869e9d74..5ecdb5785132 100644 > --- a/drivers/staging/iio/resolver/ad2s1210.c > +++ b/drivers/staging/iio/resolver/ad2s1210.c > @@ -17,6 +17,7 @@ > #include > #include > #include > +#include > > #include > #include > @@ -76,7 +77,6 @@ struct ad2s1210_gpio { > }; > > struct ad2s1210_state { > - const struct ad2s1210_platform_data *pdata; > struct mutex lock; > struct spi_device *sdev; > struct gpio_desc *sample; > @@ -84,6 +84,7 @@ struct ad2s1210_state { > struct gpio_desc *a1; > struct gpio_desc *res0; > struct gpio_desc *res1; > + bool gpioin; > unsigned int fclkin; > unsigned int fexcit; > bool hysteresis; > @@ -314,7 +315,7 @@ static ssize_t ad2s1210_store_control(struct device *dev, > } > st->resolution > = ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION]; > - if (st->pdata->gpioin) { > + if (st->gpioin) { > data = ad2s1210_read_resolution_pin(st); > if (data != st->resolution) > dev_warn(dev, "ad2s1210: resolution settings not match\n"); > @@ -376,7 +377,7 @@ static ssize_t ad2s1210_store_resolution(struct device *dev, > } > st->resolution > = ad2s1210_resolution_value[data & AD2S1210_SET_RESOLUTION]; > - if (st->pdata->gpioin) { > + if (st->gpioin) { > data = ad2s1210_read_resolution_pin(st); > if (data != st->resolution) > dev_warn(dev, "ad2s1210: resolution settings not match\n"); > @@ -603,7 +604,7 @@ static int ad2s1210_initial(struct ad2s1210_state *st) > int ret; > > mutex_lock(&st->lock); > - if (st->pdata->gpioin) > + if (st->gpioin) > st->resolution = ad2s1210_read_resolution_pin(st); > else > ad2s1210_set_resolution_pin(st); > @@ -644,7 +645,7 @@ static int ad2s1210_setup_gpios(struct ad2s1210_state *st) > int ret, i; > struct spi_device *spi = st->sdev; > struct ad2s1210_gpio *pin; > - unsigned long flags = st->pdata->gpioin ? GPIOD_IN : GPIOD_OUT_LOW; > + unsigned long flags = st->gpioin ? GPIOD_IN : GPIOD_OUT_LOW; > > struct ad2s1210_gpio gpios[] = { > { .ptr = &st->sample, .name = "sample", .flags = GPIOD_IN }, > @@ -673,16 +674,14 @@ static int ad2s1210_probe(struct spi_device *spi) > { > struct iio_dev *indio_dev; > struct ad2s1210_state *st; > + struct device_node *np = spi->dev.of_node; > int ret; > > - if (!spi->dev.platform_data) > - return -EINVAL; > - > indio_dev = devm_iio_device_alloc(&spi->dev, sizeof(*st)); > if (!indio_dev) > return -ENOMEM; > st = iio_priv(indio_dev); > - st->pdata = spi->dev.platform_data; > + st->gpioin = of_property_read_bool(np, "gpioin"); Hmm. This bothered me in the earlier patch. How are we meant to configure these pins... (and this time I actually loaded the datasheet) A0 and A1 always seem to be control signals written to the device so I don't really understand why we would ever want them to be 'inputs' on our host. RES0 and RES1 are also control signals. Clearly marked as logic inputs. The only thing I can think here is there is an evaluation board out there were we are not in control of these, some other controller is. That is a pretty weird board if so, hence I would only support the version where we use GPIO outputs from the host. This will further simplify patch 1 and get rid fo the need for this non standard bit of devicetree binding. > ret = ad2s1210_setup_gpios(st); > if (ret < 0) > return ret; > diff --git a/drivers/staging/iio/resolver/ad2s1210.h b/drivers/staging/iio/resolver/ad2s1210.h > index 63d479b20a6c..e69de29bb2d1 100644 > --- a/drivers/staging/iio/resolver/ad2s1210.h > +++ b/drivers/staging/iio/resolver/ad2s1210.h > @@ -1,17 +0,0 @@ > -/* > - * ad2s1210.h plaform data for the ADI Resolver to Digital Converters: > - * AD2S1210 > - * > - * Copyright (c) 2010-2010 Analog Devices Inc. > - * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License version 2 as > - * published by the Free Software Foundation. > - */ > -#ifndef _AD2S1210_H > -#define _AD2S1210_H > - > -struct ad2s1210_platform_data { > - bool gpioin; > -}; > -#endif /* _AD2S1210_H */