linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: Michal Simek <michal.simek@amd.com>,
	Wolfram Sang <wsa@kernel.org>,
	Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
Cc: linux-i2c@vger.kernel.org, git <git@xilinx.com>
Subject: Re: [PATCH] i2c: cadence: Support PEC for SMBus block read
Date: Tue, 19 Jul 2022 10:57:03 +0200	[thread overview]
Message-ID: <e5a63b48-5a09-cbe8-b173-a9c7b7abedc7@metafoo.de> (raw)
In-Reply-To: <768b56a8-df1c-e24d-7879-328512598549@amd.com>

On 7/18/22 11:25, Michal Simek wrote:
>
>
> On 7/17/22 16:52, Lars-Peter Clausen wrote:
>> SMBus packet error checking (PEC) is implemented by appending one
>> additional byte of checksum data at the end of the message. This 
>> provides
>> additional protection and allows to detect data corruption on the I2C 
>> bus.
>>
>> SMBus block reads support variable length reads. The first byte in 
>> the read
>> message is the number of available data bytes.
>>
>> The combination of PEC and block read is currently not supported by the
>> Cadence I2C driver.
>>   * When PEC is enabled the maximum transfer length for block reads
>>     increases from 33 to 34 bytes.
>>   * The I2C core smbus emulation layer relies on the driver updating the
>>     `i2c_msg` `len` field with the number of received bytes. The updated
>>     length is used when checking the PEC.
>>
>> Add support to the Cadence I2C driver for handling SMBus block reads 
>> with
>> PEC. To determine the maximum transfer length uses the initial `len` 
>> value
>> of the `i2c_msg`. When PEC is enabled this will be 2, when it is 
>> disabled
>> it will be 1.
>>
>> Once a read transfer is done also increment the `len` field by the 
>> amount
>> of received data bytes.
>>
>> This change has been tested with a UCM90320 PMBus power monitor, which
>> requires block reads to access certain data fields, but also has PEC
>> enabled by default.
>>
>> Fixes: df8eb5691c48 ("i2c: Add driver for Cadence I2C controller")
>
> Subject is saying that you adding support for PEC and here you are 
> saying that it is fixing initial commit.
>
> If this is adding new support I think Fixes tag shouldn't be here.
>
> If it is fixing issue subject should be updated and this Fixes tag 
> kept here.

I added it because I was afraid Wolfram would ask where is the fixes tag.

This change arguably somewhere between new feature and fix. The driver 
reports that it supports SMBus block read, but it does not work under 
the case that PEC is enabled. You can argue that it is a new feature 
because it never worked, but you can also argue it is a fix because the 
current implementation is broken. I'm fine either way with or without 
Fixes tag. I'll let Wolfram make the decision what he prefers.


  parent reply	other threads:[~2022-07-19  8:57 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-17 14:52 [PATCH] i2c: cadence: Support PEC for SMBus block read Lars-Peter Clausen
2022-07-18  9:25 ` Michal Simek
2022-07-18 12:37   ` Datta, Shubhrajyoti
2022-07-18 12:54     ` Michal Simek
2022-07-18 13:11       ` Datta, Shubhrajyoti
2022-07-24  5:46         ` Wolfram Sang
2022-07-19  8:57   ` Lars-Peter Clausen [this message]
2022-07-24  5:47 ` Wolfram Sang

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=e5a63b48-5a09-cbe8-b173-a9c7b7abedc7@metafoo.de \
    --to=lars@metafoo.de \
    --cc=git@xilinx.com \
    --cc=linux-i2c@vger.kernel.org \
    --cc=michal.simek@amd.com \
    --cc=shubhrajyoti.datta@amd.com \
    --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;
as well as URLs for NNTP newsgroup(s).