> Hum ... sorry ... I'm having some doubt about such a generic 'smbus' naming.
> I mean, stating 'smbus' within the controller node kind of says
> "I am working in SMBus mode", and not only "I am supporting Host-Notify & Alert".
> In such case, NOT having 'smbus' would mean that the driver do not support
> SMBUS and SMBus xfer and all smbus related stuff would get disabled ...
> We for sure do not want to have everybody add a smbus property in their DT
> if they support SMBus xfer for example.
> 
> This is probably too wide, don't you think ?

It would be, yet I don't think this is case.

The "smbus" property means that _additional_ SMBus restrictions apply to
that bus. Like additional timeout values, reserved addresses etc...

It does not mean that we can't use SMBus style communication on an I2C
bus. We can because we can easily emulate it. This is not an additional
restriction.

So it rather means "SMBus restrictions apply here". No such properties
means no such restrictions. But then you can't have HostNotify and Alert
because the addresses are not reserved.

We can update the binding to "smbus-restrictions" perhaps, although it
doesn't really sound nice to me. Maybe Rob also has an idea.

I'll send a patch later and then we will see what he says.

D'accord?