[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200630093135.GC5652@gnbcxd0016.gnb.st.com>
Date: Tue, 30 Jun 2020 11:31:35 +0200
From: Alain Volmat <alain.volmat@...com>
To: Wolfram Sang <wsa@...nel.org>
CC: Benjamin Tissoires <benjamin.tissoires@...hat.com>,
<robh+dt@...nel.org>, <mark.rutland@....com>,
<pierre-yves.mordret@...com>, <mcoquelin.stm32@...il.com>,
<alexandre.torgue@...com>, <linux-i2c@...r.kernel.org>,
<devicetree@...r.kernel.org>,
<linux-stm32@...md-mailman.stormreply.com>,
<linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>, <fabrice.gasnier@...com>
Subject: Re: [PATCH 4/4] i2c: stm32f7: Add SMBus-specific protocols support
Hi Wolfram,
> I meant a generic binding for the host-controller. It could be seen as a
> HW description if we need HostNotify on that bus or not.
>
> Maybe it becomes more clear with the R-Car I2C controller as an example.
> It only supports one slave address. If I want HostNotify there, I can't
> use another slave backend. Now, it could be that I need the slave EEPROM
> backend, although there is a HostNotify capable device on the bus. So, I
> am leaning to have a generic "host-notify" binding for the host.
>
> I consider platform_data legacy. If we use device_property, we should be
> safe regarding all current and future HW descriptions, or?
Ok, understood. Fine for me that way as well. I am just a little worrying that
the "host-notify" can now be present in both controller AND slave nodes
and might be a bit hard to understand. At the same time I don't have a better
proposal for naming the binding for the controller.
Please do not consider serie v2 I just posted few days ago and I will
post a serie v3 updating the binding information and using the host-notify
binding in the i2c-stm32f7 driver.
Alain
Powered by blists - more mailing lists