From: Jean Delvare <jdelvare@suse.de>
To: Aaron Sierra <asierra@xes-inc.com>
Cc: Wolfram Sang <wsa@the-dreams.de>,
linux-i2c@vger.kernel.org,
Christian Gmeiner <christian.gmeiner@gmail.com>,
Nate Case <ncase@xes-inc.com>
Subject: Re: [PATCH v6] at24: Support SMBus read/write of 16-bit devices
Date: Fri, 18 Dec 2015 21:53:53 +0100 [thread overview]
Message-ID: <20151218215353.4c342398@endymion.delvare> (raw)
In-Reply-To: <1758302572.65470.1450468070959.JavaMail.zimbra@xes-inc.com>
On Fri, 18 Dec 2015 13:47:50 -0600 (CST), Aaron Sierra wrote:
> ----- Original Message -----
> > From: "Wolfram Sang" <wsa@the-dreams.de>
> > Sent: Friday, December 11, 2015 7:19:40 AM
> >
> > I remember I had a lengthy discussion with Guenter Roeck about 16 bit
> > support via smbus. I don't have the bandwidth right now to recap the
> > discussion and check if the concerns apply to your implementation as
> > well. Could you check this thread
> >
> > https://lkml.org/lkml/2015/2/4/436
> >
> > and report back if it applies to your patch as well? This would speed up
> > the review significantly.
>
> The real bus-level multi-master issue is still present. However, it is
> documented via comments in the driver and warnings in the Kconfig.
>
> The other (and apparently bigger) issue of a single master experiencing
> corruption due to simultaneous access through i2c-dev and this driver
> appears to have been resolved. The i2cdump, i2cget, and i2cset utilities
> refuse to access any device that has a driver bound to it. My attempts
> to cause corruption using i2cdump were met with the following message
> until I unregistered the at24 driver from the device:
>
> # i2cdump 8 0x54
> No size specified (using byte-data access)
> Error: Could not set address to 0x54: Device or resource busy
You could always bypass the security check and force the access with
option -f. But then there are plenty of ways to corrupt any device that
way, regardless of the driver (or even without any driver bound to the
device, if you run multiple i2c-dev-based user-space tools in
parallel.) So I'd say this is not relevant.
--
Jean Delvare
SUSE L3 Support
prev parent reply other threads:[~2015-12-18 20:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1914980865.104978.1447718293775.JavaMail.zimbra@xes-inc.com>
2015-11-17 0:02 ` [PATCH v6] at24: Support SMBus read/write of 16-bit devices Aaron Sierra
2015-11-17 16:52 ` Jean Delvare
2015-12-11 13:19 ` Wolfram Sang
2015-12-18 19:47 ` Aaron Sierra
2015-12-18 20:53 ` Jean Delvare [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=20151218215353.4c342398@endymion.delvare \
--to=jdelvare@suse.de \
--cc=asierra@xes-inc.com \
--cc=christian.gmeiner@gmail.com \
--cc=linux-i2c@vger.kernel.org \
--cc=ncase@xes-inc.com \
--cc=wsa@the-dreams.de \
/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