On Thu, 17 Sep 2020, at 01:26, Guenter Roeck wrote:
> > I've had a look at these two examples. As you suggest the delays in zl6100.c
> > look pretty similar to what this series implements in the i2c core. I'm finding
> > it hard to dislodge the feeling that open-coding the waits is error prone, but
> > to avoid that and not implement the waits in the i2c core means having almost
> > duplicate implementations of handlers for i2c_smbus_{read,write}*() and
> > pmbus_{read,write}*() calls in the driver.
> >
>
> Not sure I can follow you here. Anyway, it seems to me that you are set on
> an implementation in the i2c core. I personally don't like that approach,
Not really set on it, but it does seem convenient. I'm looking at whether
delays resolve the issues we have with the max31785 as well (I have a bunch of
patches that introduce retries under the various circumstances we've hit poor
behaviour).
> but I'll accept a change in the ucd9000 driver to make use of it. Please
> leave the zl6100 code alone, though - it took me long enough to get that
> working, and I won't have time to test any changes.
No worries. If you don't have time to test changes it reduces the motivation to
find a general approach, and so maybe isolating the work-arounds to the ucd9000
is the way to go.
Thanks for the feedback.
Andrew
