Eric,
So even the pnp is disabled, the fixed value should be there.
I wonder if add if(!curdev->enabled) continue; In find_largest_resource is good way to fix it.
Regards
YH
static void find_largest_resource(struct pick_largest_state *state, struct bus *bus, unsigned long type_mask, unsigned long type) { struct device *curdev; for(curdev = bus->children; curdev; curdev = curdev->sibling) { int i; if(!curdev->enabled) continue;
chip superio/winbond/w83627hf device pnp 2e.0 on # Floppy io 0x60 = 0x3f0 irq 0x70 = 6 drq 0x74 = 2 end device pnp 2e.1 off # Parallel Port io 0x60 = 0x378 irq 0x70 = 7 end device pnp 2e.2 on # Com1 io 0x60 = 0x3f8 irq 0x70 = 4 end device pnp 2e.3 off # Com2 io 0x60 = 0x2f8 irq 0x70 = 3 end device pnp 2e.5 on # Keyboard io 0x60 = 0x60 io 0x62 = 0x64 irq 0x70 = 1 irq 0x72 = 12 end device pnp 2e.6 off # CIR io 0x60 = 0x90 end device pnp 2e.7 off # GAME_MIDI_GIPO1 io 0x60 = 0x70 io 0x62 = 0x74 irq 0x70 = 5 end device pnp 2e.8 off end # GPIO2 device pnp 2e.9 off end # GPIO3 device pnp 2e.a off end # ACPI device pnp 2e.b on # HW Monitor io 0x60 = 0x290 irq 0x70 = 5 end end
_____
From: YhLu Sent: Tuesday, October 26, 2004 3:29 PM To: ebiederman@lnxi.com Cc: Ronald G. Minnich; linuxbios@clustermatic.org Subject: RE: S2885
I add print_debug in device.c
if (resource->flags & IORESOURCE_FIXED) { printk_debug("\t\t%s, base=%08Lx, limit=%08Lx\r\n", dev_path(dev), resource->base, resource->limit); continue; }
Found some interesting result PNP: 002e.0, base=000003f0, limit=000007ff PNP: 002e.1, base=00000378, limit=000007ff PNP: 002e.2, base=000003f8, limit=000007ff PNP: 002e.3, base=000002f8, limit=000007ff PNP: 002e.b, base=00000290, limit=00000fff PNP: 002e.5, base=00000060, limit=ffffffff PNP: 002e.5, base=00000064, limit=ffffffff
1. It real does the continue. 2. it process disabled device,if it is get the fixed values in Config.lb
PNP: 002e.0 enabled PNP: 002e.1 disabled PNP: 002e.2 enabled PNP: 002e.3 disabled PNP: 002e.5 enabled PNP: 002e.6 disabled PNP: 002e.7 disabled PNP: 002e.8 disabled PNP: 002e.9 disabled PNP: 002e.a disabled PNP: 002e.b enabled
In Config.lb chip superio/winbond/w83627hf device pnp 2e.0 on # Floppy io 0x60 = 0x3f0 irq 0x70 = 6 drq 0x74 = 2 end device pnp 2e.1 off # Parallel Port io 0x60 = 0x378 irq 0x70 = 7 end device pnp 2e.2 on # Com1 io 0x60 = 0x3f8 irq 0x70 = 4 end device pnp 2e.3 off # Com2 io 0x60 = 0x2f8 irq 0x70 = 3 end device pnp 2e.5 on # Keyboard io 0x60 = 0x60 io 0x62 = 0x64 irq 0x70 = 1 irq 0x72 = 12 end device pnp 2e.6 off end # CIR device pnp 2e.7 off end # GAME_MIDI_GIPO1 device pnp 2e.8 off end # GPIO2 device pnp 2e.9 off end # GPIO3 device pnp 2e.a off end # ACPI device pnp 2e.b on # HW Monitor io 0x60 = 0x290 irq 0x70 = 5 end end
in superio.c static struct pnp_info pnp_dev_info[] = { { &ops, W83627HF_FDC, PNP_IO0 | PNP_IRQ0 | PNP_DRQ0, { 0x07f8, 0}, }, { &ops, W83627HF_PP, PNP_IO0 | PNP_IRQ0 | PNP_DRQ0, { 0x07f8, 0}, }, { &ops, W83627HF_SP1, PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, }, { &ops, W83627HF_SP2, PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, }, // No 4 { 0,}, { &ops, W83627HF_KBC, PNP_IO0 | PNP_IO1 | PNP_IRQ0 | PNP_IRQ1, { 0x7ff, 0 }, { 0x7ff, 0x4}, }, { &ops, W83627HF_CIR, PNP_IO0 | PNP_IRQ0, { 0x7f8, 0 }, }, { &ops, W83627HF_GAME_MIDI_GPIO1, PNP_IO0 | PNP_IO1 | PNP_IRQ0, { 0x7ff, 0 }, {0x7fe, 4}, }, { &ops, W83627HF_GPIO2,}, { &ops, W83627HF_GPIO3,}, { &ops, W83627HF_ACPI, PNP_IRQ0, }, { &ops, W83627HF_HWM, PNP_IO0 | PNP_IRQ0, { 0xff8, 0 }, }, };
YhLu YhLu@tyan.com writes:
Eric,
So even the pnp is disabled, the fixed value should be there.
I wonder if add if(!curdev->enabled) continue; In find_largest_resource is good way to fix it.
It is a little weird but that sounds like a sane way to do it. Although I think a test of !curdev->have_resources is a little better.
What puzzles me is that even disabled you seem to have had all of the resources specified so they should have had IORESOURCE_FIXED set. So I don't see how they were being looked at.
Eric
On Tue, 26 Oct 2004, YhLu wrote:
Eric,
So even the pnp is disabled, the fixed value should be there.
folks, sorry the LANL guys are not engaged in this discussions :-(
we're on Infinibomb all week :-(
ron