I have a Toshiba Portege 4000 with a parallel port. There is no BIOS setting to enable or disable the port, but the BIOS always leaves the ACPI device marked disabled. If we completely ignored the device, Linux would never be able to use it. Have you tried CONFIG_PARPORT_PC_SUPERIO? Or whatabout:
https://bugzilla.novell.com/show_bug.cgi?id=375836 User trenn@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=375836#c37 --- Comment #37 from Thomas Renninger <trenn@novell.com> 2008-05-23 07:19:53 MST --- Patch from comment #34 is wrong, please do not do that. The mechanism to activate (and parse the resources of) the device when the driver is loaded also if the Bit 1 of _STA is not set is: 1) broken: output from comment #32 shows that the IRQ in _CRS is set to 7 and dma to 0, but the PNP layer gets it wrong and passes random numbers to the driver (in Milisav's debug case above IRQ 5 and DMA 1, when he installed it was irq 14 and dma ?). 2) wrong: ACPI Spec 3.0, chap. 6.3.7 states about _STA function: "Bit 1 Set if the device is enabled and decoding its resources." "A device can only decode its hardware resources if both bits 0 and 1 are set. If the device is not present (bit 0 cleared) or not enabled (bit 1 cleared), then the device must not decode its resources." Our special case is that Bit 1 is not set. But PNP layer will decode its resources if the driver gets loaded, that is wrong. In fact, all the PNP layer can do is decoding resources, so it must take its hands off completely. This is what my patch does. IMO, in 0xD case the driver itself can try to get the device activate by guessing its resources. PNP must tell the driver when it registers either that: - The device is disabled (also do not try to touch it yourself) - The device is enabled, use pnp info for setting it up - The device (may be) enabled, try to find the resources yourself The latter is missing. Look at parport_pc driver, there are functions like: ------------ #ifdef CONFIG_PARPORT_PC_SUPERIO detect_and_report_it87(); detect_and_report_winbond(); detect_and_report_smsc(); #endif /* Onboard SuperIO chipsets that show themselves on the PCI bus. */ count += parport_pc_init_superio(autoirq, autodma); /* PnP ports, skip detection if SuperIO already found them */ if (!count) { ------------ This order must be exchanged to do it correctly, but touching this old driver is probably not a good idea. Correctly it should first register for PNP. If the device is present, but decoding ACPI resources if forbidden then above functions should get active (maybe then it's save to remove the #ifdef from them? Hmm, probably only on Windows if one already knows from the vendor which HW to poke...). options parport_pc io= irq= This is already pre-defined in our modprobe.conf, seems there already have been a lot reports about this driver: # options parport_pc io=0x378 irq=none,none # If you have multiple parallel ports, specify them this way: # options parport_pc io=0x378,0x278 irq=none,none I prefer to go the save (and IMO cleaner) way for 11.0, that irq 14 was chosen here seem to be absolutely random. People can still activate their parport with module params. We might get some devices then not working anymore (should be really seldom, when others also return 0xD and PNP does it wrong but by luck gets the right info), working around with pnpacpi=off should still work in all cases. I'll keep this bug open a bit longer for discussion... Milisav: A short check whether installation really works for you (finds the disk) in the next Beta would be great. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.