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