- Dec 14, 2021
-
-
Thomas Gleixner authored
PCI_MSIX_FLAGS_MASKALL is set in the MSI-X control register at MSI-X interrupt setup time. It's cleared on success, but the error handling path only clears the PCI_MSIX_FLAGS_ENABLE bit. That's incorrect as the reset state of the PCI_MSIX_FLAGS_MASKALL bit is zero. That can be observed via lspci: Capabilities: [b0] MSI-X: Enable- Count=67 Masked+ Clear the bit in the error path to restore the reset state. Fixes: 43855395 ("PCI/MSI: Enable and mask MSI-X early") Reported-by:Stefan Roese <sr@denx.de> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Tested-by:
-
Stefan Roese authored
Masking all unused MSI-X entries is done to ensure that a crash kernel starts from a clean slate, which correponds to the reset state of the device as defined in the PCI-E specificion 3.0 and later: Vector Control for MSI-X Table Entries -------------------------------------- "00: Mask bit: When this bit is set, the function is prohibited from sending a message using this MSI-X Table entry. ... This bit’s state after reset is 1 (entry is masked)." A Marvell NVME device fails to deliver MSI interrupts after trying to enable MSI-X interrupts due to that masking. It seems to take the MSI-X mask bits into account even when MSI-X is disabled. While not specification compliant, this can be cured by moving the masking into the success path, so that the MSI-X table entries stay in device reset state when the MSI-X setup fails. [ tglx: Move it into the success path, add comment and amend changelog ] Fixes: aa8092c1d1f1 ("PCI/MSI: Mask all unused MSI-X entries") Signed-off-by:
-
- Dec 13, 2021
-
-
Sergio Paracuellos authored
The driver is not ready yet to be compiled as a module since it depends on some symbols not exported on MIPS. We have the following current problems: Building mips:allmodconfig ... failed -------------- Error log: ERROR: modpost: missing MODULE_LICENSE() in drivers/pci/controller/pcie-mt7621.o ERROR: modpost: "mips_cm_unlock_other" [drivers/pci/controller/pcie-mt7621.ko] undefined! ERROR: modpost: "mips_cpc_base" [drivers/pci/controller/pcie-mt7621.ko] undefined! ERROR: modpost: "mips_cm_lock_other" [drivers/pci/controller/pcie-mt7621.ko] undefined! ERROR: modpost: "mips_cm_is64" [drivers/pci/controller/pcie-mt7621.ko] undefined! ERROR: modpost: "mips_gcr_base" [drivers/pci/controller/pcie-mt7621.ko] undefined! Temporarily move from 'tristate' to 'bool' until a better solution is ready. Also RALINK is redundant because SOC_MT7621 already depends on it. Hence, simplify condition. Fixes: 2bdd5238 ("PCI: mt7621: Add MediaTek MT7621 PCIe host controller driver"). Signed-off-by:
Sergio Paracuellos <sergio.paracuellos@gmail.com> Reviewed-and-Tested-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
- Dec 07, 2021
-
-
Marc Zyngier authored
Now that PERST# is properly defined as active-low in the device tree, fix the driver to correctly drive the line independently of the implied polarity. Suggested-by:
Pali Rohár <pali@kernel.org> Fixes: 1e33888f ("PCI: apple: Add initial hardware bring-up") Link: https://lore.kernel.org/r/20211123180636.80558-4-maz@kernel.org Signed-off-by:
Marc Zyngier <maz@kernel.org> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
Luca Ceresoli <luca@lucaceresoli.net>
-
Marc Zyngier authored
While the Apple PCIe driver works correctly when directly booted from the firmware, it fails to initialise when the kernel is booted from a bootloader using PCIe such as u-boot. That's because we're missing a proper reset of the port (we only clear the reset, but never assert it). The PCIe spec requirements are two-fold: - PERST# must be asserted before setting up the clocks and stay asserted for at least 100us (Tperst-clk) - Once PERST# is deasserted, the OS must wait for at least 100ms "from the end of a Conventional Reset" before we can start talking to the devices Implementing this results in a booting system. [bhelgaas: #PERST -> PERST#, update spec references to current] Fixes: 1e33888f ("PCI: apple: Add initial hardware bring-up") Link: https://lore.kernel.org/r/20211123180636.80558-2-maz@kernel.org Signed-off-by:
-
- Dec 03, 2021
-
-
Jakub Kicinski authored
cgroup.h (therefore swap.h, therefore half of the universe) includes bpf.h which in turn includes module.h and slab.h. Since we're about to get rid of that dependency we need to clean things up. v2: drop the cpu.h include from cacheinfo.h, it's not necessary and it makes riscv sensitive to ordering of include files. Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Reviewed-by:
Christoph Hellwig <hch@lst.de> Acked-by:
Krzysztof Wilczyński <kw@linux.com> Acked-by:
Peter Chen <peter.chen@kernel.org> Acked-by:
SeongJae Park <sj@kernel.org> Acked-by:
Jani Nikula <jani.nikula@intel.com> Acked-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/all/20211120035253.72074-1-kuba@kernel.org/ # v1 Link: https://lore.kernel.org/all/20211120165528.197359-1-kuba@kernel.org/ # cacheinfo discussion Link: https://lore.kernel.org/bpf/20211202203400.1208663-1-kuba@kernel.org
-
- Dec 02, 2021
-
-
Marek Behún authored
This reverts commit 239edf68. 239edf68 ("PCI: aardvark: Fix support for PCI_ROM_ADDRESS1 on emulated bridge") added support for the Type 1 Expansion ROM BAR at config offset 0x38, based on the register being listed in the Marvell Armada A3720 spec. But the spec doesn't document it at all for RC mode, and there is no ROM in the SOC, so remove this emulation for now. The PCI bridge which represents aardvark's PCIe Root Port has an Expansion ROM Base Address register at offset 0x30, but its meaning is different than PCI's Expansion ROM BAR register, although the layout is the same. (This is why we thought it does the same thing.) First: there is no ROM (or part of BootROM) in the A3720 SOC dedicated for PCIe Root Port (or controller in RC mode) containing executable code that would initialize the Root Port, suitable for execution in bootloader (this is how Expansion ROM BAR is used on x86). Second: in A3720 spec the register (address 0xD0070030) is not documented at all for Root Complex mode, but similar to other BAR registers, it has an "entangled partner" in register 0xD0075920, which does address translation for the BAR in 0xD0070030: - the BAR register sets the address from the view of PCIe bus - the translation register sets the address from the view of the CPU The other BAR registers also have this entangled partner, and they can be used to: - in RC mode: address-checking on the receive side of the RC (they can define address ranges for memory accesses from remote Endpoints to the RC) - in Endpoint mode: allow the remote CPU to access memory on A3720 The Expansion ROM BAR has only the Endpoint part documented, but from the similarities we think that it can also be used in RC mode in that way. So either Expansion ROM BAR has different meaning (if the hypothesis above is true), or we don't know it's meaning (since it is not documented for RC mode). Remove the register from the emulated bridge accessing functions. [bhelgaas: summarize reason for removal (first paragraph)] Fixes: 239edf68 ("PCI: aardvark: Fix support for PCI_ROM_ADDRESS1 on emulated bridge") Link: https://lore.kernel.org/r/20211125160148.26029-3-kabel@kernel.org Signed-off-by:
Marek Behún <kabel@kernel.org> Signed-off-by:
-
- Nov 11, 2021
-
-
Bjorn Helgaas authored
This reverts commit 2a4d9408. Robert reported a NULL pointer dereference caused by the PCI core (local_pci_probe()) calling the i2c_designware_pci driver's .runtime_resume() method before the .probe() method. i2c_dw_pci_resume() depends on initialization done by i2c_dw_pci_probe(). Prior to 2a4d9408 ("PCI: Use to_pci_driver() instead of pci_dev->driver"), pci_pm_runtime_resume() avoided calling the .runtime_resume() method because pci_dev->driver had not been set yet. 2a4d9408 and b5f9c644 ("PCI: Remove struct pci_dev->driver"), removed pci_dev->driver, replacing it by device->driver, which *has* been set by this time, so pci_pm_runtime_resume() called the .runtime_resume() method when it previously had not. Fixes: 2a4d9408 ("PCI: Use to_pci_driver() instead of pci_dev->driver") Link: https://lore.kernel.org/linux-i2c/CAP145pgdrdiMAT7=-iB1DMgA7t_bMqTcJL4N0=6u8kNY3EU0dw@mail.gmail.com/ Reported-by:
Robert Święcki <robert@swiecki.net> Tested-by:
-
Bjorn Helgaas authored
This reverts commit b5f9c644. Revert b5f9c644 ("PCI: Remove struct pci_dev->driver"), which is needed to revert 2a4d9408 ("PCI: Use to_pci_driver() instead of pci_dev->driver"). 2a4d9408 caused a NULL pointer dereference reported by Robert Święcki. Details in the revert of that commit. Fixes: 2a4d9408 ("PCI: Use to_pci_driver() instead of pci_dev->driver") Link: https://lore.kernel.org/linux-i2c/CAP145pgdrdiMAT7=-iB1DMgA7t_bMqTcJL4N0=6u8kNY3EU0dw@mail.gmail.com/ Reported-by:
-
Thomas Gleixner authored
free_msi_irqs() frees the MSI entries before destroying the sysfs entries which are exposing them. Nothing prevents a concurrent free while a sysfs file is read and accesses the possibly freed entry. Move the sysfs release ahead of freeing the entries. Fixes: 1c51b50c ("PCI/MSI: Export MSI mode using attributes, not kobjects") Signed-off-by:
-
Marc Zyngier authored
The ION AHCI device pretends that MSI masking isn't a thing, while it actually implements it and needs MSIs to be unmasked to work. Add a quirk to that effect. Reported-by:
Rui Salvaterra <rsalvaterra@gmail.com> Signed-off-by:
-
Marc Zyngier authored
It appears that some devices are lying about their mask capability, pretending that they don't have it, while they actually do. The net result is that now that we don't enable MSIs on such endpoint. Add a new per-device flag to deal with this. Further patches will make use of it, sadly. Signed-off-by:
-
Thomas Gleixner authored
The recent rework of PCI/MSI[X] masking moved the non-mask checks from the low level accessors into the higher level mask/unmask functions. This missed the fact that these accessors can be invoked from other places as well. The missing checks break XEN-PV which sets pci_msi_ignore_mask and also violates the virtual MSIX and the msi_attrib.maskbit protections. Instead of sprinkling checks all over the place, lift them back into the low level accessor functions. To avoid checking three different conditions combine them into one property of msi_desc::msi_attrib. [ josef: Fixed the missed conversion in the core code ] Fixes: fcacdfbe ("PCI/MSI: Provide a new set of mask and unmask functions") Reported-by:
Josef Johansson <josef@oderland.se> Signed-off-by:
-
- Nov 09, 2021
-
-
Florian Fainelli authored
BMIPS_GENERIC denotes support for the MIPS-based Broadcom STB platforms which this driver can support. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de>
-
- Nov 08, 2021
-
-
Niklas Schnelle authored
Commit e3a9b121 ("PCI: Export pci_dev_trylock() and pci_dev_unlock()") already exported pci_dev_trylock()/pci_dev_unlock() however in some circumstances such as during error recovery it makes sense to block waiting to get full access to the device so also export pci_dev_lock(). Link: https://lore.kernel.org/all/20210928181014.GA713179@bhelgaas/ Acked-by:
Pierre Morel <pmorel@linux.ibm.com> Acked-by:
Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by:
Vasily Gorbik <gor@linux.ibm.com>
-
Niklas Schnelle authored
This is done by adding a zpci_hot_reset_device() call which does a low level reset of the PCI function without changing its higher level function state. This way it can be used while the zPCI function is bound to a driver and with DMA tables being controlled either through the IOMMU or DMA APIs which is prohibited when using zpci_disable_device() as that drop existing DMA translations. As this reset, unlike a normal FLR, also calls zpci_clear_irq() we need to implement arch_restore_msi_irqs() and make sure we re-enable IRQs for the PCI function if they were previously disabled. Reviewed-by:
Matthew Rosato <mjrosato@linux.ibm.com> Signed-off-by:
-
- Nov 05, 2021
-
-
Nathan Rossi authored
The Pericom PI7C9X2G404/PI7C9X2G304/PI7C9X2G303 PCIe switches have an erratum for ACS P2P Request Redirect behaviour when used in the cut-through forwarding mode. The recommended work around for this issue is to use the switch in store and forward mode. The erratum results in packets being queued and not being delivered upstream, which can be observed as very poor downstream device performance and/or dropped device-generated data/interrupts. Add a fixup so that when enabling or resuming the downstream port we check if it has enabled ACS P2P Request Redirect, and if so, change the device (via the upstream port) to use the store and forward operating mode. Link: https://bugzilla.kernel.org/show_bug.cgi?id=177471 Link: https://lore.kernel.org/r/20210910025823.196508-1-nathan@nathanrossi.com Tested-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
Nathan Rossi <nathan.rossi@digi.com> Signed-off-by:
-
- Nov 04, 2021
-
-
Marc Zyngier authored
The Apple PCIe controller doesn't directly feed the endpoint's Requester ID to the IOMMU (DART), but instead maps RIDs onto Stream IDs (SIDs). The DART and the PCIe controller must thus agree on the SIDs that are used for translation (by using the 'iommu-map' property). For this purpose, parse the 'iommu-map' property each time a device gets added, and use the resulting translation to configure the PCIe RID-to-SID mapper. Similarly, remove the translation if/when the device gets removed. This is all driven from a bus notifier which gets registered at probe time. Hopefully this is the only PCI controller driver in the whole system. [bhelgaas: squash indentation from Zhaoyu Liu <zackary.liu.pro@gmail.com>: https://lore.kernel.org/r/20211031135544.GA1616@pc] Link: https://lore.kernel.org/r/20210929163847.2807812-10-maz@kernel.org Tested-by:
Alyssa Rosenzweig <alyssa@rosenzweig.io> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
Sven Peter <sven@svenpeter.dev>
-
Marc Zyngier authored
The MSI doorbell on Apple HW can be any address in the low 4GB range. However, the MSI write is matched by the PCIe block before hitting the iommu. It must thus be excluded from the IOVA range that is assigned to any PCIe device. Link: https://lore.kernel.org/r/20210929163847.2807812-9-maz@kernel.org Tested-by:
-
Marc Zyngier authored
Probe for the 'msi-ranges' property, and implement the MSI support in the form of the usual two-level hierarchy. Note that contrary to the wired interrupts, MSIs are shared among all the ports. Link: https://lore.kernel.org/r/20210929163847.2807812-8-maz@kernel.org Tested-by:
-
Marc Zyngier authored
Add support for the per-port interrupt controller that deals with both INTx signalling and management interrupts. This allows the Link-up/Link-down interrupts to be wired, allowing the bring-up to be synchronised (and provide debug information). The framework can further be used to handle the rest of the per port events if and when necessary. Likewise, INTx signalling is implemented so that end-points can actually be used. Link: https://lore.kernel.org/r/20210929163847.2807812-7-maz@kernel.org Link: https://lore.kernel.org/r/20211004150552.3844830-1-maz@kernel.org Tested-by:
-
Mauro Carvalho Chehab authored
Now that everything is in place at the poweroff sequence, this driver can use module_platform_driver(), which allows it to be removed. Link: https://lore.kernel.org/r/53b40494252444a9b830827922c4e3a301b8f863.1634812676.git.mchehab+huawei@kernel.org Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
Xiaowei Song <songxiaowei@hisilicon.com>
-
Mauro Carvalho Chehab authored
The logic under .remove ops is missing a call to dw_pcie_host_deinit(). Add it, in order to allow the DWC core to be properly cleaned up. Link: https://lore.kernel.org/r/838621e1c84ebaac153ccd9c36ea5e1254c61ead.1634812676.git.mchehab+huawei@kernel.org Signed-off-by:
-
Mauro Carvalho Chehab authored
The logic at kirin_pcie_gpio_request() enables some clkreq GPIO lines. Disable them during power-off. Link: https://lore.kernel.org/r/f403e590843de1a581cade2d534d34715706f54e.1634812676.git.mchehab+huawei@kernel.org Signed-off-by:
-
Mauro Carvalho Chehab authored
Instead of having two copies of the same logic, place the power-off logic in a separate function. No functional changes. Link: https://lore.kernel.org/r/64f6e8da3e5fff38b6c8fcb208ace46efe6555bb.1634812676.git.mchehab+huawei@kernel.org Signed-off-by:
-
Mauro Carvalho Chehab authored
In order to prepare for module unload, add a power_off method for HiKey 960. Link: https://lore.kernel.org/r/b095818b0d7fadae4cae200f481caf7a66e61fb4.1634812676.git.mchehab+huawei@kernel.org Signed-off-by:
-
Mauro Carvalho Chehab authored
There's nothing preventing this driver from being loaded as a module. Change its config from bool to tristate. Link: https://lore.kernel.org/r/b5e7cfe9df09b492750bd6db0f0c911eaae8c2d4.1634812676.git.mchehab+huawei@kernel.org Signed-off-by:
-
Mauro Carvalho Chehab authored
This driver misses the MODULE_* macros. Add them. Link: https://lore.kernel.org/r/f7a951d0c2009f5765214fc2e83e24cf41585023.1634812676.git.mchehab+huawei@kernel.org Signed-off-by:
-
Mauro Carvalho Chehab authored
Now that everything is in place, add a compatible for Kirin 970. Link: https://lore.kernel.org/r/ac8c730c0300b90d96bdaaf387d458d8949241a9.1634812676.git.mchehab+huawei@kernel.org Signed-off-by:
-
Mauro Carvalho Chehab authored
On HiKey970, there's a PEX 8606 PCI bridge on its PHY with 6 lanes. Only 4 lanes are connected: lane 0 - connected to Kirin 970 (upstream) lane 4 - M.2 slot lane 5 - mini PCIe slot lane 6 - on-board Ethernet controller Each lane has its own PERST# GPIO pin and needs a clock request. Add support to parse a DT schema containing the above data. HiKey 970 requires a little more waiting time for the PCI bridge - which is outside the SoC - to finish the PERST# reset, and then initialize the eye diagram. Increase the waiting time for the PERST# signals accordingly. [bhelgaas: squash refcount fix from Wan Jiabing <wanjiabing@vivo.com>: https://lore.kernel.org/r/20211103062518.25695-1-wanjiabing@vivo.com and drop "parent" refcount per https://lore.kernel.org/all/20211103143059.GA683503@bhelgaas/] Link: https://lore.kernel.org/r/bb391a0e0f0863b66e645048315fab1a4f63f277.1634812676.git.mchehab+huawei@kernel.org Link: https://lore.kernel.org/all/9a365cffe5af9ec5a1f79638968c3a2efa979b65.1634622716.git.mchehab+huawei@kernel.org/ Signed-off-by:
-
Alyssa Rosenzweig authoredApple's PCIe controller requires clocks to be configured in order to bring up the hardware. Add the register pokes required to do so. Adapted from Corellium's driver via Mark Kettenis's U-Boot patches. Co-developed-by:
Stan Skowronek <stan@corellium.com> Link: https://lore.kernel.org/r/20210929163847.2807812-6-maz@kernel.org Signed-off-by:
-
Alyssa Rosenzweig authored
Add a minimal driver to bring up the PCIe bus on Apple system-on-chips, particularly the Apple M1. This driver exposes the internal bus used for the USB type-A ports, Ethernet, Wi-Fi, and Bluetooth. Bringing up the radios requires additional drivers beyond what's necessary for PCIe itself. Co-developed-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Marc Zyngier authored
Just as we now allow an interrupt map to be parsed when part of an interrupt controller, there is no reason to ignore an interrupt map that would be part of a pci device node such as a root port since we already allow interrupt specifiers. Allow the matching of such property when local to the node of a PCI device, which allows the device itself to use the interrupt map for for its own purpose. Link: https://lore.kernel.org/r/20210929163847.2807812-4-maz@kernel.org Tested-by:
-
Selvin Xavier authored
Host crashes when pci_enable_atomic_ops_to_root() is called for VFs with virtual buses. The virtual buses added to SR-IOV have bus->self set to NULL and host crashes due to this. PID: 4481 TASK: ffff89c6941b0000 CPU: 53 COMMAND: "bash" ... #3 [ffff9a9481713808] oops_end at ffffffffb9025cd6 #4 [ffff9a9481713828] page_fault_oops at ffffffffb906e417 #5 [ffff9a9481713888] exc_page_fault at ffffffffb9a0ad14 #6 [ffff9a94817138b0] asm_exc_page_fault at ffffffffb9c00ace [exception RIP: pcie_capability_read_dword+28] RIP: ffffffffb952fd5c RSP: ffff9a9481713960 RFLAGS: 00010246 RAX: 0000000000000001 RBX: ffff89c6b1096000 RCX: 0000000000000000 RDX: ffff9a9481713990 RSI: 0000000000000024 RDI: 0000000000000000 RBP: 0000000000000080 R8: 0000000000000008 R9: ffff89c64341a2f8 R10: 0000000000000002 R11: 0000000000000000 R12: ffff89c648bab000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff89c648bab0c8 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffff9a9481713988] pci_enable_atomic_ops_to_root at ffffffffb95359a6 #8 [ffff9a94817139c0] bnxt_qplib_determine_atomics at ffffffffc08c1a33 [bnxt_re] #9 [ffff9a94817139d0] bnxt_re_dev_init at ffffffffc08ba2d1 [bnxt_re] Per PCIe r5.0, sec 9.3.5.10, the AtomicOp Requester Enable bit in Device Control 2 is reserved for VFs. The PF value applies to all associated VFs. Return -EINVAL if pci_enable_atomic_ops_to_root() is called for a VF. Link: https://lore.kernel.org/r/1631354585-16597-1-git-send-email-selvin.xavier@broadcom.com Fixes: 35f5ace5 ("RDMA/bnxt_re: Enable global atomic ops if platform supports") Fixes: 430a2368 ("PCI: Add pci_enable_atomic_ops_to_root()") Signed-off-by:
Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by:
Andy Gospodarek <gospo@broadcom.com>
-
Krzysztof Wilczyński authored
We already include <linux/device.h> and <linux/msi.h>, which include <asm/device.h> and <asm/msi.h>. Drop the redundant includes of <asm/device.h> and <asm/msi.h>. [bhelgaas: squash in fix from Wan Jiabing <wanjiabing@vivo.com>: https://lore.kernel.org/r/20211104063720.29375-1-wanjiabing@vivo.com] Link: https://lore.kernel.org/r/20211013003145.1107148-1-kw@linux.com Signed-off-by:
Jonathan Derrick <jonathan.derrick@linux.dev>
-
- Nov 03, 2021
-
-
Li Chen authored
When cdns_plat_pcie_probe() succeeds, return success instead of falling into the error handling code. Fixes: bd22885a ("PCI: cadence: Refactor driver to use as a core library") Link: https://lore.kernel.org/r/DM6PR19MB40271B93057D949310F0B0EDA0BF9@DM6PR19MB4027.namprd19.prod.outlook.com Signed-off-by:
Xuliang Zhang <xlzhanga@ambarella.com> Signed-off-by:
Li Chen <lchen@ambarella.com> Signed-off-by:
-
Christophe JAILLET authored
If an error occurs after a successful cdns_pcie_init_phy() call, it must be undone by a cdns_pcie_disable_phy() call, as already done above and below. Update the goto to branch at the correct place of the error handling path. Link: https://lore.kernel.org/r/db477b0cb444891a17c4bb424467667dc30d0bab.1624794264.git.christophe.jaillet@wanadoo.fr Fixes: 49e0efdc ("PCI: j721e: Add support to provide refclk to PCIe connector") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
- Nov 02, 2021
-
-
Krzysztof Wilczyński authored
Use the preferred generic header file linux/io.h that already includes the corresponding asm/io.h file. Link: https://lore.kernel.org/r/20211013003145.1107148-2-kw@linux.com Signed-off-by:
-
Mauro Carvalho Chehab authored
The PHY layer need to access APB registers too, for Kirin 970. So place them into a named regmap. Link: https://lore.kernel.org/r/daf0e4bda5a69a5ac8484e70f09351a959805c8c.1634812676.git.mchehab+huawei@kernel.org Signed-off-by:
-
Mauro Carvalho Chehab authored
The pcie-kirin driver contains both PHY and generic PCI driver. The best would be, instead, to support a PCI PHY driver, making the driver more generic. However, it is too late to remove the Kirin 960 PHY, as a change like that would make the DT schema incompatible with past versions. So, add support for an external PHY driver without removing the existing Kirin 960 PHY from it. Link: https://lore.kernel.org/r/f38361df2e9d0dc5a38ff942b631f7fef64cdc12.1634812676.git.mchehab+huawei@kernel.org Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Acked-by:
-
