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=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,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 E4E33C433E0 for ; Thu, 6 Aug 2020 23:03:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E1D9B221E5 for ; Thu, 6 Aug 2020 23:03:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="Qz+Tzz7b" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726233AbgHFXDk (ORCPT ); Thu, 6 Aug 2020 19:03:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44530 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725999AbgHFXDi (ORCPT ); Thu, 6 Aug 2020 19:03:38 -0400 Received: from mail-pl1-x642.google.com (mail-pl1-x642.google.com [IPv6:2607:f8b0:4864:20::642]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4150AC061574 for ; Thu, 6 Aug 2020 16:03:38 -0700 (PDT) Received: by mail-pl1-x642.google.com with SMTP id f10so141283plj.8 for ; Thu, 06 Aug 2020 16:03:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:content-transfer-encoding:in-reply-to:references :subject:from:cc:to:date:message-id:user-agent; bh=0gDnN//bxk4XCQG+5+85qQKDntN2R3o5FFO9hcqipr4=; b=Qz+Tzz7bYWSKTO2D5D1zgMNC/JGFqIwqPZZilBd/61zHOwvpLorhkmc7e7VEaUMNzu LnaRmb/RxkNitmzslzS10MrXEJp5npQp/zZZeMPjlconFW4iWIkykeZ/wB04ja2fGUB3 6OJdfKhct7H5dJi16+7wGmBn1PO/p/GPHw/Y8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding :in-reply-to:references:subject:from:cc:to:date:message-id :user-agent; bh=0gDnN//bxk4XCQG+5+85qQKDntN2R3o5FFO9hcqipr4=; b=uYF0DZnhEAPfhEH6bngOat8NFxhI3/gryKGj8OFdsOgd82h8i1zNlcusufDhBo78E4 F1XIIUpp10N79MvnvlU3Q3ZLHM9Nk+EA3pYz4Ik9k2YcIhH743+NtwheGFFaDB6dOBmE H1PprtMq2zvs6cYVG+9OTl0wc2JS7oxbx/2Fpfp+DqW5ggJVUXjWVK6xpOzi8E98Bm/Y GeYqI1Emg/f5IXxXrnH6VR2Hab8LkorA0/SkN2H/WXLynrThplsWB17X6OW6iWXfn8hw tdO08j7WiUeJAzH/+e1FPIUS+Q456r9UZ+D85BVsTHiM0XKhO3iELC+nZSsOWOYeaQ4T DGVQ== X-Gm-Message-State: AOAM53194D+oj9rHICyLX/7ncSvEqDhQvJYZb/W8yKPx7IGIKZiFJj5k NuDHzXcDFuIHTNwx3j5ZFLSYrg== X-Google-Smtp-Source: ABdhPJxheayUk8uIULBY6NewH6D0OhojLErEsa5goOKcKVPS5xWNRVsItvYP7z12DSkLAXSq9aVcRA== X-Received: by 2002:a17:902:7405:: with SMTP id g5mr9862707pll.173.1596755017579; Thu, 06 Aug 2020 16:03:37 -0700 (PDT) Received: from chromium.org ([2620:15c:202:1:3e52:82ff:fe6c:83ab]) by smtp.gmail.com with ESMTPSA id j16sm8166331pgb.33.2020.08.06.16.03.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 06 Aug 2020 16:03:36 -0700 (PDT) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: 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> Subject: Re: [PATCH v3 01/15] dt-bindings: iio: Add bindings for sx9310 sensor From: Stephen Boyd Cc: Daniel Campello , LKML , LKML , Hartmut Knaack , Lars-Peter Clausen , Peter Meerwald-Stadler , Douglas Anderson , open list: IIO SUBSYSTEM AND DRIVERS , ; Illegal-Object: Syntax error in Cc: address found on vger.kernel.org: Cc: ; ^-missing semicolon to end mail group, extraneous tokens in mailbox, missing end of mailbox To: Jonathan Cameron , Rob Herring Date: Thu, 06 Aug 2020 16:03:35 -0700 Message-ID: <159675501533.1360974.12010874193333451805@swboyd.mtv.corp.google.com> User-Agent: alot/0.9.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Rob Herring (2020-08-06 15:12:34) > 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 wro= te: > > > > > > > > This is mostly a decision for Rob to make, but I would make it requ= ired > > > > 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 forgott= en > > one of course!) >=20 > 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. >=20 I was thinking that a WiFi DT node may directly grab the channel from this device and use this for SAR power changes. That would avoid going all the way to userspace to figure out that something is close proximity and then tell WiFi to reduce power.