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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel