kernel/linux.git/drivers/i2c, branch v4.17.1

i2c: ocores: update HDL sources URL

2018-05-29T18:14:32+00:00

The URL is broken. This patch fixes it. Signed-off-by: Federico Vaga [wsa: shortened the URL a bit] Signed-off-by: Wolfram Sang

i2c: viperboard: return message count on master_xfer success

2018-05-15T07:31:26+00:00

Returning zero is wrong in this case. Signed-off-by: Peter Rosin Signed-off-by: Wolfram Sang Fixes: 174a13aa8669 ("i2c: Add viperboard i2c master driver")

i2c: pmcmsp: fix error return from master_xfer

2018-05-15T07:31:19+00:00

Returning -1 (-EPERM) is not appropriate here, go with -EIO. Signed-off-by: Peter Rosin Signed-off-by: Wolfram Sang Fixes: 1b144df1d7d6 ("i2c: New PMC MSP71xx TWI bus driver")

i2c: pmcmsp: return message count on master_xfer success

2018-05-15T07:30:34+00:00

Returning zero is wrong in this case. Signed-off-by: Peter Rosin Signed-off-by: Wolfram Sang Fixes: 1b144df1d7d6 ("i2c: New PMC MSP71xx TWI bus driver")

i2c: designware: fix poll-after-enable regression

2018-05-10T10:30:20+00:00

Not all revisions of DW I2C controller implement the enable status register. On platforms where that's the case (e.g. BG2CD and SPEAr ARM SoCs), waiting for enable will time out as reading the unimplemented register yields zero. It was observed that reading the IC_ENABLE_STATUS register once suffices to avoid getting it stuck on Bay Trail hardware, so replace polling with one dummy read of the register. Fixes: fba4adbbf670 ("i2c: designware: must wait for enable") Signed-off-by: Alexander Monakov Tested-by: Ben Gardner Acked-by: Jarkko Nikula Signed-off-by: Wolfram Sang Cc: stable@kernel.org

i2c: core: ACPI: Log device not acking errors at dbg loglevel

2018-04-30T08:53:31+00:00

Unfortunately some DSDTs issue bogus i2c reads to non existing devices resulting in -EREMOTEIO errors because the non existing device of course does not ack. This happens e.g. from the The Asus T100TA's _BIX method, the DSDT on the T100TA defines 2 resources on the I2C1 bus: Name (EHID, ResourceTemplate () { I2cSerialBusV2 (0x005B, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\_SB.I2C1", 0x00, ResourceConsumer, , Exclusive, ) }) OperationRegion (EHOR, GenericSerialBus, Zero, 0x0100) Field (EHOR, BufferAcc, NoLock, Preserve) { Connection (EHID), Offset (0x01), AccessAs (BufferAcc, AttribBytes (0x10)), ABCD, 8 } Name (UMPC, ResourceTemplate () { I2cSerialBusV2 (0x0066, ControllerInitiated, 0x00061A80, AddressingMode7Bit, "\\_SB.I2C1", 0x00, ResourceConsumer, , Exclusive, ) }) The _BIX method does a single read (on each BIX() call) from the EHID device through the ABCD Field, only to completely ignore the result. This read always fails as there is no i2c client at address 0x5b. The _BIX method also does several reads from the UMPC device and actually uses the results of those to provide battery information. IIRC I've also seen some DSTDs which do an i2c read to detect if a device is present, also leading to false positive errors being logged. Esp. the _BIX use is problematic as the _BIX method gets called periodically to monitor battery status. This commit stops the logs from filling up with errors like these: [ 57.327858] i2c i2c-0: i2c read 16 bytes from client@0x5b starting at reg 0x1 failed, error: -121 Signed-off-by: Hans de Goede Reviewed-by: Mika Westerberg Signed-off-by: Wolfram Sang

i2c: core: ACPI: Improve OpRegion read errors

2018-04-30T08:53:26+00:00

When we get an error doing an ACPI SerialBus I2C OpRegion read log some useful details, like the client address and which register is being read. Signed-off-by: Hans de Goede Reviewed-by: Mika Westerberg Signed-off-by: Wolfram Sang

i2c: sprd: Fix the i2c count issue

2018-04-27T12:12:43+00:00

We found the I2C controller count register is unreliable sometimes, that will cause I2C to lose data. Thus we can read the data count from 'i2c_dev->count' instead of the I2C controller count register. Signed-off-by: Baolin Wang Signed-off-by: Wolfram Sang

i2c: sprd: Prevent i2c accesses after suspend is called

2018-04-27T12:12:17+00:00

Add one flag to indicate if the i2c controller has been in suspend state, which can prevent i2c accesses after i2c controller is suspended following system suspend. Signed-off-by: Baolin Wang Signed-off-by: Wolfram Sang

i2c: dev: prevent ZERO_SIZE_PTR deref in i2cdev_ioctl_rdwr()

2018-04-27T12:04:10+00:00

i2cdev_ioctl_rdwr() allocates i2c_msg.buf using memdup_user(), which returns ZERO_SIZE_PTR if i2c_msg.len is zero. Currently i2cdev_ioctl_rdwr() always dereferences the buf pointer in case of I2C_M_RD | I2C_M_RECV_LEN transfer. That causes a kernel oops in case of zero len. Let's check the len against zero before dereferencing buf pointer. This issue was triggered by syzkaller. Signed-off-by: Alexander Popov Reviewed-by: Uwe Kleine-König [wsa: use '< 1' instead of '!' for easier readability] Signed-off-by: Wolfram Sang