1. 15 Jun, 2023 2 commits
  2. 07 Jun, 2023 2 commits
  3. 06 Jun, 2023 4 commits
  4. 02 Jun, 2023 2 commits
  5. 01 Jun, 2023 4 commits
  6. 31 May, 2023 2 commits
  7. 30 May, 2023 18 commits
  8. 26 May, 2023 1 commit
  9. 25 May, 2023 1 commit
  10. 24 May, 2023 1 commit
  11. 23 May, 2023 3 commits
    • Daniel Golle's avatar
      spi: mt65xx: make sure operations completed before unloading · 4be47a5d
      Daniel Golle authored
      When unloading the spi-mt65xx kernel module during an ongoing spi-mem
      operation the kernel will Oops shortly after unloading the module.
      This is because wait_for_completion_timeout was still running and
      returning into the no longer loaded module:
      
      Internal error: Oops: 0000000096000005 [#1] SMP
      Modules linked in: [many, but spi-mt65xx is no longer there]
      CPU: 0 PID: 2578 Comm: block Tainted: G        W  O       6.3.0-next-20230428+ #0
      Hardware name: Bananapi BPI-R3 (DT)
      pstate: 804000c5 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
      pc : __lock_acquire+0x18c/0x20e8
      lr : __lock_acquire+0x9b8/0x20e8
      sp : ffffffc009ec3400
      x29: ffffffc009ec3400 x28: 0000000000000001 x27: 0000000000000004
      x26: ffffff80082888c8 x25: 0000000000000000 x24: 0000000000000000
      x23: ffffffc009609da8 x22: ffffff8008288000 x21: ffffff8008288968
      x20: 00000000000003c2 x19: ffffff8008be7990 x18: 00000000000002af
      x17: 0000000000000000 x16: 0000000000000000 x15: ffffffc008d78970
      x14: 000000000000080d x13: 00000000000002af x12: 00000000ffffffea
      x11: 00000000ffffefff x10: ffffffc008dd0970 x9 : ffffffc008d78918
      x8 : 0000000000017fe8 x7 : 0000000000000001 x6 : 0000000000000000
      x5 : ffffff807fb53910 x4 : 0000000000000000 x3 : 0000000000000027
      x2 : 0000000000000027 x1 : 0000000000000000 x0 : 00000000000c03c2
      Call trace:
       __lock_acquire+0x18c/0x20e8
       lock_acquire+0x100/0x2a4
       _raw_spin_lock_irq+0x58/0x74
       __wait_for_common+0xe0/0x1b4
       wait_for_completion_timeout+0x1c/0x24
       0xffffffc000acc8a4 <--- used to be mtk_spi_transfer_wait
       spi_mem_exec_op+0x390/0x3ec
       spi_mem_no_dirmap_read+0x6c/0x88
       spi_mem_dirmap_read+0xcc/0x12c
       spinand_read_page+0xf8/0x1dc
       spinand_mtd_read+0x1b4/0x2fc
       mtd_read_oob_std+0x58/0x7c
       mtd_read_oob+0x8c/0x148
       mtd_read+0x50/0x6c
       ...
      
      Prevent this by completing in mtk_spi_remove if needed.
      
      Fixes: 9f763fd2 ("spi: mediatek: add spi memory support for ipm design")
      Signed-off-by: default avatarDaniel Golle <daniel@makrotopia.org>
      Link: https://lore.kernel.org/r/ZFAF6pJxMu1z6k4w@makrotopia.orgSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      4be47a5d
    • Clark Wang's avatar
      spi: lpspi: disable lpspi module irq in DMA mode · 9728fb3c
      Clark Wang authored
      When all bits of IER are set to 0, we still can observe the lpspi irq events
      when using DMA mode to transfer data.
      
      So disable irq to avoid the too much irq events.
      Signed-off-by: default avatarClark Wang <xiaoning.wang@nxp.com>
      Link: https://lore.kernel.org/r/20230505063557.3962220-1-xiaoning.wang@nxp.comSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      9728fb3c
    • Rasmus Villemoes's avatar
      spi: spi-imx: set max_native_cs for imx51/imx53/imx6 variants · 8ce1bb9a
      Rasmus Villemoes authored
      The ecspi IP block on imx51/imx53/imx6 have four native chip
      selects. Tell that to the spi core so that any non-gpio chip selects
      get validated against that upper bound.
      
      Also set the SPI_MASTER_GPIO_SS so that the core verifies that, in the
      case where both native and gpio chip selects are in use, there is at
      least one leftover native chip select (or "channel", in the ecspi
      language) for use by the slaves sitting on gpio chip selects.
      Signed-off-by: default avatarRasmus Villemoes <linux@rasmusvillemoes.dk>
      Link: https://lore.kernel.org/r/20230425134527.483607-3-linux@rasmusvillemoes.dkSigned-off-by: default avatarMark Brown <broonie@kernel.org>
      8ce1bb9a