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]
Date:   Tue, 21 Sep 2021 06:18:04 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
Cc:     Jean Delvare <jdelvare@...e.com>, Rob Herring <robh+dt@...nel.org>,
        Jiri Kosina <trivial@...nel.org>,
        Jonathan Cameron <Jonathan.Cameron@...wei.com>,
        linux-hwmon@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/6] dt-bindings: hwmon: ibm,cffps: move to trivial
 devices

On Tue, Sep 21, 2021 at 02:45:42PM +0200, Krzysztof Kozlowski wrote:
> On 21/09/2021 14:30, Guenter Roeck wrote:
> > On Tue, Sep 21, 2021 at 12:28:29PM +0200, Krzysztof Kozlowski wrote:
> >> The IBM Common Form Factor Power Supply Versions 1 and 2 bindings are
> >> trivial, so they can be integrated into trivial devices bindings.
> >>
> >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
> > 
> > I won't accept any of those "move to trivial devices" patches. In many cases
> > the bindings are simply incomplete. I can not and will not make that call,
> > and I always did and will leave it up to driver authors to decide if they
> > want to add a device to trivial devices or provide explicit bindings.
> > 
> > Please stop sending those patches.
> > 
> 
> Back in the older times, there were no trivial-devices and checkpatch
> plus maintainers required documenting compatibles, so some of such
> simple bindings were created.
> 

At the same time, as I said, the bindings for many chips are incomplete.
For this driver, we can not make that call because the datasheet is not
public. The same is true for dps650ab. For others, the datasheet is
available, and a reasonable decision can be made if the chip may ever
need more complete bindings.

So, let's qualify my statement: I'll accept such patches if you can show,
from the datasheet, that it is unlikely that explicit bindings will ever
be needed. That would be the case for LM70, for example. That would need
more than a statement that "bindings are trivial", though. It also require
a statement along the line that you have confirmed, from to the datasheet,
that there is nothing to configure for this chip that would ever require
explicit bindings.

Thanks,
Guenter

> I understand however your point, fair enough. I'll stop sending such
> patches.
> 
> Best regards,
> Krzysztof

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ