From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from saturn.retrosnub.co.uk ([46.235.226.198]:56264 "EHLO saturn.retrosnub.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727957AbeKCWPb (ORCPT ); Sat, 3 Nov 2018 18:15:31 -0400 Date: Sat, 3 Nov 2018 13:04:10 +0000 From: Jonathan Cameron To: Himanshu Jha Cc: Nishad Kamdar , 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 v7 3/3] staging: iio: ad2s1210: Add device tree table. Message-ID: <20181103130410.28b54311@archlinux> In-Reply-To: <20181103123927.339611b1@archlinux> References: <20181101153508.GA5176@himanshu-Vostro-3559> <20181103123927.339611b1@archlinux> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-iio-owner@vger.kernel.org List-Id: linux-iio@vger.kernel.org On Sat, 3 Nov 2018 12:39:27 +0000 Jonathan Cameron wrote: > On Thu, 1 Nov 2018 21:05:09 +0530 > Himanshu Jha wrote: > > > On Wed, Oct 31, 2018 at 09:30:36PM +0530, Nishad Kamdar wrote: > > > Add device tree table for matching vendor ID. > > > > > > Signed-off-by: Nishad Kamdar > > > --- > > > drivers/staging/iio/resolver/ad2s1210.c | 7 +++++++ > > > 1 file changed, 7 insertions(+) > > > > > > diff --git a/drivers/staging/iio/resolver/ad2s1210.c b/drivers/staging/iio/resolver/ad2s1210.c > > > index d3e7d5aad2c8..7c50def91a2b 100644 > > > --- a/drivers/staging/iio/resolver/ad2s1210.c > > > +++ b/drivers/staging/iio/resolver/ad2s1210.c > > > @@ -701,6 +701,12 @@ static int ad2s1210_remove(struct spi_device *spi) > > > return 0; > > > } > > > > > > +static const struct of_device_id ad2s1210_of_match[] = { > > > + { .compatible = "adi,ad2s1210", }, > > > + { } > > > +}; > > > +MODULE_DEVICE_TABLE(of, ad2s1210_of_match); > > > > I believe this needs to be documented at: > > > > Documentation/devicetree/bindings/iio/resolver/ad2s1210.txt > > > > Cc'ed to devictree list + Rob(DT Maintainer). > > > > Just wondering why didn't it came up till now from the IIO reviewers ? v7!! > > Because in staging drivers graduations we often hold off doing the > dt-bindings document until we have full visibility of where we are going. > > A lot of them have dodgy DT bindings (and that might even be the reason > they are in staging). What we don't want is to have a doc for a silly > binding in the 'official' list as we'll have to support it for ever. > > It needs documenting before moving out staging, but not necessarily now. > Particularly as this device is complex and has a 'lot' of other stuff > that isn't currently supported and quite possibly never will be. > Some of that would have non obvious dt bindings if we did support it. > For example we 'might' route the encoder outputs round to the inputs > of a counter driver and end up with a complex entity representing > the facilities that both fo them provide. > > Agreed, the DT binding doc needs to come soon and before the move out > staging, but I am quite happy with it being in the next series. > > A line in the description to that effect would have been useful of > course! > Applied, with a line on the intent to document once driver is cleaned up added. Thanks, Jonathan > Jonathan > > > > > >