Re: [PATCH] i2c: cadence: Support PEC for SMBus block read

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux