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@sang-engineering.com>
> > > ---
> > >  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
>