<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/i2c, branch v5.4.50</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.50</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v5.4.50'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-06-30T19:37:02+00:00</updated>
<entry>
<title>i2c: core: check returned size of emulated smbus block read</title>
<updated>2020-06-30T19:37:02+00:00</updated>
<author>
<name>Mans Rullgard</name>
<email>mans@mansr.com</email>
</author>
<published>2020-06-13T10:41:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=5cee9e67596f7d694e94d7def7cd9d65a7599f66'/>
<id>urn:sha1:5cee9e67596f7d694e94d7def7cd9d65a7599f66</id>
<content type='text'>
[ Upstream commit 40e05200593af06633f64ab0effff052eee6f076 ]

If the i2c bus driver ignores the I2C_M_RECV_LEN flag (as some of
them do), it is possible for an I2C_SMBUS_BLOCK_DATA read issued
on some random device to return an arbitrary value in the first
byte (and nothing else).  When this happens, i2c_smbus_xfer_emulated()
will happily write past the end of the supplied data buffer, thus
causing Bad Things to happen.  To prevent this, check the size
before copying the data block and return an error if it is too large.

Fixes: 209d27c3b167 ("i2c: Emulate SMBus block read over I2C")
Signed-off-by: Mans Rullgard &lt;mans@mansr.com&gt;
[wsa: use better errno]
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: fsi: Fix the port number field in status register</title>
<updated>2020-06-30T19:37:02+00:00</updated>
<author>
<name>Eddie James</name>
<email>eajames@linux.ibm.com</email>
</author>
<published>2020-06-09T20:15:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4a6e6413059e8cbacb99ce797ec447612f407e43'/>
<id>urn:sha1:4a6e6413059e8cbacb99ce797ec447612f407e43</id>
<content type='text'>
[ Upstream commit 502035e284cc7e9efef22b01771d822d49698ab9 ]

The port number field in the status register was not correct, so fix it.

Fixes: d6ffb6300116 ("i2c: Add FSI-attached I2C master algorithm")
Signed-off-by: Eddie James &lt;eajames@linux.ibm.com&gt;
Signed-off-by: Joel Stanley &lt;joel@jms.id.au&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>Revert "i2c: tegra: Fix suspending in active runtime PM state"</title>
<updated>2020-06-30T19:36:47+00:00</updated>
<author>
<name>Thierry Reding</name>
<email>treding@nvidia.com</email>
</author>
<published>2020-04-30T11:31:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8ae850cddf27b7b354b6abe207c5b7c05d615a53'/>
<id>urn:sha1:8ae850cddf27b7b354b6abe207c5b7c05d615a53</id>
<content type='text'>
[ Upstream commit 78ad73421831247e46c31899a7bead02740e4bef ]

This reverts commit 9f42de8d4ec2304f10bbc51dc0484f3503d61196.

It's not safe to use pm_runtime_force_{suspend,resume}(), especially
during the noirq phase of suspend. See also the guidance provided in
commit 1e2ef05bb8cf ("PM: Limit race conditions between runtime PM
and system sleep (v2)").

Signed-off-by: Thierry Reding &lt;treding@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>i2c: icy: Fix build with CONFIG_AMIGA_PCMCIA=n</title>
<updated>2020-06-24T15:50:41+00:00</updated>
<author>
<name>Max Staudt</name>
<email>max@enpas.org</email>
</author>
<published>2020-06-07T18:28:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e1ee6238534e514268bc373f03fb398ac0c8a9d0'/>
<id>urn:sha1:e1ee6238534e514268bc373f03fb398ac0c8a9d0</id>
<content type='text'>
[ Upstream commit cdb555397f438592bab00599037c347b700cf397 ]

This has been found by the Kernel Test Robot:
http://lkml.iu.edu/hypermail/linux/kernel/2006.0/06862.html

With CONFIG_AMIGA_PCMCIA=n, io_mm.h does not pull in amigahw.h and
ZTWO_VADDR is undefined. Add forgotten include to i2c-icy.c

Fixes: 4768e90ecaec ("i2c: Add i2c-icy for I2C on m68k/Amiga")
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Signed-off-by: Max Staudt &lt;max@enpas.org&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: pxa: fix i2c_pxa_scream_blue_murder() debug output</title>
<updated>2020-06-24T15:50:24+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@armlinux.org.uk</email>
</author>
<published>2020-04-27T18:49:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=32a5bc992b6cf44ec658eb589b0dbe39e15ed197'/>
<id>urn:sha1:32a5bc992b6cf44ec658eb589b0dbe39e15ed197</id>
<content type='text'>
[ Upstream commit 88b73ee7ca4c90baf136ed5a8377fc5a9b73ac08 ]

The IRQ log output is supposed to appear on a single line.  However,
commit 3a2dc1677b60 ("i2c: pxa: Update debug function to dump more info
on error") resulted in it being printed one-entry-per-line, which is
excessively long.

Fixing this is not a trivial matter; using pr_cont() doesn't work as
the previous dev_dbg() may not have been compiled in, or may be
dynamic.

Since the rest of this function output is at error level, and is also
debug output, promote this to error level as well to avoid this
problem.

Reduce the number of always zero prefix digits to save screen real-
estate.

Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&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: pxa: clear all master action bits in i2c_pxa_stop_message()</title>
<updated>2020-06-24T15:50:12+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@armlinux.org.uk</email>
</author>
<published>2020-05-06T09:36:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8a44731af689d5571dcf43eecaf49e1b11ff6b97'/>
<id>urn:sha1:8a44731af689d5571dcf43eecaf49e1b11ff6b97</id>
<content type='text'>
[ Upstream commit e81c979f4e071d516aa27cf5a0c3939da00dc1ca ]

If we timeout during a message transfer, the control register may
contain bits that cause an action to be set. Read-modify-writing the
register leaving these bits set may trigger the hardware to attempt
one of these actions unintentionally.

Always clear these bits when cleaning up after a message or after
a timeout.

Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&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: piix4: Detect secondary SMBus controller on AMD AM4 chipsets</title>
<updated>2020-06-24T15:50:08+00:00</updated>
<author>
<name>Adam Honse</name>
<email>calcprogrammer1@gmail.com</email>
</author>
<published>2020-04-10T20:48:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=dc570a1fb48c1214193b154fb6cf083d1121a551'/>
<id>urn:sha1:dc570a1fb48c1214193b154fb6cf083d1121a551</id>
<content type='text'>
[ Upstream commit f27237c174fd9653033330e4e532cd9d153ce824 ]

The AMD X370 and other AM4 chipsets (A/B/X 3/4/5 parts) and Threadripper
equivalents have a secondary SMBus controller at I/O port address
0x0B20.  This bus is used by several manufacturers to control
motherboard RGB lighting via embedded controllers.  I have been using
this bus in my OpenRGB project to control the Aura RGB on many
motherboards and ASRock also uses this bus for their Polychrome RGB
controller.

I am not aware of any CZ-compatible platforms which do not have the
second SMBus channel.  All of AMD's AM4- and Threadripper- series
chipsets that OpenRGB users have tested appear to have this secondary
bus.  I also noticed this secondary bus is present on older AMD
platforms including my FM1 home server.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202587
Signed-off-by: Adam Honse &lt;calcprogrammer1@gmail.com&gt;
Reviewed-by: Jean Delvare &lt;jdelvare@suse.de&gt;
Reviewed-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Tested-by: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@the-dreams.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>i2c: altera: Fix race between xfer_msg and isr thread</title>
<updated>2020-06-07T11:18:50+00:00</updated>
<author>
<name>Atsushi Nemoto</name>
<email>atsushi.nemoto@sord.co.jp</email>
</author>
<published>2020-05-08T13:12:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f1c582154e432e66b1f88720cd71d32543d043a8'/>
<id>urn:sha1:f1c582154e432e66b1f88720cd71d32543d043a8</id>
<content type='text'>
[ Upstream commit 5d4c7977499a736f3f80826bdc9744344ad55589 ]

Use a mutex to protect access to idev-&gt;msg_len, idev-&gt;buf, etc. which
are modified by both altr_i2c_xfer_msg() and altr_i2c_isr().

This is the minimal fix for easy backporting. A cleanup to remove the
spinlock will be added later.

Signed-off-by: Atsushi Nemoto &lt;atsushi.nemoto@sord.co.jp&gt;
Acked-by: Thor Thayer &lt;thor.thayer@linux.intel.com&gt;
[wsa: updated commit message]
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: mux: demux-pinctrl: Fix an error handling path in 'i2c_demux_pinctrl_probe()'</title>
<updated>2020-05-27T15:46:18+00:00</updated>
<author>
<name>Christophe JAILLET</name>
<email>christophe.jaillet@wanadoo.fr</email>
</author>
<published>2020-05-06T19:21:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=274cd3c7b5d3e11e7dd724e31e8ff7ddf82e5694'/>
<id>urn:sha1:274cd3c7b5d3e11e7dd724e31e8ff7ddf82e5694</id>
<content type='text'>
[ Upstream commit e9d1a0a41d4486955e96552293c1fcf1fce61602 ]

A call to 'i2c_demux_deactivate_master()' is missing in the error handling
path, as already done in the remove function.

Fixes: 50a5ba876908 ("i2c: mux: demux-pinctrl: add driver")
Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&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: fix missing pm_runtime_put_sync in i2c_device_probe</title>
<updated>2020-05-27T15:46:15+00:00</updated>
<author>
<name>Alain Volmat</name>
<email>alain.volmat@st.com</email>
</author>
<published>2020-04-30T15:43:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=33769c19feba67c484350810431db7c62f88923f'/>
<id>urn:sha1:33769c19feba67c484350810431db7c62f88923f</id>
<content type='text'>
[ Upstream commit 3c3dd56f760da056e821ac177e3ad0de4209a435 ]

In case of the I2C client exposes the flag I2C_CLIENT_HOST_NOTIFY,
pm_runtime_get_sync is called in order to always keep active the
adapter. However later on, pm_runtime_put_sync is never called
within the function in case of an error. This commit add this
error handling.

Fixes: 72bfcee11cf8 ("i2c: Prevent runtime suspend of adapter when Host Notify is required")
Signed-off-by: Alain Volmat &lt;alain.volmat@st.com&gt;
Reviewed-by: Jarkko Nikula &lt;jarkko.nikula@linux.intel.com&gt;
Signed-off-by: Wolfram Sang &lt;wsa@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
