On Sat, Jul 25, 2020 at 02:07:00PM +0200, Wolfram Sang wrote: > 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. Rob, if you have some time, I'd really appreciate an ack here. I think it is a proper binding but I'd like to have it stress-tested with your experience :) > > > > > > > > > > + restrictions are more reserved addresses and timeout definitions. > > > > + > > > > All the best, > > > > Wolfram > > > >
Attachment:
signature.asc
Description: PGP signature
