To give some context to the newcomers: while helping a user with a new
hwmon chip we discovered that the native driver is loaded fine even
though the IO ports are claimed by ACPI (OperationRegion) and
acpi_enforce_resources is "strict".
On Mon, Nov 28, 2011 at 4:48 PM, Luca Tettamanti <kronos.it@xxxxxxxxx> wrote:
> On Mon, Nov 28, 2011 at 4:08 PM, Jean Delvare <khali@xxxxxxxxxxxx> wrote:
>> On Mon, 28 Nov 2011 14:02:51 +0100, Luca Tettamanti wrote:
>>> The DSDT has this:
>>>
>>> Name (IOEB, 0x0290)
>>> OperationRegion (SIOE, SystemIO, IOEB, 0x20)
>>> Field (SIOE, ByteAcc, NoLock, Preserve)
>>> {
>>> Offset (0x05),
>>> GIDX, 8,
>>> GDAT, 8
>>> }
>>>
>>> so the requested area is well within what ACPI claims.
[cut]
>> A colleague of mine (hi Thomas!) suggests that Nikolay could boot with:
>>
>> ddebug="file osl.c +p
>
> This should be:
>
> ddebug_query="file osl.c +p"
>
> It should spam the log with all the resources found by ACPI parser,
> assuming that CONFIG_DYNAMIC_DEBUG is enabled.
Hum, the call to acpi_os_validate_address was removed between 2.6.38
and 2.6.39, with this commit by Bob More:
commit 9ad19ac456a5f097f7cbbfef820b95297d6a934f
Author: Bob Moore <robert.moore@xxxxxxxxx>
Date: Mon Feb 14 16:09:40 2011 +0800
ACPICA: Split large dsopcode and dsload.c files.
which seems to be just moving code around (the culprit here is
acpi_ds_get_region_arguments). I guess that the removal wasn't
intentional since the corresponding call to acpi_os_invalidate_address
was left in place.
Bob should I put the call back in place? Am I missing something?
Luca
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
