1. 10 Feb, 2023 7 commits
  2. 09 Feb, 2023 11 commits
  3. 07 Feb, 2023 1 commit
  4. 06 Feb, 2023 2 commits
  5. 02 Feb, 2023 2 commits
  6. 01 Feb, 2023 2 commits
  7. 30 Jan, 2023 2 commits
  8. 27 Jan, 2023 3 commits
    • Bartosz Golaszewski's avatar
      spi: spidev: fix a recursive locking error · eede42c9
      Bartosz Golaszewski authored
      When calling spidev_message() from the one of the ioctl() callbacks, the
      spi_lock is already taken. When we then end up calling spidev_sync(), we
      get the following splat:
      
      [  214.047619]
      [  214.049198] ============================================
      [  214.054533] WARNING: possible recursive locking detected
      [  214.059858] 6.2.0-rc3-0.0.0-devel+git.97ec4d55 #1 Not tainted
      [  214.065969] --------------------------------------------
      [  214.071290] spidev_test/1454 is trying to acquire lock:
      [  214.076530] c4925dbc (&spidev->spi_lock){+.+.}-{3:3}, at: spidev_ioctl+0x8e0/0xab8
      [  214.084164]
      [  214.084164] but task is already holding lock:
      [  214.090007] c4925dbc (&spidev->spi_lock){+.+.}-{3:3}, at: spidev_ioctl+0x44/0xab8
      [  214.097537]
      [  214.097537] other info that might help us debug this:
      [  214.104075]  Possible unsafe locking scenario:
      [  214.104075]
      [  214.110004]        CPU0
      [  214.112461]        ----
      [  214.114916]   lock(&spidev->spi_lock);
      [  214.118687]   lock(&spidev->spi_lock);
      [  214.122457]
      [  214.122457]  *** DEADLOCK ***
      [  214.122457]
      [  214.128386]  May be due to missing lock nesting notation
      [  214.128386]
      [  214.135183] 2 locks held by spidev_test/1454:
      [  214.139553]  #0: c4925dbc (&spidev->spi_lock){+.+.}-{3:3}, at: spidev_ioctl+0x44/0xab8
      [  214.147524]  #1: c4925e14 (&spidev->buf_lock){+.+.}-{3:3}, at: spidev_ioctl+0x70/0xab8
      [  214.155493]
      [  214.155493] stack backtrace:
      [  214.159861] CPU: 0 PID: 1454 Comm: spidev_test Not tainted 6.2.0-rc3-0.0.0-devel+git.97ec4d55 #1
      [  214.169012] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
      [  214.175555]  unwind_backtrace from show_stack+0x10/0x14
      [  214.180819]  show_stack from dump_stack_lvl+0x60/0x90
      [  214.185900]  dump_stack_lvl from __lock_acquire+0x874/0x2858
      [  214.191584]  __lock_acquire from lock_acquire+0xfc/0x378
      [  214.196918]  lock_acquire from __mutex_lock+0x9c/0x8a8
      [  214.202083]  __mutex_lock from mutex_lock_nested+0x1c/0x24
      [  214.207597]  mutex_lock_nested from spidev_ioctl+0x8e0/0xab8
      [  214.213284]  spidev_ioctl from sys_ioctl+0x4d0/0xe2c
      [  214.218277]  sys_ioctl from ret_fast_syscall+0x0/0x1c
      [  214.223351] Exception stack(0xe75cdfa8 to 0xe75cdff0)
      [  214.228422] dfa0:                   00000000 00001000 00000003 40206b00 bee266e8 bee266e0
      [  214.236617] dfc0: 00000000 00001000 006a71a0 00000036 004c0040 004bfd18 00000000 00000003
      [  214.244809] dfe0: 00000036 bee266c8 b6f16dc5 b6e8e5f6
      
      Fix it by introducing an unlocked variant of spidev_sync() and calling it
      from spidev_message() while other users who don't check the spidev->spi's
      existence keep on using the locking flavor.
      Reported-by: default avatarFrancesco Dolcini <francesco@dolcini.it>
      Fixes: 1f4d2dd4 ("spi: spidev: fix a race condition when accessing spidev->spi")
      Signed-off-by: default avatarBartosz Golaszewski <bartosz.golaszewski@linaro.org>
      Tested-by: default avatarMax Krummenacher <max.krummenacher@toradex.com>
      Link: https://lore.kernel.org/r/20230116144149.305560-1-brgl@bgdev.plSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      eede42c9
    • Serge Semin's avatar
      spi: dw: Fix wrong FIFO level setting for long xfers · c63b8fd1
      Serge Semin authored
      Due to using the u16 type in the min_t() macros the SPI transfer length
      will be cast to word before participating in the conditional statement
      implied by the macro. Thus if the transfer length is greater than 64KB the
      Tx/Rx FIFO threshold level value will be determined by the leftover of the
      truncated after the type-case length. In the worst case it will cause the
      dramatical performance drop due to the "Tx FIFO Empty" or "Rx FIFO Full"
      interrupts triggered on each xfer word sent/received to/from the bus.
      
      The problem can be easily fixed by specifying the unsigned int type in the
      min_t() macros thus preventing the possible data loss.
      
      Fixes: ea11370f ("spi: dw: get TX level without an additional variable")
      Reported-by: default avatarSergey Nazarov <Sergey.Nazarov@baikalelectronics.ru>
      Signed-off-by: default avatarSerge Semin <Sergey.Semin@baikalelectronics.ru>
      Reviewed-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Link: https://lore.kernel.org/r/20230113185942.2516-1-Sergey.Semin@baikalelectronics.ruSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      c63b8fd1
    • Randy Dunlap's avatar
      spi: correct spelling · 0f6d2cee
      Randy Dunlap authored
      Correct spelling problems for Documentation/spi/ as reported
      by codespell.
      Signed-off-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Link: https://lore.kernel.org/r/20230127064005.1558-28-rdunlap@infradead.orgSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      0f6d2cee
  9. 25 Jan, 2023 3 commits
  10. 23 Jan, 2023 5 commits
  11. 20 Jan, 2023 1 commit
  12. 13 Jan, 2023 1 commit
    • Mark Brown's avatar
      spi: SPI core CS delay fixes and additions · c5d80869
      Mark Brown authored
      Merge series from Hector Martin <marcan@marcan.st>:
      
      Commits f6c911f3 ("spi: dt-bindings: Introduce
      spi-cs-setup-ns property") and 33a2fde5 ("spi: Introduce
      spi-cs-setup-ns property") introduced a new property to represent the
      CS setup delay in the device tree, but they have some issues:
      
      - The property is only parsed as a 16-bit integer number of nanoseconds,
        which limits the maximum value to ~65us. This is not a reasonable
        upper limit, as some devices might need a lot more.
      - The property name is inconsistent with other delay properties, which
        use a "*-delay-ns" naming scheme.
      - Only the setup delay is introduced, but not the related hold and
        inactive delay times.
      
      This series fixes the issues and adds support for the two missing
      properties. Please pull in the first 3 patches as fixes for 6.2, to
      avoid introducing a problematic DT API in this release. The last two
      patches can wait until 6.3, though are probably harmless to throw in
      as fixes too, since they're trivial.
      c5d80869