> 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?
Attachment:
signature.asc
Description: PGP signature
