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

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

2019-01-26T08:44:24+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:08:49+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: i2c-scmi: fix for i2c_smbus_write_block_data

2018-11-10T15:39:10+00:00

commit 08d9db00fe0e300d6df976e6c294f974988226dd upstream.

The i2c-scmi driver crashes when the SMBus Write Block transaction is
executed:

WARNING: CPU: 9 PID: 2194 at mm/page_alloc.c:3931 __alloc_pages_slowpath+0x9db/0xec0
 Call Trace:
  ? get_page_from_freelist+0x49d/0x11f0
  ? alloc_pages_current+0x6a/0xe0
  ? new_slab+0x499/0x690
  __alloc_pages_nodemask+0x265/0x280
  alloc_pages_current+0x6a/0xe0
  kmalloc_order+0x18/0x40
  kmalloc_order_trace+0x24/0xb0
  ? acpi_ut_allocate_object_desc_dbg+0x62/0x10c
  __kmalloc+0x203/0x220
  acpi_os_allocate_zeroed+0x34/0x36
  acpi_ut_copy_eobject_to_iobject+0x266/0x31e
  acpi_evaluate_object+0x166/0x3b2
  acpi_smbus_cmi_access+0x144/0x530 [i2c_scmi]
  i2c_smbus_xfer+0xda/0x370
  i2cdev_ioctl_smbus+0x1bd/0x270
  i2cdev_ioctl+0xaa/0x250
  do_vfs_ioctl+0xa4/0x600
  SyS_ioctl+0x79/0x90
  do_syscall_64+0x73/0x130
  entry_SYSCALL_64_after_hwframe+0x3d/0xa2
ACPI Error: Evaluating _SBW: 4 (20170831/smbus_cmi-185)

This problem occurs because the length of ACPI Buffer object is not
defined/initialized in the code before a corresponding ACPI method is
called. The obvious patch below fixes this issue.

Signed-off-by: Edgar Cherkasov 
Acked-by: Viktor Krasnov 
Acked-by: Michael Brunner 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: xiic: Make the start and the byte count write atomic

2018-09-26T06:33:53+00:00

commit ae7304c3ea28a3ba47a7a8312c76c654ef24967e upstream.

Disable interrupts while configuring the transfer and enable them back.

We have below as the programming sequence
1. start and slave address
2. byte count and stop

In some customer platform there was a lot of interrupts between 1 and 2
and after slave address (around 7 clock cyles) if 2 is not executed
then the transaction is nacked.

To fix this case make the 2 writes atomic.

Signed-off-by: Shubhrajyoti Datta 
Signed-off-by: Michal Simek 
[wsa: added a newline for better readability]
Signed-off-by: Wolfram Sang 
Cc: stable@kernel.org
Signed-off-by: Greg Kroah-Hartman

i2c: ismt: fix wrong device address when unmap the data buffer

2018-08-17T18:54:55+00:00

commit 17e83549e199d89aace7788a9f11c108671eecf5 upstream.

Fix the following kernel bug:

kernel BUG at drivers/iommu/intel-iommu.c:3260!
invalid opcode: 0000 [#5] PREEMPT SMP
Hardware name: Intel Corp. Harcuvar/Server, BIOS HAVLCRB0.X64.0013.D39.1608311820 08/31/2016
task: ffff880175389950 ti: ffff880176bec000 task.ti: ffff880176bec000
RIP: 0010:[]  [] intel_unmap+0x25b/0x260
RSP: 0018:ffff880176bef5e8  EFLAGS: 00010296
RAX: 0000000000000024 RBX: ffff8800773c7c88 RCX: 000000000000ce04
RDX: 0000000080000000 RSI: 0000000000000000 RDI: 0000000000000009
RBP: ffff880176bef638 R08: 0000000000000010 R09: 0000000000000004
R10: ffff880175389c78 R11: 0000000000000a4f R12: ffff8800773c7868
R13: 00000000ffffac88 R14: ffff8800773c7818 R15: 0000000000000001
FS:  00007fef21258700(0000) GS:ffff88017b5c0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000066d6d8 CR3: 000000007118c000 CR4: 00000000003406e0
Stack:
 00000000ffffac88 ffffffff8199867f ffff880176bef5f8 ffff880100000030
 ffff880176bef668 ffff8800773c7c88 ffff880178288098 ffff8800772c0010
 ffff8800773c7818 0000000000000001 ffff880176bef648 ffffffff8150a86e
Call Trace:
 [] ? printk+0x46/0x48
 [] intel_unmap_page+0xe/0x10
 [] ismt_access+0x27b/0x8fa [i2c_ismt]
 [] ? __pm_runtime_suspend+0xa0/0xa0
 [] ? pm_suspend_timer_fn+0x80/0x80
 [] ? __pm_runtime_suspend+0xa0/0xa0
 [] ? pm_suspend_timer_fn+0x80/0x80
 [] ? pci_bus_read_dev_vendor_id+0xf0/0xf0
 [] i2c_smbus_xfer+0xec/0x4b0
 [] ? vprintk_emit+0x345/0x530
 [] i2cdev_ioctl_smbus+0x12b/0x240 [i2c_dev]
 [] ? vprintk_default+0x29/0x40
 [] i2cdev_ioctl+0x63/0x1ec [i2c_dev]
 [] do_vfs_ioctl+0x328/0x5d0
 [] ? vfs_write+0x11c/0x190
 [] ? rt_up_read+0x19/0x20
 [] SyS_ioctl+0x81/0xa0
 [] system_call_fastpath+0x16/0x6e

This happen When run "i2cdetect -y 0" detect SMBus iSMT adapter.

After finished I2C block read/write, when unmap the data buffer,
a wrong device address was pass to dma_unmap_single().

To fix this, give dma_unmap_single() the "dev" parameter, just like
what dma_map_single() does, then unmap can find the right devices.

Fixes: 13f35ac14cd0 ("i2c: Adding support for Intel iSMT SMBus 2.0 host controller")
Signed-off-by: Liwei Song 
Reviewed-by: Andy Shevchenko 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: viperboard: return message count on master_xfer success

2018-07-03T09:18:42+00:00

[ Upstream commit 35cd67a0caf767aba472452865dcb4471fcce2b1 ]

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")
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

i2c: pmcmsp: fix error return from master_xfer

2018-07-03T09:18:42+00:00

[ Upstream commit 12d9bbc5a7f347eaa65ff2a9d34995cadc05eb1b ]

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")
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

i2c: pmcmsp: return message count on master_xfer success

2018-07-03T09:18:42+00:00

[ Upstream commit de9a8634f1cb4560a35696d472cc7f1383d9b866 ]

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")
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

i2c: mv64xxx: Apply errata delay only in standard mode

2018-05-30T05:47:41+00:00

[ Upstream commit 31184d8c6ea49ea0676d100cdd7e1f102ad025b5 ]

The errata FE-8471889 description has been updated. There is still a
timing violation for repeated start. But the errata now states that it
was only the case for the Standard mode (100 kHz), in Fast mode (400 kHz)
there is no issue.

This patch limit the errata fix to the Standard mode.

It has been tesed successfully on the clearfog (Aramda 388 based board).

Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

i2c: i2c-scmi: add a MS HID

2018-03-24T09:57:32+00:00

[ Upstream commit e058e7a4bc89104540a8a303682248614b5df6f1 ]

Description of the problem:
 - i2c-scmi driver contains only two identifiers "SMBUS01" and "SMBUSIBM";
 - the fist HID (SMBUS01) is clearly defined in "SMBus Control Method
   Interface Specification, version 1.0": "Each device must specify
   'SMBUS01' as its _HID and use a unique _UID value";
 - unfortunately, BIOS vendors (like AMI) seem to ignore this requirement
   and implement "SMB0001" HID instead of "SMBUS01";
 - I speculate that they do this because only "SMB0001" is hard coded in
   Windows SMBus driver produced by Microsoft.

This leads to following situation:
 - SMBus works out of box in Windows but not in Linux;
 - board vendors are forced to add correct "SMBUS01" HID to BIOS to make
   SMBus work in Linux. Moreover the same board vendors complain that
   tools (3-rd party ASL compiler) do not like the "SMBUS01" identifier
   and produce errors.  So they need to constantly patch the compiler for
   each new version of BIOS.

As it is very unlikely that BIOS vendors implement a correct HID in
future, I would propose to consider whether it is possible to work around
the problem by adding MS HID to the Linux i2c-scmi driver.

v2: move the definition of the new HID to the driver itself.

Signed-off-by: Edgar Cherkasov 
Signed-off-by: Michael Brunner 
Acked-by: Viktor Krasnov 
Reviewed-by: Jean Delvare 
Reviewed-by: Mika Westerberg 
Signed-off-by: Wolfram Sang 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman