Eric Lee / smarc-fsl-linux-kernel

15 Nov, 2018

1 commit

13 Nov, 2018

2 commits

12 Nov, 2018

1 commit

05 Nov, 2018

2 commits

29 Oct, 2018

16 commits

20 Oct, 2018

1 commit

  • 4d5af8366   i2c: rcar: handle RXDMA HW behaviour on Gen3 ... Browse Code »

    commit 2b16fd63059ab9a46d473620749672dc342e1d21 upstream.

    On Gen3, we can only do RXDMA once per transfer reliably. For that, we
    must reset the device, then we can have RXDMA once. This patch
    implements this. When there is no reset controller or the reset fails,
    RXDMA will be blocked completely. Otherwise, it will be disabled after
    the first RXDMA transfer. Based on a commit from the BSP by Hiromitsu
    Yamasaki, yet completely refactored to handle multiple read messages
    within one transfer.

    Signed-off-by: Wolfram Sang
    Reviewed-by: Geert Uytterhoeven
    Signed-off-by: Wolfram Sang
    Cc: stable@kernel.org
    Signed-off-by: Sudip Mukherjee
    Signed-off-by: Greg Kroah-Hartman

    Wolfram Sang
     

18 Oct, 2018

1 commit

  • 74a960430   i2c: i2c-scmi: fix for i2c_smbus_write_block_data ... Browse Code »

    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

    Edgar Cherkasov
     

10 Oct, 2018

2 commits

  • b08d15cc9   i2c: uniphier-f: issue STOP only for last message or I2C_M_STOP ... Browse Code »

    [ Upstream commit 4c85609b08c4761eca0a40fd7beb06bc650f252d ]

    This driver currently emits a STOP if the next message is not
    I2C_MD_RD. It should not do it because it disturbs the I2C_RDWR
    ioctl, where read/write transactions are combined without STOP
    between.

    Issue STOP only when the message is the last one _or_ flagged with
    I2C_M_STOP.

    Fixes: 6a62974b667f ("i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver")
    Signed-off-by: Masahiro Yamada
    Signed-off-by: Wolfram Sang
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Masahiro Yamada
     
  • 82fc9c6b7   i2c: uniphier: issue STOP only for last message or I2C_M_STOP ... Browse Code »

    [ Upstream commit 38f5d8d8cbb2ffa2b54315118185332329ec891c ]

    This driver currently emits a STOP if the next message is not
    I2C_MD_RD. It should not do it because it disturbs the I2C_RDWR
    ioctl, where read/write transactions are combined without STOP
    between.

    Issue STOP only when the message is the last one _or_ flagged with
    I2C_M_STOP.

    Fixes: dd6fd4a32793 ("i2c: uniphier: add UniPhier FIFO-less I2C driver")
    Signed-off-by: Masahiro Yamada
    Signed-off-by: Wolfram Sang
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Masahiro Yamada
     

04 Oct, 2018

1 commit

  • 23210d92f   i2c: i801: Allow ACPI AML access I/O ports not reserved for SMBus ... Browse Code »

    [ Upstream commit 7fd6d98b89f382d414e1db528e29a67bbd749457 ]

    Commit 7ae81952cda ("i2c: i801: Allow ACPI SystemIO OpRegion to conflict
    with PCI BAR") made it possible for AML code to access SMBus I/O ports
    by installing custom SystemIO OpRegion handler and blocking i80i driver
    access upon first AML read/write to this OpRegion.

    However, while ThinkPad T560 does have SystemIO OpRegion declared under
    the SMBus device, it does not access any of the SMBus registers:

    Device (SMBU)
    {
    ...

    OperationRegion (SMBP, PCI_Config, 0x50, 0x04)
    Field (SMBP, DWordAcc, NoLock, Preserve)
    {
    , 5,
    TCOB, 11,
    Offset (0x04)
    }

    Name (TCBV, 0x00)
    Method (TCBS, 0, NotSerialized)
    {
    If ((TCBV == 0x00))
    {
    TCBV = (\_SB.PCI0.SMBU.TCOB << 0x05)
    }

    Return (TCBV) /* \_SB_.PCI0.SMBU.TCBV */
    }

    OperationRegion (TCBA, SystemIO, TCBS (), 0x10)
    Field (TCBA, ByteAcc, NoLock, Preserve)
    {
    Offset (0x04),
    , 9,
    CPSC, 1
    }
    }

    Problem with the current approach is that it blocks all I/O port access
    and because this system has touchpad connected to the SMBus controller
    after first AML access (happens during suspend/resume cycle) the
    touchpad fails to work anymore.

    Fix this so that we allow ACPI AML I/O port access if it does not touch
    the region reserved for the SMBus.

    Fixes: 7ae81952cda ("i2c: i801: Allow ACPI SystemIO OpRegion to conflict with PCI BAR")
    Link: https://bugzilla.kernel.org/show_bug.cgi?id=200737
    Reported-by: Yussuf Khalil
    Signed-off-by: Mika Westerberg
    Reviewed-by: Jean Delvare
    Signed-off-by: Wolfram Sang
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Mika Westerberg
     

26 Sep, 2018

1 commit

  • a8c0b9acf   i2c: aspeed: Fix initial values of master and slave state ... Browse Code »

    [ Upstream commit 517fde0eb5a8f46c54ba6e2c36e32563b23cb14f ]

    This patch changes the order of enum aspeed_i2c_master_state and
    enum aspeed_i2c_slave_state defines to make their initial value to
    ASPEED_I2C_MASTER_INACTIVE and ASPEED_I2C_SLAVE_STOP respectively.
    In case of multi-master use, if a slave data comes ahead of the
    first master xfer, master_state starts from an invalid state so
    this change fixes the issue.

    Signed-off-by: Jae Hyun Yoo
    Reviewed-by: Brendan Higgins
    Signed-off-by: Wolfram Sang
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Jae Hyun Yoo
     

20 Sep, 2018

3 commits

  • 0455f5d63   i2c: aspeed: Add an explicit type casting for *get_clk_reg_val ... Browse Code »

    [ Upstream commit 5799c4b2f1dbc0166d9b1d94443deaafc6e7a070 ]

    This commit fixes this sparse warning:
    drivers/i2c/busses/i2c-aspeed.c:875:38: warning: incorrect type in assignment (different modifiers)
    drivers/i2c/busses/i2c-aspeed.c:875:38: expected unsigned int ( *get_clk_reg_val )( ... )
    drivers/i2c/busses/i2c-aspeed.c:875:38: got void const *const data

    Reported-by: Wolfram Sang
    Signed-off-by: Jae Hyun Yoo
    Reviewed-by: Brendan Higgins
    Signed-off-by: Wolfram Sang
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Jae Hyun Yoo
     
  • d98b67089   i2c: i801: fix DNV's SMBCTRL register offset ... Browse Code »

    commit 851a15114895c5bce163a6f2d57e0aa4658a1be4 upstream.

    DNV's iTCO is slightly different with SMBCTRL sitting at a different
    offset when compared to all other devices. Let's fix so that we can
    properly use iTCO watchdog.

    Fixes: 84d7f2ebd70d ("i2c: i801: Add support for Intel DNV")
    Cc: # v4.4+
    Signed-off-by: Felipe Balbi
    Reviewed-by: Jean Delvare
    Signed-off-by: Wolfram Sang
    Signed-off-by: Greg Kroah-Hartman

    Felipe Balbi
     
  • 831223b29   i2c: xiic: Make the start and the byte count write atomic ... Browse Code »

    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

    Shubhrajyoti Datta
     

05 Sep, 2018

2 commits

  • 0ba83f87c   i2c/mux, locking/core: Annotate the nested rt_mutex usage ... Browse Code »

    [ Upstream commit 7b94ea50514d1a0dc94f02723b603c27bc0ea597 ]

    If an i2c topology has instances of nested muxes, then a lockdep splat
    is produced when when i2c_parent_lock_bus() is called. Here is an
    example:

    ============================================
    WARNING: possible recursive locking detected
    --------------------------------------------
    insmod/68159 is trying to acquire lock:
    (i2c_register_adapter#2){+.+.}, at: i2c_parent_lock_bus+0x32/0x50 [i2c_mux]

    but task is already holding lock:
    (i2c_register_adapter#2){+.+.}, at: i2c_parent_lock_bus+0x32/0x50 [i2c_mux]

    other info that might help us debug this:
    Possible unsafe locking scenario:

    CPU0
    ----
    lock(i2c_register_adapter#2);
    lock(i2c_register_adapter#2);

    *** DEADLOCK ***

    May be due to missing lock nesting notation

    1 lock held by insmod/68159:
    #0: (i2c_register_adapter#2){+.+.}, at: i2c_parent_lock_bus+0x32/0x50 [i2c_mux]

    stack backtrace:
    CPU: 13 PID: 68159 Comm: insmod Tainted: G O
    Call Trace:
    dump_stack+0x67/0x98
    __lock_acquire+0x162e/0x1780
    lock_acquire+0xba/0x200
    rt_mutex_lock+0x44/0x60
    i2c_parent_lock_bus+0x32/0x50 [i2c_mux]
    i2c_parent_lock_bus+0x3e/0x50 [i2c_mux]
    i2c_smbus_xfer+0xf0/0x700
    i2c_smbus_read_byte+0x42/0x70
    my2c_init+0xa2/0x1000 [my2c]
    do_one_initcall+0x51/0x192
    do_init_module+0x62/0x216
    load_module+0x20f9/0x2b50
    SYSC_init_module+0x19a/0x1c0
    SyS_init_module+0xe/0x10
    do_syscall_64+0x6c/0x1a0
    entry_SYSCALL_64_after_hwframe+0x42/0xb7

    Reported-by: John Sperbeck
    Tested-by: John Sperbeck
    Signed-off-by: Peter Rosin
    Signed-off-by: Peter Zijlstra (Intel)
    Cc: Davidlohr Bueso
    Cc: Deepa Dinamani
    Cc: Greg Kroah-Hartman
    Cc: Linus Torvalds
    Cc: Peter Chang
    Cc: Peter Zijlstra
    Cc: Philippe Ombredanne
    Cc: Thomas Gleixner
    Cc: Will Deacon
    Cc: Wolfram Sang
    Link: http://lkml.kernel.org/r/20180720083914.1950-3-peda@axentia.se
    Signed-off-by: Ingo Molnar
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Peter Rosin
     
  • 385b40b4f   i2c: davinci: Avoid zero value of CLKH ... Browse Code »

    [ Upstream commit cc8de9a68599b261244ea453b38678229f06ada7 ]

    If CLKH is set to 0 I2C clock is not generated at all, so avoid this value
    and stretch the clock in this case.

    Signed-off-by: Alexander Sverdlin
    Acked-by: Sekhar Nori
    Signed-off-by: Wolfram Sang
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Alexander Sverdlin
     

24 Aug, 2018

2 commits

  • 82c6d4994   i2c: imx: Fix race condition in dma read ... Browse Code »

    commit bed4ff1ed4d8f2ef5007c5c6ae1b29c5677a3632 upstream.

    This fixes a race condition, where the DMAEN bit ends up being set after
    I2C slave has transmitted a byte following the dummy read. When that
    happens, an interrupt is generated instead, and no DMA request is generated
    to kickstart the DMA read, and a timeout happens after DMA_TIMEOUT (1 sec).

    Fixed by setting the DMAEN bit before the dummy read.

    Signed-off-by: Esben Haabendal
    Acked-by: Uwe Kleine-König
    Signed-off-by: Wolfram Sang
    Cc: stable@kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Esben Haabendal
     
  • 415a02d8b   i2c: core: ACPI: Properly set status byte to 0 for multi-byte writes ... Browse Code »

    commit c463a158cb6c5d9a85b7d894cd4f8116e8bd6be0 upstream.

    acpi_gsb_i2c_write_bytes() returns i2c_transfer()'s return value, which
    is the number of transfers executed on success, so 1.

    The ACPI code expects us to store 0 in gsb->status for success, not 1.

    Specifically this breaks the following code in the Thinkpad 8 DSDT:

    ECWR = I2CW = ECWR /* \_SB_.I2C1.BAT0.ECWR */
    If ((ECST == Zero))
    {
    ECRD = I2CR /* \_SB_.I2C1.I2CR */
    }

    Before this commit we set ECST to 1, causing the read to never happen
    breaking battery monitoring on the Thinkpad 8.

    This commit makes acpi_gsb_i2c_write_bytes() return 0 when i2c_transfer()
    returns 1, so the single write transfer completed successfully, and
    makes it return -EIO on for other (unexpected) return values >= 0.

    Cc: stable@vger.kernel.org
    Signed-off-by: Hans de Goede
    Acked-by: Mika Westerberg
    Signed-off-by: Wolfram Sang
    Signed-off-by: Greg Kroah-Hartman

    Hans de Goede
     

09 Aug, 2018

1 commit

  • ea464580f   i2c: imx: Fix reinit_completion() use ... Browse Code »

    commit 9f9e3e0d4dd3338b3f3dde080789f71901e1e4ff upstream.

    Make sure to call reinit_completion() before dma is started to avoid race
    condition where reinit_completion() is called after complete() and before
    wait_for_completion_timeout().

    Signed-off-by: Esben Haabendal
    Fixes: ce1a78840ff7 ("i2c: imx: add DMA support for freescale i2c driver")
    Reviewed-by: Uwe Kleine-König
    Signed-off-by: Wolfram Sang
    Cc: stable@kernel.org
    Signed-off-by: Sudip Mukherjee
    Signed-off-by: Greg Kroah-Hartman

    Esben Haabendal
     

03 Aug, 2018

1 commit

  • c0b86d269   i2c: core: decrease reference count of device node in i2c_unregister_device ... Browse Code »

    commit e0638fa400eaccf9fa8060f67140264c4e276552 upstream.

    Reference count of device node was increased in of_i2c_register_device,
    but without decreasing it in i2c_unregister_device. Then the added
    device node will never be released. Fix this by adding the of_node_put.

    Signed-off-by: Lixin Wang
    Tested-by: Wolfram Sang
    Signed-off-by: Wolfram Sang
    Cc: stable@kernel.org
    Signed-off-by: Sudip Mukherjee
    Signed-off-by: Greg Kroah-Hartman

    Lixin Wang
     

17 Jul, 2018

1 commit

  • 33beaca90   i2c: tegra: Fix NACK error handling ... Browse Code »

    commit 54836e2d03e76d80aec3399368ffaf5b7caadd1b upstream.

    On Tegra30 Cardhu the PCA9546 I2C mux is not ACK'ing I2C commands on
    resume from suspend (which is caused by the reset signal for the I2C
    mux not being configured correctl). However, this NACK is causing the
    Tegra30 to hang on resuming from suspend which is not expected as we
    detect NACKs and handle them. The hang observed appears to occur when
    resetting the I2C controller to recover from the NACK.

    Commit 77821b4678f9 ("i2c: tegra: proper handling of error cases") added
    additional error handling for some error cases including NACK, however,
    it appears that this change conflicts with an early fix by commit
    f70893d08338 ("i2c: tegra: Add delay before resetting the controller
    after NACK"). After commit 77821b4678f9 was made we now disable 'packet
    mode' before the delay from commit f70893d08338 happens. Testing shows
    that moving the delay to before disabling 'packet mode' fixes the hang
    observed on Tegra30. The delay was added to give the I2C controller
    chance to send a stop condition and so it makes sense to move this to
    before we disable packet mode. Please note that packet mode is always
    enabled for Tegra.

    Fixes: 77821b4678f9 ("i2c: tegra: proper handling of error cases")
    Signed-off-by: Jon Hunter
    Acked-by: Thierry Reding
    Signed-off-by: Wolfram Sang
    Cc: stable@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman

    Jon Hunter
     

21 Jun, 2018

2 commits