Skip to content

K
Kernel

openeuler / Kernel
大约 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 01 6月, 2022 4 次提交
  3. 25 5月, 2022 4 次提交
  5. 19 5月, 2022 1 次提交
    • D
      PCI: microchip: Fix potential race in interrupt handling · 7013654a
      由 Daire McNamara 提交于 
      Clear the MSI bit in ISTATUS_LOCAL register after reading it, but
before reading and handling individual MSI bits from the ISTATUS_MSI
register. This avoids a potential race where new MSI bits may be set
on the ISTATUS_MSI register after it was read and be missed when the
MSI bit in the ISTATUS_LOCAL register is cleared.

ISTATUS_LOCAL is a read/write/clear register; the register's bits
are set when the corresponding interrupt source is activated. Each
source is independent and thus multiple sources may be active
simultaneously. The processor can monitor and clear status
bits. If one or more ISTATUS_LOCAL interrupt sources are active,
the RootPort issues an interrupt towards the processor (on
the AXI domain). Bit 28 of this register reports an MSI has been
received by the RootPort.

ISTATUS_MSI is a read/write/clear register. Bits 31-0 are asserted
when an MSI with message number 31-0 is received by the RootPort.
The processor must monitor and clear these bits.

Effectively, Bit 28 of ISTATUS_LOCAL informs the processor that
an MSI has arrived at the RootPort and ISTATUS_MSI informs the
processor which MSI (in the range 0 - 31) needs handling.

Reported by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://lore.kernel.org/linux-pci/20220127202000.GA126335@bhelgaas/

Link: https://lore.kernel.org/r/20220517141622.145581-1-daire.mcnamara@microchip.com
Fixes: 6f15a9c9 ("PCI: microchip: Add Microchip PolarFire PCIe controller driver")
Signed-off-by: NDaire McNamara <daire.mcnamara@microchip.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      7013654a
  7. 17 5月, 2022 1 次提交
  9. 13 5月, 2022 2 次提交
  11. 12 5月, 2022 2 次提交
  13. 11 5月, 2022 6 次提交
  15. 04 5月, 2022 1 次提交
  17. 28 4月, 2022 1 次提交
  19. 25 4月, 2022 2 次提交
  21. 11 4月, 2022 1 次提交
  23. 08 4月, 2022 4 次提交
  25. 31 3月, 2022 1 次提交
  27. 29 3月, 2022 1 次提交
  29. 23 3月, 2022 2 次提交
  31. 22 3月, 2022 1 次提交
  33. 21 3月, 2022 2 次提交
  35. 17 3月, 2022 2 次提交
  37. 14 3月, 2022 2 次提交
    • M
      PCI: rcar: Use PCI_SET_ERROR_RESPONSE after read which triggered an exception · 6e36203b
      由 Marek Vasut 提交于 
      In case the controller is transitioning to L1 in rcar_pcie_config_access(),
any read/write access to PCIECDR triggers asynchronous external abort. This
is because the transition to L1 link state must be manually finished by the
driver. The PCIe IP can transition back from L1 state to L0 on its own.

The current asynchronous external abort hook implementation restarts
the instruction which finally triggered the fault, which can be a
different instruction than the read/write instruction which started
the faulting access. Usually the instruction which finally triggers
the fault is one which has some data dependency on the result of the
read/write. In case of read, the read value after fixup is undefined,
while a read value of faulting read should be PCI_ERROR_RESPONSE.

It is possible to enforce the fault using 'isb' instruction placed
right after the read/write instruction which started the faulting
access. Add custom register accessors which perform the read/write
followed immediately by 'isb'.

This way, the fault always happens on the 'isb' and in case of read,
which is located one instruction before the 'isb', it is now possible
to fix up the return value of the read in the asynchronous external
abort hook and make that read return PCI_ERROR_RESPONSE.

Link: https://lore.kernel.org/r/20220312212349.781799-2-marek.vasut@gmail.comTested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NArnd Bergmann <arnd@arndb.de>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Wilczyński <kw@linux.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: linux-renesas-soc@vger.kernel.org
      6e36203b
    • M
      PCI: rcar: Finish transition to L1 state in rcar_pcie_config_access() · 84b57614
      由 Marek Vasut 提交于 
      In case the controller is transitioning to L1 in rcar_pcie_config_access(),
any read/write access to PCIECDR triggers asynchronous external abort. This
is because the transition to L1 link state must be manually finished by the
driver. The PCIe IP can transition back from L1 state to L0 on its own.

Avoid triggering the abort in rcar_pcie_config_access() by checking whether
the controller is in the transition state, and if so, finish the transition
right away. This prevents a lot of unnecessary exceptions, although not all
of them.

Link: https://lore.kernel.org/r/20220312212349.781799-1-marek.vasut@gmail.comTested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NMarek Vasut <marek.vasut+renesas@gmail.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Krzysztof Wilczyński <kw@linux.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Wolfram Sang <wsa@the-dreams.de>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Cc: linux-renesas-soc@vger.kernel.org
      84b57614