tp_smapi conflict with IDE, hdaps

[Shem Multinymous]

Hi,

I'm developing a new kernel module, tp_smapi, for providing access to
special features of ThinkPad laptops via a sysfs interface. See [1]
for details and [2] for the GPL sourcecode.

This module conflicts with two other systems, due to use of common IO resource.

Conflict with IDE system:
One of the functions provided by tp_smapi is setting the CD-ROM
speed+spindown ("hdparm -E" and "eject -x" have no effect on these
laptops). This is achieved by sending an appropriate command to the
laptop's SMAPI BIOS, whose implementation is totally opaque [3].
Evidently, the SMAPI BIOS sends some ATA command to the drive. If the
kernel is accessing the drive at the same time (e.g., an ongoing "cat
/dev/scd0"), the machine hangs. The ideal solution would be to figure
out the relevant ATA commands and add them to libata/ata_piix/ide, but
it's not clear how to do that. So tp_smapi needs to obtain some lock
guaranteeing there is no access (or ongoing transaction) to that ATA
device.

Conflict with the "hdaps" module:
Another function provided by tp_smapi is reporting extended battery
status, including some data not provided through ACPI. This conflict
with the recently added HDAPS accelerometer driver. Both drivers read
their data from the same ports (0x1604-0x161F), which implement a
query-reponse transaction interface, so both drivers talking to the
hardware simultaneously will wreak havoc. Some synchronization is
needed, and a way to address the request_region conflict.

What is standard procedure for resolving such conflicts?

  Shem

[1] http://thinkwiki.org/wiki/SMAPI_support_for_Linux
[2] Current: http://tpctl.sourceforge.net/rel/tp_smapi-0.09.tgz
    Future: http://sf.net/project/showfiles.php?group_id=1212&package_id=171579
[3] The SMAPI BIOS runs in SMM and thus cannot be debugged by mere mortals.
     See tp_smapi's README for known details:
    http://sourceforge.net/project/shownotes.php?release_id=377806&group_id=1212
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/