lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200806191451.3ce5ec57@archlinux>
Date:   Thu, 6 Aug 2020 19:14:51 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Rob Herring <robh+dt@...nel.org>
Cc:     Stephen Boyd <swboyd@...omium.org>,
        Daniel Campello <campello@...omium.org>,
        LKML <devicetree@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Hartmut Knaack <knaack.h@....de>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        Douglas Anderson <dianders@...omium.org>,
        "open list:IIO SUBSYSTEM AND DRIVERS" <linux-iio@...r.kernel.org>
Subject: Re: [PATCH v3 01/15] dt-bindings: iio: Add bindings for sx9310
 sensor

On Mon, 3 Aug 2020 20:01:06 -0600
Rob Herring <robh+dt@...nel.org> wrote:

> On Mon, Aug 3, 2020 at 1:00 PM Stephen Boyd <swboyd@...omium.org> wrote:
> >
> > Quoting Jonathan Cameron (2020-08-01 08:06:39)  
> > > On Fri, 31 Jul 2020 10:48:38 -0600
> > > Daniel Campello <campello@...omium.org> 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!)

I'm not that fussed though, so will leave it in.

The argument is a lot stronger for ADCs and such like, so we can
start encouraging it for those.

Jonathan


> 
> Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ