27;t really need the pnp_stop_dev() 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
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 PNP_DRI
When 8250_pnp discovers COM ports, we only get the correct ttyS names
by accident -- we rely on serial8250_isa_init_ports(), which discovers
the COM ports earlier using the addresses in SERIAL_PORT_DFNS.
These two patches remove the dependency on SERIAL_PORT_DFNS by
explicitly requesting the desir
Add an interface for registering a new UART with a specific ttyS name.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work5/include/linux/serial_8250.h
===
--- work5.orig/include/linux/serial_8250.h 2008-01-15
ff-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: work5/drivers/serial/8250_pnp.c
===
--- work5.orig/drivers/serial/8250_pnp.c2008-01-16 09:29:33.0
-0700
+++ work5/drivers/serial/8250_pnp.c 2008-01-16 09:51:0
On Tuesday 15 January 2008 12:51:35 am Jaroslav Kysela wrote:
> On Mon, 14 Jan 2008, Bjorn Helgaas wrote:
> > 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 anymo
ap <[EMAIL PROTECTED]>
Acked-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Thanks, Randy.
> ---
> Documentation/ia64/aliasing-test.c | 15 +--
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> --- linux-2.6.24-rc7.orig/Documentation/ia64/aliasing-test.c
&
On Wednesday 16 January 2008 11:44:37 am H. Peter Anvin wrote:
> Bjorn Helgaas wrote:
> > x86 users expect COM1-COM4 ports at the conventional ioport addresses
> > to be named ttyS0-ttyS3. For PNP devices, the BIOS determines the
> > order we discover them, so we might disc
On Wednesday 16 January 2008 11:39:34 am Russell King wrote:
> On Wed, Jan 16, 2008 at 10:05:41AM -0700, Bjorn Helgaas wrote:
> > When 8250_pnp discovers COM ports, we only get the correct ttyS names
> > by accident -- we rely on serial8250_isa_init_ports(), which discovers
&g
On Wednesday 16 January 2008 01:14:38 pm Russell King wrote:
> On Wed, Jan 16, 2008 at 12:59:27PM -0700, Bjorn Helgaas wrote:
> > On Wednesday 16 January 2008 11:39:34 am Russell King wrote:
> > > On Wed, Jan 16, 2008 at 10:05:41AM -0700, Bjorn Helgaas wrote:
> > > &g
On Thursday 17 January 2008 09:16:51 am Russell King wrote:
> On Thu, Jan 17, 2008 at 09:07:29AM -0700, Bjorn Helgaas wrote:
> > On Wednesday 16 January 2008 01:14:38 pm Russell King wrote:
> > > On Wed, Jan 16, 2008 at 12:59:27PM -0700, Bjorn Helgaas wrote:
> > > > O
Where are we with this problem?
(http://bugzilla.kernel.org/show_bug.cgi?id=9514)
I think (correct me if I'm misremembering), we started reserving more
motherboard resources, and then we started seeing conflicts between
some of those resources and something it87 needs.
We can't fix this by reserv
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. Basical
device or subordinate bus
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
---
drivers/pci/quirks.c | 110 +++---
drivers/usb/host/pci-quirks.c | 13 +---
2 files changed, 56 insertions(+),
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/qu
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/ar
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 http://vg
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
On Sun, 2005-03-13 at 16:14 +0100, Grzegorz Kulewski wrote:
> On Fri, 11 Mar 2005, Bjorn Helgaas wrote:
> > So here's another patch to try (revert the first one, then apply this).
> >
> > = drivers/acpi/pci_irq.c 1.37 vs edited =
> > --- 1.37/drivers/acpi/p
On Tue, 2005-03-15 at 16:02 -0700, Zwane Mwaikambo wrote:
> On Tue, 15 Mar 2005, Bjorn Helgaas wrote:
> > That seems awfully suspicious to me. So the following is
> > probably safe as far as it goes, but not sufficient for all
> > cases.
>
> VIA bridges allow
On Thu, 2005-03-17 at 09:33 +0800, Li Shaohua wrote:
> The comments in previous quirk said it's required only in PIC mode.
...
> I feel we concerned too much. Changing the interrupt line isn't harmful,
> right? Linux actually ignored interrupt line. Maybe just a
> PCI_FIXUP_ENABLE(PCI_VENDOR_ID_VIA
On Fri, 2005-03-18 at 09:09 +0800, Li Shaohua wrote:
> On Fri, 2005-03-18 at 02:08, Bjorn Helgaas wrote:
> > On Thu, 2005-03-17 at 09:33 +0800, Li Shaohua wrote:
> > > The comments in previous quirk said it's required only in PIC mode.
> > ...
> > > I fe
On Fri, 2005-03-18 at 11:07 -0700, Bjorn Helgaas wrote:
> OK. Try this one for size. It differs from what's currently in
> the tree in these ways:
>
> - It's a quirk, so we don't have to clutter acpi_pci_irq_enable()
> and pirq_enable_irq() with Vi
> Your patch applied with some problems:
>
> patching file arch/i386/pci/irq.c
> Hunk #2 succeeded at 1081 with fuzz 2 (offset 1 line).
> patching file drivers/acpi/pci_irq.c
> patching file drivers/pci/quirks.c
> Hunk #1 succeeded at 678 (offset -5 lines).
These indicate minor differences in thes
IAL to OTHER to prevent serial driver from claiming them.
8250:
Add init hook to discover the number of serial ports present.
This prevents us from poking at unused BARs.
pci_ids:
Add Netmos 9745, 9845, and sort.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
diff -u -r 2.6.12-
> On Wed, 2005-03-23 at 04:57, Bjorn Helgaas wrote:
>> Great. Shaohua, where should we go from here? Do you have more
>> concerns with the current patch, or should we ask Andrew to put it
>> in -mm? If you do have concerns, would you like to propose an
>> alternate p
-
arch/x86_64/pci/mmconfig.c |8 --
include/linux/pci.h|6 +++--
7 files changed, 51 insertions(+), 46 deletions(-)
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
= arch/i386/pci/direct.c 1.19 vs edited =
--- 1.19/arch/i386/pci/direct.c 2004-0
Don't use pci_dev->irq until after pci_enable_device().
Andy Esten reported that his NIC stopped working in
2.6.10 because of this problem.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
= drivers/net/tulip/de2104x.c 1.33 vs edited =
--- 1.33/drivers/net/tulip/de2104x.c
from
/proc/pci and stuff it into an unused port using setserial. That
doesn't work reliably anymore because pci_enable_device() is never
called, so the IRQ may not be enabled.
Thanks to Evan Clarke for reporting and helping debug this problem.
Signed-off-by: Bjorn Helgaas <[EM
On Mon, 2005-02-07 at 15:12 -0500, linux-os wrote:
> I thought somebody promised to add a pci_route_irq(dev) or some
> such so that the device didn't have to be enabled before
> the IRQ was correct.
>
> I first reported this bad IRQ problem back in December of 2004.
> Has the new function been adde
On Tue, 2005-02-08 at 07:25 -0500, linux-os wrote:
> On Mon, 7 Feb 2005, Bjorn Helgaas wrote:
>
> > On Mon, 2005-02-07 at 15:12 -0500, linux-os wrote:
> >> I thought somebody promised to add a pci_route_irq(dev) or some
> >> such so that the device didn't hav
Tone down the message about using "pci=routeirq". I do still get
a few reports, but most are now prompted just by the fact that
my email address appears in dmesg in an "error-type" message.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
= arch/i386/pci/acpi.c 1.1
Remove unused get_resource_list() declaration.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
= include/linux/ioport.h 1.15 vs edited =
--- 1.15/include/linux/ioport.h 2004-10-07 20:11:55 -06:00
+++ edited/include/linux/ioport.h 2005-02-15 15:27:49 -07:00
@@ -91,8
On Fri, 2005-03-11 at 00:08 +0100, Grzegorz Kulewski wrote:
> Anything new about it?
>
> Can I provide more usefull info?
Can you check to see whether there are any BIOS updates available
for your box? It looks to me like your USB controllers are wired
to IRQ9, and that's how the BIOS is leaving
On Fri, 2005-03-11 at 08:39 -0800, Jesse Barnes wrote:
> On Thursday, March 10, 2005 8:30 pm, Benjamin Herrenschmidt wrote:
> > On Thu, 2005-03-10 at 20:02 -0800, Jesse Barnes wrote:
> > > On Thursday, March 10, 2005 6:38 pm, Benjamin Herrenschmidt wrote:
> > > > That one is even worse... from what
On Fri, 2005-03-11 at 20:36 +0100, Grzegorz Kulewski wrote:
> On Fri, 11 Mar 2005, Bjorn Helgaas wrote:
> > Can you check to see whether there are any BIOS updates available
> > for your box? It looks to me like your USB controllers are wired
> > to IRQ9, and that's ho
Can you do an "lspci -vvn"? I'm looking at quirk_via_irqpic() in
2.6.9, which is what printed this:
> >PCI: Via IRQ fixup for :00:07.2, from 9 to 10
> >PCI: Via IRQ fixup for :00:07.3, from 9 to 10
but it looks like it should only run for PCI_DEVICE_ID_VIA_82C586_2,
PCI_DEVICE_ID
On Sat, 2005-03-12 at 09:43 +1100, Paul Mackerras wrote:
> On PPC/PPC64 machines, the host bridges generally do not appear as PCI
> devices either. *However*, the AGP spec requires a set of registers
> in PCI config space for controlling the target (host) side of the AGP
> bus. In other words you
4.
In PIC mode, some Via devices update IRQ routing when
PCI_INTERRUPT_LINE is written. So if we've updated the
device's IRQ, we also need to update PCI_INTERRUPT_LINE.
This also restores the mysterious "udelay(15)" before the
update because we don't know whether it's neces
On Thu, 2005-03-24 at 23:40 +0300, Michael Tokarev wrote:
> So, do you expect 9[78]35 cards to work? ;)
Yes, I expect them all to work. Thanks very much for testing yours!
> With this patch applied, my 9835 card now works when loading 8250_pci
> module. But things does not completely work still
On Thursday 24 March 2005 12:54 pm, Michael Tokarev wrote:
> Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing enabled
> ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
> ACPI: PCI interrupt :01:00.0[A] -> GSI 18 (level, low) -> IRQ 193
> ttyS4 at I/O 0xa400 (irq = 193) is a 16550A
> tt
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
> > > remembe
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 u
e patch, I think enlarging the tables is safer.
The space analysis above was based on increasing PNP_MAX_PORT from
8 to 32 and PNP_MAX_IRQ from 2 to 4 (total increase 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
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
>
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
> > >
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
> &
PNP reports 8042 controller data register
0061-0061 : 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 PROTEC
s 8042 controller data register
0061-0061 : 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 PROTEC
On Tuesday 24 July 2007 08:28:05 am Sébastien Dugué wrote:
> your commit 7e92b4fc345f5b6f57585fbe5ffdb0f24d7c9b26 broke the serial console
> on my box. Adding 'legacy_serial.force=1' to my boot param as a workaround
> solves the issue, but this may be hiding bugs in Linux PnP support or
> in my fi
On Tuesday 24 July 2007 12:17:36 pm Maciej W. Rozycki wrote:
> On Tue, 24 Jul 2007, Jeff Garzik wrote:
>
> > It seems clear from this report that we cannot, should not, trust BIOS for
> > something (a) so simple and (b) that has been working for over a decade.
>
> And (c) something BIOS writers
On Tuesday 24 July 2007 02:13:49 pm Jeff Garzik wrote:
> Bjorn Helgaas wrote:
> > - Linux enumerates CPUs with the MADT; I think Windows uses the ACPI
> > namespace. Sometimes there are multiple MADTs, and sometimes Linux
> > uses the wrong one.
>
> Colo
On Tuesday 24 July 2007 02:40:42 pm Jeff Garzik wrote:
> Please go back and fix the original issue!
>
> If you are having problems caused by double-probing, the fix is NOT to
> remove one the probes. The fix is to ensure use of proper resource
> reservation, and in some cases, add co-driver-awa
On Tuesday 24 July 2007 02:33:05 pm Yinghai Lu wrote:
> I have a system that has the same problem, and it turns out that FW
> missed PNP0501 is DSDT for uart. and add that it into DSDT works well.
Is this FW that has been shipped? Can you give any more details,
like DMI info and a copy of the DSD
On Tuesday 24 July 2007 10:27:26 pm Yinghai Lu wrote:
> On 7/24/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> > On Tuesday 24 July 2007 02:33:05 pm Yinghai Lu wrote:
> > > I have a system that has the same problem, and it turns out that FW
> > > missed PNP0501
On Wednesday 25 July 2007 01:45:54 am Sébastien Dugué wrote:
> looks like the commit was dropped, nevertheless here is some more info
> to try and understand what may be going on so it may benefit the posterity ;-)
Thank you very much.
Your machine does indeed describe both UARTs in ACPI, and t
On Wednesday 25 July 2007 09:48:08 am Alan Cox wrote:
> That isn't the problem with the IR stuff. In many cases the user wants
> the port to be showing up as a serial port for SIR usage. We need a clean
> automatic SIR/FIR switching for them. It has nothing to do with whether
> the ACPI data is tru
On Wednesday 25 July 2007 09:57:47 am Yinghai Lu wrote:
> On 7/25/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> > On Tuesday 24 July 2007 10:27:26 pm Yinghai Lu wrote:
> > > or we can make legacy_serial.force=1 is default at this point.
> >
> > At which point
On Wednesday 25 July 2007 07:32:53 am Sébastien Dugué wrote:
> On Wed, 25 Jul 2007 07:16:44 -0600 Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
>
> > The _DDN is a "DOS device name", and the _UID is a "logical device ID
> > that does not change across re
On Wednesday 25 July 2007 08:21:06 pm Shaohua Li wrote:
> On Wed, 2007-07-25 at 17:37 -0700, Yinghai Lu wrote:
> > On 7/25/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> > > Yinghai, you mentioned the same issue on boxes with multiple root
> > > bridges. Any chanc
y : ?
> Handled-By : Bjorn Helgaas <[EMAIL PROTECTED]>
> Patch : http://lkml.org/lkml/2007/8/21/291
> Status : patch was suggested
The following patch fixes this regression (confirmed by Andrey).
Please queue it for 2.6.23. I'll come back late
On Thursday 26 July 2007 05:05:54 pm Simon Arlott wrote:
> Does anyone ever review what Lindent does? There's a fix up patch after this
> but it missed this at the very top of the patch and the labels.
I think you answered your own question.
Did I miss some things in the fixup patch? Yes; unfor
On Wednesday 25 July 2007 08:21:06 pm Shaohua Li wrote:
> On Wed, 2007-07-25 at 17:37 -0700, Yinghai Lu wrote:
> > On 7/25/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> > > On Wednesday 25 July 2007 07:32:53 am Sébastien Dugué wrote:
> > > > On Wed, 25 J
eports COM2 first, then COM1 in the ACPI namespace.
8250_pnp currently registers devices in namespace order. On this machine,
that makes ttyS0=COM2 and ttyS1=COM1, the reverse of what we want.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: w/arch/i386/kernel/leg
On Friday 27 July 2007 12:38:56 pm Yinghai Lu wrote:
> On 7/27/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> > On Wednesday 25 July 2007 08:21:06 pm Shaohua Li wrote:
> > That doesn't help with Yinghai's PCI root ordering issue, of course.
>
> I could
>
On Friday 27 July 2007 12:05:51 pm Jeff Garzik wrote:
> Bjorn Helgaas wrote:
> > Andrew, if you drop
> > revert-x86-serial-convert-legacy-com-ports-to-platform-devices.patch
> > and apply this, we should have the previous behavior. I think the
> > conversion t
On Friday 27 July 2007 02:21:55 pm Jeff Garzik wrote:
> Bjorn Helgaas wrote:
> > On Friday 27 July 2007 12:05:51 pm Jeff Garzik wrote:
> >> This is still incomplete, as repeatedly stated. Here is the email, again.
>
> > OK, uncle! I'll work on your helpful advi
On Friday 27 July 2007 02:35:30 pm Yinghai Lu wrote:
> On 7/27/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> > Can you give a more detailed example? Maybe that would help me understand
> > the problem you're seeing.
> >
> > And why is udev not suffic
On Friday 27 July 2007 07:28:09 am [EMAIL PROTECTED] wrote:
> Looks like the problematic code is in tpm_tis.c tpm_tis_init() near here:
>
> for (i = 3; i < 16 && chip->vendor.irq == 0; i++) {
> iowrite8(i, chip->vendor.iobase +
>
On Friday 27 July 2007 04:43:13 pm Bjorn Helgaas wrote:
> On Friday 27 July 2007 07:28:09 am [EMAIL PROTECTED] wrote:
> > Looks like the problematic code is in tpm_tis.c tpm_tis_init() near here:
> >
> > for (i = 3; i < 16 &am
On Tuesday 31 July 2007 12:48:29 pm [EMAIL PROTECTED] wrote:
> Scratch that. When I wrote the first note, I was at home, and the TPM chip
> did its PNP thing and became 00:0e. I failed to notice that in my reply,
> I was at work, and the printer port on the docking station became 00:0e and
> the
On Tuesday 31 July 2007 03:31:43 pm [EMAIL PROTECTED] wrote:
> On Tue, 31 Jul 2007 14:01:21 MDT, Bjorn Helgaas said:
> > So, the BIOS is telling us that at least as currently configured, the
> > TPM can't use interrupts. /sys/devices/pnp0/00:0f/options should have
> &
On Saturday 11 August 2007 12:39:35 pm Andrey Borzenkov wrote:
> This stopped working again in 2.6.23-rc. In 2.6.22 we decided to disable PnP
> by default; it is apparently enabled now and fails to activte IrDA
> completely. So it moves to post-2.6.22 regressions :)
>
> let me know which informa
On Saturday 11 August 2007 09:49:25 am Michael Mauch wrote:
> Yinghai Lu wrote:
>
> > On 8/10/07, Michael Mauch <[EMAIL PROTECTED]> wrote:
> > > until 2.6.21, I had the normal assignments for ttyS0 and ttyS1:
> > >
> > > 00:08: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
> > > 00:09: ttyS0 at I/O 0x3
On Monday 13 August 2007 04:28:00 pm Michael Mauch wrote:
> Bjorn Helgaas wrote:
>
> > On Saturday 11 August 2007 09:49:25 am Michael Mauch wrote:
> > > Yinghai Lu wrote:
> > >
> > > > On 8/10/07, Michael Mauch <[EMAIL PROTECTED]> wrote:
> >
On Wednesday 15 August 2007 08:03:24 am Thomas Renninger wrote:
> This is not a real feature, more a fix.
> Without, PNP IO ports might not get considered. This mainly affects ACPI
> system board devices with HID PNP0C02 (at least I saw this on my and
> some other machines, but it may affect more..
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);
> &
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 th
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: send
0070-0073 : 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]>
In
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
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 Wednesday 07 November 2007 06:22:48 am Maciej W. Rozycki wrote:
> On Mon, 29 Oct 2007, Bjorn Helgaas wrote:
>
> > -001f : dma1<-- built-in resource includes 2
> > controllers
> > -000f : 00:02 <-- PNP r
On Tuesday 30 January 2007 12:01, Frédéric Riss wrote:
> When calling into an EFI firmware, the parameters need to be passed on
> the stack. The recent change to use -mregparm=3 breaks x86 EFI support.
> This patch is needed to allow the new Intel-based Macs to suspend to ram
> when run in EFI mode
I'm seeing a workqueue-related deadlock. This is on an ia64
box running SLES10, but it looks like the same problem should
be possible in current upstream on any architecture.
Here are the two tasks involved:
events/4:
schedule
__down
__lock_cpu_hotplug
lock_cpu_hotplug
flus
On Friday 05 January 2007 11:10, Len Brown wrote:
> On Friday 05 January 2007 12:24, MoRpHeUz wrote:
> > > What workaround are you using?
> >
> > This one: http://bugzilla.kernel.org/show_bug.cgi?id=7465
>
> Ah yes, the duplicate MADT issue is clearly a BIOS bug.
> It is possible that we can twe
On Wednesday 15 November 2006 21:02, Keith Owens wrote:
> I implemented this in my kdb tree, but it has a very nasty side effect,
> it stops you from debugging that part of the boot process between kdb
> startup and when the i8042 is probed. KDB starts up very early so we
> can debug the boot proc
On Saturday 16 June 2007 10:38:56 am Andrey Borzenkov wrote:
> it appears that quirk is not even applied because PnP tells us device is not
> active:
>
> [ 571.118483] pnp: PnP ACPI init
> [ 571.118611] ACPI: bus type pnp registered
> [ 571.158828] quirk_smc_enable: active = 0
> [ 571.182090]
On Sunday 10 June 2007 02:03:03 am Andrey Borzenkov wrote:
> > Can you set CONFIG_ACPI_DEBUG=y, make it so smsc-ircc2 isn't loaded
> > automatically, and try this (along with my previous patch to swap
> > FIR and SIR):
> >
> > # dmesg -n 8
> > # echo 0x200 > /sys/module/acpi/parameters/debug_le
On Sunday 10 June 2007 12:47:07 am Andrey Borzenkov wrote:
> > Maybe we should also run the legacy probe when the PnP one fails. I
> > don't know how the preconfiguration stuff will behave with the device
> > being PnP enabled, but with your patch Andrey will still need to
> > modprobe smsc-ircc wi
On Sunday 10 June 2007 04:57:12 am Pavel Machek wrote:
> > > > > Any reason to not just replace ACPI_RSD_TABLE_SIZE with ARRAY_SIZE?
> > >
> > > Probably because ARRAY_SIZE doesn't exist in ACPICA, which is
> > > where this code comes from...
> > >
> > > When we change syntax in ACPICA files in L
On Tuesday 12 June 2007 12:41:05 pm Andi Drebes wrote:
> First off: sorry for my late answer.
>
> > I agree the ACPI CA is a nuisance. But in this case, we're making
> > a mountain out of a molehill. I suspect that if somebody spent the
> > 15 minutes to make the ARRAY_SIZE patch work in both th
uot;, we do the legacy device probe, including
manual bridge preconfiguration, as before.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: w/drivers/net/irda/smsc-ircc2.c
===
--- w.orig/drivers/net/irda/smsc-ircc2.c 2007-06-06 1
On Friday 15 June 2007 07:44:41 am Andrey Borzenkov wrote:
> On Friday 15 June 2007, Bjorn Helgaas wrote:
> > Hi Andrey,
> >
> > If you have a chance, can you try the attached two patches? The
> > smsc-preconfig patch makes the HP nx5000 work, and the smsc-quirk
> &
On Saturday 07 July 2007 05:33:00 pm Luca Tettamanti wrote:
> your patch:
>
> commit 7e92b4fc345f5b6f57585fbe5ffdb0f24d7c9b26
> Author: Bjorn Helgaas <[EMAIL PROTECTED]>
> Date: Tue May 8 00:36:07 2007 -0700
>
> x86, serial: convert legacy COM ports to pla
On Monday 09 July 2007 11:30:59 am Luca wrote:
> On 7/9/07, Bjorn Helgaas <[EMAIL PROTECTED]> wrote:
> > On Saturday 07 July 2007 05:33:00 pm Luca Tettamanti wrote:
> > > your patch:
> > >
> > > commit 7e92b4fc345f5b6f57585fbe5ffdb0f24d7c9b26
>
On Wednesday 11 July 2007 01:17:42 am Russell King wrote:
> On Tue, Jul 10, 2007 at 05:03:35PM -0700, Yinghai Lu wrote:
> > [PATCH] serial: do not add port that is not initialized
> >
> > if the port is not initialized with correct iobase, and membase, we don't
> > need to add that port.
> > for x
901 - 1000 of 6731 matches
Mail list logo
