- Rename the pcie-mediatek-gen3 driver from 'mtk-pcie' to 'mtk-pcie-gen3'
so it can coexist with the pcie-mediatek driver, which also uses
'mtk-pcie' (Felix Fietkau)
* remotes/lorenzo/pci/mediatek:
PCI: mediatek-gen3: Change driver name to mtk-pcie-gen3
- Use dmam_alloc_coherent() instead of dma_map_page() to allocate the MSI
target page, which means dwc drivers will work even when ZONE_DMA32 is
disabled (Will McVicker)
- If we can't allocate an MSI target page with a 32-bit address, try
allocating one with a 64-bit address (Will McVicker)
- Switch from of_gpio_named_count() to generic gpiod_count() (Andy
Shevchenko)
- Add support for i.MX8MP PCIe (Richard Zhu)
- Fix the Freescale i.MX8 PHY driver, which had interchanged the phy_init()
and phy_power_on() interfaces (Richard Zhu)
* remotes/lorenzo/pci/dwc:
phy: freescale: imx8m-pcie: Fix the wrong order of phy_init() and phy_power_on()
PCI: imx6: Add i.MX8MP PCIe support
PCI: dwc: Replace of_gpio_named_count() by gpiod_count()
PCI: dwc: Drop dependency on ZONE_DMA32
- In an emulated PCI bridge, set Capability offsets so they match the
hardware offsets shown by U-Boot (Pali Rohár)
* remotes/lorenzo/pci/bridge-emul:
PCI: pci-bridge-emul: Set position of PCI capabilities to real HW value
- Switch from gpiod_get_from_of_node() to generic devm GPIO API (Dmitry
Torokhov)
* remotes/lorenzo/pci/apple:
PCI: apple: Do not leak reset GPIO on unbind/unload/error
- Emulate the PCI Bridge Subsystem Vendor ID (Pali Rohár)
* remotes/lorenzo/pci/aardvark:
PCI: aardvark: Add support for PCI Bridge Subsystem Vendor ID on emulated bridge
- Distribute resources to unconfigured hotplug bridges at boot-time (not
just when hot-adding such a bridge), which makes hot-adding devices to
docks work (Mika Westerberg)
- Fix the "revert to firmware assignment" code so we do the revert only if
the address is actually reachable. Previously we sometimes assigned
addresses that could not be reached via upstream bridges (Maciej W.
Rozycki)
* pci/resource:
PCI: Sanitise firmware BAR assignments behind a PCI-PCI bridge
PCI: Fix typo in pci_scan_child_bus_extend()
PCI: Fix whitespace and indentation
PCI: Distribute available resources for root buses, too
PCI: Move pci_assign_unassigned_root_bus_resources()
PCI: Pass available buses even if the bridge is already configured
PCI: Fix used_buses calculation in pci_scan_child_bus_extend()
- Expose a sysfs interface for configuring Resizable BARs so we can resize
BARs before assigning devices to a VM through VFIO (Alex Williamson)
* pci/rebar:
PCI: Expose PCIe Resizable BAR support via sysfs
- Cache the PTM capability offset instead of searching for it every time
(Bjorn Helgaas)
- Separate PTM configuration from PTM enable (Bjorn Helgaas)
- Add pci_suspend_ptm() and pci_resume_ptm() to disable and re-enable PTM
on suspend/resume so some Root Ports can safely enter a lower-power PM
state (Bjorn Helgaas)
- Disable PTM for all devices during suspend; previously we only did this
for Root Ports and even then only in certain cases (Bjorn Helgaas)
- Simplify pci_pm_suspend_noirq() (Rajvi Jingar)
- Reduce the delay after transitions to/from D3hot by using usleep_range()
instead of msleep(), which reduces the typical delay from 19ms to 10ms
(Sajid Dalvi, Will McVicker)
* pci/pm:
PCI/PM: Reduce D3hot delay with usleep_range()
PCI/PM: Simplify pci_pm_suspend_noirq()
PCI/PM: Always disable PTM for all devices during suspend
PCI/PTM: Consolidate PTM interface declarations
PCI/PTM: Reorder functions in logical order
PCI/PTM: Preserve RsvdP bits in PTM Control register
PCI/PTM: Move pci_ptm_info() body into its only caller
PCI/PTM: Add pci_suspend_ptm() and pci_resume_ptm()
PCI/PTM: Separate configuration and enable
PCI/PTM: Add pci_upstream_ptm() helper
PCI/PTM: Cache PTM Capability offset
- Correct a typo in 71020a3c0d ('PCI/MSI: Use msi_add_msi_desc()') that
reversed the sense of 'can_mask' in msi_add_msi_desc() (Josef Johansson)
* pci/msi:
PCI/MSI: Correct 'can_mask' test in msi_add_msi_desc()
- Work around a BIOS defect that makes some Intel Root Ports report an RP
PIO log size of zero (Mika Westerberg)
* pci/dpc:
PCI/DPC: Quirk PIO log size for certain Intel Root Ports
- Save L1 PM Substates Capability across suspend/resume so L1SS keeps
working after resume (Vidya Sagar)
- If device lacks L1 PM Substates Capability, don't read junk and treat it
as such a Capability (Bjorn Helgaas)
- Fix the LTR_L1.2_THRESHOLD computation, which previously configured the
threshold for entering L1.2 to be lower than intended, so L1.2 could be
used when it shouldn't be (Bjorn Helgaas)
* pci/aspm:
PCI/ASPM: Correct LTR_L1.2_THRESHOLD computation
PCI/ASPM: Ignore L1 PM Substates if device lacks capability
PCI/ASPM: Factor out L1 PM Substates configuration
PCI/ASPM: Save L1 PM Substates Capability for suspend/resume
PCI/ASPM: Refactor L1 PM Substates Control Register programming
Add a simple sysfs interface to Resizable BAR support, largely for the
purposes of assigning such devices to a VM through VFIO. Resizable BARs
present a difficult feature to expose to a VM through emulation, as
resizing a BAR is done on the host. It can fail, and often does, but we
have no means via emulation of a PCIe REBAR capability to handle the error
cases.
A vfio-pci specific ioctl interface is also cumbersome as there are often
multiple devices within the same bridge aperture and handling them is a
challenge. In the interface proposed here, expanding a BAR potentially
requires such devices to be soft-removed during the resize operation and
rescanned after, in order for all the necessary resources to be released.
A pci-sysfs interface is also more universal than a vfio specific
interface.
Please see the ABI documentation update for usage.
Link: https://lore.kernel.org/r/166336088796.3597940.14973499936692558556.stgit@omen
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: Krzysztof Wilczyński <kw@linux.com>
80d7d7a904 ("PCI/ASPM: Calculate LTR_L1.2_THRESHOLD from device
characteristics") replaced a fixed value (163840ns) with one computed from
T_POWER_OFF, Common_Mode_Restore_Time, etc., but it encoded the
LTR_L1.2_THRESHOLD value incorrectly.
This is especially a problem for small thresholds, e.g., 63ns fell into the
"threshold_ns < 1024" case and was encoded as 32ns:
LTR_L1.2_THRESHOLD_Scale = 1 (multiplier is 32ns)
LTR_L1.2_THRESHOLD_Value = 63 >> 5 = 1
LTR_L1.2_THRESHOLD = multiplier * value = 32ns * 1 = 32ns
Correct the algorithm to encode all times of 1023ns (0x3ff) or smaller
exactly and larger times conservatively (the encoded threshold is never
smaller than was requested). This reduces the chance of entering L1.2
when the device can't tolerate the exit latency.
Fixes: 80d7d7a904 ("PCI/ASPM: Calculate LTR_L1.2_THRESHOLD from device characteristics")
Link: https://lore.kernel.org/r/20221005025809.2247547-4-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
187f91db82 ("PCI/ASPM: Remove struct aspm_register_info.l1ss_cap")
inadvertently removed a check for existence of the L1 PM Substates (L1SS)
Capability before reading it.
If there is no L1SS Capability, this means we mistakenly read PCI_COMMAND
and PCI_STATUS (config address 0x04) and interpret that as the PCI_L1SS_CAP
register, so we may incorrectly configure L1SS.
Make sure the L1SS Capability exists before trying to read it.
Fixes: 187f91db82 ("PCI/ASPM: Remove struct aspm_register_info.l1ss_cap")
Link: https://lore.kernel.org/r/20221005025809.2247547-3-helgaas@kernel.org
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Previously the L1 PM Substates Control Registers (CTL1 and CTL2) weren't
saved and restored during suspend/resume leading to the L1 PM Substates
configuration being lost post-resume.
Save the L1 PM Substates Control Registers so that the configuration is
retained post-resume.
[bhelgaas: drop pci_is_pcie() testing; we can rely on pci_configure_ltr()
having already done that]
Link: https://lore.kernel.org/r/20220913131822.16557-3-vidyas@nvidia.com
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
PCIe r6.0, sec 5.9, requires a 10ms delay between programming a device to
change to or from D3hot and the time the device is next accessed (unless
Readiness Notifications are used).
The 10ms value (PCI_PM_D3HOT_WAIT) doesn't appear directly here because
some chipsets require 120ms for devices *below* them (pci_pm_d3hot_delay)
and some devices require more or less than 10ms (dev->d3hot_delay).
But msleep(10) typically waits about *20*ms, which is more than we need.
Switch to usleep_range() to improve the delay accuracy.
Based on a commit from Sajid in the Pixel 6 kernel tree [1]. On a Pixel 6,
the 10ms delay for the Exynos PCIe device delayed for an average of 19ms.
Switching to usleep_range() decreased the resume time by about 9ms.
[1] 18a8cad68d
[bhelgaas commit log, add timers-howto.rst link]
Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/timers/timers-howto.rst?id=v5.19#n73
Link: https://lore.kernel.org/r/20220921212735.2131588-1-willmcvicker@google.com
Signed-off-by: Sajid Dalvi <sdalvi@google.com>
Signed-off-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
When pci_assign_resource() is unable to assign resources to a BAR, it uses
pci_revert_fw_address() to fall back to a firmware assignment (if any).
Previously pci_revert_fw_address() assumed all addresses could reach the
device, but this is not true if the device is below a bridge that only
forwards addresses within its windows.
This problem was observed on a Tyan Tomcat IV S1564D system where the BIOS
did not assign valid addresses to several bridges and USB devices:
pci 0000:00:11.0: PCI-to-PCIe bridge to [bus 01-ff]
pci 0000:00:11.0: bridge window [io 0xe000-0xefff]
pci 0000:01:00.0: PCIe Upstream Port to [bus 02-ff]
pci 0000:01:00.0: bridge window [io 0x0000-0x0fff] # unreachable
pci 0000:02:02.0: PCIe Downstream Port to [bus 05-ff]
pci 0000:02:02.0: bridge window [io 0x0000-0x0fff] # unreachable
pci 0000:05:00.0: PCIe-to-PCI bridge to [bus 06-ff]
pci 0000:05:00.0: bridge window [io 0x0000-0x0fff] # unreachable
pci 0000:06:08.0: USB UHCI 1.1
pci 0000:06:08.0: BAR 4: [io 0xfce0-0xfcff] # unreachable
pci 0000:06:08.1: USB UHCI 1.1
pci 0000:06:08.1: BAR 4: [io 0xfce0-0xfcff] # unreachable
pci 0000:06:08.0: can't claim BAR 4 [io 0xfce0-0xfcff]: no compatible bridge window
pci 0000:06:08.1: can't claim BAR 4 [io 0xfce0-0xfcff]: no compatible bridge window
During the first pass of assigning unassigned resources, there was not
enough I/O space available, so we couldn't assign the 06:08.0 BAR and
reverted to the firmware assignment (still unreachable). Reverting the
06:08.1 assignment failed because it conflicted with 06:08.0:
pci 0000:00:11.0: bridge window [io 0xe000-0xefff]
pci 0000:01:00.0: no space for bridge window [io size 0x2000]
pci 0000:02:02.0: no space for bridge window [io size 0x1000]
pci 0000:05:00.0: no space for bridge window [io size 0x1000]
pci 0000:06:08.0: BAR 4: no space for [io size 0x0020]
pci 0000:06:08.0: BAR 4: trying firmware assignment [io 0xfce0-0xfcff]
pci 0000:06:08.1: BAR 4: no space for [io size 0x0020]
pci 0000:06:08.1: BAR 4: trying firmware assignment [io 0xfce0-0xfcff]
pci 0000:06:08.1: BAR 4: [io 0xfce0-0xfcff] conflicts with 0000:06:08.0 [io 0xfce0-0xfcff]
A subsequent pass assigned valid bridge windows and a valid 06:08.1 BAR,
but left the 06:08.0 BAR alone, so the UHCI device was still unusable:
pci 0000:00:11.0: bridge window [io 0xe000-0xefff] released
pci 0000:00:11.0: bridge window [io 0x1000-0x2fff] # reassigned
pci 0000:01:00.0: bridge window [io 0x1000-0x2fff] # reassigned
pci 0000:02:02.0: bridge window [io 0x2000-0x2fff] # reassigned
pci 0000:05:00.0: bridge window [io 0x2000-0x2fff] # reassigned
pci 0000:06:08.0: BAR 4: assigned [io 0xfce0-0xfcff] # left alone
pci 0000:06:08.1: BAR 4: assigned [io 0x2000-0x201f]
...
uhci_hcd 0000:06:08.0: host system error, PCI problems?
uhci_hcd 0000:06:08.0: host controller process error, something bad happened!
uhci_hcd 0000:06:08.0: host controller halted, very bad!
uhci_hcd 0000:06:08.0: HCRESET not completed yet!
uhci_hcd 0000:06:08.0: HC died; cleaning up
If the address assigned by firmware is not reachable because it's not
within upstream bridge windows, fail instead of assigning the unusable
address from firmware.
[bhelgaas: commit log, use pci_upstream_bridge()]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=16263
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2203012338460.46819@angie.orcam.me.uk
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2209211921250.29493@angie.orcam.me.uk
Fixes: 58c84eda07 ("PCI: fall back to original BIOS BAR addresses")
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org # v2.6.35+
Register with Subsystem Device/Vendor ID is at offset 0x2c.
Export it via the emulated bridge to enable support for the Subsystem
Device/Vendor ID - by reading it in the PCI controller config space and
storing it in the emulated bridge control structures, so that it is
exposed in the respective PCI capability.
After this change Subsystem ID is visible in lspci output at line:
Capabilities: [40] Subsystem
Link: https://lore.kernel.org/r/20220711225915.13896-1-pali@kernel.org
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
The driver allocates reset GPIO in apple_pcie_setup_port() but neither
releases the resource, nor uses devm API to have it released
automatically.
Let's fix this by switching to devm API. While at it let's use generic
devm_fwnode_gpiod_get() instead of OF-specific gpiod_get_from_of_node()
- this will allow us top stop exporting the latter down the road.
Link: https://lore.kernel.org/r/YxatO5OaI2RpxQ2M@google.com
Fixes: 1e33888fbe ("PCI: apple: Add initial hardware bring-up")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: Hector Martin <marcan@marcan.st>
Acked-by: Marc Zyngier <maz@kernel.org>
We want to disable PTM on Root Ports because that allows some chips, e.g.,
Intel mobile chips since Coffee Lake, to enter a lower-power PM state.
That means we also have to disable PTM on downstream devices. PCIe r6.0,
sec 2.2.8, recommends that functions support generation of messages in
non-D0 states, so we have to assume Switch Upstream Ports or Endpoints may
send PTM Requests while in D1, D2, and D3hot. A PTM message received by a
Downstream Port (including a Root Port) with PTM disabled must be treated
as an Unsupported Request (sec 6.21.3).
PTM was previously disabled only for Root Ports, and it was disabled in
pci_prepare_to_sleep(), which is not called at all if a driver supports
legacy PM or does its own state saving.
Instead, disable PTM early in pci_pm_suspend() and pci_pm_runtime_suspend()
so we do it in all cases.
Previously PTM was disabled *after* saving device state, so the state
restore on resume automatically re-enabled it. Since we now disable PTM
*before* saving state, we must explicitly re-enable it in pci_pm_resume()
and pci_pm_runtime_resume().
Here's a sample of errors that occur when PTM is disabled only on the Root
Port. With this topology:
0000:00:1d.0 Root Port to [bus 08-71]
0000:08:00.0 Switch Upstream Port to [bus 09-71]
Kai-Heng reported errors like this:
pcieport 0000:00:1d.0: [20] UnsupReq (First)
pcieport 0000:00:1d.0: AER: TLP Header: 34000000 08000052 00000000 00000000
Decoding TLP header 0x34...... (0011 0100b) and 0x08000052:
Fmt 001b 4 DW header, no data
Type 1 0100b Msg (Local - Terminate at Receiver)
Requester ID 0x0800 Bus 08 Devfn 00.0
Message Code 0x52 0101 0010b PTM Request
The 00:1d.0 Root Port logged an Unsupported Request error when it received
a PTM Request with Requester ID 08:00.0.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=215453
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216210
Fixes: a697f072f5 ("PCI: Disable PTM during suspend to save power")
Link: https://lore.kernel.org/r/20220909202505.314195-10-helgaas@kernel.org
Reported-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Tested-by: Rajvi Jingar <rajvi.jingar@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
We disable PTM during suspend because that allows some Root Ports to enter
lower-power PM states, which means we also need to disable PTM for all
downstream devices. Add pci_suspend_ptm() and pci_resume_ptm() for this
purpose.
pci_enable_ptm() and pci_disable_ptm() are for drivers to use to enable or
disable PTM. They use dev->ptm_enabled to keep track of whether PTM should
be enabled.
pci_suspend_ptm() and pci_resume_ptm() are PCI core-internal functions to
temporarily disable PTM during suspend and (depending on dev->ptm_enabled)
re-enable PTM during resume.
Enable/disable/suspend/resume all use internal __pci_enable_ptm() and
__pci_disable_ptm() functions that only update the PTM Control register.
Outline:
pci_enable_ptm(struct pci_dev *dev)
{
__pci_enable_ptm(dev);
dev->ptm_enabled = 1;
pci_ptm_info(dev);
}
pci_disable_ptm(struct pci_dev *dev)
{
if (dev->ptm_enabled) {
__pci_disable_ptm(dev);
dev->ptm_enabled = 0;
}
}
pci_suspend_ptm(struct pci_dev *dev)
{
if (dev->ptm_enabled)
__pci_disable_ptm(dev);
}
pci_resume_ptm(struct pci_dev *dev)
{
if (dev->ptm_enabled)
__pci_enable_ptm(dev);
}
Nothing currently calls pci_resume_ptm(); the suspend path saves the PTM
state before disabling PTM, so the PTM state restore in the resume path
implicitly re-enables it. A future change will use pci_resume_ptm() to fix
some problems with this approach.
Link: https://lore.kernel.org/r/20220909202505.314195-5-helgaas@kernel.org
Tested-by: Rajvi Jingar <rajvi.jingar@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
PTM configuration and enabling were previously mixed together:
pci_ptm_init() collected granularity info and enabled PTM for Root Ports
and Switch Upstream Ports; pci_enable_ptm() did the same for Endpoints.
Move everything related to the PTM Capability register to pci_ptm_init()
for all devices, and everything related to the PTM Control register to
pci_enable_ptm().
Link: https://lore.kernel.org/r/20220909202505.314195-4-helgaas@kernel.org
Tested-by: Rajvi Jingar <rajvi.jingar@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
PTM requires an unbroken path of PTM-supporting devices between the PTM
Root and the ultimate PTM Requester, but if a Switch supports PTM, only the
Upstream Port can have a PTM Capability; the Downstream Ports do not.
Previously we copied the PTM configuration from the Switch Upstream Port to
the Downstream Ports so dev->ptm_enabled for any device implied that all
the upstream devices support PTM.
Instead of making it look like Downstream Ports have their own PTM config,
add pci_upstream_ptm(), which returns the upstream device that has a PTM
Capability (either a Root Port or a Switch Upstream Port).
Link: https://lore.kernel.org/r/20220909202505.314195-3-helgaas@kernel.org
Tested-by: Rajvi Jingar <rajvi.jingar@linux.intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Re-work the msi_msg DMA allocation logic to use dmam_alloc_coherent() which
uses the coherent DMA mask to try to return an allocation within the DMA
mask limits. With that, we now can drop the msi_page parameter in struct
dw_pcie_rp. This allows kernel configurations that disable ZONE_DMA32 to
continue supporting a 32-bit DMA mask. Without this patch, the PCIe host
device will fail to probe when ZONE_DMA32 is disabled.
Link: https://lore.kernel.org/r/20220825235404.4132818-2-willmcvicker@google.com
Fixes: 35797e672f ("PCI: dwc: Fix MSI msi_msg DMA mapping")
Reported-by: Isaac J. Manjarres <isaacmanjarres@google.com>
Signed-off-by: Will McVicker <willmcvicker@google.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Jingoo Han <jingoohan1@gmail.com>
71020a3c0d ("PCI/MSI: Use msi_add_msi_desc()") inadvertently reversed
the sense of "msi_attrib.can_mask" in one use:
- if (entry->pci.msi_attrib.can_mask) {
- addr = pci_msix_desc_addr(entry);
- entry->pci.msix_ctrl = readl(addr + PCI_MSIX_ENTRY_VECTOR_CTRL);
+ if (!desc.pci.msi_attrib.can_mask) {
+ addr = pci_msix_desc_addr(&desc);
+ desc.pci.msix_ctrl = readl(addr + PCI_MSIX_ENTRY_VECTOR_CTRL);
Restore the original test.
[bhelgaas: commit log]
Fixes: 71020a3c0d ("PCI/MSI: Use msi_add_msi_desc()")
Link: https://lore.kernel.org/r/d818f9c9-a432-213e-4152-eaff3b7da52e@oderland.se
Signed-off-by: Josef Johansson <josef@oderland.se>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
mvebu and aardvark HW have PCIe capabilities on different offset in PCI
config space. Extend pci-bridge-emul.c code to allow setting custom driver
custom value where PCIe capabilities starts.
With this change PCIe capabilities of both drivers are reported at the same
location as where they are reported by U-Boot - in their real HW offset.
Link: https://lore.kernel.org/r/20220824112124.21675-1-pali@kernel.org
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Recent versions of dt-schema warn about unevaluatedProperties:
arch/riscv/boot/dts/microchip/mpfs-icicle-kit.dtb: pcie@2000000000: Unevaluated properties are not allowed ('clock-names', 'clocks', 'legacy-interrupt-controller', 'microchip,axi-m-atr0' were unexpected)
From schema: Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml
The clocks are required to enable interfaces between the FPGA fabric
and the core complex, so add them to the binding.
Link: https://lore.kernel.org/r/20220819231415.3860210-3-mail@conchuod.ie
Fixes: 6ee6c89aac ("dt-bindings: PCI: microchip: Add Microchip PolarFire host binding")
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
The commit b92225b034 ("dt-bindings: PCI: designware: Fix
'unevaluatedProperties' warnings") removed the clock-names property as
a requirement and from the example as it triggered unevaluatedProperty
warnings. dtbs_check was not able to pick up on this at the time, but
now can:
arch/riscv/boot/dts/sifive/hifive-unmatched-a00.dtb: pcie@e00000000: Unevaluated properties are not allowed ('clock-names' was unexpected)
From schema: linux/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml
The property was already in use by the FU740 DTS and the clock must be
enabled. The Linux and FreeBSD drivers require the property to enable
the clocks correctly Re-add the property and its "clocks" dependency,
while making it required.
Link: https://lore.kernel.org/r/20220819231415.3860210-2-mail@conchuod.ie
Fixes: b92225b034 ("dt-bindings: PCI: designware: Fix 'unevaluatedProperties' warnings")
Fixes: 43cea116be ("dt-bindings: PCI: Add SiFive FU740 PCIe host controller")
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
