s390/pci: refactor zpci function states

The current zdev->state mixes the configuration states supported by CLP
with an additional Online state which is used inconsistently to include
enabled zPCI f

s390/pci: refactor zpci function states

The current zdev->state mixes the configuration states supported by CLP
with an additional Online state which is used inconsistently to include
enabled zPCI functions which are not yet visible to the common PCI
subsytem. In preparation for a clean separation between architected
configuration states and fine grained function states remove the Online
function state.

Where we previously checked for Online it is more accurate to check if
the function is enabled to avoid an edge case where a disabled device
was still treated as Online. This also simplifies checks whether
a function is configured as this is now directly reflected by its
function state.

Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

show more ...

s390/pci: fix leak of PCI device structure

In commit 05bc1be6db4b2 ("s390/pci: create zPCI bus") we removed the
pci_dev_put() call matching the earlier pci_get_slot() done as part of
__zpci_event_av

s390/pci: fix leak of PCI device structure

In commit 05bc1be6db4b2 ("s390/pci: create zPCI bus") we removed the
pci_dev_put() call matching the earlier pci_get_slot() done as part of
__zpci_event_availability(). This was based on the wrong understanding
that the device_put() done as part of pci_destroy_device() would counter
the pci_get_slot() when it only counters the initial reference. This
same understanding and existing bad example also lead to not doing
a pci_dev_put() in zpci_remove_device().

Since releasing the PCI devices, unlike releasing the PCI slot, does not
print any debug message for testing I added one in pci_release_dev().
This revealed that we are indeed leaking the PCI device on PCI
hotunplug. Further testing also revealed another missing pci_dev_put() in
disable_slot().

Fix this by adding the missing pci_dev_put() in disable_slot() and fix
zpci_remove_device() with the correct pci_dev_put() calls. Also instead
of calling pci_get_slot() in __zpci_event_availability() to determine if
a PCI device is registered and then doing the same again in
zpci_remove_device() do this once in zpci_remove_device() which makes
sure that the pdev in __zpci_event_availability() is only used for the
result of pci_scan_single_device() which does not need a reference count
decremnt as its ownership goes to the PCI bus.

Also move the check if zdev->zbus->bus is set into zpci_remove_device()
since it may be that we're removing a device with devfn != 0 which never
had a PCI bus. So we can still set the pdev->error_state to indicate
that the device is not usable anymore, add a flag to set the error state.

Fixes: 05bc1be6db4b2 ("s390/pci: create zPCI bus")
Cc: <stable@vger.kernel.org> # 5.8+: e1bff843cde6 s390/pci: remove superfluous zdev->zbus check
Cc: <stable@vger.kernel.org> # 5.8+: ba764dd703fe s390/pci: refactor zpci_create_device()
Cc: <stable@vger.kernel.org> # 5.8+
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>

show more ...

s390/pci: refactor zpci_create_device()

Currently zpci_create_device() is only called in clp_add_pci_device()
which allocates the memory for the struct zpci_dev being created. There
is little separa

s390/pci: refactor zpci_create_device()

Currently zpci_create_device() is only called in clp_add_pci_device()
which allocates the memory for the struct zpci_dev being created. There
is little separation of concerns as only both functions together can
create a zpci_dev and the only CLP specific code in
clp_add_pci_device() is a call to clp_query_pci_fn().

Improve this by removing clp_add_pci_device() and refactor
zpci_create_device() such that it alone creates and initializes the
zpci_dev given the FID and Function Handle. For this we need to make
clp_query_pci_fn() non-static. While at it remove the function handle
parameter since we can just take that from the zpci_dev. Also move
adding to the zpci_list to after the zdev has been fully created which
eliminates a window where a partially initialized zdev can be found by
get_zdev_by_fid().

Acked-by: Pierre Morel <pmorel@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/pci: fix leak of PCI device structure

commit 0b13525c20febcfecccf6fc1db5969727401317d upstream.

In commit 05bc1be6db4b2 ("s390/pci: create zPCI bus") we removed the
pci_dev_put() call matching

s390/pci: fix leak of PCI device structure

commit 0b13525c20febcfecccf6fc1db5969727401317d upstream.

In commit 05bc1be6db4b2 ("s390/pci: create zPCI bus") we removed the
pci_dev_put() call matching the earlier pci_get_slot() done as part of
__zpci_event_availability(). This was based on the wrong understanding
that the device_put() done as part of pci_destroy_device() would counter
the pci_get_slot() when it only counters the initial reference. This
same understanding and existing bad example also lead to not doing
a pci_dev_put() in zpci_remove_device().

Since releasing the PCI devices, unlike releasing the PCI slot, does not
print any debug message for testing I added one in pci_release_dev().
This revealed that we are indeed leaking the PCI device on PCI
hotunplug. Further testing also revealed another missing pci_dev_put() in
disable_slot().

Fix this by adding the missing pci_dev_put() in disable_slot() and fix
zpci_remove_device() with the correct pci_dev_put() calls. Also instead
of calling pci_get_slot() in __zpci_event_availability() to determine if
a PCI device is registered and then doing the same again in
zpci_remove_device() do this once in zpci_remove_device() which makes
sure that the pdev in __zpci_event_availability() is only used for the
result of pci_scan_single_device() which does not need a reference count
decremnt as its ownership goes to the PCI bus.

Also move the check if zdev->zbus->bus is set into zpci_remove_device()
since it may be that we're removing a device with devfn != 0 which never
had a PCI bus. So we can still set the pdev->error_state to indicate
that the device is not usable anymore, add a flag to set the error state.

Fixes: 05bc1be6db4b2 ("s390/pci: create zPCI bus")
Cc: <stable@vger.kernel.org> # 5.8+: e1bff843cde6 s390/pci: remove superfluous zdev->zbus check
Cc: <stable@vger.kernel.org> # 5.8+: ba764dd703fe s390/pci: refactor zpci_create_device()
Cc: <stable@vger.kernel.org> # 5.8+
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

s390/pci: refactor zpci_create_device()

commit ba764dd703feacb5a9c410d191af1b6cfbe96845 upstream.

Currently zpci_create_device() is only called in clp_add_pci_device()
which allocates the memory fo

s390/pci: refactor zpci_create_device()

commit ba764dd703feacb5a9c410d191af1b6cfbe96845 upstream.

Currently zpci_create_device() is only called in clp_add_pci_device()
which allocates the memory for the struct zpci_dev being created. There
is little separation of concerns as only both functions together can
create a zpci_dev and the only CLP specific code in
clp_add_pci_device() is a call to clp_query_pci_fn().

Improve this by removing clp_add_pci_device() and refactor
zpci_create_device() such that it alone creates and initializes the
zpci_dev given the FID and Function Handle. For this we need to make
clp_query_pci_fn() non-static. While at it remove the function handle
parameter since we can just take that from the zpci_dev. Also move
adding to the zpci_list to after the zdev has been fully created which
eliminates a window where a partially initialized zdev can be found by
get_zdev_by_fid().

Acked-by: Pierre Morel <pmorel@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

s390/pci: track whether util_str is valid in the zpci_dev

We'll need to keep track of whether or not the byte string in util_str is
valid and thus needs to be passed to a vfio-pci passthrough device

s390/pci: track whether util_str is valid in the zpci_dev

We'll need to keep track of whether or not the byte string in util_str is
valid and thus needs to be passed to a vfio-pci passthrough device.

Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Acked-by: Niklas Schnelle <schnelle@linux.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>

show more ...

s390/pci: stash version in the zpci_dev

In preparation for passing the info on to vfio-pci devices, stash the
supported PCI version for the target device in the zpci_dev.

Signed-off-by: Matthew Ros

s390/pci: stash version in the zpci_dev

In preparation for passing the info on to vfio-pci devices, stash the
supported PCI version for the target device in the zpci_dev.

Signed-off-by: Matthew Rosato <mjrosato@linux.ibm.com>
Acked-by: Niklas Schnelle <schnelle@linux.ibm.com>
Acked-by: Christian Borntraeger <borntraeger@de.ibm.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>

show more ...

s390: remove orphaned function declarations

arch/s390/pci/pci_bus.h: zpci_bus_init - only declaration left after
commit 05bc1be6db4b ("s390/pci: create zPCI bus")

arch/s390/include/asm/gmap.h: gmap

s390: remove orphaned function declarations

arch/s390/pci/pci_bus.h: zpci_bus_init - only declaration left after
commit 05bc1be6db4b ("s390/pci: create zPCI bus")

arch/s390/include/asm/gmap.h: gmap_pte_notify - only declaration left
after commit 4be130a08420 ("s390/mm: add shadow gmap support")

arch/s390/include/asm/pgalloc.h: rcu_table_freelist_finish - only
declaration left after commit 36409f6353fc ("[S390] use generic RCU
page-table freeing code")

arch/s390/include/asm/tlbflush.h: smp_ptlb_all - only declaration left
after commit 5a79859ae0f3 ("s390: remove 31 bit support")

arch/s390/include/asm/vtimer.h: init_cpu_vtimer - only declaration left
after commit b5f87f15e200 ("s390/idle: consolidate idle functions and
definitions")

arch/s390/include/asm/pci.h: zpci_debug_info - only declaration left
after commit 386aa051fb4b ("s390/pci: remove per device debug attribute")

arch/s390/include/asm/vdso.h: vdso_alloc_boot_cpu - only declaration
left after commit 4bff8cb54502 ("s390: convert to GENERIC_VDSO")

arch/s390/include/asm/smp.h: smp_vcpu_scheduled - only declaration left
after commit 67626fadd269 ("s390: enforce CONFIG_SMP")

arch/s390/kernel/entry.h: restart_call_handler - only declaration left
after commit 8b646bd75908 ("[S390] rework smp code")

arch/s390/kernel/entry.h: startup_init_nobss - only declaration left
after commit 2e83e0eb85ca ("s390: clean .bss before running uncompressed
kernel")

arch/s390/kernel/entry.h: s390_early_resume - only declaration left after
commit 394216275c7d ("s390: remove broken hibernate / power management
support")

drivers/s390/char/raw3270.h: raw3270_request_alloc_bootmem - only
declaration left after commit 33403dcfcdfd ("[S390] 3270 console:
convert from bootmem to slab")

drivers/s390/cio/device.h: ccw_device_schedule_sch_unregister - only
declaration left after commit 37de53bb5290 ("[S390] cio: introduce ccw
device todos")

drivers/s390/char/tape.h: tape_hotplug_event - has only declaration
since recorded git history.

drivers/s390/char/tape.h: tape_oper_handler - has only declaration since
recorded git history.

drivers/s390/char/tape.h: tape_noper_handler - has only declaration
since recorded git history.

drivers/s390/char/tape_std.h: tape_std_check_locate - only declaration
left after commit 161beff8f40d ("s390/tape: remove tape block leftovers")

drivers/s390/char/tape_std.h: tape_std_default_handler - has only
declaration since recorded git history.

drivers/s390/char/tape_std.h: tape_std_unexpect_uchk_handler - has only
declaration since recorded git history.

drivers/s390/char/tape_std.h: tape_std_irq - has only declaration since
recorded git history.

drivers/s390/char/tape_std.h: tape_std_error_recovery - has only
declaration since recorded git history.

drivers/s390/char/tape_std.h: tape_std_error_recovery_has_failed -
has only declaration since recorded git history.

drivers/s390/char/tape_std.h: tape_std_error_recovery_succeded - has
only declaration since recorded git history.

drivers/s390/char/tape_std.h: tape_std_error_recovery_do_retry - has
only declaration since recorded git history.

drivers/s390/char/tape_std.h: tape_std_error_recovery_read_opposite -
has only declaration since recorded git history.

drivers/s390/char/tape_std.h: tape_std_error_recovery_HWBUG - has only
declaration since recorded git history.

Reviewed-by: Sven Schnelle <svens@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/pci: remove clp_rescan_pci_devices_simple()

clp_rescan_pci_devices_simple() is neither simpler than
clp_scan_pci_devices() nor does it really scan PCI devices, in particular
it will neither add

s390/pci: remove clp_rescan_pci_devices_simple()

clp_rescan_pci_devices_simple() is neither simpler than
clp_scan_pci_devices() nor does it really scan PCI devices, in particular
it will neither add newly discovered devices nor remove those which
disappeared.
Instead it only refreshes PCI function handles and also
has just a single callsite in the same translation unit left which
in fact only refreshes one specific function handle identified by
a FID.

Clarify this by renaming the function and its helper to
clp_refresh_fh() respectvely __clp_refresh_fh() and make it take
a fid directly which saves us dealing with the NULL case which
updated all function handles but is not used anymore.
Furthermore since the only callsite is in the same translation unit
make it static.

Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/pci: remove clp_rescan_pci_devices()

there is only one call site of clp_rescan_pci_devices() and
all the function does is call zpci_remove_reserved_devices()
followed by a duplicating clp_scan_

s390/pci: remove clp_rescan_pci_devices()

there is only one call site of clp_rescan_pci_devices() and
all the function does is call zpci_remove_reserved_devices()
followed by a duplicating clp_scan_pci_devices().
So inline the single call as a call to zpci_remove_reserved_devices()
and clp_scan_pci_devices() and remove the function.

Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/pci: remove unused function zpci_rescan()

the only caller of this was removed as part of the suspend/resume
removal so no need to keep this function around.

Reviewed-by: Matthew Rosato <mjrosa

s390/pci: remove unused function zpci_rescan()

the only caller of this was removed as part of the suspend/resume
removal so no need to keep this function around.

Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/pci: Implement ioremap_wc/prot() with MIO

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_

s390/pci: Implement ioremap_wc/prot() with MIO

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: Niklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.ibm.com>
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/pci: create links between PFs and VFs

On s390 PCI Virtual Functions (VFs) are scanned by firmware and are made
available to Linux via the hot-plug interface. As such the common code
path of doi

s390/pci: create links between PFs and VFs

On s390 PCI Virtual Functions (VFs) are scanned by firmware and are made
available to Linux via the hot-plug interface. As such the common code
path of doing the scan directly using the parent Physical Function (PF)
is not used and fenced off with the no_vf_scan attribute.

Even if the partition created the VFs itself e.g. using the sriov_numvfs
attribute of a PF, the PF/VF links thus need to be established after the
fact. To do this when a VF is plugged we scan through all functions on
the same zbus and test whether they are the parent PF in which case we
establish the necessary links.

With these links established there is now no more need to fence off
pci_iov_remove_virtfn() for pdev->no_vf_scan as the common code now
works fine.

Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Pierre Morel <pmorel@linux.ibm.com>
Link: https://lore.kernel.org/r/20200506154139.90609-3-schnelle@linux.ibm.com
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/pci: Handling multifunctions

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 duri

s390/pci: Handling multifunctions

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: Pierre Morel <pmorel@linux.ibm.com>
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/pci: Adding bus resource

The current PCI implementation do not provide a bus resource.
This leads to a notice being print at boot.
Let's do it more nicely and provide the bus resource.

Signed-

s390/pci: Adding bus resource

The current PCI implementation do not provide a bus resource.
This leads to a notice being print at boot.
Let's do it more nicely and provide the bus resource.

Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/pci: create zPCI bus

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

s390/pci: create zPCI bus

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: Pierre Morel <pmorel@linux.ibm.com>
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/pci: define RID and RID available

Firmware provides the bus/devfn part of the PCI addresses of a zPCI
function inside the new field RID of the CLP query PCI function
with a bit to know if this

s390/pci: define RID and RID available

Firmware provides the bus/devfn part of the PCI addresses of a zPCI
function inside the new field RID of the CLP query PCI function
with a bit to know if this field is available to use.

Let's add these fields to the clp_rsp_query_pci structure,
add corresponding fields to zdev and initialize them.

Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/pci: define kernel parameters for PCI multifunction

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

s390/pci: define kernel parameters for PCI multifunction

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: Pierre Morel <pmorel@linux.ibm.com>
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/pci: adaptation of iommu to multifunction

In the future the bus sysdata may not directly point to the
zpci_dev.

In preparation of upcoming patches let us abstract the
access to the zpci_dev fr

s390/pci: adaptation of iommu to multifunction

In the future the bus sysdata may not directly point to the
zpci_dev.

In preparation of upcoming patches let us abstract the
access to the zpci_dev from the device inside the pci device.

Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/pci: Expose new port attribute for PCIe functions

Add SysFS attribute that provides the port number for PCI functions
representing a single port of a multi-port device.

Signed-off-by: Alexande

s390/pci: Expose new port attribute for PCIe functions

Add SysFS attribute that provides the port number for PCI functions
representing a single port of a multi-port device.

Signed-off-by: Alexander Schmidt <alexs@linux.ibm.com>
Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/pci: Improve handling of unset UID

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

s390/pci: Improve handling of unset UID

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: Niklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/pci: Fix zpci_alloc_domain() over allocation

Until now zpci_alloc_domain() only prevented more than
CONFIG_PCI_NR_FUNCTIONS from being added when using automatic domain
allocation. When explici

s390/pci: Fix zpci_alloc_domain() over allocation

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: Niklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: Pierre Morel <pmorel@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/pci: embedding hotplug_slot in zdev

Embedding the hotplug_slot in zdev structure allows to
greatly simplify the hotplug handling by eliminating
the handling of the slot_list.

Signed-off-by: Pi

s390/pci: embedding hotplug_slot in zdev

Embedding the hotplug_slot in zdev structure allows to
greatly simplify the hotplug handling by eliminating
the handling of the slot_list.

Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
Reviewed-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

s390/pci: Recover handle in clp_set_pci_fn()

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>/rem

s390/pci: Recover handle in clp_set_pci_fn()

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: Niklas Schnelle <schnelle@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>

show more ...

PCI: Add PCI_STD_NUM_BARS for the number of standard BARs

Code that iterates over all standard PCI BARs typically uses
PCI_STD_RESOURCE_END. However, that requires the unusual test
"i <= PCI_STD_RE

PCI: Add PCI_STD_NUM_BARS for the number of standard BARs

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.com
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Bjorn 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/

show more ...