[+cc Masahiro, Michal, linux-kbuild, linux-kernel]
On Thu, Feb 04, 2021 at 07:30:15PM +0800, Yicong Yang wrote:
> From: Junhao He
>
> Use subdir-ccflags-* instead of ccflags-* to inherit the debug
> settings from Kconfig when traversing subdirectories.
So I guess the current behavior is:
If
On Wed, Feb 03, 2021 at 03:13:58AM +, 吳昊澄 Ricky wrote:
> > -Original Message-
> > From: Bjorn Helgaas
> > Sent: Tuesday, February 2, 2021 8:28 PM
> > To: 吳昊澄 Ricky
> > Cc: a...@arndb.de; gre...@linuxfoundation.org; yuehaib...@huawei.com;
>
From: Bjorn Helgaas
The PCIe Bandwidth Change Notification feature logs messages when the link
bandwidth changes. Some users have reported that these messages occur
often enough to significantly reduce NVMe performance. GPUs also seem to
generate these messages.
We don't know why the
On Tue, Feb 02, 2021 at 01:50:20PM -0600, Alex G. wrote:
> On 1/29/21 3:56 PM, Bjorn Helgaas wrote:
> > On Thu, Jan 28, 2021 at 06:07:36PM -0600, Alex G. wrote:
> > > On 1/28/21 5:51 PM, Sinan Kaya wrote:
> > > > On 1/28/2021 6:39 PM, Bjorn Helgaas wrote:
> > &
On Tue, Feb 02, 2021 at 02:29:45PM +0100, Mauro Carvalho Chehab wrote:
> This series add support for Kirin 970 and for the Hikey 970
> board at the already-existing driver.
>
> patches 1-3 were previously submitted as RFC:
>
> - Patch 1 converts the Synopsys Designware PCIe binding
> documenta
The subject line could be more descriptive. All patches modify
something, so the only real information it contains is "rts522a" and
"init". Maybe it could say something about powering off OCP (whatever
that is) when no memory card is present.
On Tue, Feb 02, 2021 at 06:56:41PM +0800, ricky...@re
ecific Extended Capability (VSEC) is a PCIe capability (acts
> like a wrapper) specified by PCI-SIG that allows the vendor to create
> their own and specific capability in the device config space.
>
> Signed-off-by: Gustavo Pimentel
If you fix the below, feel free to add my
Acked-by: Bjorn
On Mon, Feb 01, 2021 at 08:49:16PM +0100, Michael Walle wrote:
> Am 2021-01-17 20:27, schrieb Michael Walle:
> > Am 2021-01-16 00:57, schrieb Bjorn Helgaas:
> > > On Wed, Jan 13, 2021 at 12:32:32AM +0100, Michael Walle wrote:
> > > > Am 2021-01-12 23:58, schrieb B
On Tue, Jan 26, 2021 at 01:22:18PM +0200, Antti Järvinen wrote:
> On 22.1.2021 1.55, Bjorn Helgaas wrote:>
>
> > It looks like we would probably be trying a Secondary Bus Reset using
> > the bridge leading to the C667X. Can you confirm?
>
> Yes, this is my understa
On Sat, Jan 30, 2021 at 01:19:10AM +0300, Dmitry Baryshkov wrote:
> On Sat, 30 Jan 2021 at 00:50, Bjorn Helgaas wrote:
> > On Fri, Jan 29, 2021 at 06:45:21AM +0300, Dmitry Baryshkov wrote:
> > > On 28/01/2021 22:26, Rob Herring wrote:
> > > > On Thu, Jan 28, 202
On Thu, Jan 28, 2021 at 06:07:36PM -0600, Alex G. wrote:
> On 1/28/21 5:51 PM, Sinan Kaya wrote:
> > On 1/28/2021 6:39 PM, Bjorn Helgaas wrote:
> > > AFAICT, this thread petered out with no resolution.
> > >
> > > If the bandwidth change notifications are impor
On Fri, Jan 29, 2021 at 06:45:21AM +0300, Dmitry Baryshkov wrote:
> On 28/01/2021 22:26, Rob Herring wrote:
> > On Thu, Jan 28, 2021 at 11:52 AM Dmitry Baryshkov
> > wrote:
> > >
> > > Some Qualcomm platforms require to power up an external device before
> > > probing the PCI bus. E.g. on RB5 pla
On Thu, Jan 28, 2021 at 04:56:26PM -0800, Marc MERLIN wrote:
> On Wed, Jan 27, 2021 at 03:33:00PM -0600, Bjorn Helgaas wrote:
> > Hi Marc, I appreciate your persistence on this. I am frankly
> > surprised that you've put up with this so long.
>
> Well, been using li
[+cc Atanas -- thank you very much for the bug report!]
On Sat, Feb 22, 2020 at 10:58:40AM -0600, Bjorn Helgaas wrote:
> On Wed, Jan 15, 2020 at 04:10:08PM -0600, Bjorn Helgaas wrote:
> > I think we have a problem with link bandwidth change notifications
> > (see
> > https
On Tue, Jan 26, 2021 at 10:46:04AM -0600, Jeremy Linton wrote:
> On 1/22/21 1:48 PM, Will Deacon wrote:
> > On Fri, Jan 08, 2021 at 10:32:16AM +, Lorenzo Pieralisi wrote:
> > > On Thu, Jan 07, 2021 at 04:05:48PM -0500, Jon Masters wrote:
> > > > On 1/7/21 1:14 PM, Will Deacon wrote:
> > > > > O
On Wed, Jan 27, 2021 at 03:33:02PM -0600, Bjorn Helgaas wrote:
> On Sat, Dec 26, 2020 at 03:12:09AM -0800, Marc MERLIN wrote:
> > This started with 5.5 and hasn't gotten better since then, despite
> > some reports I tried to send.
> >
> > As per my previous message
Hi Marc, I appreciate your persistence on this. I am frankly
surprised that you've put up with this so long.
On Sat, Dec 26, 2020 at 03:12:09AM -0800, Marc MERLIN wrote:
> This started with 5.5 and hasn't gotten better since then, despite
> some reports I tried to send.
>
> As per my previous me
On Thu, Jan 28, 2021 at 01:31:00AM +0800, Kai-Heng Feng wrote:
> Commit 50310600ebda ("iommu/vt-d: Enable PCI ACS for platform opt in
> hint") enables ACS, and some platforms lose its NVMe after resume from
> firmware:
> [ 50.947816] pcieport :00:1b.0: DPC: containment event, status:0x1f01
>
From: Bjorn Helgaas
This reverts commit 4257f7e008ea394fcecc050f1569c3503b8bcc15.
Kenneth reported that after 4257f7e008ea, he sees a torrent of disk I/O
errors on his NVMe device, and possibly other devices, until a reboot.
Link:
https://lore.kernel.org/linux-pci/20201228040513.GA611645
machine is essentially useless, with a torrent of disk I/O errors
> > > on my NVMe device (at least, and possibly other devices affected)
> > > until a reboot.
> > >
> > > I do use tlp to set the PCIe ASPM to "performance" on AC and
> > > &q
On Wed, Jan 27, 2021 at 02:55:07PM +0100, Rafael J. Wysocki wrote:
> On Wed, Jan 27, 2021 at 1:54 PM Bjorn Helgaas wrote:
> >
> > From: Bjorn Helgaas
> >
> > Clean up a few _OSC-related things.
> >
> > We talked about the _OSC failure message in the last
On Wed, Jan 27, 2021 at 05:03:12AM +, Bharat Kumar Gogada wrote:
> > On Thu, Jan 21, 2021 at 03:29:16PM +0530, Bharat Kumar Gogada wrote:
> Here is the CCI spec
> https://developer.arm.com/documentation/ddi0470/k/preface
I'm sure it was obvious, but please include this in the commit log as
w
On Wed, Jan 27, 2021 at 07:58:26AM +, Chaitanya Kulkarni wrote:
> > On Jan 26, 2021, at 11:41 PM, Chaitanya Kulkarni
> > wrote:
> > On 1/26/21 14:14, Bjorn Helgaas wrote:
> >> From: Bjorn Helgaas
> >>
> >> Use PCI #defines for PCIe Device
From: Bjorn Helgaas
This message:
acpi PNP0A08:02: _OSC failed (AE_NOT_FOUND); disabling ASPM
is alarming and slightly misleading. Per the PCI Firmware Spec, r3.2, sec
4.5.1, _OSC is required for PCIe hierarchies. If _OSC is absent or fails,
the OS must not attempt to use any of the
From: Bjorn Helgaas
9778c14b4ca2 ("ACPI/PCI: Fix possible race condition on _OSC evaluation")
added locking around _OSC calls to protect the acpi_osc_data_list that
stored the results.
63f10f0f6df4 ("PCI/ACPI: move _OSC code to pci_root.c") moved the results
from acpi_
From: Bjorn Helgaas
acpi_pci_osc_control_set() is only called from pci_root.c, so stop
exporting it and make it static.
Signed-off-by: Bjorn Helgaas
---
drivers/acpi/pci_root.c | 3 +--
include/linux/acpi.h| 3 ---
2 files changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/acpi
From: Bjorn Helgaas
Clean up a few _OSC-related things.
We talked about the _OSC failure message in the last patch long ago, and I
just dropped the ball, sorry about that. Previous discussion:
https://lore.kernel.org/linux-pci/20200602223618.GA845676@bjorn-Precision-5520/
I'm happy to
From: Bjorn Helgaas
Replace pci_read_config_word() with pcie_capability_read_word().
pcie_capability_read_word() takes care of a few special cases when reading
the PCIe capability. See 8c0d3a02c130 ("PCI: Add accessors for PCI Express
Capability").
Signed-off-by: Bjorn Helgaas
--
From: Bjorn Helgaas
Use PCI #defines and the special accessors for the PCIe capability.
Bjorn Helgaas (2):
mtip32xx: use PCI #defines instead of numbers
mtip32xx: prefer pcie_capability_read_word()
drivers/block/mtip32xx/mtip32xx.c | 15 +--
1 file changed, 5 insertions(+), 10
From: Bjorn Helgaas
Use PCI #defines for PCIe Device Control register values instead of
hard-coding bit positions. No functional change intended.
Signed-off-by: Bjorn Helgaas
---
drivers/block/mtip32xx/mtip32xx.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers
On Fri, Jan 22, 2021 at 03:03:11PM +0800, Mingchuang Qiao wrote:
> On Thu, 2021-01-21 at 16:31 -0600, Bjorn Helgaas wrote:
> > [+cc Alex and Mingchuang et al from
> > https://lore.kernel.org/r/20210112072739.31624-1-mingchuang.q...@mediatek.com]
> >
> > On Tue, Jan 1
On Thu, Jan 21, 2021 at 12:48:07PM -0800, Florian Fainelli wrote:
> On 1/14/2021 12:46 PM, Florian Fainelli wrote:
> > On 1/5/21 1:22 PM, Florian Fainelli wrote:
> >> On 12/23/20 4:05 PM, Florian Fainelli wrote:
> >>>
> >>>
> >>> On 12/16/2020 1:41 PM, Jim Quinlan wrote:
> v3 -- discard commit
[+cc Alex, Murali, Kishon]
On Tue, Jan 12, 2021 at 03:36:43PM +, Antti Järvinen wrote:
> TI C667X does not support bus/hot reset.
> See https://e2e.ti.com/support/processors/f/791/t/954382
You can cite the URL as the source, but the URL will eventually become
stale, so let's include the relev
[+cc Alex and Mingchuang et al from
https://lore.kernel.org/r/20210112072739.31624-1-mingchuang.q...@mediatek.com]
On Tue, Jan 19, 2021 at 04:14:10PM +0300, Mika Westerberg wrote:
> PCIe r5.0, sec 7.5.3.16 says that the downstream ports must reset the
> LTR enable bit if the link goes down (port g
On Thu, Jan 21, 2021 at 10:57:09AM -0600, Bjorn Helgaas wrote:
> On Mon, Jan 18, 2021 at 04:58:36PM +0800, Zhangfei Gao wrote:
> > HiSilicon KunPeng920 and KunPeng930 have devices appear as PCI but are
> > actually on the AMBA bus. These fake PCI devices can support SVA via
> &g
On Mon, Jan 18, 2021 at 04:58:36PM +0800, Zhangfei Gao wrote:
> HiSilicon KunPeng920 and KunPeng930 have devices appear as PCI but are
> actually on the AMBA bus. These fake PCI devices can support SVA via
> SMMU stall feature, by setting dma-can-stall for ACPI platforms.
>
> Signed-off-by: Zhangf
[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 15, 2021 at 12:20:59PM +0100, Niklas Schnelle wrote:
> >> On 1/14/21 5
[+cc Rob]
s/coherenct/coherent/ in subject
s/traffic/DMA/ (this applies specifically to DMA, not to MMIO)
On Thu, Jan 21, 2021 at 03:29:16PM +0530, Bharat Kumar Gogada wrote:
> - Add support for routing PCIe traffic coherently when
> Cache Coherent Interconnect(CCI) is enabled in the system.
s/
[Alex is a reset expert, hoping he can chime in]
On Thu, Jan 21, 2021 at 08:53:12PM +0800, Chiqijun wrote:
> On 2021/1/9 6:25, Bjorn Helgaas wrote:
> > On Fri, Dec 25, 2020 at 05:25:30PM +0800, Chiqijun wrote:
> > > When multiple VFs do FLR at the same time, the firmware
On Wed, Jan 20, 2021 at 06:25:48PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Commit
>
> 0ca2233eb71f ("PCI: Update ROM BAR even if disabled")
>
> is missing a Signed-off-by from its authorand committer.
My mistake, I didn't intend that commit for -next yet. I dropped it,
thanks!
On Tue, Jan 19, 2021 at 04:06:21PM -0600, Bjorn Helgaas wrote:
> On Tue, Jan 19, 2021 at 11:27:57AM +0100, Daniele Palmas wrote:
> > Add Telit Vendor ID to pci_ids.h
>
> From the top of the file:
>
> * Do not add new entries to this file unless the definitions
> *
On Tue, Jan 19, 2021 at 11:27:57AM +0100, Daniele Palmas wrote:
> Add Telit Vendor ID to pci_ids.h
>From the top of the file:
* Do not add new entries to this file unless the definitions
* are shared between multiple drivers.
If this is the case, include this patch in a series that a
[cc->to Greg]
On Mon, Jan 04, 2021 at 08:59:02PM +0530, Kishon Vijay Abraham I wrote:
> Documentation/PCI/endpoint/pci-endpoint-cfs.rst explains how a user
> has to create a directory in-order to create a 'EPF Device' that
> can be configured/probed by 'EPF Driver'.
>
> Allow user to create a sub
On Mon, Jan 04, 2021 at 08:59:05PM +0530, Kishon Vijay Abraham I wrote:
> Add a new endpoint function driver to provide NTB functionality
> using multiple PCIe endpoint instances.
>
> Signed-off-by: Kishon Vijay Abraham I
Several typos below if there's any opportunity for revision.
> ---
> dri
On Tue, Jan 19, 2021 at 12:34:07PM -0600, Bjorn Helgaas wrote:
> [cc->to Greg]
>
> On Mon, Jan 04, 2021 at 08:59:02PM +0530, Kishon Vijay Abraham I wrote:
> > Documentation/PCI/endpoint/pci-endpoint-cfs.rst explains how a user
> > has to create a directory in-order to cr
On Mon, Jan 04, 2021 at 08:58:53PM +0530, Kishon Vijay Abraham I wrote:
> Add specification for the *PCI NTB* function device. The endpoint function
> driver and the host PCI driver should be created based on this
> specification.
>
> Signed-off-by: Kishon Vijay Abraham I
A few typos below if th
On Mon, Jan 04, 2021 at 08:59:09PM +0530, Kishon Vijay Abraham I wrote:
> Add documentation to help users use pci-epf-ntb function driver and
> existing host side NTB infrastructure for NTB functionality.
>
> Signed-off-by: Kishon Vijay Abraham I
> Reviewed-by: Randy Dunlap
> ---
> Documentatio
On Wed, Jan 13, 2021 at 12:32:32AM +0100, Michael Walle wrote:
> Am 2021-01-12 23:58, schrieb Bjorn Helgaas:
> > On Sat, Jan 09, 2021 at 07:31:46PM +0100, Michael Walle wrote:
> > > Am 2021-01-08 22:20, schrieb Bjorn Helgaas:
> > > > 3) If the Intel i210 is
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, Jan 14, 2021 at 02:20:10PM +0100, Niklas Schnelle wrote:
> &g
[+cc thermal and DT folks]
On Thu, Jan 14, 2021 at 06:04:18PM +0100, Waldemar Rymarkiewicz wrote:
> Hi,
>
> I've been looking for a nice way to hook up a PCIe device into the
> thermal framework recently and I want to confront my findings with the
> right people here.
>
> I have a PCIe wireless
[cc'd efifb and vgaarb maintainers on bugzilla, but not sure whether
people pay attention to that]
On Thu, Jan 14, 2021 at 10:42:53AM +, bugzilla-dae...@bugzilla.kernel.org
wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=211189
>
> Bug ID: 211189
>Summary: vgaarb
On Wed, Jan 13, 2021 at 01:16:05PM +1100, Victor Ding wrote:
> On Wed, Jan 13, 2021 at 9:32 AM Bjorn Helgaas wrote:
> > On Tue, Jan 12, 2021 at 04:02:04AM +, Victor Ding wrote:
> > > Right after powering up, the device may have ASPM enabled; however,
> > > its LTR a
[+cc Rafael, suspend/resume expert]
On Wed, Jan 13, 2021 at 01:16:23PM +1100, Victor Ding wrote:
> On Wed, Jan 13, 2021 at 9:38 AM Bjorn Helgaas wrote:
> > On Tue, Jan 12, 2021 at 04:02:05AM +, Victor Ding wrote:
> > > GL9750 has a 3100us PortTPowerOnTime; however, it
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 the UID of the function zero if
> >> there a
On Sat, Jan 09, 2021 at 07:31:46PM +0100, Michael Walle wrote:
> Hi Bjorn,
>
> Am 2021-01-08 22:20, schrieb Bjorn Helgaas:
> > On Wed, Dec 30, 2020 at 07:53:17PM +0100, Michael Walle wrote:
> > > The Intel i210 doesn't work if the Expansion ROM BAR overlaps with
On Sat, Jan 09, 2021 at 10:53:53AM +0100, Ard Biesheuvel wrote:
> The _DSM #5 method in the ACPI host bridge object tells us whether the
> OS is permitted to deviate from the resource assignment configured by
> the firmware. If this is not the case, we should not permit drivers to
> resize BARs on
On Tue, Jan 12, 2021 at 04:02:05AM +, Victor Ding wrote:
> GL9750 has a 3100us PortTPowerOnTime; however, it enters L1.2 after
> only ~4us inactivity per PCIe trace. During a suspend/resume process,
> PCI access operations are frequently longer than 4us apart.
> Therefore, the device frequently
Hi Victor,
Thanks for the patch. Improving suspend/resume performance is always
a good thing!
On Tue, Jan 12, 2021 at 04:02:04AM +, Victor Ding wrote:
> Right after powering up, the device may have ASPM enabled; however,
> its LTR and/or L1ss controls may not be in the desired states; hence,
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 Checking is turned on.
> Otherwise we automatically generate domains as devices ap
Note subject line tips at
https://lore.kernel.org/r/20171026223701.ga25...@bhelgaas-glaptop.roam.corp.google.com
On Tue, Jan 12, 2021 at 03:27:39PM +0800, mingchuang.q...@mediatek.com wrote:
> From: Mingchuang Qiao
>
> In pci bus scan flow, the LTR mechanism enable bit of DEVCTL2 register
> is
On Tue, Jan 12, 2021 at 02:49:52PM +0800, Zhangfei Gao wrote:
> HiSilicon KunPeng920 and KunPeng930 have devices appear as PCI but are
> actually on the AMBA bus. These fake PCI devices can not support tlp
> and have to enable SMMU stall mode to use the SVA feature.
>
> Add a quirk to set dma-can-
On Tue, Jan 12, 2021 at 10:55:50PM +0800, 刘乐乐(乐了) wrote:
> Ben,
>
> Thanks for your hard work. I have compiled this patch(aff2b059786d ,
> cxl-2.0v3) together qemu emulator v3, this is the first time I see a CXL
> device in linux.
>
> Still I have problems, I can saw the CXL device with `lspci -v
[+cc Keith]
On Thu, Dec 10, 2020 at 04:41:42PM -0600, Bjorn Helgaas wrote:
> On Mon, Nov 02, 2020 at 03:09:51PM +, Hedi Berriche wrote:
> > Commit 6d2c89441571 ("PCI/ERR: Update error status after reset_link()")
> > broke pcie_do_recovery(): updating status after
s/pci reset/reset/ in subject (it's obvious this is for PCI).
On Fri, Dec 25, 2020 at 05:25:30PM +0800, Chiqijun wrote:
> When multiple VFs do FLR at the same time, the firmware is
> processed serially, resulting in some VF FLRs being delayed more
> than 100ms, when the virtual machine restarts an
On Wed, Dec 30, 2020 at 07:53:17PM +0100, Michael Walle wrote:
> The Intel i210 doesn't work if the Expansion ROM BAR overlaps with
> another BAR. Networking won't work at all and once a packet is sent the
> netdev watchdog will bite:
Hi Michael,
Sorry for the issue on your system and thanks for
At the very least you could pick one of the subject line prefixes that
has been used before for either mshyperv.h or pci-hyperv.c instead of
making up something completely new and different.
On Fri, Jan 08, 2021 at 07:31:08AM +, Sunil Muthuswamy wrote:
> Currently, operations related to irq/ms
a link to the ZRX-DC specification you can mention somewhere
in this series?
> Signed-off-by: Anvesh Salveru
> Signed-off-by: Pankaj Dubey
> Signed-off-by: Shradha Todi
> Cc: Jingoo Han
> Cc: Gustavo Pimentel
> Cc: Lorenzo Pieralisi
> Cc: Rob Herring
> Cc: Bjo
There seems to be a long tradition of dreaming up random formats for
the subject lines of Hyper-V-related patches. Look at all the
different ways these are spelled, hyphenated, and capitalized:
$ git log --oneline arch/x86/include/asm/mshyperv.h
626b901f6044 ("Drivers: hv: vmbus: Add parsing
On Wed, Jan 06, 2021 at 02:57:19PM -0500, Jim Quinlan wrote:
> On Wed, Jan 6, 2021 at 2:42 PM Jim Quinlan wrote:
> >
> > -- Forwarded message -
> > From: Bjorn Helgaas
> > Date: Wed, Jan 6, 2021 at 2:19 PM
> > Subject: Re: [PATCH v2 5/6] PCI: brc
On Mon, Nov 30, 2020 at 04:11:37PM -0500, Jim Quinlan wrote:
> v2 -- Use regulator bulk API rather than multiple calls (MarkB).
>
> v1 -- Bindings are added for fixed regulators that may power the EP device.
>-- The brcmstb RC driver is modified to control these regulators
> during probe
On Mon, Nov 30, 2020 at 04:11:42PM -0500, Jim Quinlan wrote:
> Whereas most PCIe HW returns 0x on illegal accesses and the like,
> by default Broadcom's STB PCIe controller effects an abort. This simple
> handler determines if the PCIe controller was the cause of the abort and if
> so, pri
On Mon, Dec 28, 2020 at 09:50:38PM +0800, Zheng Yongjun wrote:
> spinlock can be initialized automatically with DEFINE_SPINLOCK()
> rather than explicitly calling spin_lock_init().
See this again:
https://lore.kernel.org/r/20171026223701.ga25...@bhelgaas-glaptop.roam.corp.google.com
> Signed-off
On Wed, Dec 16, 2020 at 09:19:44PM +0800, Zheng Yongjun wrote:
> Replace a comma between expression statements by a semicolon.
Looks like a good fix, but read this about the changelog title:
https://lore.kernel.org/r/20171026223701.ga25...@bhelgaas-glaptop.roam.corp.google.com
> Signed-off-by: Z
> From: Kenneth R. Crudup
>
> I've been running Linus' master branch on my laptop (Dell XPS 13
> 2-in-1). With this commit in place, after resuming from hibernate
> my machine is essentially useless, with a torrent of disk I/O errors
> on my NVMe device (at least, and possibly other devices affe
The following changes since commit 255b2d524884e4ec60333131aa0ca0ef19826dc2:
Merge branch 'remotes/lorenzo/pci/misc' (2020-12-15 15:11:14 -0600)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
tags/pci-v5.11-fixes-1
for you to fetch cha
On Fri, Dec 18, 2020 at 09:04:08PM +0530, Shradha Todi wrote:
> Since outbound iATU permits size to be greater than
> 4GB for which the support is also available, allow
> EP function to send u64 size instead of truncating
> to u32.
Please wrap your commit messages so they use more of an 80-column
On Fri, Dec 18, 2020 at 09:15:16PM +0530, Shradha Todi wrote:
> get_features ops of pci_epc_ops may return NULL, causing NULL pointer
> dereference in pci_epf_test_bind function. Let us add a check for
> pci_epc_feature pointer in pci_epf_test_bind before we access it to
> avoid any such NULL point
On Tue, Dec 22, 2020 at 03:07:43PM +, Alexander Lobakin wrote:
> Commit 660c486590aa ("PCI: dwc: Set 32-bit DMA mask for MSI target
> address allocation") added dma_mask_set() call to explicitly set
> 32-bit DMA mask for MSI message mapping, but for now it throws a
> warning on ret == 0, while
From: Bjorn Helgaas
The lkml.org, marc.info, spinics.net, etc archives are not quite as useful
as lore.kernel.org because they use different styles, add advertising, and
may disappear in the future. The lore archives are more consistent and
more likely to stick around, so prefer https
On Wed, Dec 16, 2020 at 07:24:30PM +0800, Zhou Wang wrote:
> On 2020/6/23 23:04, Bjorn Helgaas wrote:
> > On Fri, Jun 19, 2020 at 10:26:54AM +0800, Zhangfei Gao wrote:
> >> Have studied _DSM method, two issues we met comparing using quirk.
> >>
> >>
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 Tue, Dec 15, 2020 at 12:30:09PM +0530, Kishon Vijay Abraham I wrote:
> From: Nadeem Athani
>
> Cadence controller will not initiate autonomous speed change if strapped as
> Gen2. The Retrain Link bit is set as quirk to enable this speed change.
>
> Signed-off-by: Nadeem Athani
> [kis...@ti.c
from pci_find_capability() and similar (Puranjay Mohan)
- Return u16 from pci_find_ext_capability() and similar (Bjorn Helgaas)
- Fix ACPI companion lookup for device 0 on the root bus (Rafael J.
Wysocki)
Resource management:
- Keep both device and resource name for config space remaps (Ale
On Tue, Dec 15, 2020 at 01:04:25PM -0500, Alex Deucher wrote:
> On Tue, Dec 15, 2020 at 12:25 PM Bjorn Helgaas wrote:
> >
> > On Mon, Dec 14, 2020 at 10:52:26PM -0800, Kuppuswamy, Sathyanarayanan wrote:
> > > On 12/14/20 3:37 PM, Bjorn Helgaas wrote:
> > > >
On Mon, Dec 14, 2020 at 10:52:26PM -0800, Kuppuswamy, Sathyanarayanan wrote:
> On 12/14/20 3:37 PM, Bjorn Helgaas wrote:
> > On Mon, Dec 14, 2020 at 06:18:54PM -0500, Alex Deucher wrote:
> > > On Mon, Dec 14, 2020 at 6:16 PM Bjorn Helgaas wrote:
> > > > On Tue, De
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 06:18:54PM -0500, Alex Deucher wrote:
> On Mon, Dec 14, 2020 at 6:16 PM Bjorn Helgaas wrote:
> > On Tue, Dec 15, 2020 at 07:34:31AM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > On Tue, 8 Dec 2020 13:56:20
On Tue, Dec 15, 2020 at 07:34:31AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 8 Dec 2020 13:56:20 +1100 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the amdgpu tree got a conflict in:
> >
> > drivers/pci/pcie/err.c
> >
> > between commits:
> >
> > 8f1bbfbc3596 (
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 Fri, Dec 11, 2020 at 09:17:35PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> In some cases acpi_pci_find_companion() returns an incorrect device
> object as the ACPI companion for device 0 on the root bus (bus 0).
>
> On the affected systems that device is the PCI interface t
On Fri, Dec 11, 2020 at 09:50:52PM +, Chaitanya Kulkarni wrote:
> On 12/11/20 08:45, Puranjay Mohan wrote:
> > PCI core calls __pcie_print_link_status() for every device, it prints
> > both the link width and the link speed. skd_pci_info() does the same
> > thing again, hence it can be removed.
On Fri, Dec 11, 2020 at 08:49:16AM -0600, Rob Herring wrote:
> On Fri, Dec 11, 2020 at 7:58 AM Vidya Sagar wrote:
> >
> > Hi Lorenzo,
> > Apologies to bug you, but wondering if you have any further comments on
> > this patch that I need to take care of?
>
> You can check the status of your patche
ESULT_NO_AER_DRIVER.
>
> Fixes: 6d2c89441571 ("PCI/ERR: Update error status after reset_link()")
> Signed-off-by: Hedi Berriche
>
> Reviewed-by: Sinan Kaya
> Cc: Russ Anderson
> Cc: Kuppuswamy Sathyanarayanan
> Cc: Bjorn Helgaas
> Cc: Ashok Raj
> Cc: Joe
f : 18b0.pci config
> 18b2-18b21fff : 18b2.pci dbi
> 18b3-18b31fff : 18b2.pci config
>
> Since v1 [0]:
> - massage subject and commit message (Bjorn);
> - no functional changes.
>
> [0]
> https://lore.kernel.org/lkml/jvyozv8k8n5ccdp1xflodowh4abfr
[+cc Alex (please include people who have commented on previous
versions]
Looking for your ack before applying this, Alex.
On Wed, Dec 02, 2020 at 07:34:50PM +0800, Chiqijun wrote:
> When multiple VFs do FLR at the same time, the firmware is
> processed serially, resulting in some VF FLRs being d
On Mon, Dec 07, 2020 at 02:39:50PM -0800, David E. Box wrote:
> The PCI subsystem does not currently save and restore the configuration
> space for the Precision Time Measurement (PTM) PCIe extended capability
> leading to the possibility of the feature returning disabled on S3 resume.
> This has b
On Thu, Dec 10, 2020 at 08:46:24AM +0800, Lu Baolu wrote:
> The pci_subdevice_msi_create_irq_domain() should fail if the underlying
> platform is not able to support IMS (Interrupt Message Storage). Otherwise,
> the isolation of interrupt is not guaranteed.
>
> For x86, IMS is only supported on ba
101 - 200 of 3449 matches
Mail list logo
