Re: [PATCH] hwmon: (sht21) Don't use clock stretching

[Guenter Roeck <linux@roeck-us.net>]

On Wed, Jan 31, 2018 at 03:39:23PM +0100, Danilo Bargen wrote:
> Hello Guenter
> 
> Thank you for your fast review!
> 
> > The driver must now support I2C_FUNC_I2C which is a significant change in functionality
> > since it will no longer work on SMBus-only adapters.
> 
> You are right of course, I wasn't aware of that.
> 
> > You'll have to find a better
> > solution, one that retains the old functionality but also works on the Raspberry Pi.
> 
> What are my options? A separate driver (sht21nhm) would probably not be accepted, right?
> 
One option would be to implement access functions differently if clock
stretching is known to not work. That would, however, require infrastructure
support since the controller driver should tell the chip driver that it doesnot
support clock stretching.

> Or should I instead try to submit it to the Raspberry Pi kernel tree directly?
> 
> > FWIW, this should really be solved in the infrastructure. Many devices support and
> > depend on clock stretching, and we can not mess up the drivers for all those devices
> > to deal with a broken adapter.
> 
> Could you elaborate what you mean with "in the infrastructure"? Could there be a
> way to solve this on the i2c / adapter driver level?
> 
As mentioned above, this is really a i2c controller driver issue. If the
controller driver does not support clock stretching, it should tell chip drivers
about it. There should also be infrastructure support to support "simulated"
clock stretching; otherwise each and every chip driver who needs it would have
to re-implement the same set of hacks.

> An interesting sidenote is that the driver used to work on the Raspberry Pi with
> older kernel versions, but not on current ones. (I'd have to look up the exact
> versions, but I think it changed sometime last year.) Maybe something about the
> timing was changed that broke clock stretching.
> 
Wouldn't it make sense then to track down the patch which introduced the problem
and fix the underlying issue instead of working around it ?

Guenter

> > Has this been discussed on the i2c mailing list ?
> 
> I did not submit a discussion so far, and the mailing list search did not
> turn up anything related. Should I start a discussion there?
> 
> Cheers and thanks for your time,
> Danilo Bargen