t; Documentation/ABI/testing/sysfs-bus-pci | 29 +
> .../net/ethernet/mellanox/mlx5/core/main.c| 6 ++
> .../ethernet/mellanox/mlx5/core/mlx5_core.h | 12 +++
> .../net/ethernet/mellanox/mlx5/core/pci_irq.c | 73 +
> .../net/ethernet/mellanox/mlx5/core/sr
Possible subject, since this adds *two* files, not just "a file":
PCI/IOV: Add sysfs MSI-X vector assignment interface
On Sun, Mar 14, 2021 at 02:42:53PM +0200, Leon Romanovsky wrote:
> A typical cloud provider SR-IOV use case is to create many VFs for use by
> guest VMs. The VFs may not be ass
[+cc Rafael, in case you're interested in the driver core issue here]
On Wed, Mar 31, 2021 at 07:08:07AM +0300, Leon Romanovsky wrote:
> On Tue, Mar 30, 2021 at 03:41:41PM -0500, Bjorn Helgaas wrote:
> > On Tue, Mar 30, 2021 at 04:47:16PM -0300, Jason Gunthorpe wrote:
> > &g
On Tue, Mar 30, 2021 at 04:47:16PM -0300, Jason Gunthorpe wrote:
> On Tue, Mar 30, 2021 at 10:00:19AM -0500, Bjorn Helgaas wrote:
> > On Tue, Mar 30, 2021 at 10:57:38AM -0300, Jason Gunthorpe wrote:
> > > On Mon, Mar 29, 2021 at 08:29:49PM -0500, Bjorn Helgaas wrote:
> &
From: Heiner Kallweit
On the N2100, instead of just marking the r8169 chips as having
broken_parity_status, disable parity error reporting for them entirely.
This was the only relevant place that set broken_parity_status, so we no
longer need to check for it in the r8169 error interrupt handler.
From: Heiner Kallweit
For Mellanox Tavor devices, we previously set dev->broken_parity_status,
which does not change the device's behavior; it merely prevents the EDAC
PCI error reporting from warning about Master Data Parity Error, Signaled
System Error, or Detected Parity Error for this device.
From: Bjorn Helgaas
Add pci_disable_parity() to disable reporting of parity errors for a
device by clearing PCI_COMMAND_PARITY.
The device will still set PCI_STATUS_DETECTED_PARITY when it detects
a parity error or receives a Poisoned TLP, but it will not set
PCI_STATUS_PARITY, which means it
From: Bjorn Helgaas
I think this is essentially the same as Heiner's v3 posting, with these
changes:
- Added a pci_disable_parity() interface in pci.c instead of making a
public pci_quirk_broken_parity() because quirks.c is only compiled when
CONFIG_PCI_QUIRKS=y.
- Remove
On Tue, Mar 30, 2021 at 10:57:38AM -0300, Jason Gunthorpe wrote:
> On Mon, Mar 29, 2021 at 08:29:49PM -0500, Bjorn Helgaas wrote:
>
> > I think I misunderstood Greg's subdirectory comment. We already have
> > directories like this:
>
> Yes, IIRC, Greg's r
On Fri, Mar 26, 2021 at 04:01:48PM -0300, Jason Gunthorpe wrote:
> On Fri, Mar 26, 2021 at 11:50:44AM -0700, Alexander Duyck wrote:
>
> > My concern would be that we are defining the user space interface.
> > Once we have this working as a single operation I could see us having
> > to support it t
On Sun, Mar 28, 2021 at 12:04:35AM +0100, Heiner Kallweit wrote:
> On 26.03.2021 22:26, Bjorn Helgaas wrote:
> > [+cc Randy, Andrew (though I'm sure you have zero interest in this
> > ancient question :))]
> >
> > On Wed, Dec 09, 2020 at 09:31:21AM +0100, Heiner
On Fri, Mar 26, 2021 at 11:42:46PM +0200, Andy Shevchenko wrote:
> On Fri, Mar 26, 2021 at 04:26:55PM -0500, Bjorn Helgaas wrote:
> > [+cc Randy, Andrew (though I'm sure you have zero interest in this
> > ancient question :))]
> >
> > On Wed, Dec 09, 2020 at 0
[+cc Randy, Andrew (though I'm sure you have zero interest in this
ancient question :))]
On Wed, Dec 09, 2020 at 09:31:21AM +0100, Heiner Kallweit wrote:
> pci_set_mwi() and pci_try_set_mwi() do exactly the same, just that the
> former one is declared as __must_check. However also some callers of
On Fri, Mar 26, 2021 at 11:50:44AM -0700, Alexander Duyck wrote:
> I almost wonder if it wouldn't make sense to just partition this up to
> handle flexible resources in the future. Maybe something like having
> the directory setup such that you have "sriov_resources/msix/" and
> then you could hav
On Fri, Mar 26, 2021 at 09:00:50AM -0700, Alexander Duyck wrote:
> On Thu, Mar 25, 2021 at 11:44 PM Leon Romanovsky wrote:
> > On Thu, Mar 25, 2021 at 03:28:36PM -0300, Jason Gunthorpe wrote:
> > > On Thu, Mar 25, 2021 at 01:20:21PM -0500, Bjorn Helgaas wrote:
> > > &
On Thu, Mar 25, 2021 at 02:36:46PM -0300, Jason Gunthorpe wrote:
> On Thu, Mar 25, 2021 at 12:21:44PM -0500, Bjorn Helgaas wrote:
>
> > NVMe and mlx5 have basically identical functionality in this respect.
> > Other devices and vendors will likely implement similar functionalit
gt; On Thu, Mar 11, 2021 at 12:17:29PM -0600, Bjorn Helgaas wrote:
> > > > > On Wed, Mar 10, 2021 at 03:34:01PM -0800, Alexander Duyck wrote:
> > > > > >
> > > > > > I'm not so much worried about management software as the
> > > >
PTM is enabled or not.
>
> This reverts commit ac6c26da29c12fa511c877c273ed5c939dc9e96c.
>
> Signed-off-by: Vinicius Costa Gomes
> Acked-by: Bjorn Helgaas
> ---
> drivers/pci/pci.h | 3 ---
> include/linux/pci.h | 7 +++
> 2 files changed, 7 insertions(+), 3 deletions(-)
&
On Mon, Mar 22, 2021 at 09:18:22AM -0700, Vinicius Costa Gomes wrote:
> i225 has support for PCIe PTM, which allows us to implement support
> for the PTP_SYS_OFFSET_PRECISE ioctl(), implemented in the driver via
> the getcrosststamp() function.
> +static bool igc_is_ptm_supported(struct igc_adapte
On Mon, Mar 22, 2021 at 09:18:21AM -0700, Vinicius Costa Gomes wrote:
> In practice, enabling PTM also sets the enabled_ptm flag in the PCI
> device, the flag will be used for detecting if PTM is enabled before
> adding support for the SYSOFFSET_PRECISE ioctl() (which is added by
> implementing the
On Wed, Mar 10, 2021 at 03:34:01PM -0800, Alexander Duyck wrote:
> On Wed, Mar 10, 2021 at 11:09 AM Bjorn Helgaas wrote:
> > On Sun, Mar 07, 2021 at 10:55:24AM -0800, Alexander Duyck wrote:
> > > On Sun, Feb 28, 2021 at 11:55 PM Leon Romanovsky wrote:
> > &
On Sun, Mar 07, 2021 at 10:55:24AM -0800, Alexander Duyck wrote:
> On Sun, Feb 28, 2021 at 11:55 PM Leon Romanovsky wrote:
> > From: Leon Romanovsky
> >
> > @Alexander Duyck, please update me if I can add your ROB tag again
> > to the series, because you liked v6 more.
> >
> > Thanks
> >
> >
> Signed-off-by: Thomas Gleixner
> Cc: "K. Y. Srinivasan"
> Cc: Haiyang Zhang
> Cc: Stephen Hemminger
> Cc: Wei Liu
> Cc: Lorenzo Pieralisi
> Cc: Rob Herring
> Cc: Bjorn Helgaas
> Cc: linux-hyp...@vger.kernel.org
> Cc: linux-...@vger.kernel.org
Acked-b
[+cc Rafael, linux-pm]
On Thu, Mar 04, 2021 at 02:07:18PM +0800, Kai-Heng Feng wrote:
> On Sat, Feb 27, 2021 at 2:17 AM Bjorn Helgaas wrote:
> > On Fri, Feb 26, 2021 at 02:31:31PM +0100, Heiner Kallweit wrote:
> > > On 26.02.2021 13:18, Kai-Heng Feng wrote:
> > > >
On Fri, Feb 26, 2021 at 02:31:31PM +0100, Heiner Kallweit wrote:
> On 26.02.2021 13:18, Kai-Heng Feng wrote:
> > On Fri, Feb 26, 2021 at 8:10 PM Heiner Kallweit
> > wrote:
> >>
> >> On 26.02.2021 08:12, Kalle Valo wrote:
> >>> Kai-Heng Feng writes:
> >>>
> Now we have a generic D3 shutdown
On Wed, Feb 24, 2021 at 11:53:30AM +0200, Leon Romanovsky wrote:
> On Tue, Feb 23, 2021 at 03:07:43PM -0600, Bjorn Helgaas wrote:
> > On Sun, Feb 21, 2021 at 08:59:18AM +0200, Leon Romanovsky wrote:
> > > On Sat, Feb 20, 2021 at 01:06:00PM -0600, Bjorn Helgaas wrote:
> >
On Sun, Feb 21, 2021 at 08:59:18AM +0200, Leon Romanovsky wrote:
> On Sat, Feb 20, 2021 at 01:06:00PM -0600, Bjorn Helgaas wrote:
> > On Fri, Feb 19, 2021 at 09:20:18AM +0100, Greg Kroah-Hartman wrote:
> >
> > > Ok, can you step back and try to explain what problem you a
On Fri, Feb 19, 2021 at 09:20:18AM +0100, Greg Kroah-Hartman wrote:
> Ok, can you step back and try to explain what problem you are trying to
> solve first, before getting bogged down in odd details? I find it
> highly unlikely that this is something "unique", but I could be wrong as
> I do not u
On Thu, Feb 18, 2021 at 12:15:51PM +0200, Leon Romanovsky wrote:
> On Wed, Feb 17, 2021 at 12:02:39PM -0600, Bjorn Helgaas wrote:
> > [+cc Greg in case he wants to chime in on the sysfs discussion.
> > TL;DR: we're trying to add/remove sysfs files when a PCI driver that
On Wed, Feb 17, 2021 at 03:25:22PM -0400, Jason Gunthorpe wrote:
> On Wed, Feb 17, 2021 at 12:02:39PM -0600, Bjorn Helgaas wrote:
>
> > > BTW, I asked more than once how these sysfs knobs should be handled
> > > in the PCI/core.
> >
> > Thanks for the pointer
+0200, Leon Romanovsky wrote:
> On Tue, Feb 16, 2021 at 10:12:12AM -0600, Bjorn Helgaas wrote:
> > On Tue, Feb 16, 2021 at 09:33:44AM +0200, Leon Romanovsky wrote:
> > > On Mon, Feb 15, 2021 at 03:01:06PM -0600, Bjorn Helgaas wrote:
> > > > On Tue, Feb 09, 2021 at 03:3
Proposed subject:
PCI/IOV: Add dynamic MSI-X vector assignment sysfs interface
On Tue, Feb 16, 2021 at 09:33:44AM +0200, Leon Romanovsky wrote:
> On Mon, Feb 15, 2021 at 03:01:06PM -0600, Bjorn Helgaas wrote:
> > On Tue, Feb 09, 2021 at 03:34:42PM +0200, Leon Romanovsky wrote:
> &g
On Tue, Feb 09, 2021 at 03:34:42PM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Extend PCI sysfs interface with a new callback that allows configuration
> of the number of MSI-X vectors for specific SR-IOV VF. This is needed
> to optimize the performance of VFs devices by allocating
On Fri, Feb 05, 2021 at 07:35:47PM +0200, Leon Romanovsky wrote:
> On Thu, Feb 04, 2021 at 03:12:12PM -0600, Bjorn Helgaas wrote:
> > On Thu, Feb 04, 2021 at 05:50:48PM +0200, Leon Romanovsky wrote:
> > > On Wed, Feb 03, 2021 at 06:10:39PM -0600, Bjorn Helgaas wrote:
> >
[+cc Casey, Rahul]
On Fri, Feb 05, 2021 at 08:29:45PM +0100, Heiner Kallweit wrote:
> cxgb4 uses the full VPD address space for accessing its EEPROM (with some
> mapping, see t4_eeprom_ptov()). In cudbg_collect_vpd_data() it sets the
> VPD len to 32K (PCI_VPD_MAX_SIZE), and then back to 2K (CUDBG_
On Thu, Feb 04, 2021 at 05:50:48PM +0200, Leon Romanovsky wrote:
> On Wed, Feb 03, 2021 at 06:10:39PM -0600, Bjorn Helgaas wrote:
> > On Tue, Feb 02, 2021 at 09:44:29PM +0200, Leon Romanovsky wrote:
> > > On Tue, Feb 02, 2021 at 12:06:09PM -0600, Bjorn Helgaas wrote:
> >
On Tue, Feb 02, 2021 at 09:44:29PM +0200, Leon Romanovsky wrote:
> On Tue, Feb 02, 2021 at 12:06:09PM -0600, Bjorn Helgaas wrote:
> > On Tue, Jan 26, 2021 at 10:57:27AM +0200, Leon Romanovsky wrote:
> > > From: Leon Romanovsky
> > >
> > > Extend PCI sysfs inter
On Tue, Jan 26, 2021 at 10:57:27AM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Extend PCI sysfs interface with a new callback that allows configure
> the number of MSI-X vectors for specific SR-IO VF. This is needed
> to optimize the performance of newly bound devices by allocating
On Tue, Jan 26, 2021 at 10:57:29AM +0200, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> The number of MSI-X vectors is PCI property visible through lspci, that
> field is read-only and configured by the device. The static assignment
> of an amount of MSI-X vectors doesn't allow utilize the n
From: Bjorn Helgaas
Fix misspellings of "physical".
Signed-off-by: Bjorn Helgaas
---
Thanks, Willem!
drivers/net/ethernet/marvell/octeontx2/af/rvu.c | 2 +-
drivers/net/ethernet/marvell/octeontx2/nic/otx2_flows.c | 2 +-
drivers/net/ethernet/marvell/octeontx2/nic/otx2_p
From: Bjorn Helgaas
Fix misspellings of "physical".
Signed-off-by: Bjorn Helgaas
---
drivers/net/ethernet/marvell/octeontx2/af/rvu.c | 2 +-
drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ne
On Wed, Jan 13, 2021 at 09:52:23PM +0100, Heiner Kallweit wrote:
> On 06.01.2021 20:34, Heiner Kallweit wrote:
> > On 06.01.2021 20:22, Bjorn Helgaas wrote:
> >> On Wed, Jan 06, 2021 at 06:50:22PM +0100, Heiner Kallweit wrote:
> >>> If we know that a device has broken
On Thu, Jan 07, 2021 at 10:54:38PM -0500, Don Dutile wrote:
> On 1/7/21 7:57 PM, Bjorn Helgaas wrote:
> > On Sun, Jan 03, 2021 at 10:24:37AM +0200, Leon Romanovsky wrote:
> > > + **/
> > > +int pci_set_msix_vec_count(struct pci_dev *dev, int numb)
> >
[+cc Alex, Don]
This patch does not actually *configure* the number of vectors, so the
subject is not quite accurate. IIUC, this patch adds a sysfs file
that can be used to configure the number of vectors. The subject
should mention the sysfs connection.
On Sun, Jan 03, 2021 at 10:24:37AM +0200
is set. Make pci_quirk_broken_parity() public so that it can be used
> by platform code, e.g. for Thecus N2100.
>
> Signed-off-by: Heiner Kallweit
> Reviewed-by: Leon Romanovsky
Acked-by: Bjorn Helgaas
This series should all go together. Let me know if you want me to do
anything more (would
On Wed, Jan 06, 2021 at 12:05:41PM +0100, Heiner Kallweit wrote:
> Use new PCI core function pci_quirk_broken_parity(), in addition to
> setting broken_parity_status is disables parity checking.
That sentence has a typo or something so it doesn't read quite right.
Maybe:
Use new PCI core functi
On Tue, Jan 05, 2021 at 10:42:31AM +0100, Heiner Kallweit wrote:
> Simplify the quirk by using new PCI core function
> pci_quirk_broken_parity(). In addition make the quirk
> more specific, use device id 0x8169 instead of PCI_ANY_ID.
>
> Signed-off-by: Heiner Kallweit
> ---
> arch/arm/mach-iop32
On Wed, Dec 16, 2020 at 12:20:53PM +0100, Ian Kumlien wrote:
> On Wed, Dec 16, 2020 at 1:08 AM Bjorn Helgaas wrote:
> > On Tue, Dec 15, 2020 at 02:09:12PM +0100, Ian Kumlien wrote:
> > > On Tue, Dec 15, 2020 at 1:40 AM Bjorn Helgaas wrote:
> > > > On Mon, Dec 14,
On Tue, Dec 15, 2020 at 02:09:12PM +0100, Ian Kumlien wrote:
> On Tue, Dec 15, 2020 at 1:40 AM Bjorn Helgaas wrote:
> >
> > On Mon, Dec 14, 2020 at 11:56:31PM +0100, Ian Kumlien wrote:
> > > On Mon, Dec 14, 2020 at 8:19 PM Bjorn Helgaas wrote:
> >
> > > >
On Mon, Dec 14, 2020 at 11:56:31PM +0100, Ian Kumlien wrote:
> On Mon, Dec 14, 2020 at 8:19 PM Bjorn Helgaas wrote:
> > If you're interested, you could probably unload the Realtek drivers,
> > remove the devices, and set the PCI_EXP_LNKCTL_LD (Link Disable) bit
On Mon, Dec 14, 2020 at 04:47:32PM +0100, Ian Kumlien wrote:
> On Mon, Dec 14, 2020 at 3:02 PM Bjorn Helgaas wrote:
> > On Mon, Dec 14, 2020 at 10:14:18AM +0100, Ian Kumlien wrote:
> > > On Mon, Dec 14, 2020 at 6:44 AM Bjorn Helgaas wrote:
> > > >
> > > &
On Mon, Dec 14, 2020 at 10:14:18AM +0100, Ian Kumlien wrote:
> On Mon, Dec 14, 2020 at 6:44 AM Bjorn Helgaas wrote:
> >
> > [+cc Jesse, Tony, David, Jakub, Heiner, lists in case there's an ASPM
> > issue with I211 or Realtek NICs. Beginning of thread:
>
, the
Realtek device should not be relevant to the I211 path.]
On Sun, Dec 13, 2020 at 10:39:53PM +0100, Ian Kumlien wrote:
> On Sun, Dec 13, 2020 at 12:47 AM Bjorn Helgaas wrote:
> > On Sat, Oct 24, 2020 at 10:55:46PM +0200, Ian Kumlien wrote:
> > > Make pcie_aspm_check_latency co
On Mon, Dec 07, 2020 at 01:40:33AM +0530, Puranjay Mohan wrote:
> Callers of pci_find_capability() should save the return value in u8.
> change the type of pcix_cap from int to u8, to match the specification.
>
> Signed-off-by: Puranjay Mohan
> ---
> drivers/net/ethernet/broadcom/tg3.h | 2 +-
>
; > > Patches 3 and 4 will turn the behavior on by default for Dell's CML
> > > systems.
> > > Patch 5 allows accessing the value of the flags via ethtool to tell if the
> > > heuristics have turned on s0ix flows, as well as for development purposes
> > &g
s/s0ix/S0ix/ in subject.
On Wed, Dec 02, 2020 at 10:17:47AM -0600, Mario Limonciello wrote:
> These comet lake systems are not yet released, but have been validated
> on pre-release hardware.
s/comet lake/Comet Lake/ to match previous usage in patch 3/5.
> This is being submitted separately from
s/it's/its/ (in subject as well as below).
Previous patches used "S0ix", not "s0ix" (in subject as well as
below, as well as subject and commit log of 3/5 and 5/5).
On Wed, Dec 02, 2020 at 10:17:45AM -0600, Mario Limonciello wrote:
> Introduce a flag to indicate the device should be using the s0i
On Wed, Dec 02, 2020 at 10:17:44AM -0600, Mario Limonciello wrote:
> From: Vitaly Lifshits
>
> Changed a configuration in the flows to align with
> architecture requirements to achieve S0i3.2 substate.
I guess this is really talking about requirements of a specific
CPU/SOC before it will enter S
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
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.
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
> ---
>
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
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 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
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
[+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
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
On Tue, Aug 18, 2020 at 11:37:45AM +0200, Petr Machata wrote:
> Ido Schimmel writes:
> > On Mon, Aug 17, 2020 at 10:38:24AM -0500, Bjorn Helgaas wrote:
> >> You've likely seen this already, but Coverity found this problem:
> >>
> >> *** CID
You've likely seen this already, but Coverity found this problem:
*** CID 1466147: Control flow issues (DEADCODE)
/drivers/net/ethernet/mellanox/mlxsw/spectrum_policer.c: 380 in
mlxsw_sp_policers_init()
374 }
375
376 return 0;
377
378 err_family_r
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
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 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 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
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
[+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
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
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
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
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
; Signed-off-by: Denis Efremov
Reviewed-by: Bjorn Helgaas
Thanks for doing this, Denis. When possible it's better to use a PCI
core interface than to fiddle with PCI config space directly from a
driver.
> ---
> drivers/net/ethernet/cavium/liquidio/octeon_mailbox.c | 4 +---
> 1 fi
may
> falsely assume the respective ASPM link states are disabled.
> Let pci_disable_link_state() propagate errors to the caller, enabling
> the caller to react accordingly.
>
> Signed-off-by: Heiner Kallweit
Acked-by: Bjorn Helgaas
Thanks, I think this makes good sense.
> ---
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, 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 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
[+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
[+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
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
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
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 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 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 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 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 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
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
[+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
>
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
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 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 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,
1 - 100 of 231 matches
Mail list logo
