mbox series

[0/2] Add SMBus features to Tegra I2C

Message ID 1639062321-18840-1-git-send-email-akhilrajeev@nvidia.com
Headers show
Series Add SMBus features to Tegra I2C | expand

Message

Akhil R Dec. 9, 2021, 3:05 p.m. UTC
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(-)

Comments

Andy Shevchenko Dec. 9, 2021, 3:30 p.m. UTC | #1
On Thu, Dec 9, 2021 at 5:05 PM Akhil R <akhilrajeev@nvidia.com> wrote:
>
> Tegra I2C can use a gpio as an smbus-alert. Document the usage of
> the same.

...

> +optional properties:

Optional

> +- smbalert-gpio: Must contain an entry for the gpio to be used as smbus alert.

-gpios (the suffix in plural form, the singular is a legacy one)

> +  It will be used only if optional smbus-alert property is present.
Dmitry Osipenko Dec. 9, 2021, 4:04 p.m. UTC | #2
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.
Thierry Reding Dec. 10, 2021, 8:56 a.m. UTC | #3
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.

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.

Thierry
Rob Herring (Arm) Dec. 15, 2021, 6:42 p.m. UTC | #4
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