Is your ioport included in the microsoft's list being blocked by XP? Please give me an example (acpidump output from a real box) that demonstrates ACPI is missing something which must be done through native driver. I'm wondering the designer of the box should already known AML code will directly access these ioport. why they needs some other native driver to access same set of ioport at same time with acpi. It sounds like obvious broken design. So my real question is the native driver is really wanted by the platform designer? As a hacker, it make senses to discover more hardware/platform features. But do these features make sense to the designer of the box. On 2/5/07, Rudolf Marek <r.marek at assembler.cz> wrote: > Hello, > > To all: > Please continue CCing me and the lm-sensors list thanks. > > Luming Yu wrote: > > Yes, that is bad to simultaneously access same hardware by ACPI and > > native drivers without coordination. But the problem is if nativer > > driver is really needed with the existence of the ACPI support for > > that device? > > Yes for example, BIOS will export though ACPI just one temperature _TMP but the > chip monitors voltages and more temps etc etc. So from the lm-sensors point of > view the answer is yes we need a full driver for hardware monitoring. > > > Do you know the features that are NOT supported by ACPI? > > Yes as I wrote above - the voltages, fan speeds, various types of alarms... > > Instead of one temperature reading, I got 9 voltage readings, 3 temps, 5 fans > etc etc > > > Probably, just writing a acpi driver for SMBus controler could solve > > this problem completely. Just my intuition. Please correct me if I'm > > wrong. > > Problem is that the device manufacturers may do what they want in ACPI bytecode. > We cannot expect them to implement smbus bus control as specified in the > specs. They just drive the registers on their own. > > What I'm trying to implement is the ACPI isolation from selected hardware > somehow, because the ACPI bytecode can contain code that modifies virtually any > hardware in the system without the clue what others drivers do. > > Even the windows don't like it: > http://www.microsoft.com/whdc/system/pnppwr/powermgmt/BIOSAML.mspx > (I/O Ports Blocked from BIOS AML) > > Please help me find the solution. > > Thanks, > Rudolf >
