<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-dev/arch/s390/pci, branch linus/master</title>
<subtitle>Linux kernel development work - see feature branches</subtitle>
<id>https://git.zx2c4.com/linux-dev/atom/arch/s390/pci?h=linus%2Fmaster</id>
<link rel='self' href='https://git.zx2c4.com/linux-dev/atom/arch/s390/pci?h=linus%2Fmaster'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/'/>
<updated>2022-04-25T11:54:15Z</updated>
<entry>
<title>s390/pci: add error record for CC 2 retries</title>
<updated>2022-04-25T11:54:15Z</updated>
<author>
<name>Niklas Schnelle</name>
<email>schnelle@linux.ibm.com</email>
</author>
<published>2022-02-25T08:45:24Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=34fb0e703480a65754e1f8289d754dfc953ba8d4'/>
<id>urn:sha1:34fb0e703480a65754e1f8289d754dfc953ba8d4</id>
<content type='text'>
Currently it is not detectable from within Linux when PCI instructions
are retried because of a busy condition. Detecting such conditions and
especially how long they lasted can however be quite useful in problem
determination. This patch enables this by adding an s390dbf error log
when a CC 2 is first encountered as well as after the retried
instruction.

Despite being unlikely it may be possible that these added debug
messages drown out important other messages so allow setting the debug
level in zpci_err_insn*() and set their level to 1 so they can be
filtered out if need be.

Reviewed-by: Matthew Rosato &lt;mjrosato@linux.ibm.com&gt;
Reviewed-by: Pierre Morel &lt;pmorel@linux.ibm.com&gt;
Signed-off-by: Niklas Schnelle &lt;schnelle@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/pci: add PCI access type and length to error records</title>
<updated>2022-04-25T11:54:15Z</updated>
<author>
<name>Niklas Schnelle</name>
<email>schnelle@linux.ibm.com</email>
</author>
<published>2022-02-24T14:45:33Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=cde8833e40dddd6e0f067f43b2734a1ad4495065'/>
<id>urn:sha1:cde8833e40dddd6e0f067f43b2734a1ad4495065</id>
<content type='text'>
Currently when a PCI instruction returns a non-zero condition code it
can be very hard to tell from the s390dbf logs what kind of instruction
was executed. In case of PCI memory I/O (MIO) instructions it is even
impossible to tell if we attempted a load, store or block store or how
large the access was because only the address is logged.

Improve this by adding an indicator byte for the instruction type to the
error record and also store the length of the access for MIO
instructions where this can not be deduced from the request.

We use the following indicator values:
 - 'l': PCI load
 - 's': PCI store
 - 'b': PCI store block
 - 'L': PCI load (MIO)
 - 'S': PCI store (MIO)
 - 'B': PCI store block (MIO)
 - 'M': MPCIFC
 - 'R': RPCIT

Reviewed-by: Matthew Rosato &lt;mjrosato@linux.ibm.com&gt;
Reviewed-by: Pierre Morel &lt;pmorel@linux.ibm.com&gt;
Signed-off-by: Niklas Schnelle &lt;schnelle@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/pci: don't log availability events as errors</title>
<updated>2022-04-25T11:54:15Z</updated>
<author>
<name>Niklas Schnelle</name>
<email>schnelle@linux.ibm.com</email>
</author>
<published>2022-04-01T12:04:14Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=723b5a9d2bb0f759c41c3cc41f7fd89a0d8278e5'/>
<id>urn:sha1:723b5a9d2bb0f759c41c3cc41f7fd89a0d8278e5</id>
<content type='text'>
Availability events are logged in s390dbf in s390dbf/pci_error/hex_ascii
even though they don't indicate an error condition.

They have also become redundant as commit 6526a597a2e85 ("s390/pci: add
simpler s390dbf traces for events") added an s390dbf/pci_msg/sprintf log
entry for availability events which contains all non reserved fields of
struct zpci_ccdf_avail. On the other hand the availability entries in
the error log make it easy to miss actual errors and may even overwrite
error entries if the message buffer wraps.

Thus simply remove the availability events from the error log thereby
establishing the rule that any content in s390dbf/pci_error indicates
some kind of error.

Reviewed-by: Matthew Rosato &lt;mjrosato@linux.ibm.com&gt;
Reviewed-by: Pierre Morel &lt;pmorel@linux.ibm.com&gt;
Signed-off-by: Niklas Schnelle &lt;schnelle@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/pci: make better use of zpci_dbg() levels</title>
<updated>2022-04-25T11:54:15Z</updated>
<author>
<name>Niklas Schnelle</name>
<email>schnelle@linux.ibm.com</email>
</author>
<published>2022-03-18T15:25:31Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=52c79e636a58da6650cec632e5e6d46467feefcb'/>
<id>urn:sha1:52c79e636a58da6650cec632e5e6d46467feefcb</id>
<content type='text'>
While the zpci_dbg() macro offers a level parameter this is currently
largely unused. The only instance with higher importance than 3 is the
UID checking change debug message which is not actually more important
as the UID uniqueness guarantee is already exposed in sysfs so this
should rather be 3 as well.

On the other hand the "add ..." message which shows what devices are
visible at the lowest level is essential during problem determination.
By setting its level to 1, lowering the debug level can act as a filter
to only show the available functions.

On the error side the default level is set to 6 while all existing
messages are printed at level 0. This is inconsistent and means there is
no room for having messages be invisible on the default level so instead
set the default level to 3 like for errors matching the default for
debug messages.

Reviewed-by: Matthew Rosato &lt;mjrosato@linux.ibm.com&gt;
Reviewed-by: Pierre Morel &lt;pmorel@linux.ibm.com&gt;
Signed-off-by: Niklas Schnelle &lt;schnelle@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/pci: rename get_zdev_by_bus() to zdev_from_bus()</title>
<updated>2022-03-27T20:18:40Z</updated>
<author>
<name>Niklas Schnelle</name>
<email>schnelle@linux.ibm.com</email>
</author>
<published>2021-09-20T07:47:29Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=7dcfe50f58d28e0e2ba79e9e4333888bcf9442a4'/>
<id>urn:sha1:7dcfe50f58d28e0e2ba79e9e4333888bcf9442a4</id>
<content type='text'>
Getting a zpci_dev via get_zdev_by_bus() uses the long lived reference
held in zbus-&gt;function[devfn]. This is accounted for in
pcibios_add_device() and pcibios_release_device().

Therefore there is no need to increment the reference count in
get_zdev_by_bus() as is done for get_zdev_by_fid(). Instead callers must
not access the device after pcibios_release_device() was called which is
necessary for common PCI code anyway. With this though the very similar
naming may be misleading so rename get_zdev_by_bus() to zdev_from_bus()
emphasizing that we are directly referencing the zdev via the bus.

Reviewed-by: Matthew Rosato &lt;mjrosato@linux.ibm.com&gt;
Signed-off-by: Niklas Schnelle &lt;schnelle@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/pci: improve zpci_dev reference counting</title>
<updated>2022-03-27T20:18:39Z</updated>
<author>
<name>Niklas Schnelle</name>
<email>schnelle@linux.ibm.com</email>
</author>
<published>2021-09-20T07:32:21Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=c122383d221dfa2f41cfe5e672540595de986fde'/>
<id>urn:sha1:c122383d221dfa2f41cfe5e672540595de986fde</id>
<content type='text'>
Currently zpci_dev uses kref based reference counting but only accounts
for one original reference plus one reference from an added pci_dev to
its underlying zpci_dev. Counting just the original reference worked
until the pci_dev reference was added in commit 2a671f77ee49 ("s390/pci:
fix use after free of zpci_dev") because once a zpci_dev goes away, i.e.
enters the reserved state, it would immediately get released. However
with the pci_dev reference this is no longer the case and the zpci_dev
may still appear in multiple availability events indicating that it was
reserved. This was solved by detecting when the zpci_dev is already on
its way out but still hanging around. This has however shown some light
on how unusual our zpci_dev reference counting is.

Improve upon this by modelling zpci_dev reference counting on pci_dev.
Analogous to pci_get_slot() increment the reference count in
get_zdev_by_fid(). Thus all users of get_zdev_by_fid() must drop the
reference once they are done with the zpci_dev.

Similar to pci_scan_single_device(), zpci_create_device() returns the
device with an initial count of 1 and the device added to the zpci_list
(analogous to the PCI bus' device_list). In turn users of
zpci_create_device() must only drop the reference once the device is
gone from the point of view of the zPCI subsystem, it might still be
referenced by the common PCI subsystem though.

Reviewed-by: Matthew Rosato &lt;mjrosato@linux.ibm.com&gt;
Signed-off-by: Niklas Schnelle &lt;schnelle@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/pci: make zpci_set_irq()/zpci_clear_irq() static</title>
<updated>2022-03-10T14:58:17Z</updated>
<author>
<name>Niklas Schnelle</name>
<email>schnelle@linux.ibm.com</email>
</author>
<published>2022-03-08T09:49:58Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=6c2797cd51218a451a52edc2ca533f89d1a2af10'/>
<id>urn:sha1:6c2797cd51218a451a52edc2ca533f89d1a2af10</id>
<content type='text'>
Commit c1e18c17bda68 ("s390/pci: add zpci_set_irq()/zpci_clear_irq()")
made zpci_set_irq()/zpci_clear_irq() non-static in preparation for using
them in zpci_hot_reset_device(). The version of zpci_hot_reset_device()
that was finally merged however exploits the fact that IRQs and DMA is
implicitly disabled by clp_disable_fh() so the call to zpci_clear_irq()
was never added. There are no other calls outside pci_irq.c so lets make
both functions static.

Signed-off-by: Niklas Schnelle &lt;schnelle@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>s390/extable: move EX_TABLE define to asm-extable.h</title>
<updated>2022-03-07T23:33:00Z</updated>
<author>
<name>Heiko Carstens</name>
<email>hca@linux.ibm.com</email>
</author>
<published>2022-02-28T10:22:12Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=d09a307fde1c943d23ccb9fecc9a0e1a569732ad'/>
<id>urn:sha1:d09a307fde1c943d23ccb9fecc9a0e1a569732ad</id>
<content type='text'>
Follow arm64 and riscv and move the EX_TABLE define to asm-extable.h
which is a lot less generic than the current linkage.h.

Also make sure that all files which contain EX_TABLE usages actually
include the new header file. This should make sure that the files
always compile and there won't be any random compile breakage due to
other header file dependencies.

Reviewed-by: Alexander Gordeev &lt;agordeev@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Signed-off-by: Vasily Gorbik &lt;gor@linux.ibm.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'irq-msi-2022-01-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2022-01-13T17:05:29Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2022-01-13T17:05:29Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=feb7a43de5ef625ad74097d8fd3481d5dbc06a59'/>
<id>urn:sha1:feb7a43de5ef625ad74097d8fd3481d5dbc06a59</id>
<content type='text'>
Pull MSI irq updates from Thomas Gleixner:
 "Rework of the MSI interrupt infrastructure.

  This is a treewide cleanup and consolidation of MSI interrupt handling
  in preparation for further changes in this area which are necessary
  to:

   - address existing shortcomings in the VFIO area

   - support the upcoming Interrupt Message Store functionality which
     decouples the message store from the PCI config/MMIO space"

* tag 'irq-msi-2022-01-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (94 commits)
  genirq/msi: Populate sysfs entry only once
  PCI/MSI: Unbreak pci_irq_get_affinity()
  genirq/msi: Convert storage to xarray
  genirq/msi: Simplify sysfs handling
  genirq/msi: Add abuse prevention comment to msi header
  genirq/msi: Mop up old interfaces
  genirq/msi: Convert to new functions
  genirq/msi: Make interrupt allocation less convoluted
  platform-msi: Simplify platform device MSI code
  platform-msi: Let core code handle MSI descriptors
  bus: fsl-mc-msi: Simplify MSI descriptor handling
  soc: ti: ti_sci_inta_msi: Remove ti_sci_inta_msi_domain_free_irqs()
  soc: ti: ti_sci_inta_msi: Rework MSI descriptor allocation
  NTB/msi: Convert to msi_on_each_desc()
  PCI: hv: Rework MSI handling
  powerpc/mpic_u3msi: Use msi_for_each-desc()
  powerpc/fsl_msi: Use msi_for_each_desc()
  powerpc/pasemi/msi: Convert to msi_on_each_dec()
  powerpc/cell/axon_msi: Convert to msi_on_each_desc()
  powerpc/4xx/hsta: Rework MSI handling
  ...
</content>
</entry>
<entry>
<title>s390/pci: simplify __pciwb_mio() inline asm</title>
<updated>2022-01-07T10:48:17Z</updated>
<author>
<name>Niklas Schnelle</name>
<email>schnelle@linux.ibm.com</email>
</author>
<published>2022-01-05T15:10:54Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/linux-dev/commit/?id=7b2932162f66ab33a00a7cdb6d3b2db6dfdbf634'/>
<id>urn:sha1:7b2932162f66ab33a00a7cdb6d3b2db6dfdbf634</id>
<content type='text'>
The PCI Write Barrier instruction ignores the registers encoded in it.
There is thus no need to explicitly set the register to zero or to
associate it with a variable at all. In the resulting binary this removes
an unnecessary lghi and it makes the code simpler.

Signed-off-by: Niklas Schnelle &lt;schnelle@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
</content>
</entry>
</feed>
