linux.git/drivers/i2c, branch v4.7-rc4

i2c: mux: reg: Provide of_match_table

2016-06-09T20:38:16+00:00

of_match_table was not filled which prevents device to be
instantiated from device tree node.

Signed-off-by: Lukasz Gemborowski 
Reviewed-by: Alexander Sverdlin 
Signed-off-by: Wolfram Sang

i2c: octeon: Avoid printk after too long SMBUS message

2016-06-09T20:07:57+00:00

Remove the warning about a too long SMBUS message because
the ipmi_ssif driver triggers this warning too frequently so it
spams the message log.

Signed-off-by: Jan Glauber 
Signed-off-by: Wolfram Sang

i2c: octeon: Missing AAK flag in case of I2C_M_RECV_LEN

2016-06-09T20:05:32+00:00

During receive the controller requires the AAK flag for all
bytes but the final one. This was wrong in case of I2C_M_RECV_LEN,
where the decision if the final byte is to be transmitted
happened before adding the additional received length byte.

Set the AAK flag if additional bytes are to be received.

Signed-off-by: Jan Glauber 
Signed-off-by: Wolfram Sang

i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR

2016-06-09T19:38:57+00:00

Many Intel systems the BIOS declares a SystemIO OpRegion below the SMBus
PCI device as can be seen in ACPI DSDT table from Lenovo Yoga 900:

  Device (SBUS)
  {
      OperationRegion (SMBI, SystemIO, (SBAR << 0x05), 0x10)
      Field (SMBI, ByteAcc, NoLock, Preserve)
      {
          HSTS,   8,
          Offset (0x02),
          HCON,   8,
          HCOM,   8,
          TXSA,   8,
          DAT0,   8,
          DAT1,   8,
          HBDR,   8,
          PECR,   8,
          RXSA,   8,
          SDAT,   16
      }

There are also bunch of AML methods that that the BIOS can use to access
these fields. Most of the systems in question AML methods accessing the
SMBI OpRegion are never used.

Now, because of this SMBI OpRegion many systems fail to load the SMBus
driver with an error looking like one below:

  ACPI Warning: SystemIO range 0x0000000000003040-0x000000000000305F
       conflicts with OpRegion 0x0000000000003040-0x000000000000304F
       (\_SB.PCI0.SBUS.SMBI) (20160108/utaddress-255)
  ACPI: If an ACPI driver is available for this device, you should use
       it instead of the native driver

The reason is that this SMBI OpRegion conflicts with the PCI BAR used by
the SMBus driver.

It turns out that we can install a custom SystemIO address space handler
for the SMBus device to intercept all accesses through that OpRegion. This
allows us to share the PCI BAR with the AML code if it for some reason is
using it. We do not expect that this OpRegion handler will ever be called
but if it is we print a warning and prevent all access from the SMBus
driver itself.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=110041
Reported-by: Andy Lutomirski 
Reported-by: Pali Rohár 
Suggested-by: Rafael J. Wysocki 
Signed-off-by: Mika Westerberg 
Acked-by: Rafael J. Wysocki 
Reviewed-by: Jean Delvare 
Reviewed-by: Benjamin Tissoires 
Tested-by: Pali Rohár 
Tested-by: Jean Delvare 
Signed-off-by: Wolfram Sang 
Cc: stable@vger.kernel.org

i2c: dev: use after free in detach

2016-05-28T15:37:42+00:00

The call to put_i2c_dev() frees "i2c_dev" so there is a use after
free when we call cdev_del(&i2c_dev->cdev).

Fixes: d6760b14d4a1 ('i2c: dev: switch from register_chrdev to cdev API')
Signed-off-by: Dan Carpenter 
Signed-off-by: Wolfram Sang

i2c: dev: don't start function name with 'return'

2016-05-27T11:13:01+00:00

I stumbled multiple times over 'return_i2c_dev', especially before the
actual 'return res'. It makes the code hard to read, so reanme the
function to 'put_i2c_dev' which also better matches 'get_free_i2c_dev'.

Signed-off-by: Wolfram Sang

i2c: dev: switch from register_chrdev to cdev API

2016-05-26T19:18:57+00:00

i2c-dev had never moved away from the older register_chrdev interface to
implement its char device registration. The register_chrdev API has the
limitation of enabling only up to 256 i2c-dev busses to exist.

Large platforms with lots of i2c devices (i.e. pluggable transceivers)
with dedicated busses may have to exceed that limit.
In particular, there are also platforms making use of the i2c bus
multiplexing API, which instantiates a virtual bus for each possible
multiplexed selection.

This patch removes the register_chrdev usage and replaces it with the
less old cdev API, which takes away the 256 i2c-dev bus limitation.
It should not have any other impact for i2c bus drivers or user space.

This patch has been tested on qemu x86 and qemu powerpc platforms with
the aid of a module which adds and removes 5000 virtual i2c busses, as
well as validated on an existing powerpc hardware platform which makes
use of the i2c bus multiplexing API.
i2c-dev busses with device minor numbers larger than 256 have also been
validated to work with the existing i2c-tools.

Signed-off-by: Erico Nunes 
[wsa: kept includes sorted]
Signed-off-by: Wolfram Sang

i2c: xlr: rename ARCH_TANGOX to ARCH_TANGO

2016-05-26T19:18:56+00:00

The ARCH name was changed during the review process of the mach, and
this driver was forgotten to be converted. Fix it now.
http://article.gmane.org/gmane.linux.ports.arm.kernel/456331

Signed-off-by: Marc Gonzalez 
[wsa: updated commit message slightly]
Signed-off-by: Wolfram Sang

i2c: at91: change log when dma configuration fails

2016-05-26T18:54:19+00:00

When the DMA configuration fails, there is a log reporting that we can't
use DMA and indicating the error number. When booting the kernel, it is
annoying to see this error number. Moreover, people can think something
is going wrong. It is not the case, it means that DMA can't be used but
it doesn't prevent to use i2c.

Signed-off-by: Ludovic Desroches 
Signed-off-by: Wolfram Sang

i2c: rcar: should depend on HAS_DMA

2016-05-26T18:51:59+00:00

If NO_DMA=y:

    drivers/built-in.o: In function `rcar_i2c_dma_unmap':
    i2c-rcar.c:(.text+0x6f06c6): undefined reference to `bad_dma_ops'
    drivers/built-in.o: In function `rcar_i2c_dma':
    i2c-rcar.c:(.text+0x6f07e2): undefined reference to `bad_dma_ops'
    i2c-rcar.c:(.text+0x6f0838): undefined reference to `bad_dma_ops'

Add a dependency on HAS_DMA to fix this.

Signed-off-by: Geert Uytterhoeven 
Acked-by: Niklas Söderlund 
Signed-off-by: Wolfram Sang