Hi Alain, > > So, as mentioned in the other review, I'd like to evaluate other > > possibilities for the above: > > > > - One option is to enable it globally in probe(). Then you lose the > > possibility to have a device at address 0x08. > > I'd prefer avoid this solution to not lose the address 0x08. Understandably. > > - Enable it in probe() only if there is a generic binding "host-notify". > > Do you mean having the adapter walk through childs node and see if at least > one of them have the host-notify property ? This mean that such solution > wouldn't work for device relying on platform data rather than DT nodes. 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? > > - Let the core scan for a device with HOST_NOTIFY when registering an > > adapter and then call back into the driver somehow? > > You mean at adapter registration time only ? Not device probing time ? > At probing time, we could have the core (i2c_device_probe) check for the flag > HOST_NOTIFY and if setted call a dedicated host-notify reg callback ? As said above, I am leaning to the generic property. In addition, it doesn't feel right to me to add/remove the HostNotify feature at runtime depending on the client devices. Imagine someone changes another slave backend to address 0x08 and the HostNotify device comes later. Then, it won't work all of a sudden. It feels much safer to me to declare HostNotify as a feature of the IP core which it either has or it has not, configurable at boot-time. Makes sense? Kind regards, Wolfram
Attachment:
signature.asc
Description: PGP signature
