https://bugzilla.novell.com/show_bug.cgi?id=375836 User bjorn.helgaas@hp.com added comment https://bugzilla.novell.com/show_bug.cgi?id=375836#c38 --- Comment #38 from Bjorn Helgaas <bjorn.helgaas@hp.com> 2008-05-23 14:58:56 MDT --- (In reply to comment #37 from Thomas Renninger)
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 ?).
I doubt PNP is passing random numbers to the driver. We just don't understand what's happening well enough yet.
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."
This statement in the spec refers to the *hardware* behavior, not the OS behavior. If the parallel port is disabled (_STA bit 1 is cleared), the parallel port controller must not respond to any access, i.e., the hardware address decoders on the bus must be disabled.
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.
I believe this is incorrect. The language is confusing because we use "decoding" for both (1) the hardware action of recognizing and claiming a bus transaction and (2) the software action of parsing the resource descriptors.
IMO, in 0xD case the driver itself can try to get the device activate by guessing its resources.
I disagree. In an ACPI system, the driver should never have to guess at resources (though obviously there might be bugs that prevent us from realizing this ideal). I don't think the BIOS is required to enable all devices, which means that it can leave devices in the 0xD state (present, !enabled).
PNP must tell the driver when it registers either that: - The device is disabled (also do not try to touch it yourself)
_STA present == 0.
- The device is enabled, use pnp info for setting it up
_STA present == 1, enabled == 1.
- The device (may be) enabled, try to find the resources yourself The latter is missing.
ACPI is intended to remove this case.
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...).
Yep, we definitely *should* try PNP first. But many legacy drivers don't use PNP, or PNP was added later.
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: options parport_pc io= irq=
Sorry, I should have said "Linux would not be able to configure the parallel port via PNP." Of course, we can blindly poke at the device, and many drivers do that, but the intent of PNP is that this should not be necessary.
I prefer to go the save (and IMO cleaner) way for 11.0, that irq 14 was chosen here seem to be absolutely random.
I don't believe IRQ 14 is random. If Milisav looks at the "options" file for the parallel port, I'm pretty sure it will contain IRQ 14. If so, the current PNP assignment code will happily try to use it, because it doesn't know that IRQ 14 might be needed for IDE. Milisav, is there any chance you could attach the "options" file for the parport device?
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.
Having to use "pnpacpi=off" is a symptom of a defect in PNP or ACPI. Having to specify parport options on a PNPBIOS or ACPI system is also a symptom of a defect. -- 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.