mbox series

[SRU,F:linux-bluefield,v1,0/1] UBUNTU: SAUCE: i2c-mlxbf.c: support lock mechanism

Message ID 20220708193217.22920-1-asmaa@nvidia.com
Headers show
Series UBUNTU: SAUCE: i2c-mlxbf.c: support lock mechanism | expand

Message

Asmaa Mnebhi July 8, 2022, 7:32 p.m. UTC 
Buglink: https://bugs.launchpad.net/bugs/1981105

SRU Justification:

[Impact]

Support the I2C lock mechanism, otherwise there could be unexpected behavior when an i2c bus is accessed by several entities like the linux driver, ATF driver and UEFI driver. Replace ioremap_cache with ioremap since it is deprecated in later kernels.

[Fix]

* Support lock and unlock
* replace ioremap_nocache with ioremap

[Test Case]

* Make sure the i2c-mlxbf.c driver is loaded and /dev/i2c-1 is created
* check that ipmitool from the BF->BMC and from the BMC->BF work (this only applies on boards with a BMC of course)

[Regression Potential]

Any of the test cases above could be impacted due to these changes.

Comments

Tim Gardner July 11, 2022, 12:34 p.m. UTC | #1 
On 7/8/22 13:32, Asmaa Mnebhi wrote:
> Buglink: https://bugs.launchpad.net/bugs/1981105
> 
> SRU Justification:
> 
> [Impact]
> 
> Support the I2C lock mechanism, otherwise there could be unexpected
> behavior when an i2c bus is accessed by several entities like the
> linux driver, ATF driver and UEFI driver. Replace ioremap_cache with
> ioremap since it is deprecated in later kernels.
> 
> [Fix]
> 
> * Support lock and unlock * replace ioremap_nocache with ioremap
> 
> [Test Case]
> 
> * Make sure the i2c-mlxbf.c driver is loaded and /dev/i2c-1 is
> created * check that ipmitool from the BF->BMC and from the BMC->BF
> work (this only applies on boards with a BMC of course)
> 
> [Regression Potential]
> 
> Any of the test cases above could be impacted due to these changes.
> 

You have mixed 2 logically separate changes into one patch. Replacing 
ioremap_nocache with ioremap has nothing to do with adding lock 
protection for I2C access.

rtg