From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alexey Starikovskiy Subject: Re: [PATCH] Repost: asus strict model checking Date: Wed, 02 Aug 2006 22:49:11 +0400 Message-ID: <44D0F3A7.4020405@linux.intel.com> References: <1154438122.4302.354.camel@queen.suse.de> <44CF5DF6.9090603@linux.intel.com> <1154446149.4302.386.camel@queen.suse.de> <44CF7D26.5050208@linux.intel.com> <1154452931.4302.407.camel@queen.suse.de> <44CF92EB.4010801@linux.intel.com> <1154512820.4302.444.camel@queen.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from mga05.intel.com ([192.55.52.89]:28933 "EHLO fmsmga101.fm.intel.com") by vger.kernel.org with ESMTP id S932146AbWHBStS (ORCPT ); Wed, 2 Aug 2006 14:49:18 -0400 In-Reply-To: <1154512820.4302.444.camel@queen.suse.de> Sender: linux-acpi-owner@vger.kernel.org List-Id: linux-acpi@vger.kernel.org To: trenn@suse.de Cc: linux-acpi@vger.kernel.org, "Brown, Len" , acpi4asus-user@lists.sourceforge.net 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >