On Sunday 15 April 2007 14:59, Luca Tettamanti wrote:
On 4/15/07, Bjorn Helgaas [EMAIL PROTECTED] wrote:
But I missed the details, such as the specific devices in question,
which ports they use, how they are described in ACPI, which AML
methods use those ports, and which non-ACPI drivers
On Monday 16 April 2007 15:14, Luca Tettamanti wrote:
It seems that Asus exposes monitorining data using ATK0110 (enumerated
in DSDT); I see it both on my P5B-E motherboard and on my notebook (L3D)
(they have different methods though). Another motherboard with the same
device may actually call
FYI, I'm seeing the following oops with 2.6.21-rc3-mm1 (and -mm2)
on the HP rx2600 and an Intel Tiger (both ia64 boxes).
I haven't investigated this other than to determine that it
does not occur with 2.6.21-rc3 or 2.6.20-rc3-mm1, and the
instruction at move_freepages+0x10 is a load of the value
On Wednesday 14 March 2007 03:44, Mel Gorman wrote:
Please try the following patch from Yasunori Goto.
...
--- current_test.orig/mm/page_alloc.c 2007-03-08 15:44:10.0 +0900
+++ current_test/mm/page_alloc.c 2007-03-08 16:17:29.0 +0900
@@ -707,7 +707,7 @@ int
On Wednesday 14 March 2007 10:13, Mel Gorman wrote:
Ok. This looks like another case of HOLES_IN_ZONE hilarity with page_zone().
As I take a new look at the BUG_ON check in move_freepages(), it isn't even
necessary as move_freepages_block() already checks the zone boundaries. At a
later date
On Wednesday 14 March 2007 11:21, Mel Gorman wrote:
Can you tell me if the faulting line was at the check for PageBuddy?
I don't know, sorry.
Can you
also apply the following patch and boot with loglevel=8 please? The
patch moves the check for pfn_valid() before PageBuddy() is called.
On Wednesday 14 March 2007 12:59, Mel Gorman wrote:
SNIP
Virtual mem_map starts at 0xa0007fffc720
Zone PFN ranges:
Total aside, a message should have been printed out here with
sizeof(struct page) = ?? when loglevel was set to 8. I wanted it so I
could work out PFNs from the
On Thursday 28 September 2006 10:36, Jesse Barnes wrote:
On Wednesday, September 27, 2006 9:55 pm, [EMAIL PROTECTED]
wrote:
pci_fixup_video turns into generic code because there are many platforms
need this fixup for embedded VGA as well as x86. The Video BIOS
integrates into System BIOS
.
+ * Data taken from include/asm-i386/serial.h.
+ *
+ * (c) Copyright 2006 Hewlett-Packard Development Company, L.P.
+ * Bjorn Helgaas [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2
On Wednesday 21 March 2007 10:37, Russell King wrote:
On Wed, Mar 21, 2007 at 10:35:38AM -0600, Bjorn Helgaas wrote:
On Tuesday 20 March 2007 08:32, Bjorn Helgaas wrote:
On Tuesday 20 March 2007 00:46, Keith Owens wrote:
Booting with 'console=tty console=ttyS0,9600'. The serial console
On Tuesday 20 March 2007 08:32, Bjorn Helgaas wrote:
On Tuesday 20 March 2007 00:46, Keith Owens wrote:
Booting with 'console=tty console=ttyS0,9600'. The serial console on
ttyS0 (0x3f8, irq 4) is probed twice, once from serial8250_init() and
again from serial_pnp_probe().
I played
On Wednesday 21 March 2007 22:23, Keith Owens wrote:
The aim of the patch looks sensible, but it will not compile for
2.6.21-rc4. 8250_x86.c tests pnp_platform_devices, which does not
exist. Also the combination of CONFIG_SERIAL_8250_X86=y and
CONFIG_SERIAL_8250_PNP=m would result in
On Wednesday 04 April 2007 17:16, Randy Dunlap wrote:
On Wed, 04 Apr 2007 16:45:40 -0600 Bjorn Helgaas wrote:
+static int smsc_nopnp;
+module_param_named(nopnp, smsc_nopnp, bool, 0);
+MODULE_PARM_DESC(nopnp, Do not use PNP to detect controller settings);
Document this parameter (like you
On Wednesday 21 March 2007 22:23, Keith Owens wrote:
The aim of the patch looks sensible, but it will not compile for
2.6.21-rc4. 8250_x86.c tests pnp_platform_devices, which does not
exist. Also the combination of CONFIG_SERIAL_8250_X86=y and
CONFIG_SERIAL_8250_PNP=m would result in
/0x70
[c020a815] __generic_unplug_device+0x25/0x30
[c020a835] generic_unplug_device+0x15/0x30
...
Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]
Index: cciss/drivers/block/cciss.c
===
--- cciss.orig/drivers/block/cciss.c
We used to warn unless the EFI system table major revision was exactly 1.
But EFI 2.00 firmware is starting to appear, and the 2.00 changes don't
affect anything in Linux.
Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]
Index: w/include/linux/efi.h
On Friday 02 March 2007 07:03, Jean Delvare wrote:
... The primary issue is the concurrent access
to resources, which cause lots of trouble which are hard to investigate.
If ACPI reserves the ports, then the SMBus or hardware monitoring
drivers (or any other conflicting driver) will cleanly
On Friday 13 April 2007 14:07, Pavel Machek wrote:
... The primary issue is the concurrent access
to resources, which cause lots of trouble which are hard to investigate.
If ACPI reserves the ports, then the SMBus or hardware monitoring
drivers (or any other conflicting driver) will
On Sunday 15 April 2007 03:41, Jean Delvare wrote:
On Fri, 13 Apr 2007 14:59:45 -0600, Bjorn Helgaas wrote:
Of course, there are always BIOS defects. But if we could make a
case that a BIOS that doesn't declare the resources used by the AML
is defective, we could add quirks to reserve
On Saturday 31 March 2007 03:12, Petr Vandrovec wrote:
Hello,
today I noticed that kernel with 64bit I/O resources reports
incorrect /proc/iomem due to resource_size_t = int = resource_size_t
conversion in drivers/pnp/system.c, turning addresses 2-4GB into
very huge addresses at the top of
On Monday 26 March 2007 21:29, Eric W. Biederman wrote:
Luck, Tony [EMAIL PROTECTED] writes:
What I'm proposing we do is move the irq allocation code out of
pci_enable_device and the irq freeing code out of pci_disable_device
in the future.
Sounds rational ... in a world that wasn't
On Monday 02 April 2007 09:38, Bjorn Helgaas wrote:
The main reason we wait until pci_enable_device() to allocate an
IRQ number is that ia64 currently only has about 180 device vectors,
and there are machines with more PCI slots than that.
Sigh, that didn't make much sense, did
On Monday 02 April 2007 09:37, Christoph Lameter wrote:
On Sun, 1 Apr 2007, Andi Kleen wrote:
Hmm, this means there is at least 2MB worth of struct page on every node?
Or do you have overlaps with other memory (I think you have)
In that case you have to handle the overlap in
This series converts i386 and x86_64 legacy serial ports to be platform
devices and prevents probing for them if we have PNP.
This prevents double discovery, where a device was found both by the
legacy probe and by 8250_pnp.
This also prevents the serial driver from claiming IRDA devices (unless
Some HP/Compaq firmware reports via ACPI that the SMCF010 IR device is
enabled, but in fact, it leaves the device partly disabled.
HP nw8240 BIOS 68DTV Ver. F.0F, released 9/15/2005 is one BIOS that has
this problem.
Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]
Index: w/drivers/pnp/quirks.c
If we can discover devices using PNP, we can skip some legacy probes.
This flag (pnp_platform_devices) indicates that PNPBIOS or PNPACPI
is enabled and should tell us about builtin devices.
Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]
Index: work/drivers/pnp/core.c
/ir260_smsc_pnp.diff
Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]
Index: w/drivers/net/irda/smsc-ircc2.c
===
--- w.orig/drivers/net/irda/smsc-ircc2.c2007-04-04 13:45:18.0
-0600
+++ w/drivers/net/irda/smsc-ircc2.c 2007-04-04 13:47
To determine whether the user specified a module parameter, use some #defines
instead of checking for bare magic numbers.
Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]
Index: w/drivers/net/irda/smsc-ircc2.c
===
--- w.orig/drivers
UART
stuff back in. On Debian, dpkg-reconfigure setserial with the kernel
option does this.
To force the old legacy probe behavior even when we have PNPBIOS or
ACPI, load the new legacy_serial module (or build 8250 static) with
the legacy_serial.force option.
Signed-off-by: Bjorn Helgaas [EMAIL
On Wednesday 09 January 2008 08:49:52 pm Greg KH wrote:
On Wed, Jan 02, 2008 at 01:42:23PM -0700, Bjorn Helgaas wrote:
The patch below was put in 2.6.23.12 as a fix for
http://bugzilla.kernel.org/show_bug.cgi?id=9514. It apparently
does make 9514 go away, but only by coincidence
() which the above mentioned patch
also removes but with the pnp_start_dev() restored it seems pnp_stop_dev()
should also stay. Bjorn Helgaas should decide -- currently the patch as
you have it breaks drivers though. Could you drop it?
Yes, please drop pnp-do-not-stop-start-devices-in-suspend
On Saturday 12 January 2008 11:13:35 pm Rene Herman wrote:
... And, now that I have your attention, while it's
not important to the issue anymore with the tests removed as the submitted
patch did, do you have an opinion on (include/linux/pnp.h):
/* pnp driver flags */
#define
On Tuesday 13 November 2007 02:30:49 pm Greg KH wrote:
On Tue, Nov 13, 2007 at 01:36:45PM -0700, Alex Chiang wrote:
* Greg KH [EMAIL PROTECTED]:
IBM sells a program that does this for server rooms. It's
probably part of some Tivoli package somewhere, sorry I don't
remember the name.
On Tuesday 13 November 2007 03:59:36 pm Kristen Carlson Accardi wrote:
On Tue, 13 Nov 2007 12:26:32 -0800 Greg KH [EMAIL PROTECTED] wrote:
And isn't there some other tool that dumps the raw ACPI tables? I
thought the acpi developers used it all the time when debugging things
with users.
of 26 resources
per device). Shaohua's patch adds 16 port and 8 mem resources for
an increase of 24, so will use slightly less space.
Acked-by: Bjorn Helgaas [EMAIL PROTECTED]
Signed-off-by: Li Shaohua [EMAIL PROTECTED]
Signed-off-by: Zhao Yakui [EMAIL PROTECTED]
---
drivers/pnp
On Sunday 16 December 2007 06:59:39 pm Shaohua Li wrote:
On Sun, 2007-12-09 at 23:02 -0500, Mike Houston wrote:
On Mon, 10 Dec 2007 10:31:27 +0800
Shaohua Li [EMAIL PROTECTED] wrote:
This should exist in previous kernel (before we remove acpi
motherboard driver) too. Basically it's a
Convert quirk printks to dev_printk().
I made the MSI disable messages a little more consistent:
- always use disabled, not deactivated
- specify device MSI disabled or subordinate MSI disabled when
disabling MSI for only a specific device or subordinate bus
Signed-off-by: Bjorn
style used
in do_initcalls() and pnp_fixup_device().
Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]
Index: w/drivers/pci/quirks.c
===
--- w.orig/drivers/pci/quirks.c 2007-12-17 14:09:01.0 -0700
+++ w/drivers/pci/quirks.c
Convert quirk printks to dev_printk().
Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]
---
arch/x86/kernel/quirks.c | 42 ++
arch/x86/pci/fixup.c | 22 +++---
2 files changed, 33 insertions(+), 31 deletions(-)
Index: w/arch/x86
No functional changes here; these only use dev_printk when possible.
In a few cases, I tweaked message wordings to make them more consistent.
--
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Tuesday 18 December 2007 02:09:15 pm Linus Torvalds wrote:
On Tue, 18 Dec 2007, Richard Henderson wrote:
I've added dmesg, /proc/iomem, and lspci -v output to that bug.
Basically, we have
c000-cfff : free
ddf0-dfef : PCI Bus #04
On Sunday 09 December 2007 09:02:11 pm Mike Houston wrote:
On Mon, 10 Dec 2007 10:31:27 +0800
Shaohua Li [EMAIL PROTECTED] wrote:
This should exist in previous kernel (before we remove acpi
motherboard driver) too. Basically it's a broken BIOS. Could below
patch work around it?
On Tuesday 18 December 2007 10:59:18 am Jean Delvare wrote:
The real cause is pretty clear here: broken BIOS. In an ideal world we
would ask the manufacturer for a fixed BIOS and they would give that to
us, unfortunately my experience is that it won't happen. So, unless we
accept that idea
/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=a7839e960675b549f06209d18283d5cee2ce9261
The patch above increases the number of PNP port resources we support.
Prior to this patch, we ignored some port resources, which masked the
it87 problem.
Signed-off-by: Bjorn Helgaas [EMAIL
On Saturday 22 December 2007 4:21:41 am Jean Delvare wrote:
This patch makes the it87 driver request only the two ports used for the
Environment Controller device.
The problem is that the IT87xxF chips do decode 4 ports (recent chips,
0x294-0x297) or 8 ports (older chips, 0x290-0x297), not 2
On Sunday 23 December 2007 2:28:05 am Jean Delvare wrote:
Le 23/12/2007, Bjorn Helgaas a écrit:
On Saturday 22 December 2007 4:21:41 am Jean Delvare wrote:
This patch makes the it87 driver request only the two ports used for
the Environment Controller device.
The problem
On Sunday 23 December 2007 6:43:49 pm Stephane Ascoet wrote:
Bjorn Helgaas a écrit :
Good. It's not clear to me whether it is safe to leave devices
enabled while we sleep. I don't see an actual problem, but there
might be something related to hotplug while we're asleep or something.
So
On Monday 26 November 2007 11:05:38 pm Andrew Morton wrote:
On Thu, 22 Nov 2007 22:41:16 +0100 Jiri Slaby [EMAIL PROTECTED] wrote:
Ok, I hit the bug, suspend of 00:06 device complains about it:
WARNING: at .../kernel/resource.c:185 __release_resource()
Call Trace:
[8023f7b5]
On Thursday 29 November 2007 05:42:07 pm Andrew Morton wrote:
On Thu, 29 Nov 2007 16:40:37 -0700
Bjorn Helgaas [EMAIL PROTECTED] wrote:
On Monday 26 November 2007 11:05:38 pm Andrew Morton wrote:
On Thu, 22 Nov 2007 22:41:16 +0100 Jiri Slaby [EMAIL PROTECTED] wrote:
Ok, I hit the bug
On Friday 30 November 2007 03:49:55 pm Jiri Slaby wrote:
On 11/30/2007 10:08 PM, Bjorn Helgaas wrote:
On Thursday 29 November 2007 05:42:07 pm Andrew Morton wrote:
On Thu, 29 Nov 2007 16:40:37 -0700
Maybe we could either remove the pnp_{stop,start}_dev() calls
from the suspend/resume path
On Friday 30 November 2007 04:37:26 pm Rene Herman wrote:
On 30-11-07 18:04, Thomas Renninger wrote:
If I have not overseen something, it should be rather obvious that those
can all be declared __init...
---
Declare PNP option parsing functions as __init
There are
On Monday 03 December 2007 04:53:01 am Thomas Renninger wrote:
On Fri, 2007-11-30 at 16:52 -0700, Bjorn Helgaas wrote:
On Friday 30 November 2007 04:37:26 pm Rene Herman wrote:
On 30-11-07 18:04, Thomas Renninger wrote:
If I have not overseen something, it should be rather obvious
hardware
resources.
[This should go before
pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch
for best bisect-ability.]
Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]
Index: linux-mm/drivers/pnp/driver.c
===
--- linux
On Monday 03 December 2007 06:15:40 pm Dave Young wrote:
On Tue, Dec 04, 2007 at 08:55:13AM +0800, Shaohua Li wrote:
On Mon, 2007-12-03 at 18:02 +0100, Rene Herman wrote:
On 30-11-07 23:22, Rene Herman wrote:
On 30-11-07 14:14, Chris Holvenstot wrote:
For what it is worth
On Wednesday 05 December 2007 11:24:18 am Bjorn Helgaas wrote:
Re: warning on suspend-to-RAM caused by
pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch,
thread here: http://lkml.org/lkml/2007/11/22/110
On Saturday 01 December 2007 05:00:34 am Jiri Slaby wrote:
I didn't
On Friday 07 December 2007 12:13:35 am Shaohua Li wrote:
On Thu, 2007-12-06 at 02:24 +0800, Bjorn Helgaas wrote:
Index: linux-mm/drivers/pnp/driver.c
===
--- linux-mm.orig/drivers/pnp/driver.c 2007-11-30 13:58:25.0
On Tuesday 11 December 2007 10:44:43 am Borislav Petkov wrote:
On Sun, Dec 09, 2007 at 10:19:47AM +0100, Borislav Petkov wrote:
On Sun, Dec 09, 2007 at 08:50:02AM +0100, Borislav Petkov wrote:
Hi Andrew,
Hi Len,
after booting 2.6.24-rc4-mm1 (2.6.24-rc4-190-g94545ba, otoh, boots
On Tuesday 11 December 2007 01:52:55 pm Borislav Petkov wrote:
From what i can roughly tell so far it seems like an resource conflict
between acpi and
the pnp requested regions in your patch which result in the acpi_thermal code
to read the wrong (0xff) temperature value and halt the machine,
On Wednesday 12 December 2007 03:11:23 am Borislav Petkov wrote:
On Tue, Dec 11, 2007 at 05:08:59PM -0700, Bjorn Helgaas wrote:
On Tuesday 11 December 2007 01:52:55 pm Borislav Petkov wrote:
From what i can roughly tell so far it seems like an resource conflict
between acpi
On Wednesday 12 December 2007 01:16:10 am Andrew Morton wrote:
On Thu, 6 Dec 2007 16:25:57 -0700 Bjorn Helgaas [EMAIL PROTECTED] wrote:
Andrew, can you add this before
pnp-request-ioport-and-iomem-resources-used-by-active-devices.patch?
...
PNP: do not stop/start devices in suspend
On Thursday 13 December 2007 12:09:23 am Borislav Petkov wrote:
On Wed, Dec 12, 2007 at 09:21:41AM -0700, Bjorn Helgaas wrote:
On Wednesday 12 December 2007 03:11:23 am Borislav Petkov wrote:
On Tue, Dec 11, 2007 at 05:08:59PM -0700, Bjorn Helgaas wrote:
On Tuesday 11 December 2007 01:52
On Tuesday 25 December 2007 02:31:26 pm Jean Delvare wrote:
Le 23/12/2007, Bjorn Helgaas [EMAIL PROTECTED] a écrit:
On Sunday 23 December 2007 2:28:05 am Jean Delvare wrote:
The problem is that the it87 driver is used on a variety of motherboards,
some where the hardware monitoring device I
The patch below was put in 2.6.23.12 as a fix for
http://bugzilla.kernel.org/show_bug.cgi?id=9514. It apparently
does make 9514 go away, but only by coincidence. There are a
couple other ideas about fixing 9514. My proposed patch is
attached in the bugzilla.
The .12 patch reduces the number of
On Wednesday 24 October 2007 08:31:59 am Thomas Renninger wrote:
In ACPI, AML can define accesses to IO ports and System Memory by
Operation Regions. Those are not registered as done by PNPACPI using
resource templates (and _CRS/_SRS methods).
The IO ports and System Memory regions may get
On Thursday 25 October 2007 4:55:07 pm Thomas Renninger wrote:
On Thu, 2007-10-25 at 09:06 -0600, Bjorn Helgaas wrote:
Isn't the real problem that we have a bunch of drivers that use some of
the same resources, and if ACPI reserved all the right resources, all
those drivers would break
On Friday 26 October 2007 4:45:20 am Thomas Renninger wrote:
On Thu, 2007-10-25 at 21:59 -0600, Bjorn Helgaas wrote:
On Thursday 25 October 2007 4:55:07 pm Thomas Renninger wrote:
Also the BIOS developers seem to choose the regions in a very dump way
sometimes.
Just some imaginary
On Saturday 27 October 2007 9:09:47 am Matthew Garrett wrote:
On Thu, Oct 25, 2007 at 09:06:22AM -0600, Bjorn Helgaas wrote:
But we really *should* reserve things used by opregions, shouldn't
we? After all, the whole point of resource reservation is to prevent
conflicts.
Only if you're
: 00:03 -- PNP reports AT-style speaker
0064-0064 : 00:04 -- PNP reports 8042 controller status register
0070-0073 : 00:06
0070-0071 : rtc
Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]
Index: w/Documentation/kernel-parameters.txt
Question 1: Does the linux-pcmcia list still exist? It's in MAINTAINERS:
PCMCIA SUBSYSTEM
P: Linux PCMCIA Team
L: [EMAIL PROTECTED]
L: http://lists.infradead.org/mailman/listinfo/linux-pcmcia
T: git kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
S:
On Friday 19 October 2007 04:40:22 pm Russell King wrote:
On Fri, Oct 19, 2007 at 10:51:51AM -0600, Bjorn Helgaas wrote:
+ priv-io_resource = request_region(link-io.BasePort1,
+ link-io.NumPorts1, DRIVER_NAME);
+ if (!priv-io_resource
On Monday 22 October 2007 05:09:51 pm [EMAIL PROTECTED] wrote:
+config HP_WATCHDOG
+tristate Hewlett-Packard watchdog
+depends on WATCHDOG X86
I wouldn't be surprised if this device someday turned up on non-x86
systems. I know there's some x86 firmware stuff in there that
Here are two fixes:
- Minor bugfix on error path for mips.
- If resource request fails, fall back to requesting only the
ioports we actually use. This is not a problem yet, but it
will be if the PNP core claims resources before drivers attach.
--
-
To unsubscribe from this list:
: 00:06 -- PNP device 00:06 responds to 70-73
0070-0071 : rtc -- RTC driver uses only 70-71
instead of the current:
0070-0077 : rtc -- RTC_IO_EXTENT == 8
Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]
Index: w/drivers/char/rtc.c
The misc_register() error path always released an I/O port region,
even if the region was memory-mapped (only mips uses memory-mapped RTC,
as far as I can see).
Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]
Index: w/drivers/char/rtc.c
On Friday 01 February 2008 11:08:23 am Siddha, Suresh B wrote:
On Fri, Feb 01, 2008 at 01:17:14PM +0100, Andi Kleen wrote:
Jike Song [EMAIL PROTECTED] writes:
On 2/1/08, Rijndael Cosque [EMAIL PROTECTED] wrote:
Hi all,
I found the x2APIC spec via
On Tuesday 05 February 2008 01:12:46 pm Bjorn Helgaas wrote:
On Tuesday 05 February 2008 11:15:12 am Linus Torvalds wrote:
No, you don't need any quirks: you just do an insert_resource() and
ignore the error return. If the (bogus) PnP resource clashes with the
(correct) hardware PCI
On Thursday 14 February 2008 12:42:52 pm Linus Torvalds wrote:
On Thu, 14 Feb 2008, Bjorn Helgaas wrote:
Sorry for the delay. I did work on this, but I don't see how this
can work. pcibios_init() marks its reservations as not busy, so the
subsequent PNP request doesn't fail, even
On Thursday 14 February 2008 01:26:59 pm Linus Torvalds wrote:
On Thu, 14 Feb 2008, Bjorn Helgaas wrote:
On Thursday 14 February 2008 12:42:52 pm Linus Torvalds wrote:
It *shouldn't* fail.
Things should fail only when two different drivers have requested the
same
On Thursday 14 February 2008 02:37:15 pm Linus Torvalds wrote:
On Thu, 14 Feb 2008, Bjorn Helgaas wrote:
That means the PNP system driver has to be registered after the PCI
driver.
After the PCI *subsystem*
Here's the actual problem:
[ 31.133141] PCI: Unable to reserve mem
On Thursday 14 February 2008 04:14:45 pm Linus Torvalds wrote:
On Thu, 14 Feb 2008, Linus Torvalds wrote:
It should insert the resource to the root resource (or a bridge resource),
or not at all. If somebody else has already inserted a real device
resource, we already know about it,
On Wed, Oct 24, 2012 at 7:36 PM, Huang Ying ying.hu...@intel.com wrote:
In
https://bugzilla.kernel.org/show_bug.cgi?id=48981
Peter reported that /proc/bus/pci/??/??.? does not works for 3.6.
This is This is because the device configuration space registers will
be not accessible if the
On Wed, Oct 24, 2012 at 12:54 AM, Huang Ying ying.hu...@intel.com wrote:
If a PCI device and its parents are put into D3cold, unbinding the
device will trigger deadlock as follow:
- driver_unbind
- device_release_driver
- device_lock(dev) --- previous lock here
On Wed, Oct 24, 2012 at 12:54 AM, Huang Ying ying.hu...@intel.com wrote:
Some actions during shutdown need device to be in D0 state, such as
MSI shutdown etc, so resume device before shutdown.
Is there a problem report or bugzilla for this issue? What are the
symptoms by which a user could
On Wed, Aug 22, 2012 at 9:16 AM, Jiang Liu liu...@gmail.com wrote:
From: Jiang Liu jiang@huawei.com
Commit 0d52f54e2ef64c189dedc332e680b2eb4a34590a (PCI / ACPI: Make acpiphp
ignore root bridges using PCIe native hotplug) added code that made the
acpiphp driver completely ignore PCIe root
On Sat, Sep 22, 2012 at 8:11 AM, Yinghai Lu ying...@kernel.org wrote:
On Sat, Sep 22, 2012 at 1:10 AM, Fengguang Wu fengguang...@intel.com wrote:
Please check attached patch that should fix the problem.
updated more aggressive version. two patches.
Yes they work nicely. Thank you very
9038dd3b3c4c9e4c7ca0118c8df398c4c646ab58
Author: Bjorn Helgaas bhelg...@google.com
Date: Mon Sep 24 17:16:28 2012 -0600
vsprintf: Add support for IORESOURCE_UNSET in %pR
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 0e33754..b6c 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
Garrett m...@redhat.com
Acked-by: Bjorn Helgaas bhelg...@google.com
I've never directly applied PNP patches; I've always sent them through
Len's ACPI tree (cc'd), so let me know if you want me to do more than
ack this.
---
drivers/pnp/system.c | 30 ++
1 file changed
On Tue, Sep 25, 2012 at 7:25 AM, Matthew Garrett m...@redhat.com wrote:
ACPIPNP devices may have two levels of ID - the HID (a single string
defining the hardware) and the CIDs (zero or more strings defining
interfaces compatible with the hardware). If a driver matching a CID is
bound first,
On Fri, Sep 21, 2012 at 10:07 AM, Jiang Liu liu...@gmail.com wrote:
The pci_find_next_bus() is not hotplug safe, so introduce PCI hotplug
safe interfaces to walk PCI buses. To avoid some deadlock scenarios,
two interfaces are introduced.
The first one is pci_for_each_bus(), which walks all
controller/etc stuff where this is a problem. Those
devices don't have BARs, so
this line is probably the only information about them in dmesg.
Cc: Bjorn Helgaas bhelg...@google.com
Cc: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: Nathan Zimmer nzim...@sgi.com
---
drivers/pci/probe.c
*before* enumerating ACPI devices.
I realize that this will require changes in the way we bind PCI and ACPI
devices. I pointed that out in a previous response, appended below for
convenience:
On Tue, Oct 2, 2012 at 4:38 PM, Bjorn Helgaas bhelg...@google.com wrote:
We enumerate ACPI devices
On Thu, Oct 4, 2012 at 12:36 PM, Yinghai Lu ying...@kernel.org wrote:
On Thu, Oct 4, 2012 at 10:47 AM, Bjorn Helgaas bhelg...@google.com wrote:
On Wed, Oct 03, 2012 at 04:00:10PM -0700, Yinghai Lu wrote:
This is a fundamental difference: at boot-time, all the ACPI devices below
the
host
On Thu, Oct 4, 2012 at 2:14 PM, Yinghai Lu ying...@kernel.org wrote:
On Thu, Oct 4, 2012 at 12:44 PM, Bjorn Helgaas bhelg...@google.com wrote:
To answer your specific question, yes, I do think drivers that are
statically built in probably should be registered before devices are
enumerated
On Fri, Oct 5, 2012 at 8:54 AM, Nathan Zimmer nzim...@sgi.com wrote:
On 10/05/2012 09:14 AM, Joe Perches wrote:
On Fri, 2012-10-05 at 08:55 -0500, Nathan Zimmer wrote:
On 10/04/2012 11:37 AM, Joe Perches wrote:
On Thu, 2012-10-04 at 11:02 -0500, Nathan Zimmer wrote:
At many of our
On Fri, Sep 28, 2012 at 1:40 AM, Zhang Rui rui.zh...@intel.com wrote:
From 9a851d177794129a89f720c7122cb39fd163126b Mon Sep 17 00:00:00 2001
From: Zhang Rui rui.zh...@intel.com
Date: Fri, 28 Sep 2012 08:34:05 +0800
Subject: [RFC PATCH 3/6] ACPI: introduce acpi_get_generic_resources
Introduce
On Fri, Nov 2, 2012 at 11:05 PM, Huang Ying ying.hu...@intel.com wrote:
On Fri, 2012-11-02 at 10:52 -0600, Bjorn Helgaas wrote:
On Wed, Oct 24, 2012 at 12:54 AM, Huang Ying ying.hu...@intel.com wrote:
Some actions during shutdown need device to be in D0 state, such as
MSI shutdown etc, so
On Fri, Nov 2, 2012 at 11:06 PM, Huang Ying ying.hu...@intel.com wrote:
On Fri, 2012-11-02 at 10:50 -0600, Bjorn Helgaas wrote:
On Wed, Oct 24, 2012 at 12:54 AM, Huang Ying ying.hu...@intel.com wrote:
If a PCI device and its parents are put into D3cold, unbinding the
device will trigger
On Sat, Nov 3, 2012 at 1:46 AM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
ACPI 5 introduced SPISerialBus resource that allows us to enumerate and
configure the SPI slave devices behind the SPI controller. This patch adds
support for this to the SPI core.
In addition we bind ACPI
On Mon, Nov 5, 2012 at 3:31 AM, Rafael J. Wysocki r...@sisk.pl wrote:
On Saturday, November 03, 2012 09:59:28 PM Rafael J. Wysocki wrote:
On Saturday, November 03, 2012 10:13:10 PM Mika Westerberg wrote:
On Sat, Nov 03, 2012 at 01:42:02PM -0600, Bjorn Helgaas wrote:
On Sat, Nov 3, 2012 at 1
On Sat, Nov 3, 2012 at 2:39 PM, Rafael J. Wysocki r...@sisk.pl wrote:
On Saturday, November 03, 2012 01:42:02 PM Bjorn Helgaas wrote:
On Sat, Nov 3, 2012 at 1:46 AM, Mika Westerberg
mika.westerb...@linux.intel.com wrote:
ACPI 5 introduced SPISerialBus resource that allows us to enumerate
1 - 100 of 12007 matches
Mail list logo
