From: "Andrew Jeffery" <andrew@aj.id.au>
To: "Guenter Roeck" <linux@roeck-us.net>
Cc: linux-hwmon@vger.kernel.org, linux-i2c@vger.kernel.org,
"Jean Delvare" <jdelvare@suse.com>,
wsa@kernel.org, "Joel Stanley" <joel@jms.id.au>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 2/2] hwmon: (pmbus/ucd9000) Throttle SMBus transfers to avoid poor behaviour
Date: Thu, 17 Sep 2020 10:03:09 +0930 [thread overview]
Message-ID: <61537381-b1ea-48d3-b445-a33e355f8338@www.fastmail.com> (raw)
In-Reply-To: <20200916155651.GA90122@roeck-us.net>
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
next prev parent reply other threads:[~2020-09-17 0:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-14 12:28 [RFC PATCH 0/2] Throttle I2C transfers to UCD9000 devices Andrew Jeffery
2020-09-14 12:28 ` [RFC PATCH 1/2] i2c: smbus: Allow throttling of transfers to client devices Andrew Jeffery
2020-09-14 12:28 ` [RFC PATCH 2/2] hwmon: (pmbus/ucd9000) Throttle SMBus transfers to avoid poor behaviour Andrew Jeffery
2020-09-14 14:14 ` Guenter Roeck
2020-09-15 0:09 ` Andrew Jeffery
2020-09-16 5:21 ` Andrew Jeffery
2020-09-16 15:56 ` Guenter Roeck
2020-09-17 0:33 ` Andrew Jeffery [this message]
2020-09-14 16:43 ` [RFC PATCH 0/2] Throttle I2C transfers to UCD9000 devices Guenter Roeck
2020-09-15 0:19 ` Andrew Jeffery
2020-09-16 5:35 ` Andrew Jeffery
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=61537381-b1ea-48d3-b445-a33e355f8338@www.fastmail.com \
--to=andrew@aj.id.au \
--cc=jdelvare@suse.com \
--cc=joel@jms.id.au \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=wsa@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®