linux-stable.git/drivers/i2c, branch v4.9.99

i2c: i801: Restore configuration at shutdown

2018-04-29T09:31:56+00:00

commit f7f6d915a10f7f2bce17e3b1b7d3376562395a28 upstream.

On some systems, the BIOS expects certain SMBus register values to
match the hardware defaults. Restore these configuration registers at
shutdown time to avoid confusing the BIOS. This avoids hard-locking
such systems upon reboot.

Signed-off-by: Jean Delvare 
Tested-by: Jason Andryuk 
Signed-off-by: Wolfram Sang 
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman

i2c: i801: Save register SMBSLVCMD value only once

2018-04-29T09:31:56+00:00

commit a086bb8317303dd74725dca933b9b29575159382 upstream.

Saving the original value of register SMBSLVCMD in
i801_enable_host_notify() doesn't work, because this function is
called not only at probe time but also at resume time. Do it in
i801_probe() instead, so that the saved value is not overwritten at
resume time.

Signed-off-by: Jean Delvare 
Fixes: 22e94bd6779e ("i2c: i801: store and restore the SLVCMD register at load and unload")
Reviewed-by: Benjamin Tissoires 
Tested-by: Jason Andryuk 
Signed-off-by: Wolfram Sang 
Cc: stable@vger.kernel.org	# v4.10+
Signed-off-by: Greg Kroah-Hartman

i2c: i801: store and restore the SLVCMD register at load and unload

2018-04-29T09:31:56+00:00

commit 22e94bd6779e1140350c0792e85c79552ec43673 upstream.

Also do not override any other configuration in this register.

Signed-off-by: Benjamin Tissoires 
Signed-off-by: Wolfram Sang 
Cc: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman

i2c: mux: reg: put away the parent i2c adapter on probe failure

2018-04-13T17:47:57+00:00

[ Upstream commit 68118e0e73aa3a6291c8b9eb1ee708e05f110cea ]

It is only prudent to let go of resources that are not used.

Fixes: b3fdd32799d8 ("i2c: mux: Add register-based mux i2c-mux-reg")
Signed-off-by: Peter Rosin 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

i2c: i2c-scmi: add a MS HID

2018-03-24T10:00:10+00:00

[ Upstream commit e058e7a4bc89104540a8a303682248614b5df6f1 ]

Description of the problem:
 - i2c-scmi driver contains only two identifiers "SMBUS01" and "SMBUSIBM";
 - the fist HID (SMBUS01) is clearly defined in "SMBus Control Method
   Interface Specification, version 1.0": "Each device must specify
   'SMBUS01' as its _HID and use a unique _UID value";
 - unfortunately, BIOS vendors (like AMI) seem to ignore this requirement
   and implement "SMB0001" HID instead of "SMBUS01";
 - I speculate that they do this because only "SMB0001" is hard coded in
   Windows SMBus driver produced by Microsoft.

This leads to following situation:
 - SMBus works out of box in Windows but not in Linux;
 - board vendors are forced to add correct "SMBUS01" HID to BIOS to make
   SMBus work in Linux. Moreover the same board vendors complain that
   tools (3-rd party ASL compiler) do not like the "SMBUS01" identifier
   and produce errors.  So they need to constantly patch the compiler for
   each new version of BIOS.

As it is very unlikely that BIOS vendors implement a correct HID in
future, I would propose to consider whether it is possible to work around
the problem by adding MS HID to the Linux i2c-scmi driver.

v2: move the definition of the new HID to the driver itself.

Signed-off-by: Edgar Cherkasov 
Signed-off-by: Michael Brunner 
Acked-by: Viktor Krasnov 
Reviewed-by: Jean Delvare 
Reviewed-by: Mika Westerberg 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

i2c: designware: must wait for enable

2018-03-03T09:23:20+00:00

commit fba4adbbf670577e605f9ad306629db6031cd48b upstream.

One I2C bus on my Atom E3845 board has been broken since 4.9.
It has two devices, both declared by ACPI and with built-in drivers.

There are two back-to-back transactions originating from the kernel, one
targeting each device. The first transaction works, the second one locks
up the I2C controller. The controller never recovers.

These kernel logs show up whenever an I2C transaction is attempted after
this failure.
i2c-designware-pci 0000:00:18.3: timeout in disabling adapter
i2c-designware-pci 0000:00:18.3: timeout waiting for bus ready

Waiting for the I2C controller status to indicate that it is enabled
before programming it fixes the issue.

I have tested this patch on 4.14 and 4.15.

Fixes: commit 2702ea7dbec5 ("i2c: designware: wait for disable/enable only if necessary")
Cc: linux-stable  #4.13+
Signed-off-by: Ben Gardner 
Acked-by: Jarkko Nikula 
Reviewed-by: José Roberto de Souza 
Signed-off-by: Wolfram Sang 
Signed-off-by: Ben Gardner 
[Jarkko: Backported to v4.9..v4.12 before i2c-designware-core.c was renamed to i2c-designware-master.c]
Signed-off-by: Jarkko Nikula 
Signed-off-by: Greg Kroah-Hartman

i2c: riic: fix restart condition

2017-12-14T08:28:21+00:00

[ Upstream commit 2501c1bb054290679baad0ff7f4f07c714251f4c ]

While modifying the driver to use the STOP interrupt, the completion of the
intermediate transfers need to wake the driver back up in order to initiate
the next transfer (restart condition). Otherwise you get never ending
interrupts and only the first transfer sent.

Fixes: 71ccea095ea1 ("i2c: riic: correctly finish transfers")
Reported-by: Simon Horman 
Signed-off-by: Chris Brandt 
Tested-by: Simon Horman 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

i2c: i2c-cadence: Initialize configuration before probing devices

2017-12-09T21:01:53+00:00

[ Upstream commit 0e1929dedea36781e25902118c93edd8d8f09af1 ]

The cadence I2C driver calls cdns_i2c_writereg(..) to setup a workaround
in the controller, but did so after calling i2c_add_adapter() which starts
probing devices on the bus. Change the order so that the configuration is
completely finished before using the adapter.

Signed-off-by: Mike Looijmans 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

i2c: i801: Fix Failed to allocate irq -2147483648 error

2017-12-05T10:24:34+00:00

commit 6e0c9507bf51e1517a80ad0ac171e5402528fcef upstream.

On Apollo Lake devices the BIOS does not set up IRQ routing for the i801
SMBUS controller IRQ, so we end up with dev->irq set to IRQ_NOTCONNECTED.

Detect this and do not try to use the irq in this case silencing:
i801_smbus 0000:00:1f.1: Failed to allocate irq -2147483648: -107

BugLink: https://communities.intel.com/thread/114759
Signed-off-by: Hans de Goede 
Reviewed-by: Jean Delvare 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: riic: correctly finish transfers

2017-11-08T09:08:34+00:00

[ Upstream commit 71ccea095ea1d4efd004dab971be6d599e06fc3f ]

This fixes the condition where the controller has not fully completed its
final transfer and leaves the bus and controller in a undesirable state.

At the end of the last transmitted byte, the existing driver would just
signal for a STOP condition to be transmitted then immediately signal
completion. However, the full STOP procedure might not have fully taken
place by the time the runtime PM shuts off the peripheral clock, leaving
the bus in a suspended state.

Alternatively, the STOP condition on the bus may have completed, but when
the next transaction is requested by the upper layer, not all the
necessary register cleanup was finished from the last transfer which made
the driver return BUS BUSY when it really wasn't.

This patch now makes all transmit and receive transactions wait for the
STOP condition to fully complete before signaling a completed transaction.
With this new method, runtime PM no longer seems to be an issue.

Fixes: 310c18a41450 ("i2c: riic: add driver")
Signed-off-by: Chris Brandt 
Reviewed-by: Wolfram Sang 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman