Instead of relying on the fallback in asm-generic/io.h which sets
PCI_IOBASE 0 if it is not defined set it explicitly.
Link:
https://lore.kernel.org/lkml/CAK8P3a3PK9zyeP4ymELtc2ZYnymECoACiigw9Za+pvSJpCk5=g...@mail.gmail.com/
Signed-off-by: Niklas Schnelle
---
arch/sparc/include/asm/io.h | 4
Make things explicit and silence the warning by letting inb() and
friends fail with WARN_ONCE() and a 0xff... return in case PCI_IOBASE is
not defined.
Signed-off-by: Niklas Schnelle
---
v1 -> v2:
- Instead of working around the warning with a uintptr_t PCI_IOBASE make inb()
and friends ex
-generic/io.h.
Thanks,
Niklas
Changes since v1:
- Added patch to explicitly set PCI_IOBASE to 0 on sparc as suggested by Arnd
Bergmann
- Instead of working around the warning with a uintptr_t PCI_IOBASE make inb()
and friends explicitly WARN_ONCE() and return 0xff... (Arnd)
Niklas Schnelle (2
On Wed, 2021-04-14 at 15:17 -0500, Bjorn Helgaas wrote:
> On Mon, Apr 12, 2021 at 03:59:05PM +0200, Niklas Schnelle wrote:
> > On s390 each PCI device has a user-defined ID (UID) exposed under
> > /sys/bus/pci/devices//uid. This ID was designed to serve as the PCI
> > device&#
On Wed, 2021-04-14 at 13:50 +, David Laight wrote:
> From: Niklas Schnelle
> > Sent: 14 April 2021 13:35
> >
> > On Tue, 2021-04-13 at 14:12 +, David Laight wrote:
> > > From: Arnd Bergmann
> > > > Sent: 13 April 2021 14:40
> > > >
On Tue, 2021-04-13 at 14:12 +, David Laight wrote:
> From: Arnd Bergmann
> > Sent: 13 April 2021 14:40
> >
> > On Tue, Apr 13, 2021 at 3:06 PM David Laight
> > wrote:
> > > From: Arnd Bergmann
> > > > Sent: 13 April 2021 13:58
> > > ...
> > > > The remaining ones (csky, m68k, sparc32) need t
On Tue, 2021-04-13 at 14:26 +0200, Arnd Bergmann wrote:
> On Tue, Apr 13, 2021 at 1:54 PM Niklas Schnelle
> wrote:
> > When PCI_IOBASE is not defined, it is set to 0 such that it is ignored
> > in calls to the readX/writeX primitives. While mathematically obvious
> > this
s in drivers. Instead use "uintptr_t" for PCI_IOBASE
0 and explicitly cast to "void __iomem *" when calling readX/writeX.
Signed-off-by: Niklas Schnelle
---
include/asm-generic/io.h | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/includ
On Tue, 2021-04-13 at 10:32 +0300, Leon Romanovsky wrote:
> On Tue, Apr 13, 2021 at 08:57:19AM +0200, Niklas Schnelle wrote:
> > On Tue, 2021-04-13 at 08:39 +0300, Leon Romanovsky wrote:
> > > On Mon, Apr 12, 2021 at 03:59:04PM +0200, Niklas Schnelle wrote:
> >
On Tue, 2021-04-13 at 08:39 +0300, Leon Romanovsky wrote:
> On Mon, Apr 12, 2021 at 03:59:04PM +0200, Niklas Schnelle wrote:
> > Hi Narendra, Hi All,
> >
> > According to Documentation/ABI/testing/sysfs-bus-pci you are responsible
> > for the index device attribute
space infrastructure.
Thanks,
Niklas Schnelle
Niklas Schnelle (1):
s390/pci: expose a PCI device's UID as its index
Documentation/ABI/testing/sysfs-bus-pci | 11 +---
arch/s390/pci/pci_sysfs.c | 35 +
2 files changed, 42 insertions(+), 4 deletions(-)
--
2.25.1
systemd's
interface naming support for free.
Signed-off-by: Niklas Schnelle
Acked-by: Viktor Mihajlovski
---
Documentation/ABI/testing/sysfs-bus-pci | 11 +---
arch/s390/pci/pci_sysfs.c | 35 +
2 files changed, 42 insertions(+), 4 deletions(-)
diff
On Thu, 2021-04-01 at 20:46 +0800, Bixuan Cui wrote:
> The ioremap/iounmap is implemented in arch/s390/pci/pci.c.
> While CONFIG_PCI is disabled,the compilation error is reported:
> s390x-linux-gnu-ld: drivers/pcmcia/cistpl.o: in function `set_cis_map':
> cistpl.c:(.text+0x32a): undefined r
On 21/03/2021 16:51, Zhiqiang Liu wrote:
In disable_slot(), if we obtain desired PCI device
successfully by calling pci_get_slot(), we should
call pci_dev_put() to release its reference.
Thanks for the patch! This should however be fixed independently by
commit 0b13525c20fe ("s390/pci: fix
#x27;s interface
naming support for free.
Signed-off-by: Niklas Schnelle
Acked-by: Viktor Mihajlovski
---
Changes from RFC patch:
- Use sysfs_emit() instead of sprintf() (Thanks Krzysztof Wilczyński!)
Documentation/ABI/testing/sysfs-bus-pci | 11 +---
arch/s390/pci/pci_sysfs.c
ng hotplug testing, I overlooked several missing pci_dev_put() calls
for way too long. So let's add a debug print in pci_release_dev() making
it much easier to spot when the PCI device structure is not released
when it is supposed to.
Signed-off-by: Niklas Schnelle
---
drivers/pci/probe.c | 1 +
On 3/7/21 9:46 PM, Krzysztof Wilczyński wrote:
> Hi Niklas,
>
> [...]
>> +static ssize_t index_show(struct device *dev,
>> + struct device_attribute *attr, char *buf)
>> +{
>> +struct zpci_dev *zdev = to_zpci(to_pci_dev(dev));
>> +u32 index = ~0;
>> +
>> +if (zp
irectly. Thank you Greg for making me
realize that we were looking too much at just exposing platform details
instead of looking how existing interfaces could suit our purpose.
Thanks,
Niklas Schnelle
Niklas Schnelle (1):
s390/pci: expose a PCI device's UID as its index
Documentation/ABI/
#x27;s interface
naming support for free.
Signed-off-by: Niklas Schnelle
Acked-by: Viktor Mihajlovski
---
Documentation/ABI/testing/sysfs-bus-pci | 11 +---
arch/s390/pci/pci_sysfs.c | 36 +
2 files changed, 43 insertions(+), 4 deletions(-)
diff --git a
On 2/4/21 2:38 PM, Greg Kroah-Hartman wrote:
> On Thu, Feb 04, 2021 at 01:02:51PM +0100, Niklas Schnelle wrote:
>>
>>
>> On 2/4/21 11:40 AM, Greg Kroah-Hartman wrote:
>>> On Thu, Feb 04, 2021 at 10:43:53AM +0100, Niklas Schnelle wrote:
>>>> The globa
On 2/4/21 11:40 AM, Greg Kroah-Hartman wrote:
> On Thu, Feb 04, 2021 at 10:43:53AM +0100, Niklas Schnelle wrote:
>> The global UID uniqueness attribute exposes whether the platform
>> guarantees that the user-defined per-device UID attribute values
>> (/sys/bus/pci/device
/unique_uids
Signed-off-by: Niklas Schnelle
---
Documentation/ABI/testing/sysfs-bus-pci | 9 +
drivers/pci/pci-sysfs.c | 21 +
2 files changed, 30 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-bus-pci
b/Documentation/ABI/testing/sysfs-bus
n see this strictly requires the use of raw kobject handling and loses us
the direct relation with PCI so I wanted to give this just one more shot and
get your opinion on it.
Thanks,
Niklas
Niklas Schnelle (1):
PCI: Add s390 specific UID uniqueness attribute
Documentation/ABI/testing/sysfs-bu
On 1/21/21 6:28 PM, Greg Kroah-Hartman wrote:
> On Thu, Jan 21, 2021 at 06:04:52PM +0100, Niklas Schnelle wrote:
>>
>>
>> On 1/21/21 4:54 PM, Bjorn Helgaas wrote:
>>> [Greg may be able to help compare/contrast this s390 UID with udev
>>> persistent names
On 1/21/21 4:54 PM, Bjorn Helgaas wrote:
> [Greg may be able to help compare/contrast this s390 UID with udev
> persistent names]
>
> On Thu, Jan 21, 2021 at 04:31:55PM +0100, Niklas Schnelle wrote:
>> On 1/15/21 4:29 PM, Bjorn Helgaas wrote:
>>> On Fri, Jan 1
On 1/15/21 4:29 PM, Bjorn Helgaas wrote:
> On Fri, Jan 15, 2021 at 12:20:59PM +0100, Niklas Schnelle wrote:
>> On 1/14/21 5:14 PM, Greg Kroah-Hartman wrote:
>>> On Thu, Jan 14, 2021 at 04:51:17PM +0100, Niklas Schnelle wrote:
>>>> On 1/14/21 4:17 PM, Greg Kroah-Ha
On 1/19/21 9:02 PM, Matthew Rosato wrote:
> Some s390 PCI devices (e.g. ISM) perform I/O operations that have very
> specific requirements in terms of alignment as well as the patterns in
> which the data is read/written. Allowing these to proceed through the
> typical vfio_pci_bar_rw path will
On 1/20/21 6:10 PM, Matthew Rosato wrote:
> On 1/20/21 8:21 AM, Niklas Schnelle wrote:
>>
>>
>> On 1/19/21 9:02 PM, Matthew Rosato wrote:
>>> Some s390 PCI devices (e.g. ISM) perform I/O operations that have very
>> .. snip ...
>>> +
>>> +st
On 1/19/21 9:02 PM, Matthew Rosato wrote:
> Some s390 PCI devices (e.g. ISM) perform I/O operations that have very
.. snip ...
> +
> +static size_t vfio_pci_zdev_io_rw(struct vfio_pci_device *vdev,
> + char __user *buf, size_t count,
> +
On 1/15/21 4:29 PM, Bjorn Helgaas wrote:
> On Fri, Jan 15, 2021 at 12:20:59PM +0100, Niklas Schnelle wrote:
>> On 1/14/21 5:14 PM, Greg Kroah-Hartman wrote:
>>> On Thu, Jan 14, 2021 at 04:51:17PM +0100, Niklas Schnelle wrote:
>>>> On 1/14/21 4:17 PM, Greg Kroah-Ha
On 1/14/21 5:14 PM, Greg Kroah-Hartman wrote:
> On Thu, Jan 14, 2021 at 04:51:17PM +0100, Niklas Schnelle wrote:
>>
>>
>> On 1/14/21 4:17 PM, Greg Kroah-Hartman wrote:
>>> On Thu, Jan 14, 2021 at 04:06:11PM +0100, Niklas Schnelle wrote:
>>>>
>&g
On 1/14/21 4:17 PM, Greg Kroah-Hartman wrote:
> On Thu, Jan 14, 2021 at 04:06:11PM +0100, Niklas Schnelle wrote:
>>
>>
>> On 1/14/21 2:58 PM, Greg Kroah-Hartman wrote:
>>> On Thu, Jan 14, 2021 at 02:44:53PM +0100, Christian Brauner wrote:
>>>> On Thu
On 1/14/21 2:58 PM, Greg Kroah-Hartman wrote:
> On Thu, Jan 14, 2021 at 02:44:53PM +0100, Christian Brauner wrote:
>> On Thu, Jan 14, 2021 at 02:20:10PM +0100, Niklas Schnelle wrote:
>>>
>>>
>>> On 1/13/21 7:55 PM, Bjorn Helgaas wrote:
>>>>
On 1/13/21 7:55 PM, Bjorn Helgaas wrote:
> On Wed, Jan 13, 2021 at 08:47:58AM +0100, Niklas Schnelle wrote:
>> On 1/12/21 10:50 PM, Bjorn Helgaas wrote:
>>> On Mon, Jan 11, 2021 at 10:38:57AM +0100, Niklas Schnelle wrote:
>>>> We use the UID of a zPCI adapter, or t
On 1/12/21 10:50 PM, Bjorn Helgaas wrote:
> On Mon, Jan 11, 2021 at 10:38:57AM +0100, Niklas Schnelle wrote:
>> We use the UID of a zPCI adapter, or the UID of the function zero if
>> there are multiple functions in an adapter, as PCI domain if and only if
>> UID
ctive would be a great choice but I realize that there
currently are no platform specific attributes directly under
"/sys/bus/pci" so this clearly requires some discussion. What's your
thought on this and do you know of any other platform specific global
PCI attributes as I
domain
will be stable, yet currently there is no way to access this information
from userspace.
So let's solve this by showing the state of UID checking as a sysfs
attribute in /sys/bus/pci/uid_checking
Signed-off-by: Niklas Schnelle
---
Documentation/ABI/testing/sysfs-bus-pci | 11
st regards,
Niklas Schnelle
On 12/10/20 3:26 PM, Greg Kroah-Hartman wrote:
> From: Alexander Gordeev
>
> commit a2bd4097b3ec242f4de4924db463a9c94530e03a upstream.
>
> The directed MSIs are delivered to CPUs whose address is
> written to the MSI message address. The current code
On 12/10/20 4:51 PM, Matthew Rosato wrote:
> On 12/10/20 7:33 AM, Cornelia Huck wrote:
>> On Wed, 9 Dec 2020 15:27:46 -0500
>> Matthew Rosato wrote:
>>
>>> Today, ISM devices are completely disallowed for vfio-pci passthrough as
>>> QEMU will reject the device due to an (inappropriate) MSI-X c
On 12/3/20 12:19 PM, Dan Carpenter wrote:
> On Thu, Dec 03, 2020 at 11:52:48AM +0100, Niklas Schnelle wrote:
>>
>>
>> On 12/3/20 11:27 AM, Dan Carpenter wrote:
>>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/l
1ff3ff1a0b Sebastian Ott 2015-06-16 93 break;
> 7fc611ff3ff1a0b Sebastian Ott 2015-06-16 94 }
> fcf2f402937a669 Sebastian Ott 2013-12-18 95 zdev->fh =
> ccdf->fh;
> f606b3ef47c9f87 Pierre Morel2020-03-25 96
On 11/30/20 9:55 AM, Halil Pasic wrote:
> On Mon, 30 Nov 2020 09:30:33 +0100
> Niklas Schnelle wrote:
>
>> I'm not really familiar, with it but I think this is closely related
>> to what I asked Bernd Nerz. I fear that if CPUs go away we might already
>> be in
On 11/27/20 4:39 PM, Halil Pasic wrote:
> On Fri, 27 Nov 2020 11:08:10 +0100
> Niklas Schnelle wrote:
>
>>
>>
>> On 11/27/20 9:56 AM, Halil Pasic wrote:
>>> On Thu, 26 Nov 2020 18:00:37 +0100
>>> Alexander Gordeev wrote:
>>>
>>
On 11/27/20 9:56 AM, Halil Pasic wrote:
> On Thu, 26 Nov 2020 18:00:37 +0100
> Alexander Gordeev wrote:
>
>> The directed MSIs are delivered to CPUs whose address is
>> written to the MSI message data. The current code assumes
>> that a CPU logical number (as it is seen by the kernel)
>> is al
On 11/13/20 5:25 PM, Christoph Hellwig wrote:
> On Fri, Nov 13, 2020 at 02:15:59PM +0100, Niklas Schnelle wrote:
>>
>>
>> On 11/12/20 6:36 PM, Keith Busch wrote:
>>> On Thu, Nov 12, 2020 at 04:45:35PM +0100, Niklas Schnelle wrote:
>>>> You got to get
On 11/12/20 6:36 PM, Keith Busch wrote:
> On Thu, Nov 12, 2020 at 04:45:35PM +0100, Niklas Schnelle wrote:
>> You got to get something wrong, I hope in this case it's just the subject
>> of the cover letter :D
>
> I suppose the change logs could be worded a little
On 11/12/20 3:53 PM, Keith Busch wrote:
> On Thu, Nov 12, 2020 at 09:23:00AM +0100, Niklas Schnelle wrote:
>> while searching for a bug around zPCI + NVMe IRQ handling on a distro
>> kernel, I got confused around handling of the maximum number
>> of I/O queues in the NVMe
t half the performance in a fio test
but did not otherwise break things. I couldn't find a reason why
allocating only the I/O queues we actually use would be problematic in
the code either but I might have missed something of course.
Best regards,
Niklas Schnelle
Niklas Schnelle (2):
nvme-pci:
Signed-off-by: Niklas Schnelle
---
drivers/nvme/host/pci.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/nvme/host/pci.c b/drivers/nvme/host/pci.c
index 0578ff253c47..b56250b83bdf 100644
--- a/drivers/nvme/host/pci.c
+++ b/drivers/nvme/host/pci.c
@@ -2114,8 +
that in nvme_probe() we are allocating
for I/O queues that will never be used.
Fix this by moving the quirk handling into nvme_max_io_queues().
Signed-off-by: Niklas Schnelle
---
drivers/nvme/host/pci.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers
n Gunthorpe
> Cc: Dan Williams
> Cc: Kees Cook
> Cc: Andrew Morton
> Cc: John Hubbard
> Cc: Jérôme Glisse
> Cc: Jan Kara
> Cc: linux...@kvack.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-me...@vg
y the mail address) fixed and I'll happily apply.
Best regards,
Niklas Schnelle
On 10/12/20 4:19 PM, Daniel Vetter wrote:
> On Mon, Oct 12, 2020 at 04:03:28PM +0200, Niklas Schnelle wrote:
... snip
>>> Cc: Jason Gunthorpe
>>> Cc: Dan Williams
>>> Cc: K
... snip ...
>>> Cc: linux-me...@vger.kernel.org
>>> Cc: Niklas Schnelle
>>> Cc: Gerald Schaefer
>>> Cc: linux-s...@vger.kernel.org
>>> --
>>> v2: Move VM_IO | VM_PFNMAP checks around so they keep returning EINVAL
>>> like before
Hi Daniel,
freshly back from my vacation I've just taken a look at your patch.
First thanks for this fix and the detailed commit description.
Definitely makes sense to fix this and you can add my
Acked-by: Niklas Schnelle
Content wise it all looks sane and clear and since Gerald di
this is my fault.
Best regards,
Niklas Schnelle
On 9/24/20 6:26 AM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the vfio tree got a conflict in:
>
> arch/s390/pci/pci_bus.c
>
> between commit:
>
> abb95b7550f8 ("s390/pci: consol
7;re not matching the util_str_avail name in the response struct?
I think this is currently always an EBCDIC encoded string so the information
that
even if it looks like binary for anyone with a non-mainframe background
it is in fact a string seems quite helpful.
Other than that
Acke
Hi Matthew,
On 9/19/20 5:28 PM, Matthew Rosato wrote:
> 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
Acked-by: Niklas Schnelle
> ---
> arch/s390/inc
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/27/20 10:33 PM, Bjorn Helgaas wrote:
> On Thu, Aug 27, 2020 at 01:17:48PM -0600, Alex Williamson wrote:
>> On Thu, 27 Aug 2020 13:31:38 -0500
>> Bjorn Helgaas wrote:
>>
>>> Re the subject line, this patch does a lot more than just "introduce a
>>> flag"; AFAICT it actually enables important V
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
>
On 8/13/20 3:11 PM, Matthew Rosato wrote:
> On 8/13/20 8:34 AM, Niklas Schnelle wrote:
>>
>>
>> On 8/13/20 12:40 PM, Niklas Schnelle wrote:
>>>
>>>
>>> On 8/13/20 11:59 AM, Oliver O'Halloran wrote:
>>>> On Thu, Aug 13, 2020 at 7:0
On 8/13/20 12:40 PM, Niklas Schnelle wrote:
>
>
> On 8/13/20 11:59 AM, Oliver O'Halloran wrote:
>> On Thu, Aug 13, 2020 at 7:00 PM Niklas Schnelle
>> wrote:
>>>
>>>
>>> On 8/13/20 3:55 AM, Oliver O'Halloran wrote:
>>>> On
On 8/13/20 11:59 AM, Oliver O'Halloran wrote:
> On Thu, Aug 13, 2020 at 7:00 PM Niklas Schnelle
> wrote:
>>
>>
>> On 8/13/20 3:55 AM, Oliver O'Halloran wrote:
>>> On Thu, Aug 13, 2020 at 5:21 AM Matthew Rosato
>>> wrote:
>>>&
On 8/13/20 3:55 AM, Oliver O'Halloran wrote:
> On Thu, Aug 13, 2020 at 5:21 AM Matthew Rosato wrote:
>>
>> s390x has the notion of providing VFs to the kernel in a manner
>> where the associated PF is inaccessible other than via firmware.
>> These are not treated as typical VFs and access to th
On 8/13/20 3:59 AM, Oliver O'Halloran wrote:
> On Thu, Aug 13, 2020 at 6:33 AM Alex Williamson
> wrote:
>>
>> On Wed, 12 Aug 2020 15:21:11 -0400
>> Matthew Rosato wrote:
>>
... snip ...
>>
>> Is there too much implicit knowledge in defining a "detached VF"? For
>> example, why do we know that
On 7/9/20 8:34 PM, Parav Pandit wrote:
> On 7/9/2020 3:36 PM, Niklas Schnelle wrote:
>>
>> On 7/8/20 5:44 PM, Parav Pandit wrote:
... snip ..
>
>>>
>> As is the patch above fixes the dereference but results in the same
>> completion error
>&g
On 7/8/20 5:44 PM, Parav Pandit wrote:
... snip ..
>>
>
> It is likely because events_cleanup() freed the memory using kvfree() that
> health recovery context is trying to access in notifier chain.
>
> While reviewing I see few more errors as below.
> (a) mlx5_pci_err_detected() invokes mlx5_d
Hi Parav, Hi Shay,
On 7/8/20 12:43 PM, Parav Pandit wrote:
> Hi Niklas,
>
... snip ...
>>>
>
> Sorry for my late response.
> Yes, this looks good and I also found same in my analysis.
> With latest code mlx5_pci_close() already does drain_health_wq(), so the
> additional call in remove_one() is
Hello Saeed,
On 6/13/20 12:01 AM, Saeed Mahameed wrote:
> On Fri, 2020-06-12 at 15:09 +0200, Niklas Schnelle wrote:
>> Hello Parav, Hello Saeed,
>>
... snip ...
>>
>> So without really knowing anything about these functions I would
>> guess that with the de
es that sound plausible to you?
Best regards,
Niklas Schnelle
[0] dmesg output:
[ 36.447442] mlx5_core :00:00.0: poll_health:694:(pid 0): Fatal error 1
detected
[ 36.447450] mlx5_core :00:00.0: print_health_info:372:(pid 0):
assert_var[0] 0x
[ 36.447453] mlx5_core :
Hi Petr,
sorry for not reacting sooner, I was on holiday, saw your message but figured
it wasn't super critical.
Thanks for finding this issue and thank you Pierre and Vasily for stepping in.
Best,
Niklas Schnelle
On 5/28/20 11:08 AM, Petr Tesarik wrote:
> Hi all,
>
> just
these sysfs
links which are required for example by QEMU/libvirt.
Instead of duplicating the code refactor pci_iov_add_virtfn() to make
sysfs link creation callable separately.
Signed-off-by: Niklas Schnelle
Acked-by: Bjorn Helgaas
---
drivers/pci/iov.c
.
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
Acked-by: Bjorn Helgaas
---
arch/s390/include/asm/pci.h | 3 +-
arch/s390/include/asm/pci_clp.h | 3 +-
arch/s
currently the only case where
pdev->no_vf_scan is true I can of course split this into a separate patch
if requested but wanted to keep this together for the discussion.
This patch will go via the s390 tree once the first patch landed.
Best regards and your feedback is welcome,
Niklas Schne
On 5/6/20 11:10 PM, Bjorn Helgaas wrote:
> On Wed, May 06, 2020 at 05:41:38PM +0200, Niklas Schnelle wrote:
>> currently pci_iov_add_virtfn() scans the SR-IOV bars, adds the VF to the
>> bus and also creates the sysfs links between the newly added VF and its
>> parent
e s390 is currently the only case where
pdev->no_vf_scan is true I can of course split this into a separate patch
if requested but wanted to keep this together for the discussion.
Best regards and your feedback is welcome,
Niklas Schnelle
Niklas Schnelle (2):
PCI/IOV: Introduce pci_iov_sysfs_lin
these sysfs
links which are required for example by QEMU/libvirt.
Instead of duplicating the code introduce a new pci_iov_sysfs_link()
function for establishing sysfs links.
Signed-off-by: Niklas Schnelle
---
drivers/pci/iov.c | 36
include/linux/pci.
.
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
---
arch/s390/include/asm/pci.h | 3 +-
arch/s390/include/asm/pci_clp.h | 3 +-
arch/s390/pci/pci_bu
On 4/30/20 9:47 PM, Niklas Schnelle wrote:
>
>
> On 4/30/20 5:58 PM, Saeed Mahameed wrote:
>> On Thu, 2020-04-30 at 14:03 +0200, Niklas Schnelle wrote:
>>> as described in Documentation/PCI/pci-iov-howto.rst a driver with SR-
>>> IOV
>>> support sho
On 4/30/20 6:13 PM, Saeed Mahameed wrote:
> On Thu, 2020-04-30 at 14:03 +0200, Niklas Schnelle wrote:
>> Hello,
>>
>> I'm currently working on improvements in PF-VF handling on s390. One
>> thing that
>> may be a bit special for us is that the s390 hotpl
On 4/30/20 5:58 PM, Saeed Mahameed wrote:
> On Thu, 2020-04-30 at 14:03 +0200, Niklas Schnelle wrote:
>> as described in Documentation/PCI/pci-iov-howto.rst a driver with SR-
>> IOV
>> support should call pci_disable_sriov() in the remove handler.
>
> Hi
mlx5_device_disable_sriov() which is called by both.
Signed-off-by: Niklas Schnelle
---
drivers/net/ethernet/mellanox/mlx5/core/sriov.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/sriov.c
b/drivers/net/ethernet/mellanox/mlx5/core/sriov.c
index
ly missing something here in that case excuse my
ignorance.
Best regards,
Niklas Schnelle
Niklas Schnelle (1):
net/mlx5: Call pci_disable_sriov() on remove
drivers/net/ethernet/mellanox/mlx5/core/sriov.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--
2.17.1
83 matches
Mail list logo
