From: Guenter Roeck <linux@roeck-us.net>
To: Mark Brown <broonie@kernel.org>
Cc: Lars-Peter Clausen <lars@metafoo.de>,
Robert Rosengren <robert.rosengren@axis.com>,
linux-kernel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jean Delvare <jdelvare@suse.de>
Subject: Re: [PATCH] regmap: Fix i2c word access when using SMBus access functions
Date: Tue, 3 Feb 2015 08:58:30 -0800 [thread overview]
Message-ID: <20150203165830.GA15081@roeck-us.net> (raw)
In-Reply-To: <20150203160928.GN21293@sirena.org.uk>
On Tue, Feb 03, 2015 at 04:09:28PM +0000, Mark Brown wrote:
> On Tue, Feb 03, 2015 at 06:21:45AM -0800, Guenter Roeck wrote:
> > On 02/03/2015 03:42 AM, Mark Brown wrote:
>
> > >Perhaps it just needs to be more explicit about how it's handling native
> > >endian? I didn't spot it.
>
> > Thinking about it, we should actually reject requests for _NATIVE. SMBus
> > 16 bit accesses are either little endian or big endian.
>
> Yes, that makes sense. It's also hard to see a use case for _NATIVE and
> smbus.
>
> > >>I thought about that, but since the smbus functions perform endianness
> > >>conversion it would mean that I would have to undo that conversion just
> > >>to have it done again.
>
> > >No, the whole point is that by doing this you avoid any endianness
> > >conversions or formatting in the framework at all so you can just use
> > >the smbus functions to handle the formatting.
>
> > Ah, guess I got confused. The SMBus accesses are already using reg_read
> > and reg_write.
>
> It's also possible that you've spotted some bug, wouldn't be the first
> time. Was this spotted by code inspection or by running into a problem?
Oh, I did find a bug; that is the whole reason for this patch. I converted a
driver (hwmon/ads7828) to use regmap. The result works fine with a real chip
connected to an i2c controller supporting direct i2c accesses. However, my
module test code using i2c-stub (which only supports smbus accesses) fails.
In the current code, the direct i2c access functions assume that the chip
reports data MSB first. The SMBus word access functions, however, assume
LSB first. The ADS7828 reports data MSB first, so it works with the i2c
access functions but not with the currently used SMBus access functions.
A simpler fix would have been to use i2c_smbus_read_word_swapped and
i2c_smbus_write_word_swapped instead of i2c_smbus_read_word_data and
i2c_smbus_write_word_data, but then we would end up not supporting
SMBus devices which _do_ report data LSB first.
Guenter
prev parent reply other threads:[~2015-02-03 16:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-01 23:48 [PATCH] regmap: Fix i2c word access when using SMBus access functions Guenter Roeck
2015-02-02 10:09 ` Jean Delvare
2015-02-02 10:26 ` Lars-Peter Clausen
2015-02-02 11:56 ` Mark Brown
2015-02-02 14:30 ` Guenter Roeck
2015-02-03 11:42 ` Mark Brown
2015-02-03 14:21 ` Guenter Roeck
2015-02-03 16:09 ` Mark Brown
2015-02-03 16:58 ` Guenter Roeck [this message]
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=20150203165830.GA15081@roeck-us.net \
--to=linux@roeck-us.net \
--cc=broonie@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jdelvare@suse.de \
--cc=lars@metafoo.de \
--cc=linux-kernel@vger.kernel.org \
--cc=robert.rosengren@axis.com \
/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