when we're missing the necessary machine facilities zPCI can
not function. Until now it would silently fail to be initialized,
add an informational print.
Signed-off-by: NNiklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: NHeiko Carstens <hca@linux.ibm.com>

the only caller of this was removed as part of the suspend/resume
removal so no need to keep this function around.
Reviewed-by: NMatthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: NNiklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>

currently we have multiple #ifdef CONFIG_PCI_IOV blocks spread over
different compliation units and headers, all dealing with SR-IOV
specific behavior.
This violates the style guide which discourages conditionally compiled
code blocks and hinders maintainability by speading SR-IOV functionality
over many files.

Let's move all of this into a conditionally compiled pci_iov.c file and
local header and prefix SR-IOV specific functions with zpci_iov_*.
Reviewed-by: NMatthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: NNiklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>

With our current support for the new MIO PCI instructions, write
combining/write back MMIO memory can be obtained via the pci_iomap_wc()
and pci_iomap_wc_range() functions.
This is achieved by using the write back address for a specific bar
as provided in clp_store_query_pci_fn()

These functions are however not widely used and instead drivers often
rely on ioremap_wc() and ioremap_prot(), which on other platforms enable
write combining using a PTE flag set through the pgrprot value.

While we do not have a write combining flag in the low order flag bits
of the PTE like x86_64 does, with MIO support, there is a write back bit
in the physical address (bit 1 on z15) and thus also the PTE.
Which bit is used to toggle write back and whether it is available at
all, is however not fixed in the architecture. Instead we get this
information from the CLP Store Logical Processor Characteristics for PCI
command. When the write back bit is not provided we fall back to the
existing behavior.
Signed-off-by: NNiklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: NPierre Morel <pmorel@linux.ibm.com>
Reviewed-by: NGerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>

commit f606b3ef ("s390/pci: adapt events for zbus") removed the
zpci_disable_device() call for a zPCI event with PEC 0x0304 because
the device is already deconfigured by the platform.
This however skips the Linux side of the disable in particular it leads
to leaking the DMA tables and bitmaps because zpci_dma_exit_device() is
never called on the device.

If the device transitions to the Reserved state we call zpci_zdev_put()
but zpci_release_device() will not call zpci_disable_device() because
the state of the zPCI function is already ZPCI_FN_STATE_STANDBY.

If the device is put into the Standby state, zpci_disable_device() is
not called and the device is assumed to have been put in Standby through
platform action.
At this point the device may be removed by a subsequent event with PEC
0x0308 or 0x0306 which calls zpci_zdev_put() with the same problem
as above or the device may be configured again in which case
zpci_disable_device() is also not called.

Fix this by calling zpci_disable_device() explicitly for PEC 0x0304 as
before. To make it more clear that zpci_disable_device() may be called,
even if the lower level device has already been disabled by the
platform, add a comment to zpci_disable_device().

Cc: <stable@vger.kernel.org> # 5.8
Fixes: f606b3ef ("s390/pci: adapt events for zbus")
Signed-off-by: NNiklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>

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>

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>

Let's use the same signature and parameter names as in the generic
ioremap() definition making the physical address' type explicit.

Add a check against address wrap around as in the generic
lib/ioremap.c:ioremap_prot() code.

Finally use free_vm_area() instead of vunmap() as in the generic code.
Besides being clearer free_vm_area() can also skip a few additional
checks compared with vunmap().
Signed-off-by: NNiklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: NGerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>

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>

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>

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>

When UID checking is enabled a UID value of 0 is invalid and can not be
set by the user. On z/VM it is however used to indicate an unset UID.
Until now, this lead to the behavior that one PCI function could be
attached with UID 0 after which z/VM would prohibit further attachment.

Now if the user then turns off UID checking in z/VM the user could
seemingly attach additional PCI functions that would however not show up
in Linux as that would not be informed of the change in UID checking
mode. This is unexpected and confusing and lead to bug reports against
Linux.

Instead now, if we encounter an unset UID value of 0 treat it as
indicating that UID checking was turned off, switch to automatic domain
allocation, and warn the user of the possible misconfiguration.
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>

Until now zpci_alloc_domain() only prevented more than
CONFIG_PCI_NR_FUNCTIONS from being added when using automatic domain
allocation. When explicit UIDs were defined UIDs above
CONFIG_PCI_NR_FUNCTIONS were not counted at all.
When more PCI functions are added this could lead to various errors
including under sized IRQ vectors and similar issues.

Fix this by explicitly tracking the number of allocated domains.
Signed-off-by: NNiklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: NPierre Morel <pmorel@linux.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>

Hibernation is known to be broken for many years on s390. Given that
there aren't any real use cases, remove the code instead of spending
time to fix and maintain it.

Without hibernate support it doesn't make too much sense to keep power
management support; therefore remove it completely.
Acked-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Acked-by: NPeter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>

In the initial MIO support introduced in

commit 71ba41c9 ("s390/pci: provide support for MIO instructions")

zpci_map_resource() and zpci_setup_resources() default to using the
mio_wb address as the resource's start address. This means users of the
mapping, which includes most drivers, will get write combining on PCI
Stores. This may lead to problems when drivers expect write through
behavior when not using an explicit ioremap_wc().

Cc: stable@vger.kernel.org
Fixes: 71ba41c9 ("s390/pci: provide support for MIO instructions")
Signed-off-by: NNiklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: NPierre Morel <pmorel@linux.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>

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>

The config option CONFIG_PCI_NR_FUNCTIONS sets a limit on the number of
PCI functions we can support. Previously on reaching this limit there
was no indication why newly attached devices are not recognized by Linux
which could be quite confusing. Thus this patch adds a pr_err() for this
case.
Reviewed-by: NPeter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: NNiklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>

When UID checking was turned off during runtime in the underlying
hypervisor, a PCI device may be attached with the same UID. This is
already detected but happens silently. Add an error message so it can
more easily be understood why a device was not added.
Reviewed-by: NPeter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: NNiklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>

Code that iterates over all standard PCI BARs typically uses
PCI_STD_RESOURCE_END.  However, that requires the unusual test
"i <= PCI_STD_RESOURCE_END" rather than something the typical
"i < PCI_STD_NUM_BARS".

Add a definition for PCI_STD_NUM_BARS and change loops to use the more
idiomatic C style to help avoid fencepost errors.

Link: https://lore.kernel.org/r/20190927234026.23342-1-efremov@linux.com
Link: https://lore.kernel.org/r/20190927234308.23935-1-efremov@linux.com
Link: https://lore.kernel.org/r/20190916204158.6889-3-efremov@linux.comSigned-off-by: NDenis Efremov <efremov@linux.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Acked-by: Sebastian Ott <sebott@linux.ibm.com>			# arch/s390/
Acked-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>	# video/fbdev/
Acked-by: Gustavo Pimentel <gustavo.pimentel@synopsys.com>	# pci/controller/dwc/
Acked-by: Jack Wang <jinpu.wang@cloud.ionos.com>		# scsi/pm8001/
Acked-by: Martin K. Petersen <martin.petersen@oracle.com>	# scsi/pm8001/
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>			# memstick/

This patch alters the for loop iteration scheme in zpci_map_resources
to make it more usual. Thus, the patch generalizes the style for
PCI_IOV_RESOURCES iteration and improves readability.

Link: http://lkml.kernel.org/r/20190806160137.29275-1-efremov@linux.comSigned-off-by: NDenis Efremov <efremov@linux.com>
Signed-off-by: NSebastian Ott <sebott@linux.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>

Move enablement of mio addressing control from detect_machine_facilities
to pci_base_init. detect_machine_facilities runs so early that the
static branches have not been toggled yet, thus mio addressing control
was always off. In pci_base_init we have to use the SMP aware
ctl_set_bit though.

Fixes: 833b441e ("s390: enable processes for mio instructions")
Signed-off-by: NSebastian Ott <sebott@linux.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>

Unfortunately we have to handle a class of devices that don't support the
new MIO instructions. Adjust resource assignment and mapping accordingly.
Signed-off-by: NSebastian Ott <sebott@linux.ibm.com>
Signed-off-by: NVasily Gorbik <gor@linux.ibm.com>

Adjust bus resources depending on the usage of MIO instructions.

Fixes: 71ba41c9 ("s390/pci: provide support for MIO instructions")
Signed-off-by: NSebastian Ott <sebott@linux.ibm.com>
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>

Allow users to disable usage of MIO instructions by specifying pci=nomio
at the kernel command line.
Signed-off-by: NSebastian Ott <sebott@linux.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Provide support for PCI I/O instructions that work on mapped IO addresses.
Signed-off-by: NSebastian Ott <sebott@linux.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

This is a preparation patch for usage of new pci instructions.
No functional change.
Signed-off-by: NSebastian Ott <sebott@linux.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Provide a kernel parameter to force the usage of floating interrupts.
Signed-off-by: NSebastian Ott <sebott@linux.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Move everything interrupt related from pci.c to pci_irq.c.
No functional change.
Signed-off-by: NSebastian Ott <sebott@linux.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

No users of pr_debug in that file.
Signed-off-by: NSebastian Ott <sebott@linux.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

No point to keep that around.
Signed-off-by: NSebastian Ott <sebott@linux.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Map IOV resources such that pci common code recognizes the IOV
capability of PFs.
Signed-off-by: NSebastian Ott <sebott@linux.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Improve the bar check in pci_iomap_range to cover functions
for which we recognize more bars than what we can access due
to AR restrictions.
Signed-off-by: NSebastian Ott <sebott@linux.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

This reverts commit 9594ca6b.

With the handle_simple_irq irq_flow_handler it must be ensured to
not call generic_handle_irq with the same IRQ number on 2 CPUs at
the same time (interrupts are floating on s390).
Contrary to my initial investigation the irq_desc's lock usage in
handle_simple_irq does not ensure this. Thus re-introduce the bit-
lock usage in s390's pci handler.
Reported-by: NUrsula Braun <ubraun@linux.ibm.com>
Reported-by: NAlexander Schmidt <alexs@linux.ibm.com>
Signed-off-by: NSebastian Ott <sebott@linux.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Set the flag to skip scanning for VFs after SR-IOV enablement.  VF creation
will be triggered by the hotplug code.
Signed-off-by: NSebastian Ott <sebott@linux.ibm.com>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NChristoph Hellwig <hch@lst.de>

The interrupt handler uses bit_spin_lock around a call to retrieve
per irq data (the irq number). However this per irq data is only
set during irq setup time and never changed until the irq is freed.

Thus it's safe to remove the lock usage.
Signed-off-by: NSebastian Ott <sebott@linux.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>

Get rid of a leftover return code in arch_setup_msi_irqs.
Signed-off-by: NSebastian Ott <sebott@linux.ibm.com>
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>

During interrupt setup we allocate interrupt vectors, walk the list of msi
descriptors, and fill in the message data. Requesting more interrupts than
supported on s390 can lead to an out of bounds access.

When we restrict the number of interrupts we should also stop walking the
msi list after all supported interrupts are handled.

Cc: stable@vger.kernel.org
Signed-off-by: NSebastian Ott <sebott@linux.ibm.com>
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>

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>

As of today QEMU does not provide the AIS facility to its guest.  This
prevents Linux guests from using PCI devices as the ais facility is
checked during init. As this is just a performance optimization, we can
move the ais check into the code where we need it (calling the SIC
instruction). This is used at initialization and on interrupt. Both
places do not require any serialization, so we can simply skip the
instruction.

Since we will now get all interrupts, we can also avoid the 2nd scan.
As we can have multiple interrupts in parallel we might trigger spurious
irqs more often for the non-AIS case but the core code can handle that.
Signed-off-by: NChristian Borntraeger <borntraeger@de.ibm.com>
Reviewed-by: NPierre Morel <pmorel@linux.vnet.ibm.com>
Reviewed-by: NHalil Pasic <pasic@linux.vnet.ibm.com>
Acked-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>

Add support for the iommu_device_register interface to make
the s390 hardware iommus visible to the iommu core and in
sysfs.
Acked-by: NSebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>