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

i2c: riic: Clear NACK in tend isr

2019-10-05T10:27:55+00:00

commit a71e2ac1f32097fbb2beab098687a7a95c84543e upstream.

The NACKF flag should be cleared in INTRIICNAKI interrupt processing as
description in HW manual.

This issue shows up quickly when PREEMPT_RT is applied and a device is
probed that is not plugged in (like a touchscreen controller). The result
is endless interrupts that halt system boot.

Fixes: 310c18a41450 ("i2c: riic: add driver")
Cc: stable@vger.kernel.org
Reported-by: Chien Nguyen 
Signed-off-by: Chris Brandt 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: dev: fix potential memory leak in i2cdev_ioctl_rdwr

2019-06-22T06:18:26+00:00

[ Upstream commit a0692f0eef91354b62c2b4c94954536536be5425 ]

If I2C_M_RECV_LEN check failed, msgs[i].buf allocated by memdup_user
will not be freed. Pump index up so it will be freed.

Fixes: 838bfa6049fb ("i2c-dev: Add support for I2C_M_RECV_LEN")
Signed-off-by: Yingjoe Chen 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin

i2c: acorn: fix i2c warning

2019-06-22T06:18:22+00:00

commit ca21f851cc9643af049226d57fabc3c883ea648e upstream.

The Acorn i2c driver (for RiscPC) triggers the "i2c adapter has no name"
warning in the I2C core driver, resulting in the RTC being inaccessible.
Fix this.

Fixes: 2236baa75f70 ("i2c: Sanity checks on adapter registration")
Signed-off-by: Russell King 
Signed-off-by: Wolfram Sang 
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman

i2c: core-smbus: prevent stack corruption on read I2C_BLOCK_DATA

2019-04-27T07:33:47+00:00

commit 89c6efa61f5709327ecfa24bff18e57a4e80c7fa upstream.

On a I2C_SMBUS_I2C_BLOCK_DATA read request, if data->block[0] is
greater than I2C_SMBUS_BLOCK_MAX + 1, the underlying I2C driver writes
data out of the msgbuf1 array boundary.

It is possible from a user application to run into that issue by
calling the I2C_SMBUS ioctl with data.block[0] greater than
I2C_SMBUS_BLOCK_MAX + 1.

This patch makes the code compliant with
Documentation/i2c/dev-interface by raising an error when the requested
size is larger than 32 bytes.

Call Trace:
 [] dump_stack+0x67/0x92
 [] panic+0xc5/0x1eb
 [] ? vprintk_default+0x1f/0x30
 [] ? i2cdev_ioctl_smbus+0x303/0x320
 [] __stack_chk_fail+0x1b/0x20
 [] i2cdev_ioctl_smbus+0x303/0x320
 [] i2cdev_ioctl+0x4d/0x1e0
 [] do_vfs_ioctl+0x2ba/0x490
 [] ? security_file_ioctl+0x43/0x60
 [] SyS_ioctl+0x79/0x90
 [] entry_SYSCALL_64_fastpath+0x12/0x6a

Signed-off-by: Jeremy Compostella 
Signed-off-by: Wolfram Sang 
Cc: stable@kernel.org
[connoro@google.com: 4.9 backport: adjust filename]
Signed-off-by: Connor O'Brien 
Signed-off-by: Greg Kroah-Hartman

i2c: tegra: fix maximum transfer size

2019-03-23T07:44:37+00:00

commit f4e3f4ae1d9c9330de355f432b69952e8cef650c upstream.

Tegra186 and prior supports maximum 4K bytes per packet transfer
including 12 bytes of packet header.

This patch fixes max write length limit to account packet header
size for transfers.

Cc: stable@vger.kernel.org # 4.4+

Reviewed-by: Dmitry Osipenko 
Signed-off-by: Sowjanya Komatineni 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: cadence: Fix the hold bit setting

2019-03-23T07:44:33+00:00

[ Upstream commit d358def706880defa4c9e87381c5bf086a97d5f9 ]

In case the hold bit is not needed we are carrying the old values.
Fix the same by resetting the bit when not needed.

Fixes the sporadic i2c bus lockups on National Instruments
Zynq-based devices.

Fixes: df8eb5691c48 ("i2c: Add driver for Cadence I2C controller")
Reported-by: Kyle Roeschley 
Acked-by: Michal Simek 
Signed-off-by: Shubhrajyoti Datta 
Tested-by: Kyle Roeschley 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin

i2c-axxia: check for error conditions first

2019-02-20T09:13:09+00:00

[ Upstream commit 4f5c85fe3a60ace555d09898166af372547f97fc ]

It was observed that when using seqentional mode contrary to the
documentation, the SS bit (which is supposed to only be set if
automatic/sequence command completed normally), is sometimes set
together with NA (NAK in address phase) causing transfer to falsely be
considered successful.

My assumption is that this does not happen during manual mode since the
controller is stopping its work the moment it sets NA/ND bit in status
register. This is not the case in Automatic/Sequentional mode where it
is still working to send STOP condition and the actual status we get
depends on the time when the ISR is run.

This patch changes the order of checking status bits in ISR - error
conditions are checked first and only if none of them occurred, the
transfer may be considered successful. This is required to introduce
using of sequentional mode in next patch.

Signed-off-by: Krzysztof Adamski 
Reviewed-by: Alexander Sverdlin 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin

i2c: dev: prevent adapter retries and timeout being set as minus value

2019-01-16T21:16:12+00:00

commit 6ebec961d59bccf65d08b13fc1ad4e6272a89338 upstream.

If adapter->retries is set to a minus value from user space via ioctl,
it will make __i2c_transfer and __i2c_smbus_xfer skip the calling to
adapter->algo->master_xfer and adapter->algo->smbus_xfer that is
registered by the underlying bus drivers, and return value 0 to all the
callers. The bus driver will never be accessed anymore by all users,
besides, the users may still get successful return value without any
error or information log print out.

If adapter->timeout is set to minus value from user space via ioctl,
it will make the retrying loop in __i2c_transfer and __i2c_smbus_xfer
always break after the the first try, due to the time_after always
returns true.

Signed-off-by: Yi Zeng 
[wsa: minor grammar updates to commit message]
Signed-off-by: Wolfram Sang 
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman

i2c: scmi: Fix probe error on devices with an empty SMB0001 ACPI device node

2018-12-21T13:09:53+00:00

[ Upstream commit 0544ee4b1ad574aec3b6379af5f5cdee42840971 ]

Some AMD based HP laptops have a SMB0001 ACPI device node which does not
define any methods.

This leads to the following error in dmesg:

[    5.222731] cmi: probe of SMB0001:00 failed with error -5

This commit makes acpi_smbus_cmi_add() return -ENODEV instead in this case
silencing the error. In case of a failure of the i2c_add_adapter() call
this commit now propagates the error from that call instead of -EIO.

Signed-off-by: Hans de Goede 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin

i2c: axxia: properly handle master timeout

2018-12-21T13:09:53+00:00

[ Upstream commit 6c7f25cae54b840302e4f1b371dbf318fbf09ab2 ]

According to Intel (R) Axxia TM Lionfish Communication Processor
Peripheral Subsystem Hardware Reference Manual, the AXXIA I2C module
have a programmable Master Wait Timer, which among others, checks the
time between commands send in manual mode. When a timeout (25ms) passes,
TSS bit is set in Master Interrupt Status register and a Stop command is
issued by the hardware.

The axxia_i2c_xfer(), does not properly handle this situation, however.
For each message a separate axxia_i2c_xfer_msg() is called and this
function incorrectly assumes that any interrupt might happen only when
waiting for completion. This is mostly correct but there is one
exception - a master timeout can trigger if enough time has passed
between individual transfers. It will, by definition, happen between
transfers when the interrupts are disabled by the code. If that happens,
the hardware issues Stop command.

The interrupt indicating timeout will not be triggered as soon as we
enable them since the Master Interrupt Status is cleared when master
mode is entered again (which happens before enabling irqs) meaning this
error is lost and the transfer is continued even though the Stop was
issued on the bus. The subsequent operations completes without error but
a bogus value (0xFF in case of read) is read as the client device is
confused because aborted transfer. No error is returned from
master_xfer() making caller believe that a valid value was read.

To fix the problem, the TSS bit (indicating timeout) in Master Interrupt
Status register is checked before each transfer. If it is set, there was
a timeout before this transfer and (as described above) the hardware
already issued Stop command so the transaction should be aborted thus
-ETIMEOUT is returned from the master_xfer() callback. In order to be
sure no timeout was issued we can't just read the status just before
starting new transaction as there will always be a small window of time
(few CPU cycles at best) where this might still happen. For this reason
we have to temporally disable the timer before checking for TSS bit.
Disabling it will, however, clear the TSS bit so in order to preserve
that information, we have to read it in ISR so we have to ensure that
the TSS interrupt is not masked between transfers of one transaction.
There is no need to call bus recovery or controller reinitialization if
that happens so it's skipped.

Signed-off-by: Krzysztof Adamski 
Reviewed-by: Alexander Sverdlin 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin