linux-kernel - Re: [PATCH v2 2/2] hwmon: (sht4x) Add device tree match table and document it

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5c6986c4e0c6ff34bfaf94c30b79c7f3dd21d1a3.camel@egauge.net>
Date:   Sun, 21 Nov 2021 09:15:21 -0700
From:   David Mosberger-Tang <davidm@...uge.net>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Navin Sankar Velliangiri <navin@...umiz.com>,
        Jean Delvare <jdelvare@...e.com>, linux-hwmon@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 2/2] hwmon: (sht4x) Add device tree match table and
 document it

On Sat, 2021-11-20 at 13:51 -0800, Guenter Roeck wrote:
> On Sat, Nov 20, 2021 at 02:36:39PM -0700, David Mosberger-Tang wrote:
> > On Sat, 2021-11-20 at 13:12 -0800, Guenter Roeck wrote:
> > > On 11/20/21 12:40 PM, David Mosberger-Tang wrote:
> > > > This patch enables automatic loading of the sht4x module via a device
> > > > tree table entry.
> > > > 
> > > > Signed-off-by: David Mosberger-Tang <davidm@...uge.net>
> > > > ---
> > > >   .../bindings/hwmon/sensirion,sht4x.yaml       | 50 +++++++++++++++++++
> > > >   drivers/hwmon/sht4x.c                         |  7 +++
> > > 
> > > This needs to be two separate patches, one the devicetree change and the other
> > > the source code change. DT maintainers need to be copied on the devicetree
> > > patch.
> > 
> > Isn't that going to be confusing if one but not the other patch makes
> > it into a repository?  Either you end up with an undocumented device
> > tree property or you end up with documentation for an unsupported
> > property.
> > 
> This is a trivial device, so that isn't really an issue. Otherwise,
> if there are real bindings to approve, I would not accept the patch
> making the code change unless the devicetree patch is approved,
> and I would typically apply both together.

Got it, thanks for the explanation.

  --david