linux-stable.git/drivers/i2c, branch v3.12.71

i2c: fix kernel memory disclosure in dev interface

2017-01-26T16:40:41+00:00

commit 30f939feaeee23e21391cfc7b484f012eb189c3c upstream.

i2c_smbus_xfer() does not always fill an entire block, allowing
kernel stack memory disclosure through the temp variable. Clear
it before it's read to.

Signed-off-by: Vlad Tsyrklevich 
Signed-off-by: Wolfram Sang 
Signed-off-by: Jiri Slaby

i2c: at91: fix write transfers by clearing pending interrupt first

2016-11-28T21:22:55+00:00

commit 6f6ddbb09d2a5baded0e23add3ad2d9e9417ab30 upstream.

In some cases a NACK interrupt may be pending in the Status Register (SR)
as a result of a previous transfer. However at91_do_twi_transfer() did not
read the SR to clear pending interruptions before starting a new transfer.
Hence a NACK interrupt rose as soon as it was enabled again at the I2C
controller level, resulting in a wrong sequence of operations and strange
patterns of behaviour on the I2C bus, such as a clock stretch followed by
a restart of the transfer.

This first issue occurred with both DMA and PIO write transfers.

Also when a NACK error was detected during a PIO write transfer, the
interrupt handler used to wrongly start a new transfer by writing into the
Transmit Holding Register (THR). Then the I2C slave was likely to reply
with a second NACK.

This second issue is fixed in atmel_twi_interrupt() by handling the TXRDY
status bit only if both the TXCOMP and NACK status bits are cleared.

Tested with a at24 eeprom on sama5d36ek board running a linux-4.1-at91
kernel image. Adapted to linux-next.

Reported-by: Peter Rosin 
Signed-off-by: Cyrille Pitchen 
Signed-off-by: Ludovic Desroches 
Tested-by: Peter Rosin 
Signed-off-by: Wolfram Sang 
Fixes: 93563a6a71bb ("i2c: at91: fix a race condition when using the DMA controller")
Signed-off-by: Jiri Slaby

i2c: core: fix NULL pointer dereference under race condition

2016-11-08T15:38:30+00:00

commit 147b36d5b70c083cc76770c47d60b347e8eaf231 upstream.

Race condition between registering an I2C device driver and
deregistering an I2C adapter device which is assumed to manage that
I2C device may lead to a NULL pointer dereference due to the
uninitialized list head of driver clients.

The root cause of the issue is that the I2C bus may know about the
registered device driver and thus it is matched by bus_for_each_drv(),
but the list of clients is not initialized and commonly it is NULL,
because I2C device drivers define struct i2c_driver as static and
clients field is expected to be initialized by I2C core:

  i2c_register_driver()             i2c_del_adapter()
    driver_register()                 ...
      bus_add_driver()                ...
        ...                           bus_for_each_drv(..., __process_removed_adapter)
      ...                               i2c_do_del_adapter()
    ...                                   list_for_each_entry_safe(..., &driver->clients, ...)
    INIT_LIST_HEAD(&driver->clients);

To solve the problem it is sufficient to do clients list head
initialization before calling driver_register().

The problem was found while using an I2C device driver with a sluggish
registration routine on a bus provided by a physically detachable I2C
master controller, but practically the oops may be reproduced under
the race between arbitraty I2C device driver registration and managing
I2C bus device removal e.g. by unbinding the latter over sysfs:

% echo 21a4000.i2c > /sys/bus/platform/drivers/imx-i2c/unbind
  Unable to handle kernel NULL pointer dereference at virtual address 00000000
  Internal error: Oops: 17 [#1] SMP ARM
  CPU: 2 PID: 533 Comm: sh Not tainted 4.9.0-rc3+ #61
  Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
  task: e5ada400 task.stack: e4936000
  PC is at i2c_do_del_adapter+0x20/0xcc
  LR is at __process_removed_adapter+0x14/0x1c
  Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
  Control: 10c5387d  Table: 35bd004a  DAC: 00000051
  Process sh (pid: 533, stack limit = 0xe4936210)
  Stack: (0xe4937d28 to 0xe4938000)
  Backtrace:
  [] (i2c_do_del_adapter) from [] (__process_removed_adapter+0x14/0x1c)
  [] (__process_removed_adapter) from [] (bus_for_each_drv+0x6c/0xa0)
  [] (bus_for_each_drv) from [] (i2c_del_adapter+0xbc/0x284)
  [] (i2c_del_adapter) from [] (i2c_imx_remove+0x44/0x164 [i2c_imx])
  [] (i2c_imx_remove [i2c_imx]) from [] (platform_drv_remove+0x2c/0x44)
  [] (platform_drv_remove) from [] (__device_release_driver+0x90/0x12c)
  [] (__device_release_driver) from [] (device_release_driver+0x28/0x34)
  [] (device_release_driver) from [] (unbind_store+0x80/0x104)
  [] (unbind_store) from [] (drv_attr_store+0x28/0x34)
  [] (drv_attr_store) from [] (sysfs_kf_write+0x50/0x54)
  [] (sysfs_kf_write) from [] (kernfs_fop_write+0x100/0x214)
  [] (kernfs_fop_write) from [] (__vfs_write+0x34/0x120)
  [] (__vfs_write) from [] (vfs_write+0xa8/0x170)
  [] (vfs_write) from [] (SyS_write+0x4c/0xa8)
  [] (SyS_write) from [] (ret_fast_syscall+0x0/0x1c)

Signed-off-by: Vladimir Zapolskiy 
Signed-off-by: Wolfram Sang 
Signed-off-by: Jiri Slaby

i2c-eg20t: fix race between i2c init and interrupt enable

2016-10-06T06:21:58+00:00

commit 371a015344b6e270e7e3632107d9554ec6d27a6b upstream.

the eg20t driver call request_irq() function before the pch_base_address,
base address of i2c controller's register, is assigned an effective value.

there is one possible scenario that an interrupt which isn't inside eg20t
arrives immediately after request_irq() is executed when i2c controller
shares an interrupt number with others. since the interrupt handler
pch_i2c_handler() has already active as shared action, it will be called
and read its own register to determine if this interrupt is from itself.

At that moment, since base address of i2c registers is not remapped
in kernel space yet,so the INT handler will access an illegal address
and then a error occurs.

Signed-off-by: Yadi.hu 
Signed-off-by: Wolfram Sang 
Signed-off-by: Jiri Slaby

i2c: i801: add Intel Lewisburg device IDs

2016-01-05T17:35:58+00:00

commit cdc5a3110e7c3ae793f367285789a6bc39c962dc upstream.

Adding Intel codename Lewisburg platform device IDs for SMBus.

Signed-off-by: Alexandra Yates 
Reviewed-by: Jean Delvare 
Signed-off-by: Wolfram Sang 
Cc: Oliver Neukum 
Signed-off-by: Jiri Slaby

i2c: i801: Add support for Intel Broxton

2016-01-05T17:34:20+00:00

commit dd77f423e516293c37c2370b44fd700900409c48 upstream.

This patch adds the SMBUS PCI ID of Intel Broxton.

Signed-off-by: Jarkko Nikula 
Signed-off-by: Wolfram Sang 
Cc: Oliver Neukum 
Signed-off-by: Jiri Slaby

i2c: designware: Do not use parameters from ACPI on Dell Inspiron 7348

2015-10-28T15:38:22+00:00

commit 56d4b8a24cef5d66f0d10ac778a520d3c2c68a48 upstream.

ACPI SSCN/FMCN methods were originally added because then the platform can
provide the most accurate HCNT/LCNT values to the driver. However, this
seems not to be true for Dell Inspiron 7348 where using these causes the
touchpad to fail in boot:

  i2c_hid i2c-DLL0675:00: failed to retrieve report from device.
  i2c_designware INT3433:00: i2c_dw_handle_tx_abort: lost arbitration
  i2c_hid i2c-DLL0675:00: failed to retrieve report from device.
  i2c_designware INT3433:00: controller timed out

The values received from ACPI are (in fast mode):

  HCNT: 72
  LCNT: 160

this translates to following timings (input clock is 100MHz on Broadwell):

  tHIGH: 720 ns (spec min 600 ns)
  tLOW: 1600 ns (spec min 1300 ns)
  Bus period: 2920 ns (assuming 300 ns tf and tr)
  Bus speed: 342.5 kHz

Both tHIGH and tLOW are within the I2C specification.

The calculated values when ACPI parameters are not used are (in fast mode):

  HCNT: 87
  LCNT: 159

which translates to:

  tHIGH: 870 ns (spec min 600 ns)
  tLOW: 1590 ns (spec min 1300 ns)
  Bus period 3060 ns (assuming 300 ns tf and tr)
  Bus speed 326.8 kHz

These values are also within the I2C specification.

Since both ACPI and calculated values meet the I2C specification timing
requirements it is hard to say why the touchpad does not function properly
with the ACPI values except that the bus speed is higher in this case (but
still well below the max 400kHz).

Solve this by adding DMI quirk to the driver that disables using ACPI
parameters on this particulare machine.

Reported-by: Pavel Roskin 
Signed-off-by: Mika Westerberg 
Tested-by: Pavel Roskin 
Signed-off-by: Wolfram Sang 
Signed-off-by: Jiri Slaby

i2c: s3c2410: enable RuntimePM before registering to the core

2015-10-28T15:38:21+00:00

commit eadd709f5d2e8aebb1b7bf49460e97a68d81a9b0 upstream.

The core may register clients attached to this master which may use
funtionality from the master. So, RuntimePM must be enabled before, otherwise
this will fail. While here, move drvdata, too.

Signed-off-by: Wolfram Sang 
Tested-by: Krzysztof Kozlowski 
Acked-by: Kukjin Kim 
Signed-off-by: Wolfram Sang 
Signed-off-by: Jiri Slaby

i2c: rcar: enable RuntimePM before registering to the core

2015-10-28T15:38:20+00:00

commit 4f7effddf4549d57114289f273710f077c4c330a upstream.

The core may register clients attached to this master which may use
funtionality from the master. So, RuntimePM must be enabled before, otherwise
this will fail. While here, move drvdata, too.

Reported-by: Geert Uytterhoeven 
Signed-off-by: Wolfram Sang 
Signed-off-by: Wolfram Sang 
Signed-off-by: Jiri Slaby

i2c: at91: fix a race condition when using the DMA controller

2015-08-04T14:52:05+00:00

commit 93563a6a71bb69dd324fc7354c60fb05f84aae6b upstream.

For TX transactions, the TXCOMP bit in the Status Register is cleared
when the first data is written into the Transmit Holding Register.

In the lines from at91_do_twi_transfer():
at91_twi_write_data_dma(dev);
at91_twi_write(dev, AT91_TWI_IER, AT91_TWI_TXCOMP);

the TXCOMP interrupt may be enabled before the DMA controller has
actually started to write into the THR. In such a case, the TXCOMP bit
is still set into the Status Register so the interrupt is triggered
immediately. The driver understands that a transaction completion has
occurred but this transaction hasn't started yet. Hence the TXCOMP
interrupt is no longer enabled by at91_do_twi_transfer() but instead
by at91_twi_write_data_dma_callback().

Also, the TXCOMP bit in the Status Register in not a clear on read flag
but a snapshot of the transmission state at the time the Status
Register is read.
When a NACK error is dectected by the I2C controller, the TXCOMP, NACK
and TXRDY bits are set together to 1 in the SR. If enabled, the TXCOMP
interrupt is triggered at the same time. Also setting the TXRDY to 1
triggers the DMA controller to write the next data into the THR. Such
a write resets the TXCOMP bit to 0 in the SR. So depending on when the
interrupt handler reads the SR, it may fail to detect the NACK error
if it relies on the TXCOMP bit. The NACK bit and its interrupt should
be used instead.

For RX transactions, the TXCOMP bit in the Status Register is cleared
when the START bit is set into the Control Register. However to unify
the management of the TXCOMP bit when the DMA controller is used, the
TXCOMP interrupt is now enabled by the DMA callbacks for both TX and
RX transfers.

Signed-off-by: Cyrille Pitchen 
Acked-by: Ludovic Desroches 
Signed-off-by: Wolfram Sang 
Signed-off-by: Jiri Slaby