> > > > SMBus is largely compatible with I2C but there are some specifics. In > > > > case we need them on a bus, we can now use this new binding. > > > > > > > > Signed-off-by: Wolfram Sang <wsa+renesas@xxxxxxxxxxxxxxxxxxxx> > > > > --- > > > > Documentation/devicetree/bindings/i2c/i2c.txt | 5 +++++ > > > > 1 file changed, 5 insertions(+) > > > > > > > > diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt > > > > index 438ae123107e..d1f8cf3bd236 100644 > > > > --- a/Documentation/devicetree/bindings/i2c/i2c.txt > > > > +++ b/Documentation/devicetree/bindings/i2c/i2c.txt > > > > @@ -77,6 +77,11 @@ wants to support one of the below features, it should adapt these bindings. > > > > this information to detect a stalled bus more reliably, for example. > > > > Can not be combined with 'multi-master'. > > > > > > > > +- smbus > > > > > > This is a boolean? > > > > Yes. > > > > > > > > > + states that additional SMBus restrictions and features apply to this bus. > > > > + Examples of features are SMBusHostNotify and SMBusAlert. Examples of > > > > > > Do features need to be enumerated separately? > > > > They could be, do you think this is of advantage? For now, we would then > > need "host-notify" and "smbus-alert". Maybe later things like "timeout" > > could show up. > > I also recall now that I thought that "smbus" fits better the > "describing hardware" aspect, i.e. "this bus is an SMBus and not I2C". > Enumerating features felt more like configuration to me. Rob, if you have a minute to comment on it, I would much appreciate it. I'd love to get this into 5.9. Thanks and all the best!
Attachment:
signature.asc
Description: PGP signature