1. 05 Oct, 2020 2 commits
  2. 28 Sep, 2020 1 commit
    • Michael Walle's avatar
      spi: fsl-dspi: fix NULL pointer dereference · 6e383766
      Michael Walle authored
      Since commit 530b5aff ("spi: fsl-dspi: fix use-after-free in remove
      path") this driver causes a kernel oops:
      
      [    1.891065] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000080
      [..]
      [    2.056973] Call trace:
      [    2.059425]  dspi_setup+0xc8/0x2e0
      [    2.062837]  spi_setup+0xcc/0x248
      [    2.066160]  spi_add_device+0xb4/0x198
      [    2.069918]  of_register_spi_device+0x250/0x370
      [    2.074462]  spi_register_controller+0x4f4/0x770
      [    2.079094]  dspi_probe+0x5bc/0x7b0
      [    2.082594]  platform_drv_probe+0x5c/0xb0
      [    2.086615]  really_probe+0xec/0x3c0
      [    2.090200]  driver_probe_device+0x60/0xc0
      [    2.094308]  device_driver_attach+0x7c/0x88
      [    2.098503]  __driver_attach+0x60/0xe8
      [    2.102263]  bus_for_each_dev+0x7c/0xd0
      [    2.106109]  driver_attach+0x2c/0x38
      [    2.109692]  bus_add_driver+0x194/0x1f8
      [    2.113538]  driver_register+0x6c/0x128
      [    2.117385]  __platform_driver_register+0x50/0x60
      [    2.122105]  fsl_dspi_driver_init+0x24/0x30
      [    2.126302]  do_one_initcall+0x54/0x2d0
      [    2.130149]  kernel_init_freeable+0x1ec/0x258
      [    2.134520]  kernel_init+0x1c/0x120
      [    2.138018]  ret_from_fork+0x10/0x34
      [    2.141606] Code: 97e0b11d aa0003f3 b4000680 f94006e0 (f9404000)
      [    2.147723] ---[ end trace 26cf63e6cbba33a8 ]---
      
      This is because since this commit, the allocation of the drivers private
      data is done explicitly and in this case spi_alloc_master() won't set the
      correct pointer.
      
      Also move the platform_set_drvdata() to have both next to each other.
      
      Fixes: 530b5aff ("spi: fsl-dspi: fix use-after-free in remove path")
      Signed-off-by: default avatarMichael Walle <michael@walle.cc>
      Tested-by: default avatarSascha Hauer <s.hauer@pengutronix.de>
      Reviewed-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
      Link: https://lore.kernel.org/r/20200928085500.28254-1-michael@walle.ccSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      6e383766
  3. 24 Sep, 2020 1 commit
  4. 23 Sep, 2020 1 commit
  5. 21 Sep, 2020 1 commit
  6. 15 Sep, 2020 1 commit
  7. 11 Sep, 2020 1 commit
  8. 09 Sep, 2020 2 commits
  9. 08 Sep, 2020 1 commit
  10. 07 Sep, 2020 1 commit
    • Marek Vasut's avatar
      spi: stm32: Rate-limit the 'Communication suspended' message · ea8be08c
      Marek Vasut authored
      The 'spi_stm32 44004000.spi: Communication suspended' message means that
      when using PIO, the kernel did not read the FIFO fast enough and so the
      SPI controller paused the transfer. Currently, this is printed on every
      single such event, so if the kernel is busy and the controller is pausing
      the transfers often, the kernel will be all the more busy scrolling this
      message into the log buffer every few milliseconds. That is not helpful.
      
      Instead, rate-limit the message and print it every once in a while. It is
      not possible to use the default dev_warn_ratelimited(), because that is
      still too verbose, as it prints 10 lines (DEFAULT_RATELIMIT_BURST) every
      5 seconds (DEFAULT_RATELIMIT_INTERVAL). The policy here is to print 1 line
      every 50 seconds (DEFAULT_RATELIMIT_INTERVAL * 10), because 1 line is more
      than enough and the cycles saved on printing are better left to the CPU to
      handle the SPI. However, dev_warn_once() is also not useful, as the user
      should be aware that this condition is possibly recurring or ongoing. Thus
      the custom rate-limit policy.
      
      Finally, turn the message from dev_warn() to dev_dbg(), since the system
      does not suffer any sort of malfunction if this message appears, it is
      just slowing down. This further reduces the printing into the log buffer
      and frees the CPU to do useful work.
      
      Fixes: dcbe0d84 ("spi: add driver for STM32 SPI controller")
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      Cc: Alexandre Torgue <alexandre.torgue@st.com>
      Cc: Amelie Delaunay <amelie.delaunay@st.com>
      Cc: Antonio Borneo <borneo.antonio@gmail.com>
      Cc: Mark Brown <broonie@kernel.org>
      Link: https://lore.kernel.org/r/20200905151913.117775-1-marex@denx.deSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      ea8be08c
  11. 02 Sep, 2020 1 commit
    • Vincent Whitchurch's avatar
      spi: spi-loopback-test: Fix out-of-bounds read · 837ba18d
      Vincent Whitchurch authored
      The "tx/rx-transfer - crossing PAGE_SIZE" test always fails when
      len=131071 and rx_offset >= 5:
      
       spi-loopback-test spi0.0: Running test tx/rx-transfer - crossing PAGE_SIZE
       ...
         with iteration values: len = 131071, tx_off = 0, rx_off = 3
         with iteration values: len = 131071, tx_off = 0, rx_off = 4
         with iteration values: len = 131071, tx_off = 0, rx_off = 5
       loopback strangeness - rx changed outside of allowed range at: ...a4321000
         spi_msg@ffffffd5a4157690
           frame_length:  131071
           actual_length: 131071
           spi_transfer@ffffffd5a41576f8
             len:    131071
             tx_buf: ffffffd5a4340ffc
      
      Note that rx_offset > 3 can only occur if the SPI controller driver sets
      ->dma_alignment to a higher value than 4, so most SPI controller drivers
      are not affect.
      
      The allocated Rx buffer is of size SPI_TEST_MAX_SIZE_PLUS, which is 132
      KiB (assuming 4 KiB pages).  This test uses an initial offset into the
      rx_buf of PAGE_SIZE - 4, and a len of 131071, so the range expected to
      be written in this transfer ends at (4096 - 4) + 5 + 131071 == 132 KiB,
      which is also the end of the allocated buffer.  But the code which
      verifies the content of the buffer reads a byte beyond the allocated
      buffer and spuriously fails because this out-of-bounds read doesn't
      return the expected value.
      
      Fix this by using ITERATE_LEN instead of ITERATE_MAX_LEN to avoid
      testing sizes which cause out-of-bounds reads.
      Signed-off-by: default avatarVincent Whitchurch <vincent.whitchurch@axis.com>
      Link: https://lore.kernel.org/r/20200902132341.7079-1-vincent.whitchurch@axis.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      837ba18d
  12. 25 Aug, 2020 1 commit
  13. 24 Aug, 2020 1 commit
  14. 10 Aug, 2020 7 commits
  15. 05 Aug, 2020 1 commit
  16. 03 Aug, 2020 1 commit
    • Lukas Wunner's avatar
      spi: Prevent adding devices below an unregistering controller · ddf75be4
      Lukas Wunner authored
      CONFIG_OF_DYNAMIC and CONFIG_ACPI allow adding SPI devices at runtime
      using a DeviceTree overlay or DSDT patch.  CONFIG_SPI_SLAVE allows the
      same via sysfs.
      
      But there are no precautions to prevent adding a device below a
      controller that's being removed.  Such a device is unusable and may not
      even be able to unbind cleanly as it becomes inaccessible once the
      controller has been torn down.  E.g. it is then impossible to quiesce
      the device's interrupt.
      
      of_spi_notify() and acpi_spi_notify() do hold a ref on the controller,
      but otherwise run lockless against spi_unregister_controller().
      
      Fix by holding the spi_add_lock in spi_unregister_controller() and
      bailing out of spi_add_device() if the controller has been unregistered
      concurrently.
      
      Fixes: ce79d54a ("spi/of: Add OF notifier handler")
      Signed-off-by: default avatarLukas Wunner <lukas@wunner.de>
      Cc: stable@vger.kernel.org # v3.19+
      Cc: Geert Uytterhoeven <geert+renesas@glider.be>
      Cc: Octavian Purdila <octavian.purdila@intel.com>
      Cc: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
      Link: https://lore.kernel.org/r/a8c3205088a969dc8410eec1eba9aface60f36af.1596451035.git.lukas@wunner.deSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      ddf75be4
  17. 29 Jul, 2020 5 commits
    • Mark Brown's avatar
      Merge series "Some bug fix for lpspi" from Clark Wang <xiaoning.wang@nxp.com>: · 1d5cd4e7
      Mark Brown authored
      Hi,
      
      This patchset mainly fixes some recently discovered problems about CS for
      LPSPI module on i.MX8DXLEVK.
      
      Add the dt-bindings description for the new property.
      
      Clark Wang (4):
        spi: lpspi: Fix kernel warning dump when probe fail after calling
          spi_register
        spi: lpspi: remove unused fsl_lpspi->chipselect
        spi: lpspi: fix using CS discontinuously on i.MX8DXLEVK
        dt-bindings: lpspi: New property in document DT bindings for LPSPI
      
       .../bindings/spi/spi-fsl-lpspi.yaml           |  7 ++++++
       drivers/spi/spi-fsl-lpspi.c                   | 25 +++++++++++--------
       2 files changed, 21 insertions(+), 11 deletions(-)
      
      --
      2.17.1
      1d5cd4e7
    • Clark Wang's avatar
      dt-bindings: lpspi: New property in document DT bindings for LPSPI · 7ac9bbf6
      Clark Wang authored
      Add "fsl,spi-only-use-cs1-sel" to fit i.MX8DXL-EVK.
      Spi common code does not support use of CS signals discontinuously.
      It only uses CS1 without using CS0. So, add this property to re-config
      chipselect value.
      Signed-off-by: default avatarClark Wang <xiaoning.wang@nxp.com>
      Link: https://lore.kernel.org/r/20200727031513.31774-1-xiaoning.wang@nxp.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      7ac9bbf6
    • Clark Wang's avatar
      spi: lpspi: fix using CS discontinuously on i.MX8DXLEVK · 2a052590
      Clark Wang authored
      SPI common code does not support using CS discontinuously for now.
      However, i.MX8DXL-EVK only uses CS1 without CS0. Therefore, add a flag
      is_only_cs1 to set the correct TCR[PCS].
      Signed-off-by: default avatarClark Wang <xiaoning.wang@nxp.com>
      Link: https://lore.kernel.org/r/20200727031448.31661-4-xiaoning.wang@nxp.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      2a052590
    • Clark Wang's avatar
      spi: lpspi: remove unused fsl_lpspi->chipselect · 768ba490
      Clark Wang authored
      The cs-gpio is initailized by spi_get_gpio_descs() now. Remove the
      chipselect.
      Signed-off-by: default avatarClark Wang <xiaoning.wang@nxp.com>
      Link: https://lore.kernel.org/r/20200727031448.31661-3-xiaoning.wang@nxp.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      768ba490
    • Clark Wang's avatar
      spi: lpspi: Fix kernel warning dump when probe fail after calling spi_register · 16d79185
      Clark Wang authored
      Calling devm_spi_register_controller() too early will cause problem.
      When probe failed occurs after calling devm_spi_register_controller(),
      the call of spi_controller_put() will trigger the following warning dump.
      
      [    2.092138] ------------[ cut here ]------------
      [    2.096876] kernfs: can not remove 'uevent', no directory
      [    2.102440] WARNING: CPU: 0 PID: 181 at fs/kernfs/dir.c:1503 kernfs_remove_by_name_ns+0xa0/0xb0
      [    2.111142] Modules linked in:
      [    2.114207] CPU: 0 PID: 181 Comm: kworker/0:7 Not tainted 5.4.24-05024-g775c6e8a738c-dirty #1314
      [    2.122991] Hardware name: Freescale i.MX8DXL EVK (DT)
      [    2.128141] Workqueue: events deferred_probe_work_func
      [    2.133281] pstate: 60000005 (nZCv daif -PAN -UAO)
      [    2.138076] pc : kernfs_remove_by_name_ns+0xa0/0xb0
      [    2.142958] lr : kernfs_remove_by_name_ns+0xa0/0xb0
      [    2.147837] sp : ffff8000122bba70
      [    2.151145] x29: ffff8000122bba70 x28: ffff8000119d6000
      [    2.156462] x27: 0000000000000000 x26: ffff800011edbce8
      [    2.161779] x25: 0000000000000000 x24: ffff00003ae4f700
      [    2.167096] x23: ffff000010184c10 x22: ffff00003a3d6200
      [    2.172412] x21: ffff800011a464a8 x20: ffff000010126a68
      [    2.177729] x19: ffff00003ae5c800 x18: 000000000000000e
      [    2.183046] x17: 0000000000000001 x16: 0000000000000019
      [    2.188362] x15: 0000000000000004 x14: 000000000000004c
      [    2.193679] x13: 0000000000000000 x12: 0000000000000001
      [    2.198996] x11: 0000000000000000 x10: 00000000000009c0
      [    2.204313] x9 : ffff8000122bb7a0 x8 : ffff00003a3d6c20
      [    2.209630] x7 : ffff00003a3d6380 x6 : 0000000000000001
      [    2.214946] x5 : 0000000000000001 x4 : ffff00003a05eb18
      [    2.220263] x3 : 0000000000000005 x2 : ffff8000119f1c48
      [    2.225580] x1 : 2bcbda323bf5a800 x0 : 0000000000000000
      [    2.230898] Call trace:
      [    2.233345]  kernfs_remove_by_name_ns+0xa0/0xb0
      [    2.237879]  sysfs_remove_file_ns+0x14/0x20
      [    2.242065]  device_del+0x12c/0x348
      [    2.245555]  device_unregister+0x14/0x30
      [    2.249492]  spi_unregister_controller+0xac/0x120
      [    2.254201]  devm_spi_unregister+0x10/0x18
      [    2.258304]  release_nodes+0x1a8/0x220
      [    2.262055]  devres_release_all+0x34/0x58
      [    2.266069]  really_probe+0x1b8/0x318
      [    2.269733]  driver_probe_device+0x54/0xe8
      [    2.273833]  __device_attach_driver+0x80/0xb8
      [    2.278194]  bus_for_each_drv+0x74/0xc0
      [    2.282034]  __device_attach+0xdc/0x138
      [    2.285876]  device_initial_probe+0x10/0x18
      [    2.290063]  bus_probe_device+0x90/0x98
      [    2.293901]  deferred_probe_work_func+0x64/0x98
      [    2.298442]  process_one_work+0x198/0x320
      [    2.302451]  worker_thread+0x1f0/0x420
      [    2.306208]  kthread+0xf0/0x120
      [    2.309352]  ret_from_fork+0x10/0x18
      [    2.312927] ---[ end trace 58abcdfae01bd3c7 ]---
      
      So put this function at the end of the probe sequence.
      Signed-off-by: default avatarClark Wang <xiaoning.wang@nxp.com>
      Link: https://lore.kernel.org/r/20200727031448.31661-2-xiaoning.wang@nxp.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      16d79185
  18. 28 Jul, 2020 5 commits
  19. 27 Jul, 2020 3 commits
  20. 22 Jul, 2020 3 commits