From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 97E8DC433E1 for ; Thu, 6 Aug 2020 22:12:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 7879D20748 for ; Thu, 6 Aug 2020 22:12:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596751969; bh=5kIwo2Mps+WdhyyhERg/v0Yl22kiC8RQaCXpPI4M014=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=BOw5ekZPsVHjbLsgnDCFJrpLF2anWheUNxYiL5tj7bMaXmJXp0DDvSwiZTdGyfZvd 6tieJ4cx400wA0R85mLdwYepNvgooGiiJzOjM5+td/9BgCDs5XlGptWnNr9ymZ/Pty 1htOgLHzS6mJ94p7w+A5FW2NQ+E9zZhSzl1i/WpI= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726238AbgHFWMs (ORCPT ); Thu, 6 Aug 2020 18:12:48 -0400 Received: from mail.kernel.org ([198.145.29.99]:47170 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725998AbgHFWMr (ORCPT ); Thu, 6 Aug 2020 18:12:47 -0400 Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (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 DE374221E3; Thu, 6 Aug 2020 22:12:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596751967; bh=5kIwo2Mps+WdhyyhERg/v0Yl22kiC8RQaCXpPI4M014=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=InKJtaBBiNTqyGpsmNkDccmciz3oHLLWtcH3xB9h2+Vzs0MB1bUqnpN+kB/KuGDLm vrVKeETgv4CVf3pfiEuyvS1p6bVA0WpFpdDmY+VQWV7ACFUzR1vK5Q1sKV5wXbb+AD 8eBlV9CcL2zJkfes/ta+8AnwX84RPfk7pMR/Ued0= Received: by mail-ot1-f53.google.com with SMTP id h22so74752otq.11; Thu, 06 Aug 2020 15:12:46 -0700 (PDT) X-Gm-Message-State: AOAM5315Tnja29A1HsgZeSUWrvCtrCONpFK4yAanBfwQADLmrXR17wR8 pVa4zn6Ei3+Fdw2J+SE/uUOsm9PObd7t6Wma4Q== X-Google-Smtp-Source: ABdhPJymKfUI6jSAReX64xGfCidAykanzrZqSlJ6L628ZfqbwHcACImpWOlyFoKKUkxKjQjAZZyIRI+/aKWC/GjuN+U= X-Received: by 2002:a05:6830:1b79:: with SMTP id d25mr8745864ote.107.1596751965884; Thu, 06 Aug 2020 15:12:45 -0700 (PDT) MIME-Version: 1.0 References: <20200731164853.3020946-1-campello@chromium.org> <20200731104555.v3.1.I0925046377211b8b6f06764857f03b4ab592bddb@changeid> <20200801160639.1410944e@archlinux> <159648122347.1360974.1094560524092762187@swboyd.mtv.corp.google.com> <20200806191451.3ce5ec57@archlinux> In-Reply-To: <20200806191451.3ce5ec57@archlinux> From: Rob Herring Date: Thu, 6 Aug 2020 16:12:34 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 01/15] dt-bindings: iio: Add bindings for sx9310 sensor To: Jonathan Cameron Cc: Stephen Boyd , Daniel Campello , LKML , LKML , Hartmut Knaack , Lars-Peter Clausen , Peter Meerwald-Stadler , Douglas Anderson , "open list:IIO SUBSYSTEM AND DRIVERS" 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 Thu, Aug 6, 2020 at 12:14 PM Jonathan Cameron wrote: > > On Mon, 3 Aug 2020 20:01:06 -0600 > Rob Herring wrote: > > > On Mon, Aug 3, 2020 at 1:00 PM Stephen Boyd wrote: > > > > > > Quoting Jonathan Cameron (2020-08-01 08:06:39) > > > > On Fri, 31 Jul 2020 10:48:38 -0600 > > > > Daniel Campello wrote: > > > > > diff --git a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml > > > > > new file mode 100644 > > > > > index 00000000000000..5739074d3592fe > > > > > --- /dev/null > > > > > +++ b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9310.yaml > > > > > @@ -0,0 +1,65 @@ > > > [...] > > > > > + > > > > > + "#io-channel-cells": > > > > > + const: 1 > > > > > + > > > > > +required: > > > > > + - compatible > > > > > + - reg > > > > > + - "#io-channel-cells" > > > > > > > > Missed this in earlier review (only noticed when I saw whilst santity > > > > checking earlier versions. > > > > > > > > Fairly sure we should only need #io-channel-cells if we have > > > > a consumer of a channel somewhere else in DT. So it's not > > > > required as far as I can see. > > > > > > > > > > This is mostly a decision for Rob to make, but I would make it required > > > because the device is always an io channel provider. It may be that it > > > isn't providing anything in the DT to something else in the DT but it is > > > providing this information somewhere so always having to spell that out > > > is simple and doesn't hurt. > > > > I agree. If the user is split in a board file or overlay, we don't > > want to have to be adding it to the provider at that time. > > That is perhaps a reasonable view point for devices with channels that > are likely to be used by consumer drivers, but in this particular case we > are talking about a proximity sensor. So far I don't think we > have any consumer drivers for this type of sensor (I might have forgotten > one of course!) Indeed, I didn't consider whether it made sense in the first place. So should it just not be specified at all in this case? I can't really picture what the usecase for a consumer node would be. Rob