On Fri, Jul 24, 2020 at 09:36:35PM +0200, Wolfram Sang wrote: > Hi Rob, > > > > 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. > > > > > > + restrictions are more reserved addresses and timeout definitions. > > > + > > All the best, > > Wolfram >
Attachment:
signature.asc
Description: PGP signature