IO port resource conflict

[Will Mansell]

I am writing a device driver for an IT871F on POSReady. The idea is to track
voltages and temperatures.
The INF file contains the correct IO port.

[dogwatch_Device.NT]
CopyFiles=dogwatch_Device.NT.Copy
LogConfig=PortIO.LC0

[PortIO.LC0]
ConfigPriority=HARDRECONFIG
IOConfig=A10-A1F

Unfortunately this generates a resource conflict with motherboard resources.
Disabling the motherboard resources in device manager doesn't resolve the
conflict.
In similar drivers such as GiveIO undocumented kernel calls such as
ke386SetIoAccessMap are used to access this IO range and testing shows that
this method works. I don't want to use this in my driver since the call may
be non-existent in future versions of windows and I don't want to give io
access to anything in user space.
The other option is to use the smbus/I2c but then there would be
synchronization issues.
What is the correct way to address this IO space and how do I resolve the
conflict.

Thanks

Will

[Scott Noone]

Post by Will Mansell
Unfortunately this generates a resource conflict with motherboard resources.

There's already a device out there claiming the resources, so you can't just
poof up another device with the same requirements list. You'd need to load
your driver over the existing device and not create a new one.

But, you have a bigger problem: you don't own those resources and you don't
know who is talking to them. There's no way to serialize access to the
resources, so in the middle of communicating with the ports you might get
hit with an SMI and the BIOS will start partying on the registers. As you
can imagine, this can lead to unexpected results.

-scott
--
Scott Noone
Consulting Associate
OSR Open Systems Resources, Inc.
http://www.osronline.com

Post by Will Mansell
I am writing a device driver for an IT871F on POSReady. The idea is to track
voltages and temperatures.
The INF file contains the correct IO port.
[dogwatch_Device.NT]
CopyFiles=dogwatch_Device.NT.Copy
LogConfig=PortIO.LC0
[PortIO.LC0]
ConfigPriority=HARDRECONFIG
IOConfig=A10-A1F
Unfortunately this generates a resource conflict with motherboard resources.
Disabling the motherboard resources in device manager doesn't resolve the
conflict.
In similar drivers such as GiveIO undocumented kernel calls such as
ke386SetIoAccessMap are used to access this IO range and testing shows that
this method works. I don't want to use this in my driver since the call may
be non-existent in future versions of windows and I don't want to give io
access to anything in user space.
The other option is to use the smbus/I2c but then there would be
synchronization issues.
What is the correct way to address this IO space and how do I resolve the
conflict.
Thanks
Will

[Maxim S. Shatskih]

Post by Will Mansell
Unfortunately this generates a resource conflict with motherboard resources.

Once some time long ago (in w2k timeframe or such), the Windows architects - probably with a joint effort with the ACPI spec authors - decided to ban accessing the IO ports listed in the ACPI table as "motherboard resources".

The goal was to only allow ACPI BIOS to do this, and not anyone else.

For me, this idea failed miserably, since 100% of CPU temperature/voltage/fan speed monitoring products _use some hacks to bypass the recommended ways (where the recommended ways is to support this in ACPI table and expose to WMI)_.
The community of MS + BIOS vendors just plain failed to impose the standard way of doing this.

The cleanest among these hacks is what Asus does. It provides the root-enumerated pseudo-device of ATK0110 in their ACPI table, and some AsAcpi.sys driver for it, to be installed.

Then, when you have AsAcpi in the kernel, their tools like AsusProbe do work - by sending IOCTLs to AsAcpi, which calls ACPI methods or touches IO ports.

Post by Will Mansell
The other option is to use the smbus/I2c but then there would be
synchronization issues.

This can also be a good idea.

So, the ideas in the order or decreasing "implementation cleanness":

a) if you have control over BIOS and its ACPI tables - write ACPI methods to implement the temp/voltage/fan sensors, the methods must touch these IO ports. Then access the values via WMI - even VBScript will be OK.
b) write a driver, in it, invoke an ACPI method call from the ACPI BIOS to do the job
c) write a driver, in it, just stupidly access the hardcoded IO ports without ever arbitrating them by means of PnP
d) reset the IO permission bitmap and do the same as c) does, but from user mode.

[Will Mansell]

Thanks for both your replies.

For those in a similar situation there are some great bios mod tools and
tutorials.
Google "rebels haven bios".