Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 17 8月, 2020 2 次提交
    • N
      s390/pci: fix PF/VF linking on hot plug · b97bf44f
      由 Niklas Schnelle 提交于 
      Currently there are four places in which a PCI function is scanned
and made available to drivers:
 1. In pci_scan_root_bus() as part of the initial zbus
    creation.
 2. In zpci_bus_add_devices() when registering
    a device in configured state on a zbus that has already been
    scanned.
 3. When a function is already known to zPCI (in reserved/standby state)
    and configuration is triggered through firmware by PEC 0x301.
 4. When a device is already known to zPCI (in standby/reserved state)
    and configuration is triggered from within Linux using
    enable_slot().

The PF/VF linking step and setting of pdev->is_virtfn introduced with
commit e5794cf1 ("s390/pci: create links between PFs and VFs") was
only triggered for the second case, which is where VFs created through
sriov_numvfs usually land. However unlike some other platforms but like
POWER VFs can be individually enabled/disabled through
/sys/bus/pci/slots.

Fix this by doing VF setup as part of pcibios_bus_add_device() which is
called in all of the above cases.

Finally to remove the PF/VF links call the common code
pci_iov_remove_virtfn() function to remove linked VFs.
This takes care of the necessary sysfs cleanup.

Fixes: e5794cf1 ("s390/pci: create links between PFs and VFs")
Cc: <stable@vger.kernel.org> # 5.8: 2f0230b2: s390/pci: re-introduce zpci_remove_device()
Cc: <stable@vger.kernel.org> # 5.8
Acked-by: NPierre Morel <pmorel@linux.ibm.com>
Signed-off-by: NNiklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>
      b97bf44f
    • N
      s390/pci: re-introduce zpci_remove_device() · 2f0230b2
      由 Niklas Schnelle 提交于 
      For fixing the PF to VF link removal we need to perform some action on
every removal of a zdev from the common PCI subsystem.
So in preparation re-introduce zpci_remove_device() and use that instead
of directly calling the common code functions. This  was actually still
declared from earlier code but no longer implemented.
Reviewed-by: NPierre Morel <pmorel@linux.ibm.com>
Signed-off-by: NNiklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>
      2f0230b2
  3. 20 5月, 2020 1 次提交
  5. 28 4月, 2020 3 次提交
    • P
      s390/pci: Handling multifunctions · 44510d6f
      由 Pierre Morel 提交于 
      We allow multiple functions on a single bus.
We suppress the ZPCI_DEVFN definition and replace its
occurences with zpci->devfn.

We verify the number of device during the registration.

There can never be more domains in use than existing
devices, so we do not need to verify the count of domain
after having verified the count of devices.
Signed-off-by: NPierre Morel <pmorel@linux.ibm.com>
Reviewed-by: NNiklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      44510d6f
    • P
      s390/pci: create zPCI bus · 05bc1be6
      由 Pierre Morel 提交于 
      The zPCI bus is in charge to handle common zPCI resources for
zPCI devices.

Creating the zPCI bus, the PCI bus, the zPCI devices and the
PCI devices and hotplug slots
done in a specific order:
- PCI hotplug slot creation needs a PCI bus
- PCI bus needs a PCI domain
  which is reported by the pci_domain_nr() when setting up the
  host bridge
- PCI domain is set from the zPCI with devfn 0
  this is necessary to have a reproducible enumeration

Therefore we can not create devices or hotplug slots for any PCI
device associated with a zPCI device before having discovered
the function zero of the bus.

The discovery and initialization of devices can be done at several
points in the code:
- On Events, serialized in a thread context
- On initialization, in the kernel init thread context
- When powering on the hotplug slot, in a user thread context

The removal of devices and their parent bus may also be done on
events or for devices when powering down the slot.

To guarantee the existence of the bus and devices until they are
no more needed we use kref in zPCI bus and introduce a reference
count in the zPCI devices.

In this patch the zPCI bus still only accept a device with
a devfn 0.
Signed-off-by: NPierre Morel <pmorel@linux.ibm.com>
Reviewed-by: NNiklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      05bc1be6
    • P
      s390/pci: define kernel parameters for PCI multifunction · 6cf17f9a
      由 Pierre Morel 提交于 
      Using PCI multifunctions in S390 is a new feature we may want
to ignore to continue provide the same topology as in the past
to userland even if the configuration supports exposing the
topology of a multi-Function device.

A new boolean parameters allows to overwrite the kernel
pci configuration:

- pci=norid when on, disallow the use a new firmware field,
  RID, which provides the PCI <bus>:<device>.<function> part
  of the PCI address.

To be used in the following patches and satisfy the checkpatch.pl
the variable is exposed in pci.h
Signed-off-by: NPierre Morel <pmorel@linux.ibm.com>
Reviewed-by: NNiklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      6cf17f9a
  7. 23 3月, 2020 3 次提交
  9. 04 3月, 2020 1 次提交
  11. 22 1月, 2020 1 次提交
    • N
      s390/pci: Recover handle in clp_set_pci_fn() · 17cdec96
      由 Niklas Schnelle 提交于 
      When we try to recover a PCI function using

    echo 1 > /sys/bus/pci/devices/<id>/recover

or manually with

    echo 1 > /sys/bus/pci/devices/<id>/remove
    echo 0 > /sys/bus/pci/slots/<slot>/power
    echo 1 > /sys/bus/pci/slots/<slot>/power

clp_disable_fn() / clp_enable_fn() call clp_set_pci_fn() to first
disable and then reenable the function.

When the function is already in the requested state we may be left with
an invalid function handle.

To get a new valid handle we do a clp_list_pci() call. For this we need
both the function ID and function handle in clp_set_pci_fn() so pass the
zdev and get both.

To simplify things also pull setting the refreshed function handle into
clp_set_pci_fn()
Signed-off-by: NNiklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: NPeter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>
      17cdec96
  13. 30 11月, 2019 2 次提交
  15. 14 10月, 2019 1 次提交
  17. 21 8月, 2019 1 次提交
  19. 12 7月, 2019 1 次提交
  21. 04 7月, 2019 1 次提交
  23. 28 5月, 2019 1 次提交
  25. 29 4月, 2019 7 次提交
  27. 07 2月, 2019 3 次提交
  29. 02 1月, 2019 1 次提交
  31. 13 12月, 2018 1 次提交
  33. 16 8月, 2018 2 次提交
  35. 24 11月, 2017 1 次提交
    • G
      s390: pci: add SPDX identifiers to the remaining files · adbb3901
      由 Greg Kroah-Hartman 提交于 
      It's good to have SPDX identifiers in all files to make it easier to
audit the kernel tree for correct licenses.

Update the arch/s390/pci/ files with the correct SPDX license
identifier based on the license text in the file itself.  The SPDX
identifier is a legally binding shorthand, which can be used instead of
the full boiler plate text.

This work is based on a script and data from Thomas Gleixner, Philippe
Ombredanne, and Kate Stewart.

Cc: Sebastian Ott <sebott@linux.vnet.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Kate Stewart <kstewart@linuxfoundation.org>
Cc: Philippe Ombredanne <pombredanne@nexb.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      adbb3901
  37. 08 11月, 2017 1 次提交
  39. 16 8月, 2017 1 次提交
  41. 03 8月, 2017 1 次提交
  43. 28 6月, 2017 4 次提交