On Mon, Apr 02, 2018 at 04:25:17PM +, Keller, Jacob E wrote:
> > -Original Message-
> > From: Bjorn Helgaas [mailto:helg...@kernel.org]
> > Sent: Friday, March 30, 2018 2:05 PM
> > To: Tal Gilboa
> > Cc: Tariq Toukan ; Keller, Jacob E
> > ; Ariel
On Mon, Apr 02, 2018 at 03:56:06PM +, Keller, Jacob E wrote:
> > -Original Message-
> > From: Bjorn Helgaas [mailto:helg...@kernel.org]
> > Sent: Friday, March 30, 2018 2:06 PM
> > To: Tal Gilboa
> > Cc: Tariq Toukan ; Keller, Jacob E
> > ; Ariel
On Mon, Apr 02, 2018 at 05:30:54PM -0700, Jacob Keller wrote:
> On Mon, Apr 2, 2018 at 7:05 AM, Bjorn Helgaas wrote:
> > +/* PCIe speed to Mb/s reduced by encoding overhead */
> > +#define PCIE_SPEED2MBS_ENC(speed) \
> > + ((speed) == PCIE_SPEED_16_
On Thu, Apr 12, 2018 at 09:32:49PM -0700, Jakub Kicinski wrote:
> On Fri, 30 Mar 2018 16:05:18 -0500, Bjorn Helgaas wrote:
> > + if (bw_avail >= bw_cap)
> > + pci_info(dev, "%d Mb/s available bandwidth (%s x%d link)\n",
> > +
efines for 2K and 4K Max Read Request Size
Acked-by: Bjorn Helgaas
I suspect conflicts are more likely in r8169.c so it might make more
sense to route these through the netdev tree. I'd also be happy to
take them, so let me know if you want me to take them, David.
> ---
> inclu
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 recovered
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 an
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
>
[+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(
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
> pci_sriov_{g,s}et_
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
, 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
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:
&
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
ume() and susend() callbacks
> definition to suppress compiler warnings.
>
> Generic callback requires an argument of type "struct device*". Hence,
> convert it to "struct net_device*" using "dev_get_drvdata()" to use
> it in the cal
On Tue, Apr 28, 2020 at 08:13:14PM +0530, Vaibhav Gupta wrote:
> Upgrade power management from legacy to generic using dev_pm_ops.
>
> Add "__maybe_unused" attribute to resume() and susend() callbacks
> definition to suppress compiler warnings.
>
> Generic callback requires an argument of type "s
[+cc Rajat]
On Tue, Apr 02, 2019 at 10:41:20PM +0200, Heiner Kallweit wrote:
> On 02.04.2019 22:16, Florian Fainelli wrote:
> > On 4/2/19 12:55 PM, Heiner Kallweit wrote:
> >> There are numerous reports about different problems caused by ASPM
> >> incompatibilities between certain network chip ver
[+cc Frederick]
On Wed, Apr 03, 2019 at 07:53:40AM +0200, Heiner Kallweit wrote:
> On 02.04.2019 23:57, Bjorn Helgaas wrote:
> > On Tue, Apr 02, 2019 at 10:41:20PM +0200, Heiner Kallweit wrote:
> >> On 02.04.2019 22:16, Florian Fainelli wrote:
> >>> On 4/2/19 1
On Wed, Apr 03, 2019 at 07:45:29PM +0200, Heiner Kallweit wrote:
> On 03.04.2019 15:14, Bjorn Helgaas wrote:
> > On Wed, Apr 03, 2019 at 07:53:40AM +0200, Heiner Kallweit wrote:
> >> On 02.04.2019 23:57, Bjorn Helgaas wrote:
> >>> On Tue, Apr 02, 2019 at 10:41:20P
On Tue, Apr 09, 2019 at 07:32:15PM +0200, Heiner Kallweit wrote:
> On 05.04.2019 21:28, Heiner Kallweit wrote:
> > On 05.04.2019 21:10, Bjorn Helgaas wrote:
> >> On Wed, Apr 03, 2019 at 07:45:29PM +0200, Heiner Kallweit wrote:
> >>> On 03.04.2019 15:14, Bjorn Helgaa
On Fri, Apr 19, 2019 at 03:13:38PM -0700, David Miller wrote:
> From: Heiner Kallweit
> Date: Fri, 19 Apr 2019 20:27:45 +0200
>
> > In several places in the kernel we find PCI_DEVID used like this:
> > PCI_DEVID(dev->bus->number, dev->devfn) Therefore create a helper
> > for it.
>
> I'll wait fo
On Tue, Jul 28, 2020 at 09:58:10AM +0530, Vaibhav Gupta wrote:
> The .suspend() and .resume() callbacks are not defined for this driver.
> Still, their power management structure follows the legacy framework. To
> bring it under the generic framework, simply remove the binding of
> callbacks from "
On Wed, Jul 29, 2020 at 03:47:30PM +0530, Vaibhav Gupta wrote:
> On Tue, Jul 28, 2020 at 03:04:13PM -0500, Bjorn Helgaas wrote:
> > On Tue, Jul 28, 2020 at 09:58:10AM +0530, Vaibhav Gupta wrote:
> > > The .suspend() and .resume() callbacks are not defined for this driver.
> &
On Sun, Aug 02, 2020 at 08:46:48PM +0200, Borislav Petkov wrote:
> On Sun, Aug 02, 2020 at 07:28:00PM +0200, Saheed Bolarinwa wrote:
> > Because the value ~0 has a meaning to some drivers and only
>
> No, ~0 means that the PCI read failed. For *every* PCI device I know.
Wait, I'm not convinced ye
rs space.
>
> Therefore, convert enum pci_dev_flags into a set of bit fields in the
> struct pci_dev, and then drop said enum and the typedef pci_dev_flags_t.
>
> This will keep PCI device-specific features as part of the struct
> pci_dev and make the code that used to use flags
[+cc Ingo, Peter, Juri, Vincent (scheduler maintainers)]
s/hosekeeping/housekeeping/ (in subject)
On Wed, Sep 09, 2020 at 11:08:16AM -0400, Nitesh Narayan Lal wrote:
> Introduce a new API num_housekeeping_cpus(), that can be used to retrieve
> the number of housekeeping CPUs by reading an atomic
Possible subject:
PCI: Limit pci_alloc_irq_vectors() to housekeeping CPUs
On Wed, Sep 23, 2020 at 02:11:26PM -0400, Nitesh Narayan Lal wrote:
> This patch limits the pci_alloc_irq_vectors, max_vecs argument that is
> passed on by the caller based on the housekeeping online CPUs (that are
> mean
On Wed, Sep 23, 2020 at 02:11:23PM -0400, Nitesh Narayan Lal wrote:
> Introduce a new API hk_num_online_cpus(), that can be used to
> retrieve the number of online housekeeping CPUs that are meant to handle
> managed IRQ jobs.
>
> This API is introduced for the drivers that were previously relying
On Thu, Sep 24, 2020 at 05:39:07PM -0400, Nitesh Narayan Lal wrote:
>
> On 9/24/20 4:45 PM, Bjorn Helgaas wrote:
> > Possible subject:
> >
> > PCI: Limit pci_alloc_irq_vectors() to housekeeping CPUs
>
> Will switch to this.
>
> > On Wed, Sep 23, 2020
On Fri, Sep 25, 2020 at 02:26:54PM -0400, Nitesh Narayan Lal wrote:
> If we have isolated CPUs dedicated for use by real-time tasks, we try to
> move IRQs to housekeeping CPUs from the userspace to reduce latency
> overhead on the isolated CPUs.
>
> If we allocate too many IRQ vectors, moving them
TM is enabled or not.
>
> This reverts commit ac6c26da29c12fa511c877c273ed5c939dc9e96c.
>
> Signed-off-by: Vinicius Costa Gomes
AFAICT we just never had any callers at all for pci_enable_ptm(). I
probably shouldn't have merged it in the first place.
Acked-by: Bjorn Helgaas
> ---
>
the driver, or
> to one per housekeeping CPU if that is larger.
>
> Signed-off-by: Nitesh Narayan Lal
Acked-by: Bjorn Helgaas
> ---
> drivers/pci/msi.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.
On Thu, Jul 30, 2020 at 09:08:48PM +, Krzysztof Wilczyński wrote:
> Rename PCI-related variable "d3_delay" to "d3hot_delay" in the pci_dev
> struct to better align with the PCI Firmware specification (see PCI
> Firmware Specification, Revision 3.2, Section 4.6.9, p. 73).
>
> The pci_dev struct
On Tue, Jan 22, 2019 at 02:45:44PM +0800, Kai-Heng Feng wrote:
> There are some e1000e devices can only be woken up from D3 one time, by
> plugging ethernet cable. Subsequent cable plugging does set PME bit
> correctly, but it still doesn't get woken up.
>
> Since e1000e connects to the root compl
On Wed, Jan 23, 2019 at 03:17:37PM +0800, Kai Heng Feng wrote:
> > On Jan 23, 2019, at 7:51 AM, Bjorn Helgaas wrote:
> > On Tue, Jan 22, 2019 at 02:45:44PM +0800, Kai-Heng Feng wrote:
> >> There are some e1000e devices can only be woken up from D3 one time, by
> &g
On Thu, Jan 24, 2019 at 11:29:37PM +0800, Kai Heng Feng wrote:
> > On Jan 24, 2019, at 11:15 PM, Bjorn Helgaas wrote:
> > On Wed, Jan 23, 2019 at 03:17:37PM +0800, Kai Heng Feng wrote:
> >>> On Jan 23, 2019, at 7:51 AM, Bjorn Helgaas wrote:
> >>> On Tue, J
On Mon, Jan 15, 2018 at 06:44:56PM +0600, Aleksey Makarov wrote:
> From: Radoslaw Biernacki
>
> This patch adds support for the Precision Time Protocol
> Clocks and Timestamping hardware found on Cavium ThunderX
> processors.
>
> Signed-off-by: Radoslaw Biernacki
> Signed-off-by: Aleksey Makaro
On Mon, Jan 15, 2018 at 06:44:56PM +0600, Aleksey Makarov wrote:
> +++ b/drivers/net/ethernet/cavium/common/cavium_ptp.c
> @@ -0,0 +1,353 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* cavium_ptp.c - PTP 1588 clock on Cavium hardware
> + * Copyright (c) 2003-2015, 2017 Cavium, Inc.
> + */
> +
> +#
On Sun, Feb 03, 2019 at 01:46:50AM +0800, Kai Heng Feng wrote:
> > On Jan 28, 2019, at 3:51 PM, Kai Heng Feng
> > wrote:
>
> >> If I understand correctly, the bugzilla lspci
> >> (https://bugzilla.kernel.org/attachment.cgi?id=280691) was collected
> >> at point 8, and it shows PME_Status=1 when
From: Bjorn Helgaas
8c56df372bc1 ("net: add support for Cavium PTP coprocessor") added the
Cavium PTP coprocessor driver and enabled it by default. Remove the
"default y" because the driver only applies to Cavium ThunderX processors.
Fixes: 8c56df372bc1 ("net: a
Hi David,
I see you're still working on this, but if you do end up going this
direction eventually, would you mind splitting this into two patches:
1) rename the quirk to make it more generic (but not changing any
behavior), and 2) add the ConnectX devices to the quirk. That way
the ConnectX chan
On Tue, Dec 11, 2018 at 6:38 PM David Gibson
wrote:
>
> On Tue, Dec 11, 2018 at 08:01:43AM -0600, Bjorn Helgaas wrote:
> > Hi David,
> >
> > I see you're still working on this, but if you do end up going this
> > direction eventually, would you mind splitting t
[+cc LKML]
On Tue, Sep 18, 2018 at 04:32:44PM -0500, Bjorn Helgaas wrote:
> On Thu, Sep 13, 2018 at 11:37:45AM +0800, Daniel Drake wrote:
> > On 38+ Intel-based Asus products, the nvidia GPU becomes unusable
> > after S3 suspend/resume. The affected products include multiple
>
d 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
> ---
> include/linux/pci.h | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/include/linux/pci.h b/include/linux
On Thu, Jun 25, 2020 at 06:14:09AM +0800, kernel test robot wrote:
> Hi Vaibhav,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on ide/master]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to us
the Intel Faulty
> > > CPUs list is not up to date. Aya is discussing this with Bjorn.
> > Adding Bjorn Helgaas
>
> I see. Simply using pcie_relaxed_ordering_enabled() and blacklisting
> bad CPUs seems far nicer from operational perspective. Perhaps Bjorn
> will chime i
[+cc Ashok, Ding, Casey]
On Mon, Jun 29, 2020 at 12:32:44PM +0300, Aya Levin wrote:
> I wanted to turn on RO on the ETH driver based on
> pcie_relaxed_ordering_enabled().
> From my experiments I see that pcie_relaxed_ordering_enabled() return true
> on Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz. Th
Vaibhav: s/genric/generic/ in the subject
On Tue, Jun 30, 2020 at 12:09:36AM +0800, kernel test robot wrote:
> Hi Vaibhav,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on staging/staging-testing]
> [also build test ERROR on v5.8-rc3 next-20200629]
> [If your
On Sun, Jul 08, 2040 at 11:22:12AM +0300, Aya Levin wrote:
> On 7/6/2020 10:49 PM, David Miller wrote:
> > From: Aya Levin
> > Date: Mon, 6 Jul 2020 16:00:59 +0300
> >
> > > Assuming the discussions with Bjorn will conclude in a well-trusted
> > > API that ensures relaxed ordering in enabled, I'd
Remove includes of from files that don't need
it. I'll apply all these via the PCI tree unless there's objection.
---
Bjorn Helgaas (4):
igb: Remove unnecessary include of
ath9k: Remove unnecessary include of
iwlwifi: Remove unnecessary include of
From: Bjorn Helgaas
The igb driver doesn't need anything provided by pci-aspm.h, so remove
the unnecessary include of it.
Signed-off-by: Bjorn Helgaas
---
drivers/net/ethernet/intel/igb/igb_main.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_m
From: Bjorn Helgaas
Several PCI core files include pci-aspm.h even though they don't need
anything provided by that file. Remove the unnecessary includes of it.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/pci-sysfs.c |1 -
drivers/pci/pci.c |1 -
drivers/pci/probe.c |
From: Bjorn Helgaas
This part of the iwlwifi driver doesn't need anything provided by
pci-aspm.h, so remove the unnecessary include of it.
Signed-off-by: Bjorn Helgaas
---
drivers/net/wireless/intel/iwlwifi/pcie/drv.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wir
From: Bjorn Helgaas
The ath9k driver doesn't need anything provided by pci-aspm.h, so remove
the unnecessary include of it.
Signed-off-by: Bjorn Helgaas
---
drivers/net/wireless/ath/ath9k/pci.c |1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/pci
On Wed, Jul 25, 2018 at 01:33:23PM -0700, Sinan Kaya wrote:
> On 7/25/2018 12:52 PM, Bjorn Helgaas wrote:
> > emove includes of from files that don't need
> > it. I'll apply all these via the PCI tree unless there's objection.
> >
> > ---
> >
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 AM,
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,
On Mon, Jul 30, 2018 at 08:02:48AM -0700, Alexander Duyck wrote:
> On Mon, Jul 30, 2018 at 7:07 AM, Bjorn Helgaas wrote:
> > 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:
> >&g
On Mon, Jul 30, 2018 at 08:19:50PM -0700, Alexander Duyck wrote:
> On Mon, Jul 30, 2018 at 7:33 PM, Bjorn Helgaas wrote:
> > On Mon, Jul 30, 2018 at 08:02:48AM -0700, Alexander Duyck wrote:
> >> On Mon, Jul 30, 2018 at 7:07 AM, Bjorn Helgaas wrote:
> >> > On Sun, Ju
device ID
> > > definitions to help differentiate specific controllers that needed
> > > INTx masking quirks [1].
> > >
> > > Bjorn Helgaas followed on, using the device ID definitions Noa
> > > provided to replace hard-coded values within the mxl4 ID t
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:
https://p
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
With these changes, feel free to merge with the series via the netdev
tree.
> ---
> driver
From: Bjorn Helgaas
Simplify PCIe Completion Timeout setting by using the
pcie_capability_clear_and_set_word() interface. No functional change
intended.
Signed-off-by: Bjorn Helgaas
---
drivers/net/ethernet/chelsio/cxgb4/t4_hw.c | 21 +++--
1 file changed, 3 insertions
From: Bjorn Helgaas
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_ATOMIC_OP based
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 Device's VPD area by
[+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
[+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 N
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 and X550 have added ACS cap
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 Relaxed Ordering Attribute, an
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 these affected root com
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 data-co
On Wed, Aug 09, 2017 at 01:40:01AM +, Casey Leedom wrote:
> | From: Bjorn Helgaas
> | 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/bc/64-ia-32-architec
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
On Mon, Oct 23, 2017 at 07:59:58PM +0200, Romain Perier wrote:
> From: Romain Perier
>
> Now that all the drivers use dma pool API, we can remove the macro
> functions for PCI pool.
>
> Signed-off-by: Romain Perier
> Reviewed-by: Peter Senna Tschudin
Acked-by: Bjorn
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 i
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 Deve
ialize cq and srq explicitly to avoid the warnings.
Signed-off-by: Bjorn Helgaas
---
.../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/mell
On Fri, May 15, 2015 at 4:23 PM, Suravee Suthikulpanit
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 object that should normally be
Hi Aleksey,
On Fri, May 15, 2015 at 10:36 PM, Aleksey Makarov
wrote:
> Signed-off-by: Aleksey Makarov
> ---
> 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
> index e63c02a..3633cc6 100644
> --- a/include/linu
[+cc Greg]
On Sat, May 16, 2015 at 4:14 PM, David Miller wrote:
> From: Bjorn Helgaas
> Date: Sat, 16 May 2015 09:49:40 -0500
>
>> Hi Aleksey,
>>
>> On Fri, May 15, 2015 at 10:36 PM, Aleksey Makarov
>> wrote:
>>> Signed-off-by: Aleksey Makarov
On Mon, May 18, 2015 at 11:41 AM, David Miller wrote:
> From: Bjorn Helgaas
> Date: Mon, 18 May 2015 11:35:20 -0500
>
>> [+cc Greg]
>>
>> On Sat, May 16, 2015 at 4:14 PM, David Miller wrote:
>>> From: Bjorn Helgaas
>>> Date: Sat, 16 May 2015 09:49:4
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
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 suppor
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.
outine to find 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
> ________
Fix typos. Capitalize CPU, NAPI, RCU consistently. Align structure
indentation. No functional change intended; only comment and whitespace
changes.
Signed-off-by: Bjorn Helgaas
---
include/linux/netdevice.h | 215 ++---
1 file changed, 106 insertions
[+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
> --
Fix typos. Capitalize CPU, NAPI, RCU consistently. Align structure
indentation. No functional change intended; only comment and whitespace
changes.
Signed-off-by: Bjorn Helgaas
---
include/linux/netdevice.h | 215 ++---
1 file changed, 106 insertions
p(), don't set np->dev until we know we're going to
succeed.
Signed-off-by: Bjorn Helgaas
---
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/netpoll
np->dev at the points where we dev_hold() and dev_put() the
device.
Signed-off-by: Bjorn Helgaas
---
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/core/netpoll.c
+++ b/n
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->
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 = np->dev->n
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
Signed-off-by: Bjorn Helgaas
---
net/core/netpoll.c |3 +--
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 o
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 needs both of
them.
Add pci_se
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 enc
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
On Wed, Jan 20, 2016 at 3:42 AM, Yishai Hadas 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 an internal design,
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 MS
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
Acked-by: Bjorn Helgaas
I assume this will be merged with the rest via the netdev tree.
> ---
> drivers/p
101 - 200 of 231 matches
Mail list logo
