t; >
> > 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 :), I'll gripe ag
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 instead of
/
> 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't know w
: 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_runtime
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 telli
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.
> > >
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
[+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
[+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
[+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.
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 in the
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]
>
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.
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
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
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
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,
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
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 nothin
eplace 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
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
t; 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 also more in
>
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,
[+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
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
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.
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 due to con
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?
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 thi
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()
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
m>
> Cc: Ben Skeggs <bske...@redhat.com>
> Cc: Benjamin Tissoires <benjamin.tissoi...@redhat.com>
> Cc: Joerg Roedel <j...@8bytes.org>
> Cc: Adrian Hunter <adrian.hun...@intel.com>
> Cc: Yisen Zhuang <yisen.zhu...@huawei.com>
> Cc: Bjorn Helgaas &
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 s
On Fri, Mar 11, 2016 at 01:16:09PM -0800, Andy Lutomirski wrote:
> On Tue, Mar 8, 2016 at 9:45 AM, Bjorn Helgaas <helg...@kernel.org> wrote:
> > On Thu, Mar 03, 2016 at 10:53:50AM -0600, Bjorn Helgaas wrote:
> >> The purpose of this series is to:
> >>
> >>
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 <bhelg...@google.com>
---
driver
() will
ioremap() it as needed.
Signed-off-by: Bjorn Helgaas <bhelg...@google.com>
---
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
---
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 <bhelg...@google.com>
---
arch/mips/pci/fixup-loongson3.c | 14 +++---
1 file changed, 7 inserti
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 <bhelg...@google.com>
---
drivers/pci/remove.c |1 -
drivers/pci/rom.c | 31 +--
include/linux/ioport.h
.
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 <bhelg...@google.
Use a temporary struct resource pointer to avoid needless repetition of
"dev->resource[idx]". No functional change intended.
Signed-off-by: Bjorn Helgaas <bhelg...@google.com>
---
arch/ia64/sn/kernel/io_acpi_init.c | 10 +
arch/ia64/sn/kernel/io
that ioremaps the copy.
Signed-off-by: Bjorn Helgaas <bhelg...@google.com>
---
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_
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 <bhelg...@google.com>
---
drivers/pci/rom.c
Signed-off-by: Bjorn Helgaas <bhelg...@google.com>
---
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 -
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 <bhelg...@google.com>
---
arch/ia64/pci/fixup.c |3 ++-
arch/x86/pci/fixup.c
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 <bhelg...@google.com>
---
drivers/pci/rom.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/pci/rom.c b/drive
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 <bhelg...@google.com>
---
drivers/pci/setup-res.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/pci/setup-r
l.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 copy
PCI: Set
ags a breakage during the
> > driver's automated testing which parses dmesg and picks up the error.
> >
> > Reported-by: Daniel Vetter <daniel.vet...@intel.com>
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92992
> > CC: Bjorn Helgaas <bhelg...@go
stead 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 Vetter <daniel.vet...@intel.com>
>
rs. Since quirks.c
> needs just 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 <bhelg...@google.com>
> Cc:
[+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: [??? 0x
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
[+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 different PCI
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 interrupt problems again
[+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_T_64BIT /boot/config-3.14.0-0
[+cc Rafael]
On Mon, Mar 10, 2014 at 5:45 PM, Paul Bolle pebo...@tiscali.nl 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_resource()
From: Bjorn
On Mon, Mar 10, 2014 at 6:15 PM, Paul Bolle pebo...@tiscali.nl wrote:
On Mon, 2014-03-10 at 18:07 -0600, Bjorn Helgaas wrote:
On Mon, Mar 10, 2014 at 5:45 PM, Paul Bolle pebo...@tiscali.nl wrote:
A bit of doubt is caused by two new boot time messages:
pnp 00:00: unknown resource type 10
On Fri, Mar 7, 2014 at 1:40 PM, Bjorn Helgaas bhelg...@google.com 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:48 AM, Paul Bolle pebo...@tiscali.nl 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
like a good place to start, so you
On Thu, Mar 6, 2014 at 1:25 PM, Paul Bolle pebo...@tiscali.nl 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-related messages
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 pebo...@tiscali.nl wrote:
This might end up not being relevant. And this is surely documented
somewhere, but anyhow:
- what
On Fri, Mar 7, 2014 at 2:03 PM, Paul Bolle pebo...@tiscali.nl 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, here's a debug patch
On Thu, Mar 6, 2014 at 1:25 PM, Paul Bolle pebo...@tiscali.nl 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-related messages
On Sun, Feb 9, 2014 at 6:25 AM, Paul Bolle pebo...@tiscali.nl 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
Nikula jani.nik...@intel.com
Acked-by: Bjorn Helgaas bhelg...@google.com
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
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
|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 bhelg...@google.com
+ status = acpi_evaluate_object(handle, _DSM
On Fri, Jan 24, 2014 at 8:36 AM, Rafael J. Wysocki r...@rjwysocki.net 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 r...@rjwysocki.net
wrote:
On Thursday, January 23, 2014 11:21:01 AM Bjorn Helgaas wrote:
On Wed, Jan
On Thu, Jan 23, 2014 at 5:33 PM, Rafael J. Wysocki r...@rjwysocki.net wrote:
On Thursday, January 23, 2014 11:21:01 AM Bjorn Helgaas wrote:
On Wed, Jan 22, 2014 at 8:42 PM, Yijing Wang wangyij...@huawei.com wrote:
Since acpi_evaluate_object() returns acpi_status and not plain int
86 matches
Mail list logo
