Re: quirk_e100_interrupt() called too early

On Thursday 28 June 2007 10:01:08 am Kok, Auke wrote: Marian Balakowicz wrote: I am enabling and testing PCI on tqm5200 mpc5200 based board where I faced the following issue. I am using EEPRO100 PCI card for which there is specific quirk_e100_interrupt that tries to disable interrupts

Re: [patch 7/9] e100: disable interrupts at boot

On Thursday 27 April 2006 04:00, Jeff Garzik wrote: [EMAIL PROTECTED] wrote: From: Bjorn Helgaas [EMAIL PROTECTED] Apparently the Intel PRO/100 device enables interrupts on reset. Unless firmware explicitly disables PRO/100 interrupts, we can get a flood of interrupts when a driver

e100: disable interrupts at boot

: http://bugzilla.kernel.org/show_bug.cgi?id=5918 Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED] Index: work-mm5/drivers/pci/quirks.c === --- work-mm5.orig/drivers/pci/quirks.c 2006-04-03 15:04:33.0 -0600 +++ work-mm5

Re: e100: disable interrupts at boot

On Wednesday 05 April 2006 15:52, Roland Dreier wrote: + case 0x1030 ... 0x1034: Do we use the gcc case range extension in the kernel? (This is an honest question -- I don't think I've seen it used anywhere, and I'd be curious to know what the taste arbiters think of it) There are a

Re: Request for advice on where to put Root Complex fix up code for downstream device

Hi Casey, On Thu, May 07, 2015 at 12:34:51AM +, Casey Leedom wrote: Hello, I've included both the Network and PCI Development mailing lists because this crosses both domains. If this violates protocols, I apologise in advance. I believe that this ~probably~ will be a PCI

Re: [PATCH net-next v3 1/2] pci: Add Cavium PCI vendor id

Hi Aleksey, On Fri, May 15, 2015 at 10:36 PM, Aleksey Makarov aleksey.maka...@auriga.com wrote: Signed-off-by: Aleksey Makarov aleksey.maka...@auriga.com --- include/linux/pci_ids.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h

Re: [V4 PATCH 3/6] pci: Generic function for setting up PCI device DMA coherency

On Fri, May 15, 2015 at 4:23 PM, Suravee Suthikulpanit suravee.suthikulpa...@amd.com wrote: This patch refactors of_pci_dma_configure() into a more generic pci_dma_configure(), which can be reused by non-OF code. Then, it adds support for setting up PCI device DMA coherency from ACPI _CCA

[PATCH] net/mlx4: Avoid 'may be used uninitialized' warnings

to avoid the warnings. Signed-off-by: Bjorn Helgaas bhelg...@google.com --- .../net/ethernet/mellanox/mlx4/resource_tracker.c |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c b/drivers/net/ethernet/mellanox/mlx4

Re: [PATCH net-next v3 1/2] pci: Add Cavium PCI vendor id

On Mon, May 18, 2015 at 11:41 AM, David Miller da...@davemloft.net wrote: From: Bjorn Helgaas bhelg...@google.com Date: Mon, 18 May 2015 11:35:20 -0500 [+cc Greg] On Sat, May 16, 2015 at 4:14 PM, David Miller da...@davemloft.net wrote: From: Bjorn Helgaas bhelg...@google.com Date: Sat, 16

Re: [PATCH net-next v3 1/2] pci: Add Cavium PCI vendor id

[+cc Greg] On Sat, May 16, 2015 at 4:14 PM, David Miller da...@davemloft.net wrote: From: Bjorn Helgaas bhelg...@google.com Date: Sat, 16 May 2015 09:49:40 -0500 Hi Aleksey, On Fri, May 15, 2015 at 10:36 PM, Aleksey Makarov aleksey.maka...@auriga.com wrote: Signed-off-by: Aleksey Makarov

e1000e pci_disable_link_state_locked() issues

I think we have some issues with the e1000e usage of pci_disable_link_state_locked(), which Yinghai added with 9f728f53dd70 (PCI/e1000e: Add and use pci_disable_link_state_locked()). That fixed an AER deadlock in the following path, where pci_bus_sem is held by pci_walk_bus(), and we deadlocked

Re: [PATCH V3 0/2] pci: Provide a flag to access VPD through function 0

On Wed, Jun 17, 2015 at 11:29 AM, Rustad, Mark D mark.d.rus...@intel.com wrote: + Alex On Jun 5, 2015, at 2:59 PM, Rustad, Mark D mark.d.rus...@intel.com wrote: On Jun 3, 2015, at 11:46 AM, Mark D Rustad mark.d.rus...@intel.com wrote: Many multi-function devices provide shared registers in

Re: Request for advice on where to put Root Complex fix up code for downstream device

Hi Casey, Sorry, this one slipped through and I forgot to respond earlier. On Thu, May 07, 2015 at 11:31:58PM +, Casey Leedom wrote: | From: Bjorn Helgaas [bhelg...@google.com] | Sent: Thursday, May 07, 2015 4:04 PM | | There are a lot of fixups in drivers/pci/quirks.c. For things

Re: Request for advice on where to put Root Complex fix up code for downstream device

the Root Complex Port for a given PCI Device? It seem like it might prove useful in the future. Otherwise I'll just incorporate that loop in my PCI Quirk. Sure, I wouldn't mind seeing a new interface for that. Bjorn From: Bjorn Helgaas [bhelg

Re: [PATCH] pci: Use a bus-global mutex to protect VPD operations

On Mon, May 18, 2015 at 05:00:37PM -0700, Mark D Rustad wrote: Some devices have a problem with concurrent VPD access to different functions of the same physical device, so move the protecting mutex from the pci_vpd structure to the pci_bus structure. There are a number of reports on support

Re: [PATCH V4 0/2] pci: Provide a flag to access VPD through function 0

on function 0 or there will be an infinite recursion. Signed-off-by: Mark Rustad mark.d.rus...@intel.com Signed-off-by: Bjorn Helgaas bhelg...@google.com Acked-by: Alexander Duyck alexander.h.du...@redhat.com CC: sta...@vger.kernel.org commit

Re: [Intel-wired-lan] [PATCH V3 0/2] pci: Provide a flag to access VPD through function 0

On Mon, Jul 6, 2015 at 12:31 PM, Rustad, Mark D mark.d.rus...@intel.com wrote: On Jun 26, 2015, at 11:04 AM, Rustad, Mark D mark.d.rus...@intel.com wrote: Sorry, Mark, I've just been busy with other issues and haven't had a chance to look at this yet. Is there any chance of this getting into

Re: [PATCH 1/2] PCI: Add mechanism to find topologically near cores

Hi Daniel, On Wed, Dec 23, 2015 at 06:01:40PM +0800, Daniel J Blueman wrote: > Some devices (eg ixgbe) make assumptions about device to core locality when > specifying interrupts locality hints and allocate starting from core 0. > Moreover, interrupts may not be routable to distant NUMA nodes due

Re: [PATCH v3 0/6] Introduce pci_(request|release)_(mem|io)_regions

On Tue, Jun 07, 2016 at 09:44:00AM +0200, Johannes Thumshirn wrote: > The first patch in this series introduces the following 4 helper functions to > the PCI core: > > * pci_request_mem_regions() > * pci_request_io_regions() > * pci_release_mem_regions() > * pci_release_io_regions() > > which

Re: mlx4 fails ("go bit not cleared") without MSI

On Wed, Jan 20, 2016 at 3:42 AM, Yishai Hadas <yish...@mellanox.com> wrote: >> From: Bjorn Helgaas [mailto:bhelg...@google.com] >> I assume you're tried booting with "pci=nomsi" or "mlx_core.msi_x=0" >> and it works for you? Note that my board might be

[PATCH] Revert "netpoll: Fix extra refcount release in netpoll_cleanup()"

This reverts commit 543e3a8da5a4c453e992d5351ef405d5e32f27d7. Direct callers of __netpoll_setup() depend on it to set np->dev, so we can't simply move that assignment up to netpoll_stup(). Reported-by: Bart Van Assche <bart.vanass...@sandisk.com> Signed-off-by: Bjorn Helgaas <bhelg..

[PATCH v2] net: Fix typos and whitespace.

Fix typos. Capitalize CPU, NAPI, RCU consistently. Align structure indentation. No functional change intended; only comment and whitespace changes. Signed-off-by: Bjorn Helgaas <bhelg...@google.com> --- include/linux/netdevice.h | 215 ++---

[PATCH] netpoll: Fix extra refcount release in netpoll_cleanup()

don't set np->dev until we know we're going to succeed. Signed-off-by: Bjorn Helgaas <bhelg...@google.com> --- net/core/netpoll.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/core/netpoll.c b/net/core/netpoll.c index 94acfc8..32e373e 100644 --- a/net/core/n

Re: [PATCH v2] netpoll: Fix extra refcount release in netpoll_cleanup()

On Fri, Mar 25, 2016 at 07:33:42AM -0400, Neil Horman wrote: > On Thu, Mar 24, 2016 at 09:56:21PM -0500, Bjorn Helgaas wrote: > > netpoll_setup() does a dev_hold() on np->dev, the netpoll device. If it > > fails, it correctly does a dev_put() but leaves np->

netpoll rtnl_dereference() usage

Hi Neil, Since we're looking at netpoll, here's another question (or two). 0790bbb68f9d ("netpoll: cleanup sparse warnings") adds this: @@ -1236,7 +1236,11 @@ void __netpoll_cleanup(struct netpoll *np) struct netpoll_info *npinfo; unsigned long flags; - npinfo =

[PATCH] net: Fix typos and whitespace.

Fix typos. Capitalize CPU, NAPI, RCU consistently. Align structure indentation. No functional change intended; only comment and whitespace changes. Signed-off-by: Bjorn Helgaas <bhelg...@google.com> --- include/linux/netdevice.h | 215 ++---

Re: [PATCH] net: Fix typos and whitespace.

[+cc Vlad] On Wed, Mar 23, 2016 at 08:45:30AM -0500, Bjorn Helgaas wrote: > Fix typos. Capitalize CPU, NAPI, RCU consistently. Align structure > indentation. No functional change intended; only comment and whitespace > changes. > > Signed-off-by: Bjorn Helgaas <b

[PATCH v2] netpoll: Fix extra refcount release in netpoll_cleanup()

r np->dev at the points where we dev_hold() and dev_put() the device. Signed-off-by: Bjorn Helgaas <bhelg...@google.com> --- net/core/netpoll.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/core/netpoll.c b/net/core/netpoll.c index 94acfc8..a57bd17 100644 --- a/net/co

Re: [PATCH pci] pci: Add helper function to set VPD size

On Fri, Apr 15, 2016 at 11:12:02AM -0500, Steve Wise wrote: > On 4/14/2016 1:35 PM, Steve Wise wrote: > >>The fix is to add a PCI helper function to set the VPD size, so the > >>driver can expicitly set the exact size of the VPD. > >> > >>Fixes commit 104daa71b396 ("PCI: Determine actual VPD size

Re: [PATCH pci] pci: Add helper function to set VPD size

utes the valid VPD size by parsing the VPD starting at offset 0x0. We don't attempt to read past that valid size because that causes some devices to crash. However, some devices do have data past that valid size. For example, Chelsio adapters contain two VPD structures, and the driver

Re: [PATCH v4 0/7] thunderbolt: Introducing Thunderbolt(TM) networking

On Mon, Jul 18, 2016 at 01:00:33PM +0300, Amir Levy wrote: > This is version 4 of Thunderbolt(TM) driver for non-Apple hardware. > > Changes since v3: > - Moved new Thunderbolt device IDs from pci_ids.h to icm_nhi.h. > - Cleanup and added some comments in code. > > These patches were pushed to

Re: [PATCH] vmxnet3: Move PCI Id to pci_ids.h

On Fri, Aug 05, 2016 at 11:00:39AM -0700, Adit Ranadive wrote: > The VMXNet3 PCI Id will be shared with our upcoming paravirtual RDMA > driver. Moved it to the shared location in pci_ids.h and updated the > driver version. > > Suggested-by: Leon Romanovsky > Signed-off-by: Adit

Re: [PATCH v2] PCI: lock each enable/disable num_vfs operation in sysfs

On Fri, Jan 06, 2017 at 01:59:08PM -0800, Emil Tantilov wrote: > Enabling/disabling SRIOV via sysfs by echo-ing multiple values > simultaneously: > > echo 63 > /sys/class/net/ethX/device/sriov_numvfs& > echo 63 > /sys/class/net/ethX/device/sriov_numvfs > > sleep 5 > > echo 0 >

Re: linux <=4.9.5, 4.10-rc7 ok, 4.9.6 - 4.9.8 nok with realtek wlan, atom

[+cc rtl8192ce folks in case they've seen this] On Thu, Feb 09, 2017 at 03:45:01PM +0100, rupert THURNER wrote: > hi, > > not technical expert enough, i just wanted to give a short user > feedback. for realtek wlan on atom, kernels up to 4.9.5 are ok, and > kernel 4.10.0-rc7-g926af6273fc6 (arch

Re: [RFC PATCH kernel] PCI: Enable access to custom VPD for Chelsio devices (cxgb3)

Hi Alexey, On Thu, Aug 11, 2016 at 08:03:29PM +1000, Alexey Kardashevskiy wrote: > There is at least one Chelsio 10Gb card which uses VPD area to store > some custom blocks (example below). However pci_vpd_size() returns > the length of the first block only assuming that there can be only > one

Re: [PATCH v4 01/16] vmxnet3: Move PCI Id to pci_ids.h

ad...@vmware.com> Acked-by: Bjorn Helgaas <bhelg...@google.com> > --- > --- > drivers/net/vmxnet3/vmxnet3_int.h | 3 +-- > include/linux/pci_ids.h | 1 + > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/vmxnet3/vmxnet3_int.h

Re: [net-next 5/5] PCI: disable FLR for 82579 device

rote: > > On Tue, 27 Sep 2016 13:17:02 -0500 > > Bjorn Helgaas <helg...@kernel.org> wrote: > > > >> On Sun, Sep 25, 2016 at 10:02:43AM +0300, Neftin, Sasha wrote: > >> > On 9/24/2016 12:05 AM, Jeff Kirsher wrote: > >> > >On Fri, 2016-09

Re: [net-next 5/5] PCI: disable FLR for 82579 device

On Thu, Sep 22, 2016 at 11:39:01PM -0700, Jeff Kirsher wrote: > From: Sasha Neftin > > 82579 has a problem reattaching itself after the device is detached. > The bug was reported by Redhat. The suggested fix is to disable > FLR capability in PCIe configuration space. > >

Re: [PATCH v4 01/16] vmxnet3: Move PCI Id to pci_ids.h

On Wed, Sep 14, 2016 at 07:36:34PM +, Adit Ranadive wrote: > On Wed, Sep 14, 2016 at 09:25:18 -0700, Yuval Shaia wrote: > > On Wed, Sep 14, 2016 at 04:00:25PM +, Adit Ranadive wrote: > > > On Wed, Sep 14, 2016 at 04:09:12 -0700, Yuval Shaia wrote: > > > > Please update vmxnet3_drv.c

Re: [net-next 5/5] PCI: disable FLR for 82579 device

On Sun, Sep 25, 2016 at 10:02:43AM +0300, Neftin, Sasha wrote: > On 9/24/2016 12:05 AM, Jeff Kirsher wrote: > >On Fri, 2016-09-23 at 09:01 -0500, Bjorn Helgaas wrote: > >>On Thu, Sep 22, 2016 at 11:39:01PM -0700, Jeff Kirsher wrote: > >>>From: Sasha Neftin <sasha.n

Re: [PATCH v5 00/16] Add Paravirtual RDMA Driver

On Sat, Sep 24, 2016 at 04:21:24PM -0700, Adit Ranadive wrote: > MAINTAINERS|9 + > drivers/infiniband/Kconfig |1 + > drivers/infiniband/hw/Makefile |1 + > drivers/infiniband/hw/pvrdma/Kconfig |7 +

Re: [PATCH kernel v3] PCI: Enable access to custom VPD for Chelsio devices (cxgb3)

On Mon, Oct 24, 2016 at 06:04:17PM +1100, Alexey Kardashevskiy wrote: > There is at least one Chelsio 10Gb card which uses VPD area to store > some custom blocks (example below). However pci_vpd_size() returns > the length of the first block only assuming that there can be only > one VPD "End Tag"

mlx4 BUG_ON in probe path

Hi Yishai, Johannes has been working on an mlx4 initialization problem on an IBM x3850 X6. The underlying problem is a PCI core issue -- we're setting RCB in the Mellanox device, which means it thinks it can generate 128-byte Completions, even though the Root Port above it can't handle them.

Re: kill off pci_enable_msi_{exact,range}

On Fri, Jan 13, 2017 at 09:05:53AM +0100, Christoph Hellwig wrote: > On Fri, Jan 13, 2017 at 08:55:03AM +0100, Christoph Hellwig wrote: > > On Thu, Jan 12, 2017 at 03:29:00PM -0600, Bjorn Helgaas wrote: > > > Applied all three (with Tom's ack on the amd-xgbe patch) to pci/m

Re: kill off pci_enable_msi_{exact,range}

On Mon, Jan 09, 2017 at 09:37:37PM +0100, Christoph Hellwig wrote: > I had hope that we could kill these old interfaces of for 4.10-rc, > but as of today Linus tree still has two users: > > (1) the cobalt media driver, for which I sent a patch long time ago, > it got missed in the merge

Re: [PATCH 5/5] PCI: remove pci_enable_msix

On Tue, Mar 28, 2017 at 09:24:15AM -0700, David Daney wrote: > On 03/27/2017 11:41 PM, Christoph Hellwig wrote: > >On Mon, Mar 27, 2017 at 10:30:46AM -0700, David Daney wrote: > >>>Use pci_enable_msix_{exact,range} for now, as I told you before. > >>> > >> > >>That still results in twice as many

Re: [PATCH 5/5] PCI: remove pci_enable_msix

On Mon, Mar 27, 2017 at 10:29:36AM +0200, Christoph Hellwig wrote: > Unused now that all callers switched to pci_alloc_irq_vectors. > > Signed-off-by: Christoph Hellwig <h...@lst.de> Acked-by: Bjorn Helgaas <bhelg...@google.com> I assume this will be merged with the res

Re: [PATCH 4/4] PCI: remove pci_enable_msix

ga3...@bhelgaas-glaptop.roam.corp.google.com) Acked-by: Bjorn Helgaas <bhelg...@google.com> > --- > drivers/pci/msi.c | 21 - > include/linux/pci.h | 4 > 2 files changed, 25 deletions(-) > > diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c &g

Re: export pcie_flr and remove copies of it in drivers

On Fri, Apr 14, 2017 at 9:41 AM, Bjorn Helgaas <helg...@kernel.org> wrote: > On Thu, Apr 13, 2017 at 04:53:32PM +0200, Christoph Hellwig wrote: >> Hi all, >> >> this exports the PCI layer pcie_flr helper, and removes various opencoded >> copies of it. > &g

Re: [PATCH 1/7] PCI: export pcie_flr

[+cc Alex] On Thu, Apr 13, 2017 at 04:53:33PM +0200, Christoph Hellwig wrote: > Currently we opencode the FLR sequence in lots of place, export a core > helper instead. We split out the probing for FLR support as all the > non-core callers already know their hardware. > > Signed-off-by:

Re: export pcie_flr and remove copies of it in drivers

non-PCI tree, here's my ack for the drivers/pci parts, assuming the probe thing is resolved: Acked-by: Bjorn Helgaas <bhelg...@google.com> Otherwise, I'd be glad to take the series given acks for the non-PCI parts. Just let me know. Bjorn

Re: export pcie_flr and remove copies of it in drivers V2

On Fri, Apr 14, 2017 at 09:11:24PM +0200, Christoph Hellwig wrote: > Hi all, > > this exports the PCI layer pcie_flr helper, and removes various opencoded > copies of it. > > Changes since V1: > - rebase on top of the pci/virtualization branch > - fixed the probe case in __pci_dev_reset > -

Re: Legacy features in PCI Express devices

On Mon, Mar 13, 2017 at 05:10:57PM +0100, Mason wrote: > Hello, > > There are two revisions of our PCI Express controller. > > Rev 1 did not support the following features: > > 1) legacy PCI interrupt delivery (INTx signals) > 2) I/O address space > > Internally, someone stated that such

Re: [PATCH] PCI: Update ACS quirk for more Intel 10G NICs

On Thu, Jul 20, 2017 at 02:41:01PM -0700, Roland Dreier wrote: > From: Roland Dreier > > Add one more variant of the 82599 plus the device IDs for X540 and X550 > variants. Intel has confirmed that none of these devices does peer-to-peer > between functions. The X540

Re: [PATCH net RESEND] PCI: fix oops when try to find Root Port for a PCI device

On Tue, Aug 15, 2017 at 11:24:48PM +0800, Ding Tianhong wrote: > Eric report a oops when booting the system after applying > the commit a99b646afa8a ("PCI: Disable PCIe Relaxed..."): > ... > It looks like the pci_find_pcie_root_port() was trying to > find the Root Port for the PCI device which is

Re: [PATCH v6 0/3] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

On Thu, Jul 06, 2017 at 08:58:51PM +0800, Ding Tianhong wrote: > Hi Bjorn: > > Could you please give some feedback about this patchset, it looks like no > more comments for more than a week, > thanks. :) I was on vacation when you posted it, but don't worry, it's still in the queue:

Re: [PATCH 5/7] IB/hfi1: use pcie_flr instead of duplicating it

On Thu, Apr 27, 2017 at 08:47:58AM +0200, Christoph Hellwig wrote: > On Tue, Apr 25, 2017 at 02:39:55PM -0500, Bjorn Helgaas wrote: > > This still leaves these: > > > > [PATCH 4/7] ixgbe: use pcie_flr instead of duplicating it > > [PATCH 6/7] crypto: qat: use pcie

Re: [PATCH net-next 1/4] ixgbe: sparc: rename the ARCH_WANT_RELAX_ORDER to IXGBE_ALLOW_RELAXED_ORDER

[+cc Casey] On Wed, Apr 26, 2017 at 09:18:33AM -0700, Alexander Duyck wrote: > On Wed, Apr 26, 2017 at 2:26 AM, Ding Tianhong > wrote: > > Hi Amir: > > > > It is really glad to hear that the mlx5 will support RO mode this year, if > > so, do you agree that enable it

Re: [PATCH 5/7] IB/hfi1: use pcie_flr instead of duplicating it

On Mon, Apr 24, 2017 at 04:35:07PM +0200, Christoph Hellwig wrote: > On Mon, Apr 24, 2017 at 02:16:31PM +, Byczkowski, Jakub wrote: > > Tested-by: Jakub Byczkowski > > Are you (and Doug) ok with queueing this up in the PCI tree? Applied this with Jakub's

Re: [PATCH v9 1/4] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING

On Sat, Aug 05, 2017 at 03:15:10PM +0800, Ding Tianhong wrote: > From: Casey Leedom > > The patch adds a new flag PCI_DEV_FLAGS_NO_RELAXED_ORDERING to indicate that > Relaxed Ordering (RO) attribute should not be used for Transaction Layer > Packets (TLP) targetted towards

Re: [PATCH v9 0/4] Add new PCI_DEV_FLAGS_NO_RELAXED_ORDERING flag

On Mon, Aug 07, 2017 at 02:14:48PM -0700, David Miller wrote: > From: Ding Tianhong > Date: Mon, 7 Aug 2017 12:13:17 +0800 > > > Hi David： > > > > I think networking tree merge it is a better choice, as it mainly used to > > tell the NIC > > drivers how to use the

Re: [PATCH v9 2/4] PCI: Disable PCIe Relaxed Ordering if unsupported

On Tue, Aug 08, 2017 at 09:22:39PM -0500, Bjorn Helgaas wrote: > On Sat, Aug 05, 2017 at 03:15:11PM +0800, Ding Tianhong wrote: > > When bit4 is set in the PCIe Device Control register, it indicates > > whether the device is permitted to use relaxed ordering. > > On some pl

Re: [PATCH v9 2/4] PCI: Disable PCIe Relaxed Ordering if unsupported

On Sat, Aug 05, 2017 at 03:15:11PM +0800, Ding Tianhong wrote: > When bit4 is set in the PCIe Device Control register, it indicates > whether the device is permitted to use relaxed ordering. > On some platforms using relaxed ordering can have performance issues or > due to erratum can cause

Re: [PATCH v9 1/4] PCI: Add new PCIe Fabric End Node flag, PCI_DEV_FLAGS_NO_RELAXED_ORDERING

On Wed, Aug 09, 2017 at 01:40:01AM +, Casey Leedom wrote: > | From: Bjorn Helgaas <helg...@kernel.org> > | Sent: Tuesday, August 8, 2017 4:22 PM > | > | This needs to include a link to the Intel spec > | > (https://software.intel.com/sites/default/files/managed/9e/b

Re: [PATCH net RESEND] PCI: fix oops when try to find Root Port for a PCI device

On Wed, Aug 16, 2017 at 09:33:03PM +0200, Thierry Reding wrote: > On Tue, Aug 15, 2017 at 12:03:31PM -0500, Bjorn Helgaas wrote: > > On Tue, Aug 15, 2017 at 11:24:48PM +0800, Ding Tianhong wrote: > > > Eric report a oops when booting the system after applying > > > th

Re: [PATCH] PCI: Allow PCI express root ports to find themselves

ributes to avoid Chelsio T5 > Completion erratum") > Signed-off-by: Thierry Reding <tred...@nvidia.com> Acked-by: Bjorn Helgaas <bhelg...@google.com> I *think* this should work for everybody, but I can't test it personally. > --- > This applies on top of and was tes

Re: [PATCH 0/2] Replace driver's usage of hard-coded device IDs to #defines

; > Noa Osherovich introduced a series of new Mellanox device ID > > > definitions to help differentiate specific controllers that needed > > > INTx masking quirks [1]. > > > > > > Bjorn Helgaas followed on, using the device ID definitions Noa > > > pr

Re: [PATCH v1] ACPI: Switch to use generic UUID API

m> > Cc: Ben Skeggs <bske...@redhat.com> > Cc: Benjamin Tissoires <benjamin.tissoi...@redhat.com> > Cc: Joerg Roedel <j...@8bytes.org> > Cc: Adrian Hunter <adrian.hun...@intel.com> > Cc: Yisen Zhuang <yisen.zhu...@huawei.com> > Cc: Bjorn Helgaas &

Re: [Intel-wired-lan] [PATCH] PCI: Check/Set ARI capability before setting numVFs

On Thu, Oct 05, 2017 at 04:07:41PM -0500, Bjorn Helgaas wrote: > On Wed, Oct 04, 2017 at 04:29:14PM -0700, Alexander Duyck wrote: > > On Wed, Oct 4, 2017 at 4:01 PM, Bjorn Helgaas <helg...@kernel.org> wrote: > > > On Wed, Oct 04, 2017 at 08:52:58AM -0700, Tony Nguyen wrote:

[PATCH] bnx2x: Use pci_ari_enabled() instead of local copy

From: Bjorn Helgaas <bhelg...@google.com> Use pci_ari_enabled() from the PCI core instead of the identical local copy bnx2x_ari_enabled(). No functional change intended. Signed-off-by: Bjorn Helgaas <bhelg...@google.com> --- drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c |

Re: [PATCH v2 06/15] PCI: endpoint: make config_item_type const

ccinelle. > > Signed-off-by: Bhumika Goyal <bhumi...@gmail.com> Acked-by: Bjorn Helgaas <bhelg...@google.com> Please apply this along with the rest of the series, since it depends on an earlier patch in the series. > --- > * Changes in v2- Combine all the followup patch

Re: [Intel-wired-lan] [PATCH] PCI: Check/Set ARI capability before setting numVFs

On Wed, Oct 04, 2017 at 04:29:14PM -0700, Alexander Duyck wrote: > On Wed, Oct 4, 2017 at 4:01 PM, Bjorn Helgaas <helg...@kernel.org> wrote: > > On Wed, Oct 04, 2017 at 08:52:58AM -0700, Tony Nguyen wrote: > >> This fixes a bug that can occur if an AER error is encountered

Re: [PATCH] PCI: Check/Set ARI capability before setting numVFs

On Wed, Oct 04, 2017 at 08:52:58AM -0700, Tony Nguyen wrote: > This fixes a bug that can occur if an AER error is encountered while SRIOV > devices are present. > > This issue was seen by doing the following. Inject an AER error to a device > that has SRIOV devices. After the device has

[PATCH] qed: Remove unused QED_RDMA_DEV_CAP_* symbols and dev->dev_caps

From: Bjorn Helgaas <bhelg...@google.com> The QED_RDMA_DEV_CAP_* symbols are only used to set bits in dev->dev_caps. Nobody ever looks at those bits. Remove the symbols and dev_caps itself. Note that if these are ever used and added back, it looks incorrect to set QED_RDMA_DEV_CAP_

[PATCH] cxgb4: Simplify PCIe Completion Timeout setting

From: Bjorn Helgaas <bhelg...@google.com> Simplify PCIe Completion Timeout setting by using the pcie_capability_clear_and_set_word() interface. No functional change intended. Signed-off-by: Bjorn Helgaas <bhelg...@google.com> --- drivers/net/ethernet/chelsio/cxgb4/t4

Re: [PATCH v15 5/5] PCI: Remove PCI pool macro functions

a.com> > Reviewed-by: Peter Senna Tschudin <peter.se...@collabora.com> I already acked this once on Oct 24. Please keep that ack and include it in any future postings so I don't have to deal with this again. Acked-by: Bjorn Helgaas <bhelg...@google.com> > --- > inc

Re: [PATCH 1/3] PCI: introduce a device-managed version of pci_set_mwi

e reordering below, PCI: Add pcim_set_mwi(), a device-managed pci_set_mwi() Add pcim_set_mwi(), a device-managed version of pci_set_mwi(). First user is the Realtek r8169 driver. Acked-by: Bjorn Helgaas <bhelg...@google.com> With these changes, feel free to merge with the se

Re: [PATCH v14 5/5] PCI: Remove PCI pool macro functions

a.com> > Reviewed-by: Peter Senna Tschudin <peter.se...@collabora.com> Acked-by: Bjorn Helgaas <bhelg...@google.com> Since this barely touches drivers/pci and linux-pci wasn't copied until v14, I assume you're planning to merge this via some other tree. Let me know if you need a

Re: [PATCH v6 5/5] PCI: Remove unused pcie_get_minimum_link()

On Thu, May 03, 2018 at 03:00:43PM -0500, Bjorn Helgaas wrote: > From: Bjorn Helgaas <bhelg...@google.com> > > In some cases pcie_get_minimum_link() returned misleading information > because it found the slowest link and the narrowest link without > considering the total

Re: [PATCH v6 0/5] PCI: Improve PCIe link status reporting

On Thu, May 03, 2018 at 03:00:07PM -0500, Bjorn Helgaas wrote: > This is based on Tal's recent work to unify the approach for reporting PCIe > link speed/width and whether the device is being limited by a slower > upstream link. > > The new pcie_print_link_status() interface appear

Re: [PATCH v6 0/5] PCI: Improve PCIe link status reporting

[+to Davem] On Thu, May 03, 2018 at 03:00:07PM -0500, Bjorn Helgaas wrote: > This is based on Tal's recent work to unify the approach for reporting PCIe > link speed/width and whether the device is being limited by a slower > upstream link. > > The new pcie_print_link_status() int

Re: [PATCH] PCI: allow drivers to limit the number of VFs to 0

On Thu, May 24, 2018 at 06:20:15PM -0700, Jakub Kicinski wrote: > Hi Bjorn! > > On Thu, 24 May 2018 18:57:48 -0500, Bjorn Helgaas wrote: > > On Mon, Apr 02, 2018 at 03:46:52PM -0700, Jakub Kicinski wrote: > > > Some user space depends on enabling sriov_totalvfs number

Re: [PATCH] PCI: allow drivers to limit the number of VFs to 0

On Fri, May 25, 2018 at 03:27:52PM -0400, Don Dutile wrote: > On 05/25/2018 10:02 AM, Bjorn Helgaas wrote: > > On Thu, May 24, 2018 at 06:20:15PM -0700, Jakub Kicinski wrote: > > > Hi Bjorn! > > > > > > On Thu, 24 May 2018 18:57:48 -0500, Bjorn Helgaas wrote: &

Re: [PATCH] PCI: allow drivers to limit the number of VFs to 0

, which has implications for VF enablement via the sysfs "sriov_numvfs" file.] On Fri, May 25, 2018 at 09:02:23AM -0500, Bjorn Helgaas wrote: > On Thu, May 24, 2018 at 06:20:15PM -0700, Jakub Kicinski wrote: > > Hi Bjorn! > > > > On Thu, 24 May 2018 18:57:48 -0500, Bj

Re: [PATCH] PCI: allow drivers to limit the number of VFs to 0

On Fri, May 25, 2018 at 02:05:21PM -0700, Jakub Kicinski wrote: > On Fri, 25 May 2018 09:02:23 -0500, Bjorn Helgaas wrote: > > On Thu, May 24, 2018 at 06:20:15PM -0700, Jakub Kicinski wrote: > > > On Thu, 24 May 2018 18:57:48 -0500, Bjorn Helgaas wrote: > > > > On M

Re: [PATCH] PCI: allow drivers to limit the number of VFs to 0

Hi Jakub, On Mon, Apr 02, 2018 at 03:46:52PM -0700, Jakub Kicinski wrote: > Some user space depends on enabling sriov_totalvfs number of VFs > to not fail, e.g.: > > $ cat .../sriov_totalvfs > .../sriov_numvfs > > For devices which VF support depends on loaded FW we have the >

Re: [PATCH] PCI: allow drivers to limit the number of VFs to 0

On Fri, May 25, 2018 at 09:02:23AM -0500, Bjorn Helgaas wrote: > On Thu, May 24, 2018 at 06:20:15PM -0700, Jakub Kicinski wrote: > > Hi Bjorn! > > > > On Thu, 24 May 2018 18:57:48 -0500, Bjorn Helgaas wrote: > > > On Mon, Apr 02, 2018 at 03:46:52PM -0700, Jakub Kic

[PATCH v6 4/5] ixgbe: Report PCIe link properties with pcie_print_link_status()

From: Bjorn Helgaas <bhelg...@google.com> Previously the driver used pcie_get_minimum_link() to warn when the NIC is in a slot that can't supply as much bandwidth as the NIC could use. pcie_get_minimum_link() can be misleading because it finds the slowest link and the narrowest link (whi

[PATCH v6 2/5] bnxt_en: Report PCIe link properties with pcie_print_link_status()

From: Bjorn Helgaas <bhelg...@google.com> Previously the driver used pcie_get_minimum_link() to warn when the NIC is in a slot that can't supply as much bandwidth as the NIC could use. pcie_get_minimum_link() can be misleading because it finds the slowest link and the narrowest link (whi

[PATCH v6 5/5] PCI: Remove unused pcie_get_minimum_link()

From: Bjorn Helgaas <bhelg...@google.com> In some cases pcie_get_minimum_link() returned misleading information because it found the slowest link and the narrowest link without considering the total bandwidth of the link. For example, consider a path with these two links: - 16.0 GT/s x

[PATCH v6 3/5] cxgb4: Report PCIe link properties with pcie_print_link_status()

From: Bjorn Helgaas <bhelg...@google.com> Previously the driver used pcie_get_minimum_link() to warn when the NIC is in a slot that can't supply as much bandwidth as the NIC could use. pcie_get_minimum_link() can be misleading because it finds the slowest link and the narrowest link (whi

[PATCH v6 0/5] PCI: Improve PCIe link status reporting

talk about it. I'm hoping the reduce code size, improved functionality, and consistency across drivers is enough to make this worthwhile. --- Bjorn Helgaas (5): bnx2x: Report PCIe link properties with pcie_print_link_status() bnxt_en: Report PCIe link properties with pcie_print_l

[PATCH v6 1/5] bnx2x: Report PCIe link properties with pcie_print_link_status()

From: Bjorn Helgaas <bhelg...@google.com> Previously the driver used pcie_get_minimum_link() to warn when the NIC is in a slot that can't supply as much bandwidth as the NIC could use. pcie_get_minimum_link() can be misleading because it finds the slowest link and the narrowest link (whi

Re: [PATCH 3/4] tsi108_eth: use dma API properly

[+cc David, FYI, I plan to merge this via PCI along with the rest of Christoph's series] On Wed, Jan 10, 2018 at 07:03:21PM +0100, Christoph Hellwig wrote: > We need to pass a struct device to the dma API, even if some > architectures still support that for legacy reasons, and should not mix > it

Re: remove pci_dma_* abuses and workarounds V2

[+cc David] On Wed, Jan 10, 2018 at 07:03:18PM +0100, Christoph Hellwig wrote: > Back before the dawn of time pci_dma_* with a NULL pci_dev argument > was used for all kinds of things, e.g. dma mapping for non-PCI > devices. All this has been long removed, but it turns out we > still care for a

Re: [REGRESSION, bisect] pci: cxgb4 probe fails after commit 104daa71b3961434 ("PCI: Determine actual VPD size on first access")

On Tue, Jan 23, 2018 at 05:59:09PM +0530, Arjun Vynipadath wrote: > Sending on behalf of "Casey Leedom " > > Way back on April 11, 2016 we reported a regression in Linux kernel 4.6-rc2 > brought on by kernel.org commit 104daa71b396. This commit calculates the > size of a PCI

Re: [PATCH v17 0/4] Replace PCI pool by DMA pool API

On Tue, Jan 02, 2018 at 04:17:24PM -0600, Bjorn Helgaas wrote: > On Tue, Jan 02, 2018 at 06:53:52PM +0100, Romain Perier wrote: > > The current PCI pool API are simple macro functions direct expanded to > > the appropriate dma pool functions. The prototypes are almost the same >

Re: [PATCH v17 0/4] Replace PCI pool by DMA pool API

On Tue, Jan 02, 2018 at 06:53:52PM +0100, Romain Perier wrote: > The current PCI pool API are simple macro functions direct expanded to > the appropriate dma pool functions. The prototypes are almost the same > and semantically, they are very similar. I propose to use the DMA pool > API directly

Re: [net-next 10/16] net/mlx5: Support PCIe buffer congestion handling via Devlink

On Sun, Jul 29, 2018 at 03:00:28PM -0700, Alexander Duyck wrote: > On Sun, Jul 29, 2018 at 2:23 AM, Moshe Shemesh wrote: > > On Sat, Jul 28, 2018 at 7:06 PM, Bjorn Helgaas wrote: > >> On Thu, Jul 26, 2018 at 07:00:20AM -0700, Alexander Duyck wrote: > >> > On Thu,

Re: [net-next 10/16] net/mlx5: Support PCIe buffer congestion handling via Devlink

On Thu, Jul 26, 2018 at 07:00:20AM -0700, Alexander Duyck wrote: > On Thu, Jul 26, 2018 at 12:14 AM, Jiri Pirko wrote: > > Thu, Jul 26, 2018 at 02:43:59AM CEST, jakub.kicin...@netronome.com wrote: > >>On Wed, 25 Jul 2018 08:23:26 -0700, Alexander Duyck wrote: > >>> On Wed, Jul 25, 2018 at 5:31

  1   2   >