mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Stephen Douthit <stephend@adiengineering.com>
To: Pontus Andersson <epontan@gmail.com>, Wolfram Sang <wsa@the-dreams.de>
Cc: Seth Heasley <seth.heasley@intel.com>,
	Neil Horman <nhorman@tuxdriver.com>,
	linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] i2c: ismt: Separate I2C block read from SMBus block read
Date: Fri, 6 Oct 2017 18:54:56 -0400	[thread overview]
Message-ID: <9e4c9318-579f-b5f2-6ad2-c1cb9aad8e78@adiengineering.com> (raw)
In-Reply-To: <20171005141311.GA8565@leonis.localdomain>

On 10/05/2017 10:13 AM, Pontus Andersson wrote:
> On Thu, Oct 05, 2017 at 02:41:33PM +0200, Wolfram Sang wrote:
>> On Mon, Oct 02, 2017 at 02:45:19PM +0200, Pontus Andersson wrote:
>>> Commit b6c159a9cb69 ("i2c: ismt: Don't duplicate the receive length for
>>> block reads") broke I2C block reads. It aimed to fix normal SMBus block
>>> read, but changed the correct behavior of I2C block read in the process.
>>>
>>> According to Documentation/i2c/smbus-protocol, one vital difference
>>> between normal SMBus block read and I2C block read is that there is no
>>> byte count prefixed in the data sent on the wire:
>>>
>>>   SMBus Block Read:  i2c_smbus_read_block_data()
>>>   S Addr Wr [A] Comm [A]
>>>              S Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P
>>>
>>>   I2C Block Read:  i2c_smbus_read_i2c_block_data()
>>>   S Addr Wr [A] Comm [A]
>>>              S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P
>>>
>>> Therefore the two transaction types need to be processed differently in
>>> the driver by copying of the dma_buffer as done previously for the
>>> I2C_SMBUS_I2C_BLOCK_DATA case.
>>>
>>> Fixes: b6c159a9cb69 ("i2c: ismt: Don't duplicate the receive length for block reads")
>>> Signed-off-by: Pontus Andersson <epontan@gmail.com>
>>> Cc: stable@vger.kernel.org
>>
>> Applied to for-current, thanks!
> 
> Thank you! Is it safe to asume it will be backported to 4.4 stable
> branch and upwards as the problematic commit did (once in mainline)?
> 
>> Might have been good to CC the patch author of the problematic commit,
>> too.
> 
> Yes, of course! Stephen is CC now at least (kept the commit message
> quoted at his convenience).

Doh.  Looks like our regression test gave a false pass on the I2C access 
case.  I'd guess it's probably doing a series of byte reads instead of a 
block read and missing the I2C_SMBUS_I2C_BLOCK_DATA case entirely.

Unfortunately I can't find the board that was modded with more I2C 
devices on the ismt bus to verify this right now.  I'll check with Dan 
on Monday to see if he knows where that board is stashed.

Apologies for moving the bug instead of fixing it, and FWIW I'll have an 
update Monday.

  reply	other threads:[~2017-10-06 22:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-02 12:45 Pontus Andersson
2017-10-05 12:41 ` Wolfram Sang
2017-10-05 14:13   ` Pontus Andersson
2017-10-06 22:54     ` Stephen Douthit [this message]
2017-10-07  8:14     ` Wolfram Sang
     [not found]       ` <c9a1d377-1a72-a1fa-304a-48d593d48e6b@adiengineering.com>
2017-10-09 17:18         ` Stephen Douthit

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=9e4c9318-579f-b5f2-6ad2-c1cb9aad8e78@adiengineering.com \
    --to=stephend@adiengineering.com \
    --cc=epontan@gmail.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=seth.heasley@intel.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

all inboxes | Powered by JetHome®