Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 23 2月, 2019 1 次提交
    • L
      PCI: Fix __initdata issue with "pci=disable_acs_redir" parameter · bc5d9726
      由 Logan Gunthorpe 提交于 
      commit d2fd6e81912a665993b24dcdc1c1384a42a54f7e upstream.

The disable_acs_redir parameter stores a pointer to the string passed to
pci_setup().  However, the string passed to PCI setup is actually a
temporary copy allocated in static __initdata memory.  After init, once the
memory is freed, it is no longer valid to reference this pointer.

This bug was noticed in v5.0-rc1 after a change in commit c5eb1190074c
("PCI / PM: Allow runtime PM without callback functions") caused
pci_disable_acs_redir() to be called during shutdown which manifested
as an unable to handle kernel paging request at:

  RIP: 0010:pci_enable_acs+0x3f/0x1e0
  Call Trace:
     pci_restore_state.part.44+0x159/0x3c0
     pci_restore_standard_config+0x33/0x40
     pci_pm_runtime_resume+0x2b/0xd0
     ? pci_restore_standard_config+0x40/0x40
     __rpm_callback+0xbc/0x1b0
     rpm_callback+0x1f/0x70
     ? pci_restore_standard_config+0x40/0x40
      rpm_resume+0x4f9/0x710
     ? pci_conf1_read+0xb6/0xf0
     ? pci_conf1_write+0xb2/0xe0
     __pm_runtime_resume+0x47/0x70
     pci_device_shutdown+0x1e/0x60
     device_shutdown+0x14a/0x1f0
     kernel_restart+0xe/0x50
     __do_sys_reboot+0x1ee/0x210
     ? __fput+0x144/0x1d0
     do_writev+0x5e/0xf0
     ? do_writev+0x5e/0xf0
     do_syscall_64+0x48/0xf0
     entry_SYSCALL_64_after_hwframe+0x44/0xa9

It was also likely possible to trigger this bug when hotplugging PCI
devices.

To fix this, instead of storing a pointer, we use kstrdup() to copy the
disable_acs_redir_param to its own buffer which will never be freed.

Fixes: aaca43fd ("PCI: Add "pci=disable_acs_redir=" parameter for peer-to-peer support")
Tested-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NLogan Gunthorpe <logang@deltatee.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bc5d9726
  3. 13 2月, 2019 2 次提交
  5. 17 1月, 2019 3 次提交
  7. 13 1月, 2019 1 次提交
    • J
      PCI / PM: Allow runtime PM without callback functions · b541ebbe
      由 Jarkko Nikula 提交于 
      commit c5eb1190074cfb14c5d9cac692f1912eecf1a5e4 upstream.

a9c8088c ("i2c: i801: Don't restore config registers on runtime PM")
nullified the runtime PM suspend/resume callback pointers while keeping the
runtime PM enabled.

This caused the SMBus PCI device to stay in D0 with
/sys/devices/.../power/runtime_status showing "error" when the runtime PM
framework attempted to autosuspend the device.  This is due to PCI bus
runtime PM, which checks for driver runtime PM callbacks and returns
-ENOSYS if they are not set.

Since i2c-i801.c doesn't need to do anything device-specific for runtime
PM, Jean Delvare proposed this be fixed in the PCI core rather than adding
dummy runtime PM callback functions in the PCI drivers.

Change pci_pm_runtime_suspend()/pci_pm_runtime_resume() so they allow
changing the PCI device power state during runtime PM transitions even if
the driver supplies no runtime PM callbacks.

This fixes the runtime PM regression on i2c-i801.c.

It is not obvious why the code previously required the runtime PM
callbacks.  The test has been there since the code was introduced by
6cbf8214 ("PCI PM: Run-time callbacks for PCI bus type").

On the other hand, a similar change was done to generic runtime PM
callbacks in 05aa55dd ("PM / Runtime: Lenient generic runtime pm
callbacks").

Fixes: a9c8088c ("i2c: i801: Don't restore config registers on runtime PM")
Reported-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NJarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NJean Delvare <jdelvare@suse.de>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: stable@vger.kernel.org	# v4.18+
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b541ebbe
  9. 17 12月, 2018 1 次提交
    • T
      PCI: imx6: Fix link training status detection in link up check · 2a031cab
      由 Trent Piepho 提交于 
      [ Upstream commit 68bc10bf992180f269816ff3d22eb30383138577 ]

This bug was introduced in the interaction for two commits on either
branch of the merge commit 562df5c8 ("Merge branch
'pci/host-designware' into next").

Commit 4d107d3b ("PCI: imx6: Move link up check into
imx6_pcie_wait_for_link()"), changed imx6_pcie_wait_for_link() to poll
the link status register directly, checking for link up and not
training, and made imx6_pcie_link_up() only check the link up bit (once,
not a polling loop).

While commit 886bc5ce ("PCI: designware: Add generic
dw_pcie_wait_for_link()"), replaced the loop in
imx6_pcie_wait_for_link() with a call to a new dwc core function, which
polled imx6_pcie_link_up(), which still checked both link up and not
training in a loop.

When these two commits were merged, the version of
imx6_pcie_wait_for_link() from 886bc5ce was kept, which eliminated
the link training check placed there by 4d107d3b. However, the
version of imx6_pcie_link_up() from 4d107d3b was kept, which
eliminated the link training check that had been there and was moved to
imx6_pcie_wait_for_link().

The result was the link training check got lost for the imx6 driver.

Eliminate imx6_pcie_link_up() so that the default handler,
dw_pcie_link_up(), is used instead. The default handler has the correct
code, which checks for link up and also that it still is not training,
fixing the regression.

Fixes: 562df5c8 ("Merge branch 'pci/host-designware' into next")
Signed-off-by: NTrent Piepho <tpiepho@impinj.com>
[lorenzo.pieralisi@arm.com: rewrote the commit log]
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NLucas Stach <l.stach@pengutronix.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Joao Pinto <Joao.Pinto@synopsys.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Richard Zhu <hongxing.zhu@nxp.com>
Signed-off-by: NSasha Levin <sashal@kernel.org>
      2a031cab
  11. 06 12月, 2018 3 次提交
  13. 14 11月, 2018 8 次提交
  15. 06 10月, 2018 1 次提交
    • K
      treewide: Replace more open-coded allocation size multiplications · 329e0989
      由 Kees Cook 提交于 
      As done treewide earlier, this catches several more open-coded
allocation size calculations that were added to the kernel during the
merge window. This performs the following mechanical transformations
using Coccinelle:

	kvmalloc(a * b, ...) -> kvmalloc_array(a, b, ...)
	kvzalloc(a * b, ...) -> kvcalloc(a, b, ...)
	devm_kzalloc(..., a * b, ...) -> devm_kcalloc(..., a, b, ...)
Signed-off-by: NKees Cook <keescook@chromium.org>
      329e0989
  17. 02 10月, 2018 1 次提交
  19. 28 9月, 2018 1 次提交
    • D
      PCI: Reprogram bridge prefetch registers on resume · 08387454
      由 Daniel Drake 提交于 
      On 38+ Intel-based ASUS products, the NVIDIA GPU becomes unusable after S3
suspend/resume.  The affected products include multiple generations of
NVIDIA GPUs and Intel SoCs.  After resume, nouveau logs many errors such
as:

  fifo: fault 00 [READ] at 0000005555555000 engine 00 [GR] client 04
        [HUB/FE] reason 4a [] on channel -1 [007fa91000 unknown]
  DRM: failed to idle channel 0 [DRM]

Similarly, the NVIDIA proprietary driver also fails after resume (black
screen, 100% CPU usage in Xorg process).  We shipped a sample to NVIDIA for
diagnosis, and their response indicated that it's a problem with the parent
PCI bridge (on the Intel SoC), not the GPU.

Runtime suspend/resume works fine, only S3 suspend is affected.

We found a workaround: on resume, rewrite the Intel PCI bridge
'Prefetchable Base Upper 32 Bits' register (PCI_PREF_BASE_UPPER32).  In the
cases that I checked, this register has value 0 and we just have to rewrite
that value.

Linux already saves and restores PCI config space during suspend/resume,
but this register was being skipped because upon resume, it already has
value 0 (the correct, pre-suspend value).

Intel appear to have previously acknowledged this behaviour and the
requirement to rewrite this register:
https://bugzilla.kernel.org/show_bug.cgi?id=116851#c23

Based on that, rewrite the prefetch register values even when that appears
unnecessary.

We have confirmed this solution on all the affected models we have in-hands
(X542UQ, UX533FD, X530UN, V272UN).

Additionally, this solves an issue where r8169 MSI-X interrupts were broken
after S3 suspend/resume on ASUS X441UAR.  This issue was recently worked
around in commit 7bb05b85 ("r8169: don't use MSI-X on RTL8106e").  It
also fixes the same issue on RTL6186evl/8111evl on an Aimfor-tech laptop
that we had not yet patched.  I suspect it will also fix the issue that was
worked around in commit 7c53a722 ("r8169: don't use MSI-X on
RTL8168g").

Thomas Martitz reports that this change also solves an issue where the AMD
Radeon Polaris 10 GPU on the HP Zbook 14u G5 is unresponsive after S3
suspend/resume.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=201069Signed-off-by: NDaniel Drake <drake@endlessm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-By: NPeter Wu <peter@lekensteyn.nl>
CC: stable@vger.kernel.org
      08387454
  21. 27 9月, 2018 1 次提交
    • M
      ACPI / hotplug / PCI: Don't scan for non-hotplug bridges if slot is not bridge · f188b99f
      由 Mika Westerberg 提交于 
      HP 6730b laptop has an ethernet NIC connected to one of the PCIe root
ports.  The root ports themselves are native PCIe hotplug capable.  Now,
during boot after PCI devices are scanned the BIOS triggers ACPI bus check
directly to the NIC:

  ACPI: \_SB_.PCI0.RP06.NIC_: Bus check in hotplug_event()

It is not clear why it is sending bus check but regardless the ACPI hotplug
notify handler calls enable_slot() directly (instead of going through
acpiphp_check_bridge() as there is no bridge), which ends up handling
special case for non-hotplug bridges with native PCIe hotplug.  This
results a crash of some kind but the reporter only sees black screen so it
is hard to figure out the exact spot and what actually happens.  Based on
a few fix proposals it was tracked to crash somewhere inside
pci_assign_unassigned_bridge_resources().

In any case we should not really be in that special branch at all because
the ACPI notify happened to a slot that is not a PCI bridge (it is just a
regular PCI device).

Fix this so that we only go to that special branch if we are calling
enable_slot() for a bridge (e.g., the ACPI notification was for the
bridge).

Link: https://bugzilla.kernel.org/show_bug.cgi?id=201127
Fixes: 84c8b58e ("ACPI / hotplug / PCI: Don't scan bridges managed by native hotplug")
Reported-by: NPeter Anemone <peter.anemone@gmail.com>
Signed-off-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
CC: stable@vger.kernel.org	# v4.18+
      f188b99f
  23. 22 9月, 2018 1 次提交
  25. 21 9月, 2018 1 次提交
  27. 17 9月, 2018 1 次提交
    • S
      PCI: hv: support reporting serial number as slot information · a15f2c08
      由 Stephen Hemminger 提交于 
      The Hyper-V host API for PCI provides a unique "serial number" which
can be used as basis for sysfs PCI slot table. This can be useful
for cases where userspace wants to find the PCI device based on
serial number.

When an SR-IOV NIC is added, the host sends an attach message
with serial number. The kernel doesn't use the serial number, but
it is useful when doing the same thing in a userspace driver such
as the DPDK. By having /sys/bus/pci/slots/N it provides a direct
way to find the matching PCI device.

There maybe some cases where serial number is not unique such
as when using GPU's. But the PCI slot infrastructure will handle
that.

This has a side effect which may also be useful. The common udev
network device naming policy uses the slot information (rather
than PCI address).
Signed-off-by: NStephen Hemminger <sthemmin@microsoft.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a15f2c08
  29. 12 9月, 2018 3 次提交
  31. 11 9月, 2018 3 次提交
  33. 23 8月, 2018 1 次提交
  35. 17 8月, 2018 1 次提交
    • R
      PCI / ACPI / PM: Resume all bridges on suspend-to-RAM · 9d64b539
      由 Rafael J. Wysocki 提交于 
      Commit 26112ddc (PCI / ACPI / PM: Resume bridges w/o drivers on
suspend-to-RAM) attempted to fix a functional regression resulting
from commit c62ec461 (PM / core: Fix direct_complete handling
for devices with no callbacks) by resuming PCI bridges without
drivers (that is, "parallel PCI" ones) during system-wide suspend if
the target system state is not ACPI S0 (working state).

That turns out insufficient, however, as it is reported that, at
least in one case, the platform firmware gets confused if a PCIe
root port is suspended before entering the ACPI S3 sleep state.
That issue was exposed by commit 77b3729ca03 (PCI / PM: Use
SMART_SUSPEND and LEAVE_SUSPENDED flags for PCIe ports) that allowed
PCIe ports to stay in runtime suspend during system-wide suspend
(which is OK for suspend-to-idle, but turns out to be problematic
otherwise).

For this reason, drop the driver check from acpi_pci_need_resume()
and resume all bridges (including PCIe ports with drivers) during
system-wide suspend if the target system state is not ACPI S0.

[If the target system state is ACPI S0, it means suspend-to-idle
 and the platform firmware is not going to be invoked to actually
 suspend the system, so there is no need to resume the bridges in
 that case.]

Fixes: 77b3729ca03 (PCI / PM: Use SMART_SUSPEND and LEAVE_SUSPENDED flags for PCIe ports)
Link: https://bugzilla.kernel.org/show_bug.cgi?id=200675Reported-by: Nteika kazura <teika@gmx.com>
Tested-by: Nteika kazura <teika@gmx.com>
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: 4.16+ <stable@vger.kernel.org> # 4.16+: 26112ddc (PCI / ACPI / PM: Resume bridges ...)
Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9d64b539
  37. 16 8月, 2018 1 次提交
  39. 15 8月, 2018 3 次提交
    • J
      PCI: Limit config space size for Netronome NFP5000 · 2538fb89
      由 Jakub Kicinski 提交于 
      Like the NFP4000 and NFP6000, the NFP5000 as an erratum where reading/
writing to PCI config space addresses above 0x600 can cause the NFP to
generate PCIe completion timeouts.

Limit the NFP5000's PF's config space size to 0x600 bytes as is already
done for the NFP4000 and NFP6000.

The NFP5000's VF is 0x6003 (PCI_DEVICE_ID_NETRONOME_NFP6000_VF), the same
device ID as the NFP6000's VF.  Thus, its config space is already limited
by the existing use of quirk_nfp6000().
Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NTony Egan <tony.egan@netronome.com>
      2538fb89
    • H
      PCI/MSI: Set IRQCHIP_ONESHOT_SAFE for PCI-MSI irqchips · 923aa4c3
      由 Heiner Kallweit 提交于 
      If flag IRQCHIP_ONESHOT_SAFE isn't set for an irqchip and we have a
threaded interrupt with no primary handler, flag IRQF_ONESHOT needs to be
set for the interrupt, causing some overhead in the threaded interrupt
handler.  For more detailed explanation also check following comment in
__setup_irq():

  The interrupt was requested with handler = NULL, so we use the default
  primary handler for it. But it does not have the oneshot flag set.  In
  combination with level interrupts this is deadly, because the default
  primary handler just wakes the thread, then the irq lines is reenabled,
  but the device still has the level irq asserted.  Rinse and repeat....

  While this works for edge type interrupts, we play it safe and reject
  unconditionally because we can't say for sure which type this interrupt
  really has.  The type flags are unreliable as the underlying chip
  implementation can override them.

Another comment in __setup_irq() gives a hint already that this
overhead can be avoided for PCI-MSI:

  Some irq chips like MSI based interrupts are per se one shot safe.  Check
  the chip flags, so we can avoid the unmask dance at the end of the
  threaded handler for those.

Following this let's mark all PCI-MSI irqchips as oneshot-safe.

See also discussion here:
https://lkml.kernel.org/r/alpine.DEB.2.21.1808032136490.1658@nanos.tec.linutronix.deSigned-off-by: NHeiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      923aa4c3
    • B
      PCI/VPD: Check for VPD access completion before checking for timeout · 6eaf2781
      由 Bert Kenward 提交于 
      Previously we checked the timeout before checking the VPD access completion
bit.  On a very heavily loaded system this can cause VPD access to timeout.
Check the completion bit before checking the timeout.
Signed-off-by: NBert Kenward <bkenward@solarflare.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      6eaf2781
  41. 14 8月, 2018 2 次提交
    • M
      PCI: Match Root Port's MPS to endpoint's MPSS as necessary · 9f0e8935
      由 Myron Stowe 提交于 
      In commit 27d868b5 ("PCI: Set MPS to match upstream bridge"), we made
sure every device's MPS setting matches its upstream bridge, making it more
likely that a hot-added device will work in a system with an optimized MPS
configuration.

Recently I've started encountering systems where the endpoint device's MPSS
capability is less than its Root Port's current MPS value, thus the
endpoint is not capable of matching its upstream bridge's MPS setting (see:
bugzilla via "Link:" below).  This leaves the system vulnerable - the
upstream Root Port could respond with larger TLPs than the device can
handle, and the device will consider them to be 'Malformed'.

One could use the "pci=pcie_bus_safe" kernel parameter to work around the
issue, but that forces a user to supply a kernel parameter to get the
system to function reliably and may end up limiting MPS settings of other
unrelated, sub-topologies which could benefit from maintaining their larger
values.

Augment Keith's approach to include tuning down a Root Port's MPS setting
when its hot-added endpoint device is not capable of matching it.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=200527Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: NJon Mason <jdmason@kudzu.us>
Cc: Keith Busch <keith.busch@intel.com>
Cc: Sinan Kaya <okaya@kernel.org>
Cc: Dongdong Liu <liudongdong3@huawei.com>
      9f0e8935
    • M
      PCI: Skip MPS logic for Virtual Functions (VFs) · 3dbe97ef
      由 Myron Stowe 提交于 
      PCIe r4.0, sec 9.3.5.4, "Device Control Register", shows both
Max_Payload_Size (MPS) and Max_Read_request_Size (MRRS) to be 'RsvdP' for
VFs.  Just prior to the table it states:

  "PF and VF functionality is defined in Section 7.5.3.4 except where
   noted in Table 9-16.  For VF fields marked 'RsvdP', the PF setting
   applies to the VF."

All of which implies that with respect to Max_Payload_Size Supported
(MPSS), MPS, and MRRS values, we should not be paying any attention to the
VF's fields, but rather only to the PF's.  Only looking at the PF's fields
also logically makes sense as it's the sole physical interface to the PCIe
bus.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=200527
Fixes: 27d868b5 ("PCI: Set MPS to match upstream bridge")
Signed-off-by: NMyron Stowe <myron.stowe@redhat.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Cc: stable@vger.kernel.org # 4.3+
Cc: Keith Busch <keith.busch@intel.com>
Cc: Sinan Kaya <okaya@kernel.org>
Cc: Dongdong Liu <liudongdong3@huawei.com>
Cc: Jon Mason <jdmason@kudzu.us>
      3dbe97ef