Skip to content

cloud-kernel
cloud-kernel

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

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 26 5月, 2019 2 次提交
  3. 17 4月, 2019 1 次提交
  5. 14 11月, 2018 1 次提交
  7. 11 9月, 2018 1 次提交
  9. 23 8月, 2018 1 次提交
  11. 15 8月, 2018 1 次提交
  13. 14 8月, 2018 1 次提交
  15. 10 8月, 2018 5 次提交
  17. 13 7月, 2018 3 次提交
    • R
      PCI: iproc: Activate PAXC bridge quirk for more devices · b95e2cd0
      由 Ray Jui 提交于 
      Activate PAXC bridge quirk for more PAXC based PCIe root complex with
the following PCIe device ID:
0xd750, 0xd802, 0xd804
Signed-off-by: NRay Jui <ray.jui@broadcom.com>
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: NOza Pawandeep <poza@codeaurora.org>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
      b95e2cd0
    • G
      PCI: Mark fall-through switch cases before enabling -Wimplicit-fallthrough · d6488ac1
      由 Gustavo A. R. Silva 提交于 
      In preparation to enabling -Wimplicit-fallthrough, mark switch cases where
we are expecting to fall through.

Warning level 2 was used: -Wimplicit-fallthrough=2
Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      d6488ac1
    • J
      PCI: Workaround IDT switch ACS Source Validation erratum · aa667c64
      由 James Puthukattukaran 提交于 
      Some IDT switches incorrectly flag an ACS Source Validation error on
completions for config read requests even though PCIe r4.0, sec 6.12.1.1,
says that completions are never affected by ACS Source Validation.  Here's
the text of IDT 89H32H8G3-YC, erratum #36:

  Item #36 - Downstream port applies ACS Source Validation to Completions
  Section 6.12.1.1 of the PCI Express Base Specification 3.1 states that
  completions are never affected by ACS Source Validation.  However,
  completions received by a downstream port of the PCIe switch from a
  device that has not yet captured a PCIe bus number are incorrectly
  dropped by ACS Source Validation by the switch downstream port.

  Workaround: Issue a CfgWr1 to the downstream device before issuing the
  first CfgRd1 to the device.  This allows the downstream device to capture
  its bus number; ACS Source Validation no longer stops completions from
  being forwarded by the downstream port.  It has been observed that
  Microsoft Windows implements this workaround already; however, some
  versions of Linux and other operating systems may not.

When doing the first config read to probe for a device, if the device is
behind an IDT switch with this erratum:

  1. Disable ACS Source Validation if enabled
  2. Wait for device to become ready to accept config accesses (by using
     the Config Request Retry Status mechanism)
  3. Do a config write to the endpoint
  4. Enable ACS Source Validation (if it was enabled to begin with)

The workaround suggested by IDT is basically only step 3, but we don't know
when the device is ready to accept config requests.  That means we need to
do config reads until we receive a non-Config Request Retry Status, which
means we need to disable ACS SV temporarily.
Signed-off-by: NJames Puthukattukaran <james.puthukattukaran@oracle.com>
[bhelgaas: changelog, clean up whitespace, fold in unused variable fix
from Anders Roxell <anders.roxell@linaro.org>]
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NAlex Williamson <alex.williamson@redhat.com>
      aa667c64
  19. 30 6月, 2018 1 次提交
    • D
      PCI: Add DMA alias quirk for Microsemi Switchtec NTB · ad281ecf
      由 Doug Meyer 提交于 
      Add a quirk for the Microsemi Switchtec parts to allow DMA access via
non-transparent bridging to work when the IOMMU is turned on.

This exclusively addresses the ability of a remote NT endpoint to perform
DMA accesses through the locally enumerated NT endpoint.  Other aspects of
the Switchtec NTB functionality, such as interrupts for doorbells and
messages are independent of this quirk, and will work whether the IOMMU is
on or off.

When a requestor on one NT endpoint accesses memory on another NT endpoint,
it does this via a devfn proxy ID.  Proxy IDs are statically assigned to
each NT endpoint by the NTB hardware as part of the release-from-reset
sequence prior to PCI enumeration.  These proxy IDs cannot be modified
dynamically, and are not visible to the host during enumeration.

When the Switchtec NTB driver loads it will map local requestor IDs, such
as the root complex and transparent bridge DMA engines, to proxy IDs by
populating those requestor IDs in hardware mapping table table entries.
This establishes a fixed relationship between a requestor ID and a proxy
ID.

When a peer on a remote NT endpoint performs an access within a particular
translation window in it's NT endpoint BAR address space, that access is
translated to a DMA request on the local endpoint's bus.  As part of the
translation process, the original requestor ID has its devfn replaced with
the proxy ID, and the bus portion of the BDF is replaced with the bus of
the local NT endpoint.  Thus, the DMA access from a remote NT endpoint will
appear on the local bus to have come from the unknown devfn which the IOMMU
will reject.

Interrogate NTB hardware registers for each remote NT endpoint to obtain
the proxy IDs that have been assigned to it and alias them to the local
(enumerated) NT endpoint's device.  The IOMMU then accepts the remote proxy
IDs as if they were requests coming directly from the enumerated endpoint,
giving remote requestors access to memory resources which the local host
has made available.

Note that the aliasing of the proxy IDs cannot be performed at the driver
level given the current IOMMU architecture.  Superficially this is because
pci_add_dma_alias() symbol is not exported.  Functionally, the current
IOMMU design requires the aliasing to be performed prior to the creation of
IOMMU groups.  If a driver were to attempt to use pci_add_dma_alias() in
its probe routine it would fail since the IOMMU groups have been set up by
that time.  If the Switchtec hardware supported dynamic proxy ID
(re-)assignment this would be an issue, but it does not.

To further clarify static proxy ID assignment: While the requester ID to
proxy ID mapping can be dynamically changed, the number and value of proxy
IDs given to an NT EP cannot, even for dynamic reconfiguration such as
hot-add.  Therefore, the chip configuration must account a priori for the
proxy IDs needs, considering both static and dynamic system configurations.
For example, a port on the chip may not having anything plugged into it at
start of day; but it must have a sufficient number of proxy IDs assigned to
accommodate the supported devices which may be hot-added.

Switchtec NTB functionality with the IOMMU off is unchanged by this quirk.
Signed-off-by: NDoug Meyer <dmeyer@gigaio.com>
[bhelgaas: use hard-coded Device IDs instead of adding #defines for each]
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NLogan Gunthorpe <logang@deltatee.com>
      ad281ecf
  21. 11 5月, 2018 2 次提交
  23. 08 5月, 2018 1 次提交
  25. 28 4月, 2018 2 次提交
  27. 11 4月, 2018 1 次提交
    • S
      PCI: Mark Broadcom HT1100 and HT2000 Root Port Extended Tags as broken · 1b30dfd3
      由 Sinan Kaya 提交于 
      Per PCIe r3.1, sec 2.2.6.2 and 7.8.4, a Requester may not use 8-bit Tags
unless its Extended Tag Field Enable is set, but all Receivers/Completers
must handle 8-bit Tags correctly regardless of their Extended Tag Field
Enable.

Some devices do not handle 8-bit Tags as Completers, so add a quirk for
them.  If we find such a device, we disable Extended Tags for the entire
hierarchy to make peer-to-peer DMA possible.

The Broadcom HT1100/HT2000/HT2100 seems to have issues with handling 8-bit
tags.  Mark it as broken.

This fixes Xorg hangs and unresponsive keyboards with errors like this:

  radeon 0000:06:00.0: GPU lockup (current fence id 0x000000000000000e last fence id 0x0000000000000
  [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)
  [drm:r600_resume [radeon]] *ERROR* r600 startup failed on resume

Fixes: 60db3a4d ("PCI: Enable PCIe Extended Tags if supported")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196197Signed-off-by: NSinan Kaya <okaya@codeaurora.org>
Signed-off-by: NBjorn Helgaas <helgaas@kernel.org>
CC: stable@vger.kernel.org	# v4.11: 62ce94a7 PCI: Mark Broadcom HT2100 Root Port Extended Tags as broken
CC: stable@vger.kernel.org	# v4.11
      1b30dfd3
  29. 20 3月, 2018 4 次提交
  31. 16 3月, 2018 1 次提交
    • A
      arch: remove tile port · bb9d8126
      由 Arnd Bergmann 提交于 
      The Tile architecture port was added by Chris Metcalf in 2010, and
maintained until early 2018 when he orphaned it due to his departure
from Mellanox, and nobody else stepped up to maintain it. The product
line is still around in the form of the BlueField SoC, but no longer
uses the Tile architecture.

There are also still products for sale with Tile-GX SoCs, notably the
Mikrotik CCR router family. The products all use old (linux-3.3) kernels
with lots of patches and won't be upgraded by their manufacturers. There
have been efforts to port both OpenWRT and Debian to these, but both
projects have stalled and are very unlikely to be continued in the future.

Given that we are reasonably sure that nobody is still using the port
with an upstream kernel any more, it seems better to remove it now while
the port is in a good shape than to let it bitrot for a few years first.

Cc: Chris Metcalf <chris.d.metcalf@gmail.com>
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Link: http://www.mellanox.com/page/npu_multicore_overview
Link: https://jenkins.debian.net/view/rebootstrap/job/rebootstrap_tilegx_gcc7/Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      bb9d8126
  33. 14 3月, 2018 1 次提交
    • L
      vga_switcheroo: Use device link for HDA controller · 07f4f97d
      由 Lukas Wunner 提交于 
      Back in 2013, runtime PM for GPUs with integrated HDA controller was
introduced with commits 0d69704a ("gpu/vga_switcheroo: add driver
control power feature. (v3)") and 246efa4a ("snd/hda: add runtime
suspend/resume on optimus support (v4)").

Briefly, the idea was that the HDA controller is forced on and off in
unison with the GPU.

The original code is mostly still in place even though it was never a
100% perfect solution:  E.g. on access to the HDA controller, the GPU
is powered up via vga_switcheroo_runtime_resume_hdmi_audio() but there
are no provisions to keep it resumed until access to the HDA controller
has ceased:  The GPU autosuspends after 5 seconds, rendering the HDA
controller inaccessible.

Additionally, a kludge is required when hda_intel.c probes:  It has to
check whether the GPU is powered down (check_hdmi_disabled()) and defer
probing if so.

However in the meantime (in v4.10) the driver core has gained a feature
called device links which promises to solve such issues in a clean way:
It allows us to declare a dependency from the HDA controller (consumer)
to the GPU (supplier).  The PM core then automagically ensures that the
GPU is runtime resumed as long as the HDA controller's ->probe hook is
executed and whenever the HDA controller is accessed.

By default, the HDA controller has a dependency on its parent, a PCIe
Root Port.  Adding a device link creates another dependency on its
sibling:

                            PCIe Root Port
                             ^          ^
                             |          |
                             |          |
                            HDA  ===>  GPU

The device link is not only used for runtime PM, it also guarantees that
on system sleep, the HDA controller suspends before the GPU and resumes
after the GPU, and on system shutdown the HDA controller's ->shutdown
hook is executed before the one of the GPU.  It is a complete solution.

Using this functionality is as simple as calling device_link_add(),
which results in a dmesg entry like this:

        pci 0000:01:00.1: Linked as a consumer to 0000:01:00.0

The code for the GPU-governed audio power management can thus be removed
(except where it's still needed for legacy manual power control).

The device link is added in a PCI quirk rather than in hda_intel.c.
It is therefore legal for the GPU to runtime suspend to D3cold even if
the HDA controller is not bound to a driver or if CONFIG_SND_HDA_INTEL
is not enabled, for accesses to the HDA controller will cause the GPU to
wake up regardless if they're occurring outside of hda_intel.c (think
config space readout via sysfs).

Contrary to the previous implementation, the HDA controller's power
state is now self-governed, rather than GPU-governed, whereas the GPU's
power state is no longer fully self-governed.  (The HDA controller needs
to runtime suspend before the GPU can.)

It is thus crucial that runtime PM is always activated on the HDA
controller even if CONFIG_SND_HDA_POWER_SAVE_DEFAULT is set to 0 (which
is the default), lest the GPU stays awake.  This is achieved by setting
the auto_runtime_pm flag on every codec and the AZX_DCAPS_PM_RUNTIME
flag on the HDA controller.

A side effect is that power consumption might be reduced if the GPU is
in use but the HDA controller is not, because the HDA controller is now
allowed to go to D3hot.  Before, it was forced to stay in D0 as long as
the GPU was in use.  (There is no reduction in power consumption on my
Nvidia GK107, but there might be on other chips.)

The code paths for legacy manual power control are adjusted such that
runtime PM is disabled during power off, thereby preventing the PM core
from resuming the HDA controller.

Note that the device link is not only added on vga_switcheroo capable
systems, but for *any* GPU with integrated HDA controller.  The idea is
that the HDA controller streams audio via connectors located on the GPU,
so the GPU needs to be on for the HDA controller to do anything useful.

This commit implicitly fixes an unbalanced runtime PM ref upon unbind of
hda_intel.c:  On ->probe, a runtime PM ref was previously released under
the condition "azx_has_pm_runtime(chip) || hda->use_vga_switcheroo", but
on ->remove a runtime PM ref was only acquired under the first of those
conditions.  Thus, binding and unbinding the driver twice on a
vga_switcheroo capable system caused the runtime PM refcount to drop
below zero.  The issue is resolved because the AZX_DCAPS_PM_RUNTIME flag
is now always set if use_vga_switcheroo is true.

For more information on device links please refer to:
https://www.kernel.org/doc/html/latest/driver-api/device_link.html
Documentation/driver-api/device_link.rst

Cc: Dave Airlie <airlied@redhat.com>
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Reviewed-by: NPeter Wu <peter@lekensteyn.nl>
Tested-by: Kai Heng Feng <kai.heng.feng@canonical.com> # AMD PowerXpress
Tested-by: Mike Lothian <mike@fireburn.co.uk>          # AMD PowerXpress
Tested-by: Denis Lisov <dennis.lissov@gmail.com>       # Nvidia Optimus
Tested-by: Peter Wu <peter@lekensteyn.nl>              # Nvidia Optimus
Tested-by: Lukas Wunner <lukas@wunner.de>              # MacBook Pro
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Link: https://patchwork.freedesktop.org/patch/msgid/51bd38360ff502a8c42b1ebf4405ee1d3f27118d.1520068884.git.lukas@wunner.de
      07f4f97d
  35. 05 3月, 2018 1 次提交
  37. 27 2月, 2018 1 次提交
  39. 23 2月, 2018 1 次提交
    • F
      PCI: Add ACS quirk for Ampere root ports · 4ef76ad0
      由 Feng Kan 提交于 
      The Ampere Computing PCIe root port does not support ACS at this point.
However, the hardware provides isolation and source validation through the
SMMU. The stream ID generated by the PCIe ports contain both the
bus/device/function number as well as the port ID in its 3 most significant
bits. Turn on ACS but disable all the peer-to-peer features.

APM is being rebranded to Ampere.  The Vendor and Device IDs change, but
the functionality stays the same.
Signed-off-by: NFeng Kan <fkan@apm.com>
Signed-off-by: NBjorn Helgaas <helgaas@kernel.org>
      4ef76ad0
  41. 17 2月, 2018 1 次提交
    • C
      PCI/cxgb4: Extend T3 PCI quirk to T4+ devices · 7dcf688d
      由 Casey Leedom 提交于 
      We've run into a problem where our device is attached
to a Virtual Machine and the use of the new pci_set_vpd_size()
API doesn't help.  The VM kernel has been informed that
the accesses are okay, but all of the actual VPD Capability
Accesses are trapped down into the KVM Hypervisor where it
goes ahead and imposes the silent denials.

The right idea is to follow the kernel.org
commit 1c7de2b4 ("PCI: Enable access to non-standard VPD for
Chelsio devices (cxgb3)") which Alexey Kardashevskiy authored
to establish a PCI Quirk for our T3-based adapters. This commit
extends that PCI Quirk to cover Chelsio T4 devices and later.

The advantage of this approach is that the VPD Size gets set early
in the Base OS/Hypervisor Boot and doesn't require that the cxgb4
driver even be available in the Base OS/Hypervisor.  Thus PF4 can
be exported to a Virtual Machine and everything should work.

Fixes: 67e65879 ("cxgb4: Set VPD size so we can read both VPD structures")
Cc: <stable@vger.kernel.org>  # v4.9+
Signed-off-by: NCasey Leedom <leedom@chelsio.com>
Signed-off-by: NArjun Vynipadath <arjun@chelsio.com>
Signed-off-by: NGanesh Goudar <ganeshgr@chelsio.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7dcf688d
  43. 19 1月, 2018 1 次提交
  45. 17 1月, 2018 2 次提交
  47. 13 1月, 2018 1 次提交
  49. 19 12月, 2017 2 次提交
  51. 02 11月, 2017 1 次提交
    • G
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      由 Greg Kroah-Hartman 提交于 
      Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier.  The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
 - file had no licensing information it it.
 - file was a */uapi/* one with no licensing information in it,
 - file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne.  Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed.  Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
 - Files considered eligible had to be source code files.
 - Make and config files were included as candidates if they contained >5
   lines of source
 - File already had some variant of a license header in it (even if <5
   lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

 - when both scanners couldn't find any license traces, file was
   considered to have no license information in it, and the top level
   COPYING file license applied.

   For non */uapi/* files that summary was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0                                              11139

   and resulted in the first patch in this series.

   If that file was a */uapi/* path one, it was "GPL-2.0 WITH
   Linux-syscall-note" otherwise it was "GPL-2.0".  Results of that was:

   SPDX license identifier                            # files
   ---------------------------------------------------|-------
   GPL-2.0 WITH Linux-syscall-note                        930

   and resulted in the second patch in this series.

 - if a file had some form of licensing information in it, and was one
   of the */uapi/* ones, it was denoted with the Linux-syscall-note if
   any GPL family license was found in the file or had no licensing in
   it (per prior point).  Results summary:

   SPDX license identifier                            # files
   ---------------------------------------------------|------
   GPL-2.0 WITH Linux-syscall-note                       270
   GPL-2.0+ WITH Linux-syscall-note                      169
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause)    21
   ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause)    17
   LGPL-2.1+ WITH Linux-syscall-note                      15
   GPL-1.0+ WITH Linux-syscall-note                       14
   ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause)    5
   LGPL-2.0+ WITH Linux-syscall-note                       4
   LGPL-2.1 WITH Linux-syscall-note                        3
   ((GPL-2.0 WITH Linux-syscall-note) OR MIT)              3
   ((GPL-2.0 WITH Linux-syscall-note) AND MIT)             1

   and that resulted in the third patch in this series.

 - when the two scanners agreed on the detected license(s), that became
   the concluded license(s).

 - when there was disagreement between the two scanners (one detected a
   license but the other didn't, or they both detected different
   licenses) a manual inspection of the file occurred.

 - In most cases a manual inspection of the information in the file
   resulted in a clear resolution of the license that should apply (and
   which scanner probably needed to revisit its heuristics).

 - When it was not immediately clear, the license identifier was
   confirmed with lawyers working with the Linux Foundation.

 - If there was any question as to the appropriate license identifier,
   the file was flagged for further research and to be revisited later
   in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights.  The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
 - a full scancode scan run, collecting the matched texts, detected
   license ids and scores
 - reviewing anything where there was a license detected (about 500+
   files) to ensure that the applied SPDX license was correct
 - reviewing anything where there was no detection but the patch license
   was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
   SPDX license was correct

This produced a worksheet with 20 files needing minor correction.  This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg.  Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected.  This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.)  Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b2441318