: probe with driver e1000e failed with
> error -12
> `
> After bisecting the tree, the following patch [3] seems to be the first "bad"
> commit
>
> ````````
On Thu, Sep 26, 2024 at 07:03:16PM +0300, Ville Syrjälä wrote:
> On Wed, Sep 25, 2024 at 02:28:42PM -0500, Bjorn Helgaas wrote:
> > On Wed, Sep 25, 2024 at 05:45:21PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > On some older laptops i91
chines. Apart from that we'll just let the normal
> pci pm code take care of everything for us.
>
> Cc: Bjorn Helgaas
> Cc: "Rafael J. Wysocki"
> Cc: Rodrigo Vivi
> Cc: linux-...@vger.kernel.org
> Cc: intel-gfx@lists.freedesktop.org
> Signed-off-by: Ville
On Wed, Sep 25, 2024 at 05:45:24PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> If the driver doesn't call pci_save_state() driver/pci will
> normally save+power manage the device from the _noirq() pm
> hooks.
drivers/pci. Or maybe just mention the PM hook names specifically.
> We can
+++++------
> drivers/pci/pci-driver.c | 16 +++-
> 2 files changed, 94 insertions(+), 43 deletions(-)
> Cc: Bjorn Helgaas
> Cc: "Rafael J. Wysocki"
> Cc: Rodrigo Vivi
> Cc: linux-...@vger.kernel.org
> Cc: intel-gfx@lists.freedesktop.org
> Signed-
h_string(ecrc_policy_str, ARRAY_SIZE(ecrc_policy_str), str);
> + i = match_string(ecrc_policy_str, str);
> if (i < 0)
> return;
>
Acked-by: Bjorn Helgaas# drivers/pci/
> +++ b/mm/vmpressure.c
> @@ -388,7 +388,7 @@ int vmpressure_register_event(str
f/0x170
>
> Switch to a shared static key for all instances.
>
> Fixes: 7e89efc6e9e4 ("PCI: Lock upstream bridge for pci_reset_function()")
> Reported-by: Jani Saarinen
> Closes:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14834/bat-apl-1/boot0.txt
> Cc: Dav
tion()")
> Reported-by: Jani Saarinen
> Closes:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14834/bat-apl-1/boot0.txt
> Cc: Dave Jiang
> Cc: Bjorn Helgaas
> Signed-off-by: Dan Williams
Applied with Alison's reviewed-by and Jani's tested-by to for-linus
fo
loses:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_14834/bat-apl-1/boot0.txt
> Cc: Dave Jiang
> Cc: Bjorn Helgaas
> Signed-off-by: Dan Williams
> ---
> drivers/pci/probe.c | 7 ---
> include/linux/pci.h | 1 -
> 2 files changed, 4 insertions(+), 4 deletions(-)
n RPL-P
> >
> > arch/x86/kernel/early-quirks.c| 19 +++---
>
> Bjorn, ack for merging this via drm-intel-next?
Sorry, I had ignored this because I didn't think it affected any PCI
stuff. This is fine with me:
Acked-by: Bjorn Helgaas
But since you asked :)
On Tue, Jan 23, 2024 at 08:44:04PM +, Sakari Ailus wrote:
> On Tue, Jan 23, 2024 at 11:24:23AM -0600, Bjorn Helgaas wrote:
> ...
> > - I don't know whether it's feasible, but it would be nice if the
> > intel_pm_runtime_pm.c rework could be done in one shot
sound/
> Reviewed-by: Jacek Lawrynowicz #
> drivers/accel/ivpu/
> Acked-by: Rodrigo Vivi # drivers/gpu/drm/i915/
> Reviewed-by: Rodrigo Vivi
Acked-by: Bjorn Helgaas # drivers/pci/
- Previous PM history uses "PM: " in the subject lines (not "pm: ").
- I don
ed-by: Takashi Iwai # sound/
> Reviewed-by: Jacek Lawrynowicz #
> drivers/accel/ivpu/
> Acked-by: Rodrigo Vivi # drivers/gpu/drm/i915/
> Reviewed-by: Rodrigo Vivi
Acked-by: Bjorn Helgaas # drivers/pci/
> -EXPORT_SYMBOL_GPL(pm_runtime_get_if_active);
> +EXPORT_SYMBOL_GPL(pm_ru
On Mon, Jul 24, 2023 at 08:47:48PM +0800, suijingfeng wrote:
> On 2023/7/20 03:32, Bjorn Helgaas wrote:
> > "drm/loongson: Add an implement for ..." also solves a problem, but it
> > lacks a commit log, so I don't know what the problem is.
>
> I have already
On Mon, Jul 24, 2023 at 08:16:18PM +0800, suijingfeng wrote:
> On 2023/7/20 03:32, Bjorn Helgaas wrote:
> > > 2) It does not take the PCI Bar may get relocated into consideration.
> > > 3) It is not effective for the PCI device without a dedicated VRAM Bar.
> > > 4)
On Wed, Jul 12, 2023 at 12:43:02AM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> This patch adds the aperture_contain_firmware_fb() function to do the
> determination. Unfortunately, due to the fact that the apertures list
> will be freed dynamically, the location and size information of th
[+cc linux-pci; I don't apply or ack PCI patches unless they appear there]
On Wed, Jul 12, 2023 at 12:43:04AM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> The observation behind this is that we should avoid accessing the global
> screen_info directly. Call the aperture_contain_firmware_fb
[+cc linux-pci]
On Wed, Jul 12, 2023 at 12:43:01AM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> Currently, the default VGA device selection is not perfect. Potential
> problems are:
>
> 1) This function is a no-op on non-x86 architectures.
> 2) It does not take the PCI Bar may get reloca
[+cc linux-pci (please cc in the future since the bulk of this patch
is in drivers/pci/)]
On Wed, Jul 12, 2023 at 12:43:05AM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> Currently, the strategy of selecting the default boot on a multiple video
> card coexistence system is not perfect. Pot
On Fri, Jun 30, 2023 at 10:14:11AM +0800, suijingfeng wrote:
> On 2023/6/30 01:44, Limonciello, Mario wrote:
> > > On 2023/6/29 23:54, Bjorn Helgaas wrote:
> > > > On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote:
> > > > 4) Right now we're i
On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote:
> Hi,
>
>
> A nouveau developer(Lyude) from redhat send me a R-B,
>
> Thanks for the developers of nouveau project.
>
>
> Please allow me add a link[1] here.
>
>
> [1]
> https://lore.kernel.org/all/0afadc69f99a36bc9d03ecf54ff2585
On Fri, Jun 09, 2023 at 03:09:26PM -0700, David E. Box wrote:
> Hi Bjorn,
>
> On Thu, 2023-06-08 at 15:52 -0500, Bjorn Helgaas wrote:
> > On Tue, Apr 11, 2023 at 02:33:23PM -0700, David E. Box wrote:
> > > In commit f492edb40b54 ("PCI: vmd: Add quirk to configure PCIe
On Fri, Jun 09, 2023 at 10:27:39AM +0800, Sui Jingfeng wrote:
> On 2023/6/9 03:19, Bjorn Helgaas wrote:
> > On Thu, Jun 08, 2023 at 07:43:22PM +0800, Sui Jingfeng wrote:
> > > From: Sui Jingfeng
> > >
> > > The vga_is_firmware_default() function is arch-depend
On Tue, Apr 11, 2023 at 02:33:23PM -0700, David E. Box wrote:
> In commit f492edb40b54 ("PCI: vmd: Add quirk to configure PCIe ASPM and
> LTR") the VMD driver calls pci_enabled_link_state as a callback from
> pci_bus_walk. Both will acquire the pci_bus_sem lock leading to a lockdep
> warning. Inste
On Thu, Jun 08, 2023 at 07:43:22PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> The vga_is_firmware_default() function is arch-dependent, which doesn't
> sound right. At least, it also works on the Mips and LoongArch platforms.
> Tested with the drm/amdgpu and drm/radeon drivers. However,
Start with verb and capitalize to match ("Deal only with ...")
On Thu, Jun 08, 2023 at 07:43:21PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> vgaarb only deal with the VGA devcie(pdev->class == 0x0300), so replace the
> pci_get_subsys() function with pci_get_class(). Filter the non pci d
Capitalize subject to match ("Tidy ...")
On Thu, Jun 08, 2023 at 07:43:19PM +0800, Sui Jingfeng wrote:
> From: Sui Jingfeng
>
> This patch replaces the leading space with a tab and removes the double
> blank line, no functional change.
Can you move this to the end of the series? The functional
Match the subject line style:
$ git log --oneline drivers/pci/vgaarb.c
f321c35feaee PCI/VGA: Replace full MIT license text with SPDX identifier
d5109fe4d1ec PCI/VGA: Use unsigned format string to print lock counts
4e6c91847a7f PCI/VGA: Log bridge control messages when adding devices
dc59
On Wed, Mar 22, 2023 at 03:45:01PM -0500, Bjorn Helgaas wrote:
> Hi David,
>
> On Tue, Mar 21, 2023 at 04:38:49PM -0700, David E. Box wrote:
> > The VMD driver calls pci_enabled_link_state as a callback from
> > pci_bus_walk. Both will acquire the pci_bus_sem lock leading to
Hi David,
On Tue, Mar 21, 2023 at 04:38:49PM -0700, David E. Box wrote:
> The VMD driver calls pci_enabled_link_state as a callback from
> pci_bus_walk. Both will acquire the pci_bus_sem lock leading to a lockdep
> warning. Add an argument to pci_enable_link_state to set whether the lock
> should
[+cc Christian, author of pci_resize_resource(), Sergei, author of
rebalancing patches]
Hi Lucas,
On Fri, Jun 17, 2022 at 11:44:41AM -0700, Lucas De Marchi wrote:
> Cc'ing intel-pci, lkml, Bjorn
>
> On Fri, Jun 17, 2022 at 11:32:37AM +0300, Jani Nikula wrote:
> > On Thu, 16 Jun 2022, priyanka.da
On Fri, Mar 11, 2022 at 12:06:38PM +0200, Jani Nikula wrote:
> early-quirks.c is the only user of drm/i915_drm.h that also needs
> drm/i915_pciids.h. Include the masses of PCI ID macros only where
> needed.
>
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
> Cc: x...@ke
The following changes since commit fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf:
Linux 5.16-rc1 (2021-11-14 13:56:52 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git
tags/pci-v5.17-fixes-1
for you to fetch changes up to 9c494ca4d3a535
On Wed, Jan 19, 2022 at 12:30:04PM -0800, Lucas De Marchi wrote:
> On Tue, Jan 18, 2022 at 02:01:45PM -0600, Bjorn Helgaas wrote:
> > Haha :) I was hoping not to touch it myself because I think this
> > whole stolen memory thing is kind of nasty. It's not clear to me why
&
On Tue, Jan 18, 2022 at 07:37:29PM +0100, Borislav Petkov wrote:
> On Tue, Jan 18, 2022 at 11:58:53AM -0600, Bjorn Helgaas wrote:
> > I don't really care much one way or the other. I think the simplest
> > approach is to remove QFLAG_APPLY_ONCE from intel_graphics_quirks()
>
On Tue, Jan 18, 2022 at 06:26:48PM +0100, Borislav Petkov wrote:
> On Tue, Jan 18, 2022 at 08:36:56AM -0800, Lucas De Marchi wrote:
> > I had the impression the subject/title should be imperative, with it
> > more relaxed in the body. It seems we have one more difference among
> > subsystems and I
On Wed, Jan 12, 2022 at 04:21:28PM -0800, Lucas De Marchi wrote:
> On Wed, Jan 12, 2022 at 06:08:05PM -0600, Bjorn Helgaas wrote:
> > On Wed, Jan 12, 2022 at 03:30:43PM -0800, Lucas De Marchi wrote:
> > > The flags are only used to mark a quirk to be called once and nothing
>
ace the uses of QFLAG_APPLY_ONCE with static local variables in
> the few quirks that use this logic and remove all the flags logic.
>
> Signed-off-by: Lucas De Marchi
> Reviewed-by: Bjorn Helgaas
Only occurred to me now, but another, less intrusive approach would be
to just r
On Mon, Jan 10, 2022 at 12:11:36PM -0500, Rodrigo Vivi wrote:
> On Fri, Jan 07, 2022 at 08:57:32PM -0600, Bjorn Helgaas wrote:
> > On Fri, Jan 07, 2022 at 01:05:16PM -0800, Lucas De Marchi wrote:
> > > early_pci_scan_bus() does a depth-first traversal, possibly calling
> &g
On Fri, Jan 07, 2022 at 01:05:16PM -0800, Lucas De Marchi wrote:
> early_pci_scan_bus() does a depth-first traversal, possibly calling
> the quirk functions for each device based on vendor, device and class
> from early_qrk table. intel_graphics_quirks() however uses PCI_ANY_ID
> and does additiona
s applied/
> So replace the uses of QFLAG_APPLY_ONCE with static local variables in
> the few quirks that use this logic and remove all the flags logic.
>
> Signed-off-by: Lucas De Marchi
Reviewed-by: Bjorn Helgaas
> ---
>
> v3: Keep in this patch only the
On Thu, Jan 06, 2022 at 02:30:47PM -0800, Lucas De Marchi wrote:
> On Thu, Jan 06, 2022 at 03:58:50PM -0600, Bjorn Helgaas wrote:
> > On Wed, Jan 05, 2022 at 04:36:53PM -0800, Lucas De Marchi wrote:
> > > When using QFLAG_APPLY_ONCE we make sure the quirk is called only once.
&g
On Wed, Jan 05, 2022 at 04:36:54PM -0800, Lucas De Marchi wrote:
> Remove extra parenthesis and wrap lines so it's easier to read what are
> the conditions being checked. The call to the hook also had an extra
> indentation: remove here to conform to coding style.
It's nice when your subject lines
lderlake-P.
>
> Since there are just a few quirks using the QFLAG_APPLY_ONCE logic and
> that is even the only flag, just use a static local variable in the
> quirk function itself. This allows to mark the quirk as applied only
> when it really is. As pointed out by Bjorn Helgaas, this is
On Fri, Dec 17, 2021 at 10:13:13PM -0800, Lucas De Marchi wrote:
> When using QFLAG_APPLY_ONCE we make sure the quirk is applied only once.
Maybe "called" only once, since you're about to add a distinction
between "called" and "applied"?
I'm not really sure the concept of QFLAG_APPLY_ONCE, QFLAG_
[+cc Joel (reporter)]
On Mon, Jun 21, 2021 at 04:50:14PM -0500, Bjorn Helgaas wrote:
> - Forwarded message from bugzilla-dae...@bugzilla.kernel.org -
>
> Date: Mon, 21 Jun 2021 02:50:09 +
> From: bugzilla-dae...@bugzilla.kernel.org
> To: bj...@helgaas.com
> Subject
- Forwarded message from bugzilla-dae...@bugzilla.kernel.org -
Date: Mon, 21 Jun 2021 02:50:09 +
From: bugzilla-dae...@bugzilla.kernel.org
To: bj...@helgaas.com
Subject: [Bug 213519] New: WARNING on system reboot in:
drivers/gpu/drm/i915/intel_runtime_pm.c:635
intel_runtime_pm
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 Fri, Apr 10, 2020 at 05:56:13PM +0200, Rafael J. Wysocki wrote:
> From: "Rafael J. Wysocki"
>
> Rename DPM_FLAG_NEVER_SKIP to DPM_FLAG_NO_DIRECT_COMPLETE which
> matches its purpose more closely.
>
> No functional impact.
>
> Signed-off-by: Rafael J. Wysock
s is not linked to
> > the main index.rst file, in order to avoid build warnings.
> >
> > Signed-off-by: Mauro Carvalho Chehab
> > Acked-by: Mark Brown
> > Acked-by: Bjorn Helgaas
> > Acked-by: Srivatsa S. Bhat (VMware)
>
> So I can't apply this one
On Thu, Oct 11, 2018 at 03:11:01PM +0800, Bin Meng wrote:
> On Wed, Oct 10, 2018 at 1:02 AM Bjorn Helgaas wrote:
> > On Mon, Oct 08, 2018 at 05:44:08PM +0800, Bin Meng wrote:
> > > On Thu, Oct 4, 2018 at 4:12 AM Bjorn Helgaas wrote:
> > > > On Thu, Sep 27, 2018
On Mon, Oct 08, 2018 at 05:44:08PM +0800, Bin Meng wrote:
> On Thu, Oct 4, 2018 at 4:12 AM Bjorn Helgaas wrote:
> > On Thu, Sep 27, 2018 at 10:10:07AM +0800, Bin Meng wrote:
> > > On Thu, Sep 27, 2018 at 12:57 AM Bjorn Helgaas wrote:
> > > > On Wed, Sep 26, 2018
On Thu, Sep 27, 2018 at 10:10:07AM +0800, Bin Meng wrote:
> On Thu, Sep 27, 2018 at 12:57 AM Bjorn Helgaas wrote:
> > On Wed, Sep 26, 2018 at 08:14:01AM -0700, Bin Meng wrote:
> > > Add more PCI IDs to the Intel GPU "spurious interrupt" quirk table,
> > > whi
[+cc Intel DRM maintainers, etc]
On Wed, Sep 26, 2018 at 08:14:01AM -0700, Bin Meng wrote:
> Add more PCI IDs to the Intel GPU "spurious interrupt" quirk table,
> which are known to break.
Do you have a reference for this? Any public bug reports, bugzilla,
Intel spec reference or errata? "Which
On Mon, Jul 09, 2018 at 10:36:48AM +0200, Daniel Vetter wrote:
> Avoids the inverted condition compared to the open-coded version.
>
> Signed-off-by: Daniel Vetter
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
Acked-by: Bjorn Helgaas
I assume you'll merge this
On Mon, Nov 27, 2017 at 11:57:46AM -0500, Sinan Kaya wrote:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI device is present. This restricts the device drivers to be
> reused for other domain numbers.
>
> Getting ready to remove pci_get_bus_and_slot() functi
Hi Sinan,
On Mon, Nov 27, 2017 at 11:57:37AM -0500, Sinan Kaya wrote:
> Deprecate pci_get_bus_and_slot() in favor of pci_get_domain_bus_and_slot()
> in order to remove domain 0 assumptions in the kernel.
>
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
> where a PCI devi
in
> Cc: Jarkko Sakkinen
> Cc: Jani Nikula
> Cc: Ben Skeggs
> Cc: Benjamin Tissoires
> Cc: Joerg Roedel
> Cc: Adrian Hunter
> Cc: Yisen Zhuang
> Cc: Bjorn Helgaas
> Cc: Zhang Rui
> Cc: Felipe Balbi
> Cc: Mathias Nyman
> Cc: Heikki Krogerus
> Cc
On Thu, Mar 03, 2016 at 10:53:50AM -0600, Bjorn Helgaas wrote:
> The purpose of this series is to:
> ...
> - Move arch-specific shadow ROM location knowledge, e.g.,
> 0xC-0xD, from PCI core to arch code.
> ...
> Bjorn Helgaas (12):
> PCI: Mark shad
On Fri, Mar 11, 2016 at 01:16:09PM -0800, Andy Lutomirski wrote:
> On Tue, Mar 8, 2016 at 9:45 AM, Bjorn Helgaas wrote:
> > On Thu, Mar 03, 2016 at 10:53:50AM -0600, Bjorn Helgaas wrote:
> >> The purpose of this series is to:
> >>
> >> - Fix the "BA
On Thu, Mar 03, 2016 at 10:53:50AM -0600, Bjorn Helgaas wrote:
> The purpose of this series is to:
>
> - Fix the "BAR 6: [??? 0x flags 0x2] has bogus alignment"
> messages reported by Linus [1], Andy [2], and others.
>
> - Move arch-specific shadow
The value of pdev->rom_attr is the definitive indicator of the fact that
we're created a sysfs attribute. Check that rather than rom_size, which is
only used incidentally when deciding whether to create a sysfs attribute.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/pci-sysfs.
_map_rom() will
ioremap() it as needed.
Signed-off-by: Bjorn Helgaas
---
arch/mips/pci/fixup-loongson3.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/mips/pci/fixup-loongson3.c b/arch/mips/pci/fixup-loongson3.c
index b66b1eb..c015ca1 100644
--- a/arch
Use a temporary struct resource pointer to avoid needless repetition of
"pdev->resource[PCI_ROM_RESOURCE]". No functional change intended.
Signed-off-by: Bjorn Helgaas
---
arch/mips/pci/fixup-loongson3.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff
The IORESOURCE_ROM_COPY and IORESOURCE_ROM_BIOS_COPY bits are unused.
Remove them and code that depends on them.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/remove.c |1 -
drivers/pci/rom.c | 31 +--
include/linux/ioport.h |2 --
3 files changed, 1
.
Note that this makes it obvious that (a) we're putting a virtual address in
a struct resource, and (b) we're passing a virtual address to ioremap()
below in the PCI_ROM_RESOURCE case. These are both pre-existing problems
that I'll resolve next.
Signed-off-by: Bjorn Helgaas
---
arch
Use a temporary struct resource pointer to avoid needless repetition of
"dev->resource[idx]". No functional change intended.
Signed-off-by: Bjorn Helgaas
---
arch/ia64/sn/kernel/io_acpi_init.c | 10 +
arch/ia64/sn/kernel/io_init.c | 39 --
that ioremaps the copy.
Signed-off-by: Bjorn Helgaas
---
arch/ia64/sn/kernel/io_acpi_init.c | 18 +++---
arch/ia64/sn/kernel/io_init.c | 17 +
2 files changed, 16 insertions(+), 19 deletions(-)
diff --git a/arch/ia64/sn/kernel/io_acpi_init.c
b/arch/ia
Remove unnecessary indentation in pci_map_rom(). This is logically part of
the previous patch; I split it out to make the critical changes in that
patch more obvious. No functional change intended.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/rom.c | 37
om the ROM BAR.
Signed-off-by: Bjorn Helgaas
---
arch/ia64/pci/fixup.c | 22 --
arch/x86/pci/fixup.c | 22 --
drivers/pci/rom.c | 11 ---
include/linux/ioport.h |2 +-
4 files changed, 33 insertions(+), 24 deletions(-)
diff --git
ed by pdev_sort_resources(), which already ignores
IORESOURCE_PCI_FIXED resources.
Link:
http://lkml.kernel.org/r/ca+55afyvmftbb0oz_yx8+eqoejnzgtcsysj9quhepdz9bhd...@mail.gmail.com
Signed-off-by: Bjorn Helgaas
---
arch/ia64/pci/fixup.c |3 ++-
arch/x86/pci/fixup.c |3 ++-
2 files chang
If we're using a RAM shadow copy instead of the ROM BAR, we don't need to
touch the ROM BAR enable bit.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/rom.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/rom.c b/drivers/pci/rom.c
ind
IORESOURCE_PCI_FIXED means the resource can't be moved, so if it's set,
don't bother trying to assign or reassign the resource.
Signed-off-by: Bjorn Helgaas
---
drivers/pci/setup-res.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/pci/setup-res.c b/drivers/
kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/resource
---
Bjorn Helgaas (12):
PCI: Mark shadow copy of VGA ROM as IORESOURCE_PCI_FIXED
PCI: Don't assign or reassign immutable resources
PCI: Don't enable/disable ROM BAR if we're using a RAM shadow
age flags a breakage during the
> > driver's automated testing which parses dmesg and picks up the error.
> >
> > Reported-by: Daniel Vetter
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92992
> > CC: Bjorn Helgaas
> > CC: Rafael J. Wysocki
> - use pr_debug(), pr_err() instead of the corresponding printk() (Rafael)
The version history is very useful during development but not after
merging, so I prefer it to go after the "---" marker so it doesn't get
included in the permanent changelog.
> Reported-by: Daniel Vet
a few extra register defines from i915_reg.h, decouple the
> two by defining the required registers locally in quirks.c. This was
> already done for a few other igpu related registers.
>
> Cc: Bjorn Helgaas
> Cc: linux-...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org
> Sign
[+cc Matthew]
On Tue, Apr 21, 2015 at 09:07:45AM -0700, Linus Torvalds wrote:
> Hmm. The odd Intel PCI resource mess is back.
>
> Or maybe it never went away.
>
> I get these when suspending. Things *work*, but it's really spamming
> my logs a fair bit:
>
> i915 :00:02.0: BAR 6: [??? 0x00
On Tue, Apr 21, 2015 at 11:07 AM, Linus Torvalds
wrote:
> Hmm. The odd Intel PCI resource mess is back.
>
> Or maybe it never went away.
>
> I get these when suspending. Things *work*, but it's really spamming
> my logs a fair bit:
>
> i915 :00:02.0: BAR 6: [??? 0x flags 0x2] has bog
On Fri, Aug 08, 2014 at 03:54:04PM +0200, Thomas Jarosch wrote:
> New Intel G3258 CPU, new MSI board, same problem:
> The GPU interrupt fired like crazy on monitor unplug.
>
> lspci output:
> 00:02.0 VGA compatible controller: Intel Corporation Device 0402 (rev 06)
> Subsystem: Micro-Star
On Fri, Apr 25, 2014 at 11:35:21AM -0600, Bjorn Helgaas wrote:
> [+cc Daniel, Jani, intel-gfx, dri-devel, -cc stable]
>
> On Mon, Apr 07, 2014 at 03:10:32PM +0200, Thomas Jarosch wrote:
> > After a CPU upgrade while keeping the same mainboard,
> > we faced "spurious
[+cc Daniel, Jani, intel-gfx, dri-devel, -cc stable]
On Mon, Apr 07, 2014 at 03:10:32PM +0200, Thomas Jarosch wrote:
> After a CPU upgrade while keeping the same mainboard,
> we faced "spurious interrupt" problems again.
>
> It turned out that the new CPU also featured a
> new GPU with a differen
On Mon, Mar 10, 2014 at 6:15 PM, Paul Bolle wrote:
> On Mon, 2014-03-10 at 18:07 -0600, Bjorn Helgaas wrote:
>> On Mon, Mar 10, 2014 at 5:45 PM, Paul Bolle wrote:
>> > A bit of doubt is caused by two new boot time messages:
>> > pnp 00:00: unknown resource type 10
[+cc Rafael]
On Mon, Mar 10, 2014 at 5:45 PM, Paul Bolle wrote:
> Bjorn Helgaas schreef op ma 10-03-2014 om 12:24 [-0600]:
>> Thanks. Can you try the patch below? I think it should fix the problem.
>>
>>
>> PCI: Don't check resource_size() in pci_bus_alloc_reso
[+cc linux-pci]
On Sat, Mar 08, 2014 at 03:44:37PM +0100, Paul Bolle wrote:
> Bjorn Helgaas schreef op za 08-03-2014 om 07:12 [-0700]:
> > I assume you have CONFIG_PHYS_ADDR_T_64BIT=n (which is perfectly
> > legal); let me know if otherwise.
>
> $ grep CONFIG_PHYS_ADDR
On Fri, Mar 7, 2014 at 1:40 PM, Bjorn Helgaas wrote:
> It seems quite possible that I broke pci_bus_alloc_resource(), which could
> cause an allocation failure like this.
>
> If you have a chance to try it, here's a debug patch against v3.14-rc5. It
> should apply cleanly
On Fri, Mar 7, 2014 at 2:03 PM, Paul Bolle wrote:
> On Fri, 2014-03-07 at 13:40 -0700, Bjorn Helgaas wrote:
>> It seems quite possible that I broke pci_bus_alloc_resource(), which could
>> cause an allocation failure like this.
>>
>> If you have a chance to try it, h
On Fri, Mar 07, 2014 at 06:16:49PM +0100, Paul Bolle wrote:
> Bjorn Helgaas schreef op vr 07-03-2014 om 09:55 [-0700]:
> > On Fri, Mar 7, 2014 at 2:48 AM, Paul Bolle wrote:
> > > This might end up not being relevant. And this is surely documented
> > > somewhere, b
On Thu, Mar 6, 2014 at 1:25 PM, Paul Bolle wrote:
> Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]:
>> Can you open a kernel.org bugzilla report and attach complete dmesg
>> logs of the working and broken kernels to it? There might be more
>> useful resource-rela
On Fri, Mar 7, 2014 at 2:48 AM, Paul Bolle wrote:
> Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]:
>> I wouldn't start bisecting yet, but if you're in the mood, this
>> commit: 96702be56037 "Merge branch 'pci/resource' into next" looks
>&g
On Thu, Mar 6, 2014 at 1:25 PM, Paul Bolle wrote:
> Bjorn Helgaas schreef op ma 10-02-2014 om 14:33 [-0700]:
>> Can you open a kernel.org bugzilla report and attach complete dmesg
>> logs of the working and broken kernels to it? There might be more
>> useful resource-rela
On Sun, Feb 9, 2014 at 6:25 AM, Paul Bolle wrote:
> On Sun, 2014-02-09 at 13:15 +, Steven Newbury wrote:
>> PCI resource allocation is undergoing some changes at the moment, it's
>> definitely a bug if the Flush Page isn't getting allocated. I'm looking
>> forward to hopefully getting pci_bus
ula
> Acked-by: Bjorn Helgaas
> Signed-off-by: Yijing Wang
> ---
> v4->v5: Add some detailed debug info for acpi_evaluate_object()
> failure suggested by Bjorn.
> v3->v4: Fix spell error, add Jani Nikula reviewed-by.
> v2->v3: Fix compile error point
se.c |9 +
> drivers/gpu/drm/nouveau/nouveau_acpi.c | 23 +--
> drivers/pci/pci-label.c|9 ++---
For the drivers/pci/pci-label.c part,
Acked-by: Bjorn Helgaas
> + status = acpi_evaluate_object(handle, &q
On Fri, Jan 24, 2014 at 8:36 AM, Rafael J. Wysocki wrote:
> On Friday, January 24, 2014 07:54:29 AM Bjorn Helgaas wrote:
>> On Thu, Jan 23, 2014 at 5:33 PM, Rafael J. Wysocki
>> wrote:
>> > On Thursday, January 23, 2014 11:21:01 AM Bjorn Helgaas wrote:
>> >
On Thu, Jan 23, 2014 at 5:33 PM, Rafael J. Wysocki wrote:
> On Thursday, January 23, 2014 11:21:01 AM Bjorn Helgaas wrote:
>> On Wed, Jan 22, 2014 at 8:42 PM, Yijing Wang wrote:
>> > Since acpi_evaluate_object() returns acpi_status and not plain int,
>> > ACPI_F
96 matches
Mail list logo
