<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/i2c/busses, branch v6.3.2</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.3.2</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.3.2'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2023-05-11T14:17:27+00:00</updated>
<entry>
<title>i2c: xiic: xiic_xfer(): Fix runtime PM leak on error path</title>
<updated>2023-05-11T14:17:27+00:00</updated>
<author>
<name>Lars-Peter Clausen</name>
<email>lars@metafoo.de</email>
</author>
<published>2023-04-14T02:10:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=688fdfc458bfa651dca39c736d39c1b7520af0e8'/>
<id>urn:sha1:688fdfc458bfa651dca39c736d39c1b7520af0e8</id>
<content type='text'>
[ Upstream commit d663d93bb47e7ab45602b227701022d8aa16040a ]

The xiic_xfer() function gets a runtime PM reference when the function is
entered. This reference is released when the function is exited. There is
currently one error path where the function exits directly, which leads to
a leak of the runtime PM reference.

Make sure that this error path also releases the runtime PM reference.

Fixes: fdacc3c7405d ("i2c: xiic: Switch from waitqueue to completion")
Signed-off-by: Lars-Peter Clausen &lt;lars@metafoo.de&gt;
Reviewed-by: Michal Simek &lt;michal.simek@amd.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>i2c: cadence: cdns_i2c_master_xfer(): Fix runtime PM leak on error path</title>
<updated>2023-05-11T14:17:27+00:00</updated>
<author>
<name>Lars-Peter Clausen</name>
<email>lars@metafoo.de</email>
</author>
<published>2023-04-14T02:10:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5b14d7c6ba0ba5d167f5ef588ca6dfe1af6dd0aa'/>
<id>urn:sha1:5b14d7c6ba0ba5d167f5ef588ca6dfe1af6dd0aa</id>
<content type='text'>
[ Upstream commit ae1664f04f504a998737f5bb563f16b44357bcca ]

The cdns_i2c_master_xfer() function gets a runtime PM reference when the
function is entered. This reference is released when the function is
exited. There is currently one error path where the function exits
directly, which leads to a leak of the runtime PM reference.

Make sure that this error path also releases the runtime PM reference.

Fixes: 1a351b10b967 ("i2c: cadence: Added slave support")
Signed-off-by: Lars-Peter Clausen &lt;lars@metafoo.de&gt;
Reviewed-by: Michal Simek &lt;michal.simek@amd.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>i2c: omap: Fix standard mode false ACK readings</title>
<updated>2023-05-11T14:16:52+00:00</updated>
<author>
<name>Reid Tonking</name>
<email>reidt@ti.com</email>
</author>
<published>2023-04-26T19:49:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ea2e98118b59ed775c7127838fffe4cfe2a8dafa'/>
<id>urn:sha1:ea2e98118b59ed775c7127838fffe4cfe2a8dafa</id>
<content type='text'>
commit c770657bd2611b077ec1e7b1fe6aa92f249399bd upstream.

Using standard mode, rare false ACK responses were appearing with
i2cdetect tool. This was happening due to NACK interrupt triggering
ISR thread before register access interrupt was ready. Removing the
NACK interrupt's ability to trigger ISR thread lets register access
ready interrupt do this instead.

Cc: &lt;stable@vger.kernel.org&gt; # v3.7+
Fixes: 3b2f8f82dad7 ("i2c: omap: switch to threaded IRQ support")
Signed-off-by: Reid Tonking &lt;reidt@ti.com&gt;
Acked-by: Vignesh Raghavendra &lt;vigneshr@ti.com&gt;
Reviewed-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>i2c: ocores: generate stop condition after timeout in polling mode</title>
<updated>2023-04-13T16:29:29+00:00</updated>
<author>
<name>Gregor Herburger</name>
<email>gregor.herburger@tq-group.com</email>
</author>
<published>2023-04-13T09:37:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f8160d3b35fc94491bb0cb974dbda310ef96c0e2'/>
<id>urn:sha1:f8160d3b35fc94491bb0cb974dbda310ef96c0e2</id>
<content type='text'>
In polling mode, no stop condition is generated after a timeout. This
causes SCL to remain low and thereby block the bus. If this happens
during a transfer it can cause slaves to misinterpret the subsequent
transfer and return wrong values.

To solve this, pass the ETIMEDOUT error up from ocores_process_polling()
instead of setting STATE_ERROR directly. The caller is adjusted to call
ocores_process_timeout() on error both in polling and in IRQ mode, which
will set STATE_ERROR and generate a stop condition.

Fixes: 69c8c0c0efa8 ("i2c: ocores: add polling interface")
Signed-off-by: Gregor Herburger &lt;gregor.herburger@tq-group.com&gt;
Signed-off-by: Matthias Schiffer &lt;matthias.schiffer@ew.tq-group.com&gt;
Acked-by: Peter Korsgaard &lt;peter@korsgaard.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Reviewed-by: Federico Vaga &lt;federico.vaga@cern.ch&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</content>
</entry>
<entry>
<title>i2c: mchp-pci1xxxx: Update Timing registers</title>
<updated>2023-03-29T19:12:06+00:00</updated>
<author>
<name>Tharun Kumar P</name>
<email>tharunkumar.pasumarthi@microchip.com</email>
</author>
<published>2023-03-20T14:22:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=aa874cdfec07d4dd9c6f0c356d65c609ba31a26f'/>
<id>urn:sha1:aa874cdfec07d4dd9c6f0c356d65c609ba31a26f</id>
<content type='text'>
Update I2C timing registers based on latest hardware design.
This fix does not break functionality of chips with older design and
existing users will not be affected.

Fixes: 361693697249 ("i2c: microchip: pci1xxxx: Add driver for I2C host controller in multifunction endpoint of pci1xxxx switch")
Signed-off-by: Tharun Kumar P &lt;tharunkumar.pasumarthi@microchip.com&gt;
Reviewed-by: Andy Shevchenko &lt;andriy.shevchenko@linux.intel.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</content>
</entry>
<entry>
<title>i2c: xgene-slimpro: Fix out-of-bounds bug in xgene_slimpro_i2c_xfer()</title>
<updated>2023-03-16T20:15:43+00:00</updated>
<author>
<name>Wei Chen</name>
<email>harperchen1110@gmail.com</email>
</author>
<published>2023-03-14T16:54:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=92fbb6d1296f81f41f65effd7f5f8c0f74943d15'/>
<id>urn:sha1:92fbb6d1296f81f41f65effd7f5f8c0f74943d15</id>
<content type='text'>
The data-&gt;block[0] variable comes from user and is a number between
0-255. Without proper check, the variable may be very large to cause
an out-of-bounds when performing memcpy in slimpro_i2c_blkwr.

Fix this bug by checking the value of writelen.

Fixes: f6505fbabc42 ("i2c: add SLIMpro I2C device driver on APM X-Gene platform")
Signed-off-by: Wei Chen &lt;harperchen1110@gmail.com&gt;
Cc: stable@vger.kernel.org
Reviewed-by: Andi Shyti &lt;andi.shyti@kernel.org&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</content>
</entry>
<entry>
<title>i2c: hisi: Only use the completion interrupt to finish the transfer</title>
<updated>2023-03-16T20:02:15+00:00</updated>
<author>
<name>Yicong Yang</name>
<email>yangyicong@hisilicon.com</email>
</author>
<published>2023-03-13T07:45:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d98263512684a47e81bcb72a5408958ecd1e60b0'/>
<id>urn:sha1:d98263512684a47e81bcb72a5408958ecd1e60b0</id>
<content type='text'>
The controller will always generate a completion interrupt when the
transfer is finished normally or not. Currently we use either error or
completion interrupt to finish, this may result the completion
interrupt unhandled and corrupt the next transfer, especially at low
speed mode. Since on error case, the error interrupt will come first
then is the completion interrupt. So only use the completion interrupt
to finish the whole transfer process.

Fixes: d62fbdb99a85 ("i2c: add support for HiSilicon I2C controller")
Reported-by: Sheng Feng &lt;fengsheng5@huawei.com&gt;
Signed-off-by: Sheng Feng &lt;fengsheng5@huawei.com&gt;
Signed-off-by: Yicong Yang &lt;yangyicong@hisilicon.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</content>
</entry>
<entry>
<title>i2c: hisi: Avoid redundant interrupts</title>
<updated>2023-03-16T20:00:47+00:00</updated>
<author>
<name>Yicong Yang</name>
<email>yangyicong@hisilicon.com</email>
</author>
<published>2023-03-13T07:45:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cc9812a3096d1986caca9a23bee99effc45c08df'/>
<id>urn:sha1:cc9812a3096d1986caca9a23bee99effc45c08df</id>
<content type='text'>
After issuing all the messages we can disable the TX_EMPTY interrupts
to avoid handling redundant interrupts. For doing a sinlge bus
detection (i2cdetect -y -r 0) we can reduce ~97% interrupts (before
~12000 after ~400).

Signed-off-by: Sheng Feng &lt;fengsheng5@huawei.com&gt;
Signed-off-by: Yicong Yang &lt;yangyicong@hisilicon.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</content>
</entry>
<entry>
<title>i2c: mxs: ensure that DMA buffers are safe for DMA</title>
<updated>2023-03-16T19:47:32+00:00</updated>
<author>
<name>Matthias Schiffer</name>
<email>matthias.schiffer@ew.tq-group.com</email>
</author>
<published>2023-02-13T15:25:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5190417bdf72c71b65bd9892103c6186816a6e8b'/>
<id>urn:sha1:5190417bdf72c71b65bd9892103c6186816a6e8b</id>
<content type='text'>
We found that after commit 9c46929e7989
("ARM: implement THREAD_INFO_IN_TASK for uniprocessor systems"), the
PCF85063 RTC driver stopped working on i.MX28 due to regmap_bulk_read()
reading bogus data into a stack buffer. This is caused by the i2c-mxs
driver using DMA transfers even for messages without the I2C_M_DMA_SAFE
flag, and the aforementioned commit enabling vmapped stacks.

As the MXS I2C controller requires DMA for reads of &gt;4 bytes, DMA can't be
disabled, so the issue is fixed by using i2c_get_dma_safe_msg_buf() to
create a bounce buffer when needed.

Fixes: 9c46929e7989 ("ARM: implement THREAD_INFO_IN_TASK for uniprocessor systems")
Signed-off-by: Matthias Schiffer &lt;matthias.schiffer@ew.tq-group.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</content>
</entry>
<entry>
<title>i2c: imx-lpi2c: check only for enabled interrupt flags</title>
<updated>2023-03-16T19:35:57+00:00</updated>
<author>
<name>Alexander Stein</name>
<email>alexander.stein@ew.tq-group.com</email>
</author>
<published>2023-01-30T15:32:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1c7885004567e8951d65a983be095f254dd20bef'/>
<id>urn:sha1:1c7885004567e8951d65a983be095f254dd20bef</id>
<content type='text'>
When reading from I2C, the Tx watermark is set to 0. Unfortunately the
TDF (transmit data flag) is enabled when Tx FIFO entries is equal or less
than watermark. So it is set in every case, hence the reset default of 1.
This results in the MSR_RDF _and_ MSR_TDF flags to be set thus trying
to send Tx data on a read message.
Mask the IRQ status to filter for wanted flags only.

Fixes: a55fa9d0e42e ("i2c: imx-lpi2c: add low power i2c bus driver")
Signed-off-by: Alexander Stein &lt;alexander.stein@ew.tq-group.com&gt;
Tested-by: Emanuele Ghidoli &lt;emanuele.ghidoli@toradex.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
</content>
</entry>
</feed>
