linux-kernel - Re: [PATCH 1/3] i3c: fix i2c and i3c scl rate by bus mode

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190422202732.0d539af3@collabora.com>
Date:   Mon, 22 Apr 2019 20:27:32 +0200
From:   Boris Brezillon <boris.brezillon@...labora.com>
To:     Vitor Soares <Vitor.Soares@...opsys.com>
Cc:     "linux-i3c@...ts.infradead.org" <linux-i3c@...ts.infradead.org>,
        "joao.pinto@...opsys.com" <Joao.Pinto@...opsys.com>,
        Boris Brezillon <bbrezillon@...nel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/3] i3c: fix i2c and i3c scl rate by bus mode

On Mon, 22 Apr 2019 17:54:29 +0000
Vitor Soares <Vitor.Soares@...opsys.com> wrote:

> > > > > >       
> > > > > > >  {
> > > > > > >  	i3cbus->mode = mode;
> > > > > > >  
> > > > > > > -	if (!i3cbus->scl_rate.i3c)
> > > > > > > -		i3cbus->scl_rate.i3c = I3C_BUS_TYP_I3C_SCL_RATE;
> > > > > > > -
> > > > > > > -	if (!i3cbus->scl_rate.i2c) {
> > > > > > > -		if (i3cbus->mode == I3C_BUS_MODE_MIXED_SLOW)
> > > > > > > -			i3cbus->scl_rate.i2c = I3C_BUS_I2C_FM_SCL_RATE;
> > > > > > > -		else
> > > > > > > -			i3cbus->scl_rate.i2c = I3C_BUS_I2C_FM_PLUS_SCL_RATE;
> > > > > > > +	switch (i3cbus->mode) {
> > > > > > > +	case I3C_BUS_MODE_PURE:
> > > > > > > +		if (!i3cbus->scl_rate.i3c)
> > > > > > > +			i3cbus->scl_rate.i3c = I3C_BUS_TYP_I3C_SCL_RATE;
> > > > > > > +		break;
> > > > > > > +	case I3C_BUS_MODE_MIXED_FAST:
> > > > > > > +		if (!i3cbus->scl_rate.i3c)
> > > > > > > +			i3cbus->scl_rate.i3c = I3C_BUS_TYP_I3C_SCL_RATE;
> > > > > > > +		if (!i3cbus->scl_rate.i2c)
> > > > > > > +			i3cbus->scl_rate.i2c = i2c_scl_rate;
> > > > > > > +		break;
> > > > > > > +	case I3C_BUS_MODE_MIXED_SLOW:
> > > > > > > +		if (!i3cbus->scl_rate.i2c)
> > > > > > > +			i3cbus->scl_rate.i2c = i2c_scl_rate;
> > > > > > > +		i3cbus->scl_rate.i3c = i3cbus->scl_rate.i2c;      
> > > > > > 
> > > > > > Maybe we should do
> > > > > > 
> > > > > > 		if (!i3cbus->scl_rate.i3c ||
> > > > > > 		    i3cbus->scl_rate.i3c > i3cbus->scl_rate.i2c)
> > > > > > 			i3cbus->scl_rate.i3c = i3cbus->scl_rate.i2c;
> > > > > > 					   
> > > > > > Just in case the I3C rate forced by the user is lower than the max I2C
> > > > > > rate.      
> > > > > 
> > > > > That was something that I considered but TBH it isn't a real use case.    
> > > > 
> > > > Add a WARN_ON() to at least catch such inconsistencies. And maybe we
> > > > should add a dev_warn() when the user-defined rates do not match
> > > > the mode/LVR constraints. It's easy to do a mistake when writing a dts.    
> > > 
> > > I think the WARN_ON() is too evasive on the screen and won't provide the 
> > > information we want.
> > > The dev_warn() should work perfectly here.
> > > 
> > > 		if (i3cbus->scl_rate.i3c < i3cbus->scl_rate.i2c)
> > > 			dev_warn(&i3cbus->cur_master->dev->dev,
> > > 				     "%s: i3c-scl-hz lower then i2c-scl-hz\n",  __func__);  
> > 
> > Using dev_warn() sounds good, though I don't think you need the
> > __func__ here. Also, please print the i2c/i3c rates in the message, and
> > align the second line on the open parens.
> >   
> > > 		if (i3cbus->scl_rate.i2c != I3C_BUS_I2C_FM_SCL_RATE ||
> > > 		    i3cbus->scl_rate.i2c != I3C_BUS_I2C_FM_PLUS_SCL_RATE)
> > > 			dev_warn(&i3cbus->cur_master->dev->dev,
> > > 				     "%s: i2c-scl-hz not defined according MIPI I3C spec\n", 
> > > 				     __func__);  
> > 
> > Is that really a problem? Having an i2c rate that is less than FM speed
> > sounds like a valid case to me.  
> 
> I'm addressing the spec constrains.

"Table 57 I3C Timing Requirements When Communicating With I2C Legacy
Devices" says that freq can be between 0 and 400KHz when operating in
slow(FM) mode. Yes, maximum rate when not specified otherwise is
400Khz, but the point of overloading the max I2C/I3C spec is to allow
custom rates when the default/spec ones are not achievable, so I'm not
sure complaining in that case is legitimate.

We should definitely complain when one tries to set a maximum rate that
is higher than what devices can do (i3cbus->scl_rate.i2c >
max_i2c_scl_rate).

Same goes for I3C communications, we shouldn't care when the forced rate
is lower than what the bus is capable of, what's important is to
complain when it's higher than what's supported.