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

i2c: piix4: Fix port selection for AMD Family 16h Model 30h

2019-09-06T08:22:23+00:00

[ Upstream commit c7c06a1532f3fe106687ac82a13492c6a619ff1c ]

Family 16h Model 30h SMBus controller needs the same port selection fix
as described and fixed in commit 0fe16195f891 ("i2c: piix4: Fix SMBus port
selection for AMD Family 17h chips")

commit 6befa3fde65f ("i2c: piix4: Support alternative port selection
register") also fixed the port selection for Hudson2, but unfortunately
this is not the exact same device and the AMD naming and PCI Device IDs
aren't particularly helpful here.

The SMBus port selection register is common to the following Families
and models, as documented in AMD's publicly available BIOS and Kernel
Developer Guides:

 50742 - Family 15h Model 60h-6Fh (PCI_DEVICE_ID_AMD_KERNCZ_SMBUS)
 55072 - Family 15h Model 70h-7Fh (PCI_DEVICE_ID_AMD_KERNCZ_SMBUS)
 52740 - Family 16h Model 30h-3Fh (PCI_DEVICE_ID_AMD_HUDSON2_SMBUS)

The Hudson2 PCI Device ID (PCI_DEVICE_ID_AMD_HUDSON2_SMBUS) is shared
between Bolton FCH and Family 16h Model 30h, but the location of the
SmBus0Sel port selection bits are different:

 51192 - Bolton Register Reference Guide

We distinguish between Bolton and Family 16h Model 30h using the PCI
Revision ID:

  Bolton is device 0x780b, revision 0x15
  Family 16h Model 30h is device 0x780b, revision 0x1F
  Family 15h Model 60h and 70h are both device 0x790b, revision 0x4A.

The following additional public AMD BKDG documents were checked and do
not share the same port selection register:

 42301 - Family 15h Model 00h-0Fh doesn't mention any
 42300 - Family 15h Model 10h-1Fh doesn't mention any
 49125 - Family 15h Model 30h-3Fh doesn't mention any

 48751 - Family 16h Model 00h-0Fh uses the previously supported
         index register SB800_PIIX4_PORT_IDX_ALT at 0x2e

Signed-off-by: Andrew Cooks 
Signed-off-by: Jean Delvare 
Cc: stable@vger.kernel.org [v4.6+]
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin

i2c: emev2: avoid race when unregistering slave client

2019-09-06T08:21:59+00:00

[ Upstream commit d7437fc0d8291181debe032671a289b6bd93f46f ]

After we disabled interrupts, there might still be an active one
running. Sync before clearing the pointer to the slave device.

Fixes: c31d0a00021d ("i2c: emev2: add slave support")
Reported-by: Krzysztof Adamski 
Signed-off-by: Wolfram Sang 
Reviewed-by: Krzysztof Adamski 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin

i2c: rcar: avoid race when unregistering slave client

2019-09-06T08:21:58+00:00

[ Upstream commit 7b814d852af6944657c2961039f404c4490771c0 ]

After we disabled interrupts, there might still be an active one
running. Sync before clearing the pointer to the slave device.

Fixes: de20d1857dd6 ("i2c: rcar: add slave support")
Reported-by: Krzysztof Adamski 
Signed-off-by: Wolfram Sang 
Reviewed-by: Krzysztof Adamski 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin

gcc-9: don't warn about uninitialized variable

2019-08-09T15:52:27+00:00

commit cf676908846a06443fa5e6724ca3f5dd7460eca1 upstream.

I'm not sure what made gcc warn about this code now.  The 'ret' variable
does end up initialized in all cases, but it's definitely not obvious,
so the compiler is quite reasonable to warn about this.

So just add initialization to make it all much more obvious both to
compilers and to humans.

Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

i2c: stm32f7: fix the get_irq error cases

2019-07-31T05:27:02+00:00

[ Upstream commit 79b4499524ed659fb76323efc30f3dc03967c88f ]

During probe, return the "get_irq" error value instead of -EINVAL which
allows the driver to be deferred probed if needed.
Fix also the case where of_irq_get() returns a negative value.
Note :
On failure of_irq_get() returns 0 or a negative value while
platform_get_irq() returns a negative value.

Fixes: aeb068c57214 ("i2c: i2c-stm32f7: add driver")
Reviewed-by: Pierre-Yves MORDRET 
Signed-off-by: Fabien Dessenne 
Signed-off-by: Fabrice Gasnier 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin

i2c: pca-platform: Fix GPIO lookup code

2019-07-10T07:53:39+00:00

[ Upstream commit a0cac264a86fbf4d6cb201fbbb73c1d335e3248a ]

The devm_gpiod_request_gpiod() call will add "-gpios" to
any passed connection ID before looking it up.

I do not think the reset GPIO on this platform is named
"reset-gpios-gpios" but rather "reset-gpios" in the device
tree, so fix this up so that we get a proper reset GPIO
handle.

Also drop the inclusion of the legacy GPIO header.

Fixes: 0e8ce93bdceb ("i2c: pca-platform: add devicetree awareness")
Signed-off-by: Linus Walleij 
Reviewed-by: Chris Packham 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin

i2c: dev: fix potential memory leak in i2cdev_ioctl_rdwr

2019-06-22T06:15:17+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-19T06:18:00+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: xiic: Add max_read_len quirk

2019-06-11T10:20:53+00:00

commit 49b809586730a77b57ce620b2f9689de765d790b upstream.

This driver does not support reading more than 255 bytes at once because
the register for storing the number of bytes to read is only 8 bits. Add
a max_read_len quirk to enforce this.

This was found when using this driver with the SFP driver, which was
previously reading all 256 bytes in the SFP EEPROM in one transaction.
This caused a bunch of hard-to-debug errors in the xiic driver since the
driver/logic was treating the number of bytes to read as zero.
Rejecting transactions that aren't supported at least allows the problem
to be diagnosed more easily.

Signed-off-by: Robert Hancock 
Reviewed-by: Michal Simek 
Signed-off-by: Wolfram Sang 
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman

i2c: synquacer: fix synquacer_i2c_doxfer() return value

2019-06-09T07:17:19+00:00

commit ff9378904d9d7a3fcb8406604e089e535e357b1d upstream.

master_xfer should return the number of messages successfully
processed.

Fixes: 0d676a6c4390 ("i2c: add support for Socionext SynQuacer I2C controller")
Cc:  # v4.19+
Signed-off-by: Okamoto Satoru 
Signed-off-by: Masahisa Kojima 
Acked-by: Ard Biesheuvel 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman