You need to sign in or sign up before continuing.
- 23 2月, 2022 5 次提交
-
-
由 Pali Rohár 提交于
Register 0x1910 unmasks interrupts and legacy INTx interrupts are unmasked because driver does not support individual masking yet. Link: https://lore.kernel.org/r/20220222155030.988-11-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
由 Pali Rohár 提交于
Split struct pci_ops between ops and child_ops. Member ops is used for accessing PCIe Root Ports via pci-bridge-emul.c driver and child_ops for accessing real PCIe cards. There is no need to mix these two struct pci_ops into one as PCI core code already provides separate callbacks via bridge->ops and bridge->child_ops. Link: https://lore.kernel.org/r/20220222155030.988-9-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
由 Pali Rohár 提交于
AER registers start at mvebu offset 0x0100. Registers PCI_ERR_ROOT_COMMAND, PCI_ERR_ROOT_STATUS and PCI_ERR_ROOT_ERR_SRC are not supported on pre-XP hardware and returns zeros. Note that AER interrupt is not supported yet as mvebu emulated bridge does not implement interrupts support at all yet. Also remove custom macro PCIE_HEADER_LOG_4_OFF as it is unused and correctly this register should be referenced via standard macros with offset, e.g. as: PCIE_CAP_PCIERR_OFF + PCI_ERR_HEADER_LOG + 4. Link: https://lore.kernel.org/r/20220222155030.988-8-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
由 Pali Rohár 提交于
Register with Subsystem Device/Vendor ID is at offset 0x2c. Export is via emulated bridge. After this change Subsystem ID is visible in lspci output at line: Capabilities: [40] Subsystem Link: https://lore.kernel.org/r/20220222155030.988-7-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
由 Pali Rohár 提交于
If x1/x4 mode is not set correctly then link with endpoint card is not established. Use DTS property 'num-lanes' to deteriminate x1/x4 mode. Link: https://lore.kernel.org/r/20220222155030.988-6-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
- 03 2月, 2022 9 次提交
-
-
由 Pali Rohár 提交于
Add support for reporting PCI_EXP_LNKSTA_DLLLA bit in Link Control register on emulated bridge via PCIE_STAT_OFF reg. Function mvebu_pcie_link_up() already parses this register and returns if Data Link is Active or not. Also correctly indicate DLLLA capability via PCI_EXP_LNKCAP_DLLLARC bit in Link Control Capability register which is required for reporting DLLLA bit. Link: https://lore.kernel.org/r/20220104153529.31647-12-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: NRob Herring <robh@kernel.org>
-
由 Pali Rohár 提交于
Logic and code for clearing PCI_EXP_LNKCTL_CLKREQ_EN bit is correct, but comment describing it is misleading. PCI_EXP_LNKCTL_CLKREQ_EN bit should be hardwired to zero but mvebu hw allows to change it. Link: https://lore.kernel.org/r/20220104153529.31647-11-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: NRob Herring <robh@kernel.org>
-
由 Pali Rohár 提交于
Reason for clearing this bit is because mvebu hw returns incorrectly this bit set to 1. Link: https://lore.kernel.org/r/20220104153529.31647-10-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: NRob Herring <robh@kernel.org>
-
由 Pali Rohár 提交于
With this change also PCI vendor id is read from mvebu registers. Link: https://lore.kernel.org/r/20220104153529.31647-9-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: NRob Herring <robh@kernel.org>
-
由 Pali Rohár 提交于
This will make PCI bridge to return zeros when accessing IO base and limit registers, as required by PCIe base specification. This allows to remove adhoc checks around mvebu_pcie_handle_iobase_change() function for unsupported IO ranges. PCI_BRIDGE_EMUL_NO_IO_FORWARD ensures that there will be no non-zeros write to IO registers when IO is not supported. Link: https://lore.kernel.org/r/20220104153529.31647-8-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: NRob Herring <robh@kernel.org>
-
由 Pali Rohár 提交于
Member pcie->nports is initialized to correct value before the previous for-loop. There is not need to initialize it more times. Link: https://lore.kernel.org/r/20220104153529.31647-7-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: NRob Herring <robh@kernel.org> Acked-by: NThomas Petazzoni <thomas.petazzoni@bootlin.com>
-
由 Pali Rohár 提交于
There is no description for CONFIG_PCI_MVEBU option. Add it. Link: https://lore.kernel.org/r/20220104153529.31647-6-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: NRob Herring <robh@kernel.org> Acked-by: NThomas Petazzoni <thomas.petazzoni@bootlin.com>
-
由 Pali Rohár 提交于
PCI: pci-bridge-emul: Rename PCI_BRIDGE_EMUL_NO_PREFETCHABLE_BAR to PCI_BRIDGE_EMUL_NO_PREFMEM_FORWARD This flag describe whether PCI bridge supports forwarding of prefetchable memory requests in given range between primary and secondary buses. It does not specify if bridge has support for prefetchable memory BAR (moreover this pci-bridge-emul.c driver does not provide support for BARs). So change name of this flag to be less misleading and add comment. Link: https://lore.kernel.org/r/20220104153529.31647-4-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: NRob Herring <robh@kernel.org>
-
由 Pali Rohár 提交于
It is read-only constant structure, so properly mark it with const keyword. Link: https://lore.kernel.org/r/20220104153529.31647-3-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: NRob Herring <robh@kernel.org> Acked-by: NThomas Petazzoni <thomas.petazzoni@bootlin.com>
-
- 16 1月, 2022 1 次提交
-
-
由 Yury Norov 提交于
find_first{,_zero}_bit is a more effective analogue of 'next' version if start == 0. This patch replaces 'next' with 'first' where things look trivial. Signed-off-by: NYury Norov <yury.norov@gmail.com> Tested-by: NWolfram Sang <wsa+renesas@sang-engineering.com>
-
- 13 1月, 2022 11 次提交
-
-
由 Sergio Paracuellos 提交于
Since all MIPS-specific code has been removed from driver, allow it to be enabled for COMPILE_TEST on all architectures. Mark it as tristate and remove MIPS the MIPS dependency. Signed-off-by: NSergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Sergio Paracuellos 提交于
The MT7621 PCIe host controller driver can be built as a module, but it lacks a MODULE_LICENSE(), which causes a build error: ERROR: modpost: missing MODULE_LICENSE() in drivers/pci/controller/pcie-mt7621.o Add MODULE_LICENSE() to the driver. Fixes: 2bdd5238 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver") Link: https://lore.kernel.org/r/20211207104924.21327-5-sergio.paracuellos@gmail.comSigned-off-by: NYanteng Si <siyanteng@loongson.cn> Signed-off-by: NSergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NKrzysztof Wilczyński <kw@linux.com>
-
由 Sergio Paracuellos 提交于
On the MIPS ralink mt7621 platform, we need to set up I/O coherency units based on the host bridge apertures. To remove this arch dependency from the driver itself, move the coherency setup from the driver to pcibios_root_bridge_prepare(). [bhelgaas: squash add/remove into one patch, commit log] Link: https://lore.kernel.org/r/20211207104924.21327-3-sergio.paracuellos@gmail.com Link: https://lore.kernel.org/r/20211207104924.21327-4-sergio.paracuellos@gmail.comSigned-off-by: NSergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> # arch/mips Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de> # arch/mips
-
由 Sergio Paracuellos 提交于
Sparse complains about mt7621_pci_ops symbol is not declared and asks if it should be declared as static instead. Sparse is right. Hence declare symbol as static. Link: https://lore.kernel.org/r/20211117152952.12271-1-sergio.paracuellos@gmail.comReported-by: Nkernel test robot <lkp@intel.com> Signed-off-by: NSergio Paracuellos <sergio.paracuellos@gmail.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NKrzysztof Wilczyński <kw@linux.com>
-
由 Jim Quinlan 提交于
If any downstream device can be a wakeup device, do not turn off the regulators as the device will need them on. Link: https://lore.kernel.org/r/20220106160332.2143-8-jim2101024@gmail.comSigned-off-by: NJim Quinlan <jim2101024@gmail.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Jim Quinlan 提交于
This Broadcom STB PCIe RC driver has one port and connects directly to one device, be it a switch or an endpoint. We want to be able to leverage the recently added mechanism that allocates and turns on/off subdevice regulators. All that needs to be done is to put the regulator DT nodes in the bridge below host and to set the pci_ops methods add_bus and remove_bus. Note that the pci_subdev_regulators_add_bus() method is wrapped for two reasons: 1. To achieve link up after the voltage regulators are turned on. 2. If, in the case of an unsuccessful link up, to redirect any PCIe accesses to subdevices, e.g. the scan for DEV/ID. This redirection is needed because the Broadcom PCIe HW will issue a CPU abort if such an access is made when the link is down. [bhelgaas: fold in https://lore.kernel.org/r/20220112013100.48029-1-jim2101024@gmail.com] Link: https://lore.kernel.org/r/20220106160332.2143-7-jim2101024@gmail.comSigned-off-by: NJim Quinlan <jim2101024@gmail.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> -
由 Jim Quinlan 提交于
Add a mechanism to identify standard PCIe regulators in the DT, allocate them, and turn them on before the rest of the bus is scanned during pci_host_probe(). The allocated structure that contains the regulators is stored in the port driver dev.driver_data field. Here is a point-by-point of how and when this mechanism is activated: If: -- PCIe RC driver sets pci_ops {add,remove)_bus to pci_subdev_regulators_{add,remove}_bus during its probe. -- There is a DT node "RB" under the host bridge DT node. -- During the RC driver's pci_host_probe() the add_bus callback is invoked where (bus->parent && pci_is_root_bus(bus->parent) is true Then: -- A struct subdev_regulators structure will be allocated and assigned to bus->dev.driver_data. -- regulator_bulk_{get,enable} will be invoked on &bus->dev and the former will search for and process any vpcie{12v,3v3,3v3aux}-supply properties that reside in node "RB". -- The regulators will be turned off/on for any unbind/bind operations. -- The regulators will be turned off/on for any suspend/resumes, but only if the RC driver handles this on its own. This will appear in a later commit for the pcie-brcmstb.c driver. The unabridged reason for doing this is as follows. We would like the Broadcom STB PCIe root complex driver (and others) to be able to turn off/on regulators[1] that provide power to endpoint[2] devices. Typically, the drivers of these endpoint devices are stock Linux drivers that are not aware that these regulator(s) exist and must be turned on for the driver to be probed. The simple solution of course is to turn these regulators on at boot and keep them on. However, this solution does not satisfy at least three of our usage modes: 1. For example, one customer uses multiple PCIe controllers, but wants the ability to, by script invoking and unbind, turn any or all of them and their subdevices off to save power, e.g. when in battery mode. 2. Another example is when a watchdog script discovers that an endpoint device is in an unresponsive state and would like to unbind, power toggle, and re-bind just the PCIe endpoint and controller. 3. Of course we also want power turned off during suspend mode. However, some endpoint devices may be able to "wake" during suspend and we need to recognise this case and veto the nominal act of turning off its regulator. Such is the case with Wake-on-LAN and Wake-on-WLAN support where the PCIe endpoint device needs to be kept powered on in order to receive network packets and wake the system. In all of these cases it is advantageous for the PCIe controller to govern the turning off/on the regulators needed by the endpoint device. The first two cases can be done by simply unbinding and binding the PCIe controller, if the controller has control of these regulators. [1] These regulators typically govern the actual power supply to the endpoint chip. Sometimes they may be the official PCIe socket power -- such as 3.3v or aux-3.3v. Sometimes they are truly the regulator(s) that supply power to the EP chip. [2] The 99% configuration of our boards is a single endpoint device attached to the PCIe controller. I use the term endpoint but it could possibly mean a switch as well. Link: https://lore.kernel.org/r/20220106160332.2143-6-jim2101024@gmail.comSigned-off-by: NJim Quinlan <jim2101024@gmail.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> -
由 Jim Quinlan 提交于
We need to take some code in brcm_pcie_setup() and put it in a new function brcm_pcie_linkup(). In future commits the brcm_pcie_linkup() function will be called indirectly by pci_host_probe() as opposed to the host driver invoking it directly. Some code that was executed after the PCIe linkup is now placed so that it executes prior to linkup, since this code has to run prior to the invocation of pci_host_probe(). Link: https://lore.kernel.org/r/20220106160332.2143-5-jim2101024@gmail.comSigned-off-by: NJim Quinlan <jim2101024@gmail.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
由 Jim Quinlan 提交于
Do at least a dev_err() on some calls to reset_control_rearm() and brcm_phy_stop(). In some cases it may not make sense to return this error value "above" as doing so will cause more trouble than is warranted. Link: https://lore.kernel.org/r/20220106160332.2143-2-jim2101024@gmail.comSigned-off-by: NJim Quinlan <jim2101024@gmail.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
-
由 Florian Fainelli 提交于
Define the legacy MSI interrupt bitmask as well as the non-legacy interrupt bitmask using GENMASK and then use them in brcm_msi_set_regs() in place of __GENMASK(). Link: https://lore.kernel.org/r/20211122190459.3189616-1-f.fainelli@gmail.comReported-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
-
由 Christophe JAILLET 提交于
The 'used' field of 'struct brcm_msi' is used as a bitmap. Declare it with DECLARE_BITMAP() and adjust users accordingly. This fixes a harmless Coverity warning about array vs singleton usage. This bitmap can be used for either legacy or MSI interrupts, which require a size of BRCM_INT_PCI_MSI_LEGACY_NR or BRCM_INT_PCI_MSI_NR respectively. Add a BUILD_BUG_ON() to ensure it is large enough. Suggested-by: NKrzysztof Wilczynski <kw@linux.com> Addresses-Coverity: "Out-of-bounds access (ARRAY_VS_SINGLETON)" Link: https://lore.kernel.org/r/e6d9da2112aab2939d1507b90962d07bfd735b4c.1636273671.git.christophe.jaillet@wanadoo.frSigned-off-by: NChristophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
-
- 12 1月, 2022 2 次提交
-
-
由 Sunil Muthuswamy 提交于
Add arm64 Hyper-V vPCI support by implementing the arch specific interfaces. Introduce an IRQ domain and chip specific to Hyper-v vPCI that is based on SPIs. The IRQ domain parents itself to the arch GIC IRQ domain for basic vector management. [bhelgaas: squash in fix from Yang Li <yang.lee@linux.alibaba.com>: https://lore.kernel.org/r/20220112003324.62755-1-yang.lee@linux.alibaba.com] Link: https://lore.kernel.org/r/1641411156-31705-3-git-send-email-sunilmut@linux.microsoft.comSigned-off-by: NSunil Muthuswamy <sunilmut@microsoft.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NMarc Zyngier <maz@kernel.org> Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
-
由 Sunil Muthuswamy 提交于
Encapsulate arch dependencies in Hyper-V vPCI through a set of arch-dependent interfaces. Adding these arch specific interfaces will allow for an implementation for other architectures, such as arm64. There are no functional changes expected from this patch. Link: https://lore.kernel.org/r/1641411156-31705-2-git-send-email-sunilmut@linux.microsoft.comSigned-off-by: NSunil Muthuswamy <sunilmut@microsoft.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com> Reviewed-by: NBoqun Feng <boqun.feng@gmail.com> Reviewed-by: NMarc Zyngier <maz@kernel.org> Reviewed-by: NMichael Kelley <mikelley@microsoft.com>
-
- 11 1月, 2022 1 次提交
-
-
由 Jim Quinlan 提交于
The current brcmstb driver works for Arm and Arm64. A few things are modified here for us to support MIPs as well. o There are four outbound range register groups and each directs a window of up to 128MB. Even though there are four 128MB DT "ranges" in the bmips PCIe DT node, these ranges are contiguous and are collapsed into a single range by the OF range parser. Now the driver assumes a single range -- for MIPs only -- and splits it back into 128MB sizes. o For bcm7425, the config space accesses must be 32-bit reads or writes. In addition, the 4k config space register array is missing and not used. o The registers for the upper 32-bits of the outbound window address do not exist. o Burst size must be set to 256 (this refers to an internal bus). Signed-off-by: NJim Quinlan <jim2101024@gmail.com> Acked-by: NFlorian Fainelli <f.fainelli@gmail.com> Signed-off-by: NThomas Bogendoerfer <tsbogend@alpha.franken.de>
-
- 08 1月, 2022 1 次提交
-
-
由 Krzysztof Wilczyński 提交于
Fix a number of misspelled words, and while at it, correct two phrases used to indicate a status of an operation where words used have been cleverly truncated and thus always trigger a spellchecking error while performing a static code analysis over the PCI tree. [bhelgaas: reverse sense of quirk ternary] Link: https://lore.kernel.org/r/20220107225942.121484-1-kw@linux.comSigned-off-by: NKrzysztof Wilczyński <kw@linux.com> Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
-
- 07 1月, 2022 2 次提交
-
-
由 Kishon Vijay Abraham I 提交于
Get "syscon" pcie_mode and pcie_id offset from the argument of "ti,syscon-pcie-id" and "ti,syscon-pcie-mode" phandle respectively. Previously a subnode to "syscon" node was added which has the exact memory mapped address of pcie_mode and pcie_id but now the offset of pcie_mode and pcie_id within "syscon" is now being passed as argument to "ti,syscon-pcie-id" and "ti,syscon-pcie-mode" phandle. If the offset is not provided in "ti,syscon-pcie-id"/"ti,syscon-pcie-mode", the full memory mapped address of pcie_ctrl is used in order to maintain old DT compatibility. Similar change for J721E is as discussed in [1] [1] -> http://lore.kernel.org/r/CAL_JsqKiUcO76bo1GoepWM1TusJWoty_BRy2hFSgtEVMqtrvvQ@mail.gmail.com Link: https://lore.kernel.org/r/20211126083119.16570-3-kishon@ti.comSigned-off-by: NKishon Vijay Abraham I <kishon@ti.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
由 qizhong cheng 提交于
Described in PCIe CEM specification sections 2.2 (PERST# Signal) and 2.2.1 (Initial Power-Up (G3 to S0)). The deassertion of PERST# should be delayed 100ms (TPVPERL) for the power and clock to become stable. Link: https://lore.kernel.org/r/20211227133110.14500-1-qizhong.cheng@mediatek.comSigned-off-by: Nqizhong cheng <qizhong.cheng@mediatek.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: NPali Rohár <pali@kernel.org>
-
- 06 1月, 2022 2 次提交
-
-
由 Pali Rohár 提交于
Now when driver uses devm_pci_remap_iospace() function, it is possible implement ->remove() callback for unbinding device from driver. Implement mvebu_pcie_remove() callback with proper cleanup phase, drop driver's suppress_bind_attrs flag and switch type of CONFIG_PCI_MVEBU option from bool to tristate. This allows to compile pci-mvebu.c driver as loadable module pci-mvebu.ko with ability to unload it. Link: https://lore.kernel.org/r/20211126144307.7568-3-pali@kernel.orgSigned-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
由 Karthik L Gopalakrishnan 提交于
Add support for this VMD device which supports the bus restriction mode. The feature that turns off vector 0 for MSI-X remapping is also enabled. Link: https://lore.kernel.org/r/20211217231211.46018-1-francisco.munoz.ruiz@linux.intel.comSigned-off-by: NKarthik L Gopalakrishnan <karthik.l.gopalakrishnan@intel.com> Signed-off-by: NFrancisco Munoz <francisco.munoz.ruiz@linux.intel.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: NJon Derrick <jonathan.derrick@linux.dev>
-
- 05 1月, 2022 1 次提交
-
-
由 Hou Zhiqiang 提交于
The current Layerscape PCIe driver directly uses the physical layer LTSSM code to check the link-up state, which treats the > L0 states as link-up. This is not correct, since there is not explicit map between link-up state and LTSSM. So this patch changes to use the DWC common link-up check function. Link: https://lore.kernel.org/r/20211224094000.8513-1-Zhiqiang.Hou@nxp.comSigned-off-by: NHou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: NRob Herring <robh@kernel.org>
-
- 04 1月, 2022 5 次提交
-
-
由 Rikard Falkeborn 提交于
The only usage of pci_ep_ops is to assign its address to the ops field in the dw_pcie_ep struct which is a pointer to const struct dw_pcie_ep_ops. Make it const to allow the compiler to put it in read-only memory. Link: https://lore.kernel.org/r/20211204220316.88655-1-rikard.falkeborn@gmail.comSigned-off-by: NRikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: NKrzysztof Wilczyński <kw@linux.com>
-
由 Kai-Heng Feng 提交于
When Samsung PCIe Gen4 NVMe is connected to Intel ADL VMD, the combination causes AER message flood and drags the system performance down. The issue doesn't happen when VMD mode is disabled in BIOS, since AER isn't enabled by acpi_pci_root_create() . When VMD mode is enabled, AER is enabled regardless of _OSC: [ 0.410076] acpi PNP0A08:00: _OSC: platform does not support [AER] ... [ 1.486704] pcieport 10000:e0:06.0: AER: enabled with IRQ 146 Since VMD is an aperture to regular PCIe root ports, honor ACPI _OSC to disable PCIe features accordingly to resolve the issue. Suggested-by: NRafael J. Wysocki <rafael@kernel.org> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215027 Link: https://lore.kernel.org/r/20211203031541.1428904-1-kai.heng.feng@canonical.comSigned-off-by: NKai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
-
由 Pali Rohár 提交于
Armada XP and new hardware supports access to DEVCAP2, DEVCTL2 and LNKCTL2 configuration registers of PCIe core via PCIE_CAP_PCIEXP. So export them via emulated software root bridge. Pre-XP hardware does not support these registers and returns zeros. Link: https://lore.kernel.org/r/20211125124605.25915-16-pali@kernel.org Fixes: 1f08673e ("PCI: mvebu: Convert to PCI emulated bridge config space") Signed-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
由 Pali Rohár 提交于
PME Status bit in Root Status Register (PCIE_RC_RTSTA_OFF) is read-only and can be cleared only by writing 0b to the Interrupt Cause RW0C register (PCIE_INT_CAUSE_OFF). Link: https://lore.kernel.org/r/20211125124605.25915-15-pali@kernel.org Fixes: 1f08673e ("PCI: mvebu: Convert to PCI emulated bridge config space") Signed-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-
由 Pali Rohár 提交于
Comment in Armada 370 functional specification is misleading. PCI_EXP_DEVCTL_*RE bits are supported and configures receiving of error interrupts. Link: https://lore.kernel.org/r/20211125124605.25915-14-pali@kernel.org Fixes: 1f08673e ("PCI: mvebu: Convert to PCI emulated bridge config space") Signed-off-by: NPali Rohár <pali@kernel.org> Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
-