linux-kernel - Re: [PATCH 0/2] Add SMBus features to Tegra I2C

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] [day] [month] [year] [list]

Message-ID: <Ybo3GNYSZ9HLIwqj@robh.at.kernel.org>
Date:   Wed, 15 Dec 2021 12:42:32 -0600
From:   Rob Herring <robh@...nel.org>
To:     Thierry Reding <thierry.reding@...il.com>
Cc:     Dmitry Osipenko <digetx@...il.com>,
        Akhil R <akhilrajeev@...dia.com>, andy.shevchenko@...il.com,
        christian.koenig@....com, dri-devel@...ts.freedesktop.org,
        jonathanh@...dia.com, ldewangan@...dia.com,
        linaro-mm-sig@...ts.linaro.org, linux-i2c@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
        linux-tegra@...r.kernel.org, p.zabel@...gutronix.de,
        sumit.semwal@...aro.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 0/2] Add SMBus features to Tegra I2C

On Fri, Dec 10, 2021 at 09:56:28AM +0100, Thierry Reding wrote:
> On Thu, Dec 09, 2021 at 07:04:30PM +0300, Dmitry Osipenko wrote:
> > 09.12.2021 18:05, Akhil R пишет:
> > > Add support for SMBus Alert and SMBus block read functions to
> > > i2c-tegra driver
> > > 
> > > Akhil R (2):
> > >   dt-bindings: i2c: tegra: Add SMBus feature properties
> > >   i2c: tegra: Add SMBus block read and SMBus alert functions
> > > 
> > >  .../devicetree/bindings/i2c/nvidia,tegra20-i2c.txt |  4 ++
> > >  drivers/i2c/busses/i2c-tegra.c                     | 54 +++++++++++++++++++++-
> > >  2 files changed, 57 insertions(+), 1 deletion(-)
> > > 
> > 
> > How this was tested? This series must include the DT patch. If there is
> > no real user in upstream for this feature, then I don't think that we
> > should bother at all about it.
> 
> This is primarily used by a device that uses ACPI and the driver uses
> the firmware-agnostic APIs to get at this. However, it also means that
> the driver effectively provides this same support for DT via those APIs
> and therefore it makes sense to document that part even if there are no
> current users of the DT bits.

Then definitely a NAK.

> One big advantage of this is that it helps keep the ACPI and DT bindings
> in sync, and document this on the DT side also allows us to document the
> ACPI side of things where no formal documentation exists, as far as I
> know.

I have no bandwidth to review ACPI bindings and don't think the whole 
use DT bindings in ACPI is a good idea either. If someone wants this to 
be a thing, then they need to step up and review bindings.

Rob