[-cc j...@sgi.com (stale)]
On Mon, Jan 14, 2013 at 11:47 AM, Cong Ding wrote:
> On Mon, Jan 14, 2013 at 11:19:15AM -0700, Bjorn Helgaas wrote:
>> On Mon, Jan 14, 2013 at 10:53 AM, Cong Ding wrote:
>> > we should ensure the pointer is not null before the first use, rather
On Tue, Nov 27, 2012 at 7:09 AM, Colin King wrote:
> From: Colin Ian King
>
> BugLink: http://bugs.launchpad.net/bugs/962038
>
> Right now using pcie_aspm=force will not enable ASPM if the FADT indicates
> ASPM is unsupported. However, the semantics of force should probably allow
> for this, esp
- Untangle _PRT from struct pci_bus (Bjorn Helgaas)
- Request _OSC control before scanning root bus (Taku Izumi)
- Assign resources when adding host bridge (Yinghai Lu)
- Remove root bus when removing host bridge (Yinghai Lu)
- Remove _PRT during hot remove (Yinghai Lu)
SRIOV
On Sun, Dec 9, 2012 at 4:00 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Currently, as soon as an ACPI device node object (struct acpi_device)
> is created, the driver core attempts to probe ACPI drivers against
> it. That leads to some unpleasant side effects, like the fact that
>
On Sun, Dec 9, 2012 at 4:00 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Devices created by acpi_create_platform_device() sometimes may need
> to be added to the device hierarchy as children of PCI bridges.
An example of this hierarchy would help to understand it.
> For
> this pur
On Sun, Dec 9, 2012 at 4:04 PM, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> If acpi_bus_check_add() is called for a handle already having an
> existing struct acpi_device object attached, it is not necessary to
> check the type and status of the device correspondig to it, so
> change t
On Thu, Dec 13, 2012 at 4:51 AM, Jan Glauber wrote:
> On Mon, 2012-12-10 at 14:14 -0700, Bjorn Helgaas wrote:
>> On Wed, Nov 14, 2012 at 2:41 AM, Jan Glauber wrote:
>> > Add PCI support for s390, (only 64 bit mode is supported by hardware):
>> > - PCI facility te
[+cc Betty]
On Thu, Dec 13, 2012 at 4:04 PM, Lucas Kannebley Tavares
wrote:
> On architectures such as ppc64, there is no root bus device (it belongs
> to the hypervisor). DRM attempted to get one, causing a null-pointer
> dereference.
In addition to ppc64, at least ia64 and parisc have the same
[+cc Rafael]
On Thu, Dec 13, 2012 at 8:31 AM, Kirill A. Shutemov
wrote:
> From: "Kirill A. Shutemov"
>
> Correct ACPI PCI hotplug imeplementation should have _RMV method in a
> PCI slot (device under pci bridge). In Acer Aspire S5 case we have it
> deeper in hierarchy:
>
> Device (RP05)
> {
>
On Fri, Sep 21, 2012 at 10:07 AM, Jiang Liu 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 PCI buses hold
On Sat, Sep 29, 2012 at 4:09 PM, Stephan Schreiber wrote:
> Hello Bjorn,
> thank you very much for the patch.
> I tested it; it works.
>
> (typing mistake: it must read PCI_COMMAND_MEMORY instead of PCI_COMMAND_MEM
> at one location;
> some hunks of the patch couldn't be applied automatically on K
(Jiang Liu)
- Remove fakephp driver (Bjorn Helgaas)
- Fix VGA ref count in hotplug remove path (Yinghai Lu)
- Allow acpiphp to handle PCIe ports without native hotplug (Jiang Liu)
- Implement resume regardless of pciehp_force param (Oliver Neukum)
- Make pci_fixup_irqs() work after init (Thie
This is an old bug report I'd like to close out. Do you guys know
anything about it? I couldn't even find the
"microamps_requested_vmmc" string in the v3.6 kernel, so I suspect
it's obsolete.
https://bugzilla.kernel.org/show_bug.cgi?id=35142
Hardware name: Qosmio E10
sysfs: cannot create duplic
bove...
>>>
>>> This was 3.8.0-rc3-next-20130114.
>>
>> There are two things you can try. First, revert all of the ACPICA patches
>> and see if that helps. Second, if that doesn't help, try to revert things in
>> the PCI tree (alternatively, you can try
in Kconfigs.
>
> CC: Bjorn Helgaas
> CC: Jesse Barnes
> CC: Matthew Garrett
> Cc: Greg Kroah-Hartman
> Signed-off-by: Kees Cook
I missed this the first time you posted it, so thanks for resending
it. I applied it to my for-linus branch, headed for v3.8.
> ---
> d
> CC: Adam Belay
> CC: Bjorn Helgaas
> Cc: Greg Kroah-Hartman
> Signed-off-by: Kees Cook
Acked-by: Bjorn Helgaas
Rafael, do you want to apply this?
> ---
> drivers/pnp/pnpbios/Kconfig |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/
On Fri, Jan 18, 2013 at 9:07 AM, Jiang Liu wrote:
> If user specifies "pci=nopciehp" on kernel boot command line, OSPM
> won't claim PCIe native hotplug service from firmware and no PCIe
> port devices will be created for PCIe native hotplug service.
Why do we need this option?
If I understand c
Thomas Lehmann <[EMAIL PROTECTED]> verified that this
entry works.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work6/drivers/serial/8250_pnp.c
===
--- work6.orig/drivers/serial/8250_pnp.c2008
On Sat, Jun 02, 2012 at 11:30:23AM +0800, Jiang Liu wrote:
> ... address range 0xfed98000-0xfed9 has been reserved by motherboard
> device(PNP0C02). I guess that BIOS has assigned address "0xfed98000" to
> :00:04.0 for thermal management functionality. The BAR0 of
> :00:04.0 may be loc
On Mon, Jul 2, 2012 at 2:49 PM, Kamil Grzebien wrote:
> On Mon, Jul 2, 2012 at 6:31 AM, Stanislaw Gruszka wrote:
>> On Sun, Jul 01, 2012 at 07:01:58PM +0100, Kamil Grzebien wrote:
>>> I haven't tried your patch yet, but wanted to share with one thing.
>>> Currently I use new kernel 3.4.3, where t
> because it is locked down by BIOS to chipset, readback should be 0xfed98004.
>
> and pci_size will return 32k for 0xfed98000.
A device with a read-only BAR doesn't conform to the PCI spec. We
can't determine how much space the device consumes.
It's just an accident that BIOS put it at an addres
On Mon, Dec 3, 2012 at 1:59 PM, Shuah Khan wrote:
> On Mon, Dec 3, 2012 at 1:00 PM, Alex Williamson
> wrote:
>> On Mon, 2012-12-03 at 12:48 -0700, Alex Williamson wrote:
>>> On Mon, 2012-12-03 at 10:40 -0700, Shuah Khan wrote:
>>> > On Mon, Dec 3, 2012 at 9:37 AM, Betty Dall wrote:
>>> > > The f
On Thu, Dec 20, 2012 at 12:11 PM, Sasha Levin wrote:
> Remove cases of redundant checks and remote unreachable paths.
>
> Signed-off-by: Sasha Levin
Thanks, Sasha. I applied this for v3.9.
> ---
> drivers/pci/hotplug/cpqphp_ctrl.c | 57
> ++-
> 1 file chan
[+cc David, Michal, Koichi, Ben, Paul]
On Fri, Dec 7, 2012 at 12:15 AM, Yinghai Lu wrote:
> On Sat, Nov 3, 2012 at 9:39 PM, Yinghai Lu wrote:
>> For root bus hot add, fw could assign some resource for the devices for
>> that root bus before notifying os via acpi, we should check and use those
>>
[+cc Rafael]
On Tue, Sep 25, 2012 at 8:29 AM, Jiang Liu wrote:
> From: Jiang Liu
>
> Currently pci_bind.c is used to maintain binding relationship between
> ACPI and PCI devices. But it's broken when handling PCI hotplug events.
>
> For the acpiphp driver, it's designed to update the binding re
On Mon, Jan 7, 2013 at 4:49 PM, Bjorn Helgaas wrote:
> [+cc David, Michal, Koichi, Ben, Paul]
>
> On Fri, Dec 7, 2012 at 12:15 AM, Yinghai Lu wrote:
>> On Sat, Nov 3, 2012 at 9:39 PM, Yinghai Lu wrote:
>>> For root bus hot add, fw could assign some resource for the devic
On Sun, Jan 6, 2013 at 5:13 AM, Yijing Wang wrote:
> On 2013/1/5 5:50, Bjorn Helgaas wrote:
>> [+to Yijing, +cc Kenji]
>>
>> On Fri, Jan 4, 2013 at 1:01 PM, Bjorn Helgaas wrote:
>>> On Thu, Jan 3, 2013 at 8:41 AM, Jiang Liu wrote:
>>>> Hi Daniel,
>
On Tue, Jan 8, 2013 at 11:27 AM, Yinghai Lu wrote:
> On Tue, Jan 8, 2013 at 9:57 AM, Bjorn Helgaas wrote:
>>> I'm really sorry that it's taken me so long to get to these.
>>>
>>> I applied these to my pci/yinghai-survey-resources branch. I
>>>
On Wed, Jan 9, 2013 at 10:53 AM, Yinghai Lu wrote:
> On Wed, Jan 9, 2013 at 9:35 AM, Bjorn Helgaas wrote:
>>> I don't know, that could be separated patcheset after we conclude
>>> pci root bus hotplug support.
>>
>> The main reason I review patches before
[+cc Myron]
On Wed, Jan 9, 2013 at 1:19 PM, Rafael J. Wysocki wrote:
> On Thursday, January 10, 2013 12:58:25 AM Jiang Liu wrote:
>> Hi Rafael,
>> Thanks for your great efforts to review the patch.
>>
>> On 01/09/2013 08:01 AM, Rafael J. Wysocki wrote:
>> > Hi,
>> >
>> > On Wednesday, Janua
erested architecutres (x86 and ia64 at the moment) with functions
> that will set the root bridge's ACPI handle before its dev member is
> passed to device_register(). Make both x86 and ia64 provide such
> implementations of pcibios_root_bridge_prepare() and remove
> acpi_pci_find_root_bri
On Wed, Jan 9, 2013 at 1:10 PM, Rafael J. Wysocki wrote:
> On Wednesday, January 09, 2013 11:01:39 AM Yinghai Lu wrote:
>> On Wed, Jan 9, 2013 at 10:39 AM, Bjorn Helgaas wrote:
>> >> the reason why we need to change those codes for x86, we want to make it
>> &g
On Thu, Jan 10, 2013 at 6:07 AM, Rafael J. Wysocki wrote:
> On Wednesday, January 09, 2013 05:34:32 PM Bjorn Helgaas wrote:
>> On Wed, Jan 9, 2013 at 1:10 PM, Rafael J. Wysocki wrote:
>> > On Wednesday, January 09, 2013 11:01:39 AM Yinghai Lu wrote:
>> >> On Wed,
On Fri, 2005-04-01 at 21:23 +0200, Jacek Luczak wrote:
> Michael Thonke napisał(a):
> > Hello Jacek,
> >
> > I finially got it working :-) my PCI-Express devices working now...
> > I grabbed the last bk-snapshot from kernel.org 2.6.12-rc1-bk3 and et volia
> > everything except the Marvell Yokon PC
> Version from syskonnect site require only changing usage of
> pci_dev->slot_name to pci_name(pci_dev) in skge.c and skethtool.c. After
> that everything should work fine. So I think there is no need to post my
> path here but if you really whant I may do this. Whole path agains
> 2.6.12-rc2 take
Call pci_enable_device() before looking at IRQ and resources.
The driver requires this fix or the "pci=routeirq" workaround
on 2.6.10 and later kernels.
Reported and tested by Artur Lipowski.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
= drivers/net/wan/pc300_drv.
On Wed, 2005-04-13 at 15:02 -0700, Ashok Raj wrote:
> On Wed, Apr 13, 2005 at 02:31:43PM -0700, Bjorn Helgaas wrote:
> >
> >Call pci_enable_device() before looking at IRQ and resources.
> >The driver requires this fix or the "pci=routeirq" workaround
>
On Thu, 2005-04-14 at 13:11 -0400, Lee Revell wrote:
> I get this message occasionally on both my machines. I googled and saw
> some references to this message on 2.4 but nothing for 2.6. Some of the
> references were to APIC, which I don't have enabled.
>
> Both machines are using VIA chipsets
On Thu, 2005-04-14 at 16:56 -0400, Lee Revell wrote:
> Is the VIA IRQ fixup related to the "spurious interrupts" messages in
> any way? Googling the 2.4 threads on the issue gave me the impression
> that it's related to broken hardware. I think excessive disk activity
> might trigger it.
If you
On Friday 05 August 2005 9:17 am, matthieu castet wrote:
> Bjorn Helgaas wrote:
> > The workaround
> > accepts stuff that is illegal according to the spec,
> > so speak up if you think this is a problem.
> >
> May be print some warnings if the acpi is broken...
Yes
On Friday 05 August 2005 10:49 am, Kristen Accardi wrote:
> Changing of the guards.
>
> Signed-off-by: Kristen Carlson Accardi <[EMAIL PROTECTED]>
>
> diff -uprN -X linux-2.6.13-rc5/Documentation/dontdiff
> linux-2.6.13-rc5/drivers/pci/hotplug/pciehp_core.c
> linux-2.6.13-rc5-new/drivers/pci/ho
On Friday 05 August 2005 10:27 am, Kristen Accardi wrote:
> On the 6700/6702 PXH part, a MSI may get corrupted if an ACPI hotplug
> driver and SHPC driver in MSI mode are used together. This patch will
> prevent MSI from being enabled for the SHPC.
Can you outline the scenario that causes the c
On Thursday 04 August 2005 4:31 am, Marcel Selhorst wrote:
> This patch includes support for the new Infineon Trusted Platform Module
> SLB 9635 TT 1.2 and does further include ACPI-support for both chip versions
> (SLD 9630 TT 1.1 and SLB9635 TT 1.2). Since the ioports and configuration
> register
On Friday 05 August 2005 5:51 pm, Kristen Accardi wrote:
> On the 6700/6702 PXH part, a MSI may get corrupted if an ACPI hotplug
> driver and SHPC driver in MSI mode are used together. This patch will
> prevent MSI from being enabled for the SHPC as part of an early pci
> quirk, as well as on any
On Thursday 04 August 2005 5:26 pm, Bjorn Helgaas wrote:
> Maybe the third time's the charm :-) Added a bugfix
> (pcibios_penalize_isa_irq()) and a workaround for HP
> HPET firmware description since last time. The workaround
> accepts stuff that is illegal according to the sp
IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
around in I/O port space. Poking at things that don't exist causes MCAs
on HP ia64 systems.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work-vga/dri
On Thursday 11 August 2005 2:34 pm, Christoph Hellwig wrote:
> On Thu, Aug 11, 2005 at 02:24:43PM -0600, Bjorn Helgaas wrote:
> > IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
> > around in I/O port space. Poking at things that don't exist c
On Thursday 11 August 2005 2:36 pm, Jeff Garzik wrote:
> Bjorn Helgaas wrote:
> > IA64 boxes only have PCI IDE devices, so there's no need to blindly poke
> > around in I/O port space. Poking at things that don't exist causes MCAs
> > on HP ia64 systems.
> &
On Thursday 11 August 2005 2:56 pm, Jeff Garzik wrote:
> Bjorn Helgaas wrote:
> > On Thursday 11 August 2005 2:36 pm, Jeff Garzik wrote:
> >>Bjorn Helgaas wrote:
> >>> config IDE_GENERIC
> >>> tristate "generic/default IDE chipset support"
&g
On Thursday 11 August 2005 3:56 pm, Jeff Garzik wrote:
> Jeff Garzik wrote:
> > 00:1f.1 IDE interface: Intel Corporation 82801EB/ER (ICH5/ICH5R) IDE
> > Controller
> > (rev 02) (prog-if 8a [Master SecP PriP])
> > Subsystem: Hewlett-Packard Company d530 CMT (DG746A)
> > Control: I/
On Friday 12 August 2005 2:40 am, Alan Cox wrote:
> Assuming all IA-64 boxes are PCI or better then you actually want to
> edit include/asm-ia64/ide.h and edit ide_default_io_base where someone
> years ago cut and pasted x86-32 values so that case 2-5 are removed.
> Then you will just probe the com
On Friday 12 August 2005 1:44 pm, Peter Martuccelli wrote:
> Stumbled into this problem working on the ipmi_si driver. When the
> ipmi_si driver initialization fails the acpi_tb_get_table
> call, after rsdt_info has been allocated, acpi_get_firmware_table()
> will oops trying to reference off rsd
On Saturday 13 August 2005 9:10 am, Karsten Wiese wrote:
> this fixes the 'doubled ioapic level interrupt rate' issue I've been
> seeing on a K8T800/AMD64 mainboard.
> It also switches off quirk_via_irq() for the VT8237 southbridge.
These patches seem unrelated except that they both contain the
te
On Tuesday 16 August 2005 9:26 am, Karsten Wiese wrote:
> What about the following version?
> quirk_via_686irq() only works on pci_devs that are part of the 686.
> Sooner or later there'll be more VIA southbridge types, which will
> not need quirk_via_irq() like the 8237.
Do you have VIA spec refe
On Tuesday 16 August 2005 3:38 am, Bartlomiej Zolnierkiewicz wrote:
> On 8/15/05, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> > On Friday 12 August 2005 2:40 am, Alan Cox wrote:
> Agreed but I have few comments:
> * is this change OK w.r.t. IA64_HP_SIM?
Kernels for the HP
On Wednesday 17 August 2005 2:30 pm, Corey Minyard wrote:
> Basically, the IPMI system interface needs information from a specific
> IPMI table to know how to configure itself. Those tables can reference
> GPEs, so the driver can use those (though AFAIK it has never been tested).
The informatio
If the PCDP supplies parity, use it (only none/even/odd supported),
and don't append parity/stop bit arguments unless baud is present.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work/drivers/firm
Add support for UARTs in MMIO space and clean up a little whitespace.
HP legacy-free ia64 machines need this.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work/drivers/serial/8250_pnp.c
===
--- work.orig/drivers/
ISAPNP, PNPBIOS, and PNPACPI all had their own kmalloc wrappers that
reimplemented kcalloc(). Remove the wrappers and just use kcalloc()
directly.
Note that this also removes the PNPBIOS error message when the kmalloc
fails.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work/d
On Thursday 28 July 2005 6:10 am, Nick Piggin wrote:
> I have a VIA SMP system and somewhere between 2.6.12-rc3 and 2.6.12
> the USB mouse started moving around really slowly. Anyway, it turns
> out that the attached patch (against 2.6.13-rc3-git8) fixes the problem.
Can you try this:
Index: work
On Wednesday 27 July 2005 5:12 am, Rahul Tank wrote:
>i am writing a serial device driver. After going
> thru few linux journals i have understood that serial
> ports get mapped at standard addrerss.We need to take
> these regions, register driver and talk to them
> (read,write).
If your devic
On Friday 29 July 2005 5:17 pm, Andrew Morton wrote:
> Khalid Aziz <[EMAIL PROTECTED]> wrote:
> >
> > Serial console is broken on ia64 on an HP rx2600 machine on
> > 2.6.13-rc3-mm3. When kernel is booted up with "console=ttyS,...", no
> > output ever appears on the console and system is hung. So I
On Saturday 30 July 2005 12:10 pm, Christoph Lameter wrote:
> On Sat, 30 Jul 2005, Alex Williamson wrote:
>
> > On Fri, 2005-07-29 at 16:31 -0700, Christoph Lameter wrote:
> > > What you are dealing with is a machine that is using ITC as a time bases.
> > > That is a special case.
> >
> >The
Seems pointless to require .c files to test CONFIG_PNP_DEBUG and
conditionally define DEBUG before including . Just
test CONFIG_PNP_DEBUG directly in pnp.h.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work/drivers/pnp/
om an RSTYPE_ADDRESS64 was passed as an int,
which corrupts the value.
This is one of the things that prevents 8250_pnp from working
on HP ia64 boxes. After 8250_pnp works, we will be able to
remove 8250_acpi.c.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work/drivers/pnp/pnpacpi
On Tuesday 02 August 2005 7:01 pm, Shaohua Li wrote:
> On Tue, 2005-08-02 at 09:55 -0600, Bjorn Helgaas wrote:
> > Any objections to the patch below? I posted it last Wednesday,
> > but haven't heard anything. Once we have this fix, 8250_pnp
> > should have sufficient
np from working
on HP ia64 boxes. After 8250_pnp works, we will be able to
remove 8250_acpi.c.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work-mm/drivers/pnp/pnpacpi/rsparser.c
===
--- work-mm.orig/drivers/pnp/pnpacpi/rs
On Wednesday 03 August 2005 3:16 pm, matthieu castet wrote:
> Bjorn Helgaas wrote:
> > On Tuesday 02 August 2005 7:01 pm, Shaohua Li wrote:
> >>Did you have plan to remove other
> >>legacy acpi drivers?
> > No, I didn't -- which ones are you thinking
On Thursday 04 August 2005 6:38 am, matthieu castet wrote:
> Bjorn Helgaas wrote:
> > On Wednesday 03 August 2005 3:16 pm, matthieu castet wrote:
> >>Bjorn Helgaas wrote:
> >> > drivers/char/hpet.c
> >> > This probably should be converted to
On Wednesday 13 July 2005 7:09 pm, Matt Tolentino wrote:
> This patch addresses a problem on x86 EFI systems with larger memory
> configurations. Up until now, we've relied on the fact that the
> ACPI RSDT would reside somewhere in low memory that could be permanently
> mapped in kernel address
g
the IRQ resource failed.
Parse IRQ descriptors that contain multiple interrupts. This violates
the spec (in _CRS, only one interrupt per descriptor is allowed), but
some firmware, e.g., HP rx7620 and rx8620 descriptions of HPET, has this
bug.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]
CONFIG_IDE_MAX_HWIFS is a generic thing, no need to have it duplicated
by every arch that uses it.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work-ide/include/asm-alpha/ide.h
===
--- work-ide.orig/include/asm
On Wednesday 24 August 2005 10:53 am, Kumar Gala wrote:
> Removed IA64 architecture specific users of asm/segment.h and
> asm-ia64/segment.h itself
I posted a similar patch a month ago, but I only removed the
arch/ia64 includes of asm/segment.h.
There are still a few drivers that include asm/segm
Ping... any objection to this?
CONFIG_IDE_MAX_HWIFS is a generic thing, no need to have it duplicated
by every arch that uses it.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work-ide/include/asm-alpha
On Monday 29 August 2005 10:09 am, Tom Rini wrote:
> linux-2.6.13-trini/drivers/serial/kgdb_8250.c | 594 +
The existing stuff in drivers/serial is named "8250_*"; is
there a reason you're using "kgdb_8250" rather than "8250_kgdb"?
> + * serial8250_unregister_by_port - rem
On Wednesday 31 August 2005 2:10 pm, Tom Rini wrote:
> On Wed, Aug 31, 2005 at 01:38:52PM -0600, Bjorn Helgaas wrote:
> > On Monday 29 August 2005 10:09 am, Tom Rini wrote:
> I've tried intentionally to not mention 'ttyS' anywhere (exposed to the
> user) because it&
On Thursday 08 September 2005 1:34 am, Andrew Morton wrote:
> Len Brown <[EMAIL PROTECTED]> wrote:
> >
> > Hi Linus, please pull from the release branch here:
> >
> > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
> > release
>
> There are a few bugs which I'd identif
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, bu
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 Sla
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/drive
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, o
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 machi
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
>
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?
> >
> >
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:
> > &g
On Saturday 19 January 2008 4:03:39 am Frans Pop wrote:
> Dave Young wrote:
> > I noticed the port number changed to 40 in 2.6.24-rc8, but it's not
> > enough for me still.
>
> Same here, though the extreme noise has gone.
> From /proc/ioports and dmesg it looks like I'm short by either 1, or 3 :-(
On Monday 17 December 2007 02:09:40 pm [EMAIL PROTECTED] wrote:
> Convert quirk printks to dev_printk().
>
> Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
>
> ---
> arch/x86/kernel/quirks.c | 42 ++
> arch
7/12/4/466
Related change:
http://git.kernel.org/?p=linux/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 mask
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),
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
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
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 motherbo
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 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:
> > [] relea
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 <[EM
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,sta
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
> >
> >
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
sts that Windows only stops a device to rebalance 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 <[EMA
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:
> > > >
> > >
801 - 900 of 6731 matches
Mail list logo
