On Thu, 2025-04-24 at 14:02 +0200, Niklas Schnelle wrote:
> Issue uevents during PCI recovery using pci_uevent_ers() as done by EEH
> and AER PCIe recovery routines.
>
> Cc: sta...@vger.kernel.org
> Fixes: 4cdf2f4e24ff ("s390/pci: implement minimal PCI error recovery"
Issue uevents during PCI recovery using pci_uevent_ers() as done by EEH
and AER PCIe recovery routines.
Cc: sta...@vger.kernel.org
Fixes: 4cdf2f4e24ff ("s390/pci: implement minimal PCI error recovery")
Signed-off-by: Niklas Schnelle
---
Question: pci_uevent_ers
wrappers may not be necessary if you don't have the global
prototypes though, right? In this case I think we might want to still
align the parameter types as this seems generally cleaner and the
internal callers already use size_t anyway.
Either way I gave the whole series a quick test on s390x with PCI
devices and all looks good. So feel free to add:
Acked-by: Niklas Schnelle
Tested-by: Niklas Schnelle
On Thu, 2023-03-23 at 17:33 +0100, Niklas Schnelle wrote:
> We introduce a new HAS_IOPORT Kconfig option to indicate support for I/O
> Port access. In a future patch HAS_IOPORT=n will disable compilation of
> the I/O accessor functions inb()/outb() and friends on architectures
> w
ns will be added in subsequent patches on
a per subsystem basis.
Co-developed-by: Arnd Bergmann
Signed-off-by: Arnd Bergmann
Acked-by: Johannes Berg # for ARCH=um
Acked-by: Geert Uytterhoeven
Signed-off-by: Niklas Schnelle
---
Note: This patch is the initial patch of a larger series[0].
On Tue, 2023-03-14 at 13:37 +0100, Johannes Berg wrote:
> On Tue, 2023-03-14 at 13:11 +0100, Niklas Schnelle wrote:
> > --- a/arch/um/Kconfig
> > +++ b/arch/um/Kconfig
> > @@ -56,6 +56,7 @@ config NO_IOPORT_MAP
> >
> > config ISA
> > bool
> > +
On Tue, 2023-03-14 at 13:11 +0100, Niklas Schnelle wrote:
> We introduce a new HAS_IOPORT Kconfig option to indicate support for I/O
> Port access. In a future patch HAS_IOPORT=n will disable compilation of
> the I/O accessor functions inb()/outb() and friends on architectures
> w
On Tue, 2023-03-14 at 14:29 +0100, Arnd Bergmann wrote:
> On Tue, Mar 14, 2023, at 13:11, Niklas Schnelle wrote:
> > We introduce a new HAS_IOPORT Kconfig option to indicate support for I/O
> > Port access. In a future patch HAS_IOPORT=n will disable compilation of
> > the I
d-by: Arnd Bergmann
Signed-off-by: Niklas Schnelle
---
arch/alpha/Kconfig | 1 +
arch/arm/Kconfig| 1 +
arch/arm64/Kconfig | 1 +
arch/ia64/Kconfig | 1 +
arch/m68k/Kconfig | 1 +
arch/microblaze/Kconfig | 1 +
arch/mips/Kconfig | 2 ++
arch/parisc/Kconfig |
On Fri, 2022-05-06 at 14:53 +0200, Arnd Bergmann wrote:
> On Fri, May 6, 2022 at 2:27 PM Maciej W. Rozycki wrote:
> > On Fri, 6 May 2022, Arnd Bergmann wrote:
> >
> > > > If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > > pattern put on the bus/in the TLP in the addre
On Fri, 2022-05-06 at 13:27 +0100, Maciej W. Rozycki wrote:
> On Fri, 6 May 2022, Arnd Bergmann wrote:
>
> > > If this is PCI/PCIe indeed, then an I/O access is just a different bit
> > > pattern put on the bus/in the TLP in the address phase. So what is there
> > > inherent to the s390 architec
On Fri, 2022-05-06 at 13:33 +0200, Arnd Bergmann wrote:
> On Fri, May 6, 2022 at 12:20 PM Maciej W. Rozycki wrote:
> > On Thu, 5 May 2022, Arnd Bergmann wrote:
> > I think I'm missing something here. IIUC we're talking about a PCI/PCIe
> > bus used with s390 hardware, right?
> >
> > (It has to
On Fri, 2022-05-06 at 19:12 +1000, Finn Thain wrote:
>
> On Thu, 5 May 2022, Bjorn Helgaas wrote:
>
> > On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas wrote:
> > > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
On Thu, 2022-05-05 at 14:53 -0500, Bjorn Helgaas wrote:
> On Thu, May 05, 2022 at 07:39:42PM +0200, Arnd Bergmann wrote:
> > On Thu, May 5, 2022 at 6:10 PM Bjorn Helgaas wrote:
> > > On Wed, May 04, 2022 at 11:31:28PM +0200, Arnd Bergmann wrote:
> > > > The main goal is to avoid c), which is what
On Wed, 2022-05-04 at 23:31 +0200, Arnd Bergmann wrote:
> On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas wrote:
> > On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
> > > We introduce a new HAS_IOPORT Kconfig option to indicate support for
> > > I/O Por
support is optional. The "depends on" relations on HAS_IOPORT
in drivers as well as ifdefs for HAS_IOPORT specific sections will be
added in subsequent patches on a per subsystem basis.
Co-developed-by: Arnd Bergmann
Signed-off-by: Niklas Schnelle
---
arch/alpha/Kconfig | 1 +
arch/a
On Thu, 2021-12-30 at 16:44 +1300, Michael Schmitz wrote:
> Hi Arnd,
>
> Am 30.12.2021 um 14:48 schrieb Arnd Bergmann:
> > On Tue, Dec 28, 2021 at 11:15 PM Michael Schmitz
> > wrote:
> > > Am 29.12.2021 um 16:41 schrieb Arnd Bergmann:
> > > > On Tue, Dec 28, 2021 at 8:20 PM Michael Schmitz
> >
: Arnd Bergmann
Signed-off-by: Niklas Schnelle
---
arch/alpha/Kconfig | 1 +
arch/arc/Kconfig| 1 +
arch/arm/Kconfig| 1 +
arch/arm64/Kconfig | 1 +
arch/ia64/Kconfig | 1 +
arch/m68k/Kconfig | 1 +
arch/microblaze/Kconfig | 1 +
arch/mips/Kconfig | 1
7;t follow the convention exactly as
it is called from pci_release_dev() but at least that isn't very
confusing.
So for the arch/s390/pci bit:
Acked-by: Niklas Schnelle
the device. Thus pci_dev_is_added() is always
false and can be dropped.
Signed-off-by: Niklas Schnelle
---
arch/powerpc/platforms/powernv/pci-sriov.c | 6 --
arch/powerpc/platforms/pseries/setup.c | 3 +--
2 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/arch/powerpc
n-5520/
[1]
https://lore.kernel.org/lkml/caosf1cfyuf9faesnparj+7w0mktpvtcm8vxjhdsfsndc6k_...@mail.gmail.com/
Niklas Schnelle (1):
powerpc: Drop superfluous pci_dev_is_added() calls
arch/powerpc/platforms/powernv/pci-sriov.c | 6 --
arch/powerpc/platforms/pseries/setup.c | 3 +--
2 files changed, 1 insertion(+), 8 deletions(-)
--
2.25.1
On Wed, 2021-09-08 at 11:37 +1000, Oliver O'Halloran wrote:
> On Tue, Sep 7, 2021 at 10:21 PM Niklas Schnelle
> wrote:
> > On Tue, 2021-09-07 at 10:45 +0200, Niklas Schnelle wrote:
> > > On Tue, 2021-09-07 at 12:04 +1000, Oliver O'Halloran wrote:
> > >
On Tue, 2021-09-07 at 10:45 +0200, Niklas Schnelle wrote:
> On Tue, 2021-09-07 at 12:04 +1000, Oliver O'Halloran wrote:
> > On Mon, Sep 6, 2021 at 7:49 PM Niklas Schnelle
> > wrote:
> > > Patch 3 I already sent separately resulting in the discussion below but
On Tue, 2021-09-07 at 12:04 +1000, Oliver O'Halloran wrote:
> On Mon, Sep 6, 2021 at 7:49 PM Niklas Schnelle wrote:
> > Patch 3 I already sent separately resulting in the discussion below but
> > without
> > a final conclusion.
> >
> > https://lore.kernel.
esconfig (attached as .config)
> > compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
> > reproduce (this is a W=1 build):
> > #
> > https://github.com/0day-ci/linux/commit/404ed8c00a612e7ae31c50557c80c6726c464863
> > git remote add linux-review https://github.com/0day-ci/linux
&
On Mon, 2021-09-06 at 21:05 -0500, Linas Vepstas wrote:
> On Mon, Sep 6, 2021 at 4:49 AM Niklas Schnelle
> wrote:
>
> > I believe we might be the first
> > implementation of PCI device recovery in a virtualized setting requiring
> > us to
> > coordinate the
ned-off-by: Niklas Schnelle
---
drivers/pci/pci.c | 3 ++-
include/linux/pci.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index aacf575c15cf..3f416c6d3b0b 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -5040,12 +5040,13
we use the newly introduced zpci_hot_reset_device() which also
takes the PCI function out of the error state.
Signed-off-by: Niklas Schnelle
---
arch/s390/include/asm/pci.h | 4 +-
arch/s390/pci/pci.c | 49 ++
arch/s390/pci/pci_event.c |
The helper function pci_dev_is_added() from drivers/pci/pci.h is used in
PCI arch code of both s390 and powerpc leading to awkward relative
includes. Move it to the global include/linux/pci.h and get rid of these
includes just for that one function.
Signed-off-by: Niklas Schnelle
---
arch
-by: Niklas Schnelle
---
arch/s390/include/asm/pci.h| 1 +
arch/s390/pci/pci.c| 58 ++
arch/s390/pci/pci_irq.c| 9 +
drivers/pci/hotplug/s390_pci_hpc.c | 24 +
4 files changed, 92 insertions(+)
diff --git a/arch/s390
nforming the OS that it should
be ready to be used again. Note that the same event is also issued by the
hypervisor if the function was manually taken into a service mode for example
for firmware upgrade via the hypervisor and is now ready to be used again.
Thanks,
Niklas Schnelle
Niklas Schn
ess through the handle will
show an up to date handle reducing the chance of confusion. Also it
makes sure we have one single place where a zPCI function handle is
updated after initialization.
Signed-off-by: Niklas Schnelle
---
arch/s390/include/asm/pci.h | 1 +
arch/s390/pci/pci
On Wed, 2021-08-25 at 14:04 -0500, Bjorn Helgaas wrote:
> On Mon, Aug 23, 2021 at 12:53:39PM +0200, Niklas Schnelle wrote:
> > On Fri, 2021-08-20 at 17:37 -0500, Bjorn Helgaas wrote:
> > > On Tue, Jul 20, 2021 at 05:01:45PM +0200, Niklas Schnelle wrote:
> > > > The he
On Fri, 2021-08-20 at 17:37 -0500, Bjorn Helgaas wrote:
> On Tue, Jul 20, 2021 at 05:01:45PM +0200, Niklas Schnelle wrote:
> > The helper function pci_dev_is_added() from drivers/pci/pci.h is used in
> > PCI arch code of both s390 and powerpc leading to awkward relative
> >
lwig
> Signed-off-by: Logan Gunthorpe
> Cc: Niklas Schnelle
> Cc: Gerald Schaefer
> Cc: Heiko Carstens
> Cc: Vasily Gorbik
> Cc: Christian Borntraeger
> ---
> arch/s390/pci/pci_dma.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/s390/pci/pc
The helper function pci_dev_is_added() from drivers/pci/pci.h is used in
PCI arch code of both s390 and powerpc leading to awkward relative
includes. Move it to the global include/linux/pci.h and get rid of these
includes just for that one function.
Signed-off-by: Niklas Schnelle
---
Since v1
On Tue, 2021-07-20 at 11:58 +0200, Niklas Schnelle wrote:
> The helper function pci_dev_is_added() from drivers/pci/pci.h is used in
> PCI arch code of both s390 and powerpc leading to awkward relative
> includes. Move it to the global include/linux/pci.h and get rid of these
> inclu
The helper function pci_dev_is_added() from drivers/pci/pci.h is used in
PCI arch code of both s390 and powerpc leading to awkward relative
includes. Move it to the global include/linux/pci.h and get rid of these
includes just for that one function.
Signed-off-by: Niklas Schnelle
---
Since v1
On Tue, 2021-07-20 at 10:34 +0200, Niklas Schnelle wrote:
> On Mon, 2021-07-19 at 14:11 +0200, Niklas Schnelle wrote:
> > The helper function pci_dev_is_added() from drivers/pci/pci.h is used in
> > PCI arch code of both s390 and powerpc leading to awkward relative
> > inc
On Mon, 2021-07-19 at 14:11 +0200, Niklas Schnelle wrote:
> The helper function pci_dev_is_added() from drivers/pci/pci.h is used in
> PCI arch code of both s390 and powerpc leading to awkward relative
> includes. Move it to the global include/linux/pci.h and get rid of these
> inclu
The helper function pci_dev_is_added() from drivers/pci/pci.h is used in
PCI arch code of both s390 and powerpc leading to awkward relative
includes. Move it to the global include/linux/pci.h and get rid of these
includes just for that one function.
Signed-off-by: Niklas Schnelle
---
arch
y: Logan Gunthorpe
> Cc: Niklas Schnelle
> Cc: Gerald Schaefer
> Cc: Heiko Carstens
> Cc: Vasily Gorbik
> Cc: Christian Borntraeger
> ---
> arch/s390/pci/pci_dma.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/s390/pci/pc
t; {
> del_gendisk(bdev->gendisk);
> - blk_cleanup_queue(bdev->gendisk->queue);
> + blk_cleanup_disk(bdev->gendisk);
> blk_mq_free_tag_set(&bdev->tag_set);
> - put_disk(bdev->gendisk);
> }
>
> void scm_blk_set_available(struct scm_blk_dev *bdev)
Not an expert on SCM or this code but I gave this a quick test and it
seems to work fine.
Tested-by: Niklas Schnelle
irtio-pci devices all seems to work fine.
I already commented on Christoph's mail that I like the helper approach,
so as for s390 you can add my
Acked-by: Niklas Schnelle
>
> arch/alpha/kernel/pci_iommu.c| 7 +--
> arch/ia64/hp/common/sba_iommu.c | 3 +--
> arch/pow
On 8/21/20 1:19 AM, Nicolin Chen wrote:
> We are expending the default DMA segmentation boundary to its
> possible maximum value (ULONG_MAX) to indicate that a device
> doesn't specify a boundary limit. So all dma_get_seg_boundary
> callers should take a precaution with the return values since
>
45 matches
Mail list logo
