I was referring to this peace of artwork(asus_info is pointer to DSDT header):
------------------------------------------------------------------------------
if (hotk->model == END_MODEL) { /* match failed */
if (asus_info &&
strncmp(asus_info->oem_table_id, "ODEM", 4) == 0) {
hotk->model = P30;
printk(KERN_NOTICE
" Samsung P30 detected, supported\n");
} else {
hotk->model = M2E;
printk(KERN_NOTICE " unsupported model %s, trying "
"default values\n", string);
printk(KERN_NOTICE
" send /proc/acpi/dsdt to the developers\n");
}
hotk->methods = &model_conf[hotk->model];
return AE_OK;
}
------------------------------------------------------------------------------
Thomas Renninger wrote:
> On Tue, 2006-08-01 at 21:44 +0400, Alexey Starikovskiy wrote:
>> Thomas Renninger wrote:
>>> On Tue, 2006-08-01 at 20:11 +0400, Alexey Starikovskiy wrote:
>>>> Checks for Samsung P30/P35 are real hacks IMHO.
>>> Why?
>> Because this DSDT signature could appear on any machine, and has nothing to do
>> with ASUS or Samsung.
>
> The string seems to define how the ATKD ACPI device has to be used.
> If this Device pops up on other machines than Asus it's fine.
> AFAIK the mappings from the string returned by ATKD.INIT and how the
> device has to be used then works fine.
>
> It's probably much better than the way done on Thinkpads:
> If we have ACPI func xy we assume to have an A21 or similar and use this
> set of function/variables.
>
> I consider this an ugly hack:
> IBM_HANDLE(ec, root, "\\_SB.PCI0.ISA.EC0", /* 240, 240x */
> "\\_SB.PCI.ISA.EC", /* 570 */
> "\\_SB.PCI0.ISA0.EC0", /* 600e/x, 770e, 770x */
> "\\_SB.PCI0.ISA.EC", /* A21e, A2xm/p, T20-22, X20-21 */
> "\\_SB.PCI0.AD4S.EC0", /* i1400, R30 */
> "\\_SB.PCI0.ICH3.EC0", /* R31 */
> "\\_SB.PCI0.LPC.EC", /* all others */
>
> On Asus we should be happy ATKD.INIT is returning something useful and
> one can guess (be sure?) which ACPI functions to use for what.
> Checking for that string and making use of different ACPI
> variable/method names seems to be intended and looks like the defined
> way this should be used. As long as this is not officially specified (by
> ACPI consortium and/or vendors) and such special Devices exist, it is
> the best we can do.
>
> Thomas
>
>
> -
> 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
>
-
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
