Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751580AbdFFLGB (ORCPT ); Tue, 6 Jun 2017 07:06:01 -0400 Received: from mail-wr0-f180.google.com ([209.85.128.180]:34532 "EHLO mail-wr0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751393AbdFFLF6 (ORCPT ); Tue, 6 Jun 2017 07:05:58 -0400 Date: Tue, 6 Jun 2017 13:05:54 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: Andy Lutomirski Cc: Darren Hart , platform-driver-x86@vger.kernel.org, Andy Shevchenko , Andy Lutomirski , Mario Limonciello , Rafael Wysocki , "linux-kernel@vger.kernel.org" , Linux ACPI Subject: Re: [PATCH 15/16] platform/x86: wmi-mof: New driver to expose embedded WMI MOF metadata Message-ID: <20170606110554.GB4690@pali> References: <201705271314.16241@pali> <20170605221456.GA27270@fury> <201706060019.26462@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3746 Lines: 109 On Monday 05 June 2017 15:39:44 Andy Lutomirski wrote: > On Mon, Jun 5, 2017 at 3:19 PM, Pali Rohár wrote: > > On Tuesday 06 June 2017 00:14:56 Darren Hart wrote: > >> On Sat, May 27, 2017 at 01:14:15PM +0200, Pali Rohár wrote: > >> > > metadata. I think that Samba has tools to interpret it, but there > >> > > is currently no interface to get the data in the first place. > >> > > >> > No, there is no non-ms-windows tool for interpreting those binary > >> > MOF (BMF) data yet. > >> > >> Good point. Updated. > > > > You are too late :-) Now there is my at https://github.com/pali/bmfdec > > See my email "Binary MOF buffer in WMI is finally decoded!". > > > > It comes out like this on my laptop. I don't know enough about MOF to > know what we're supposed to do with this, but I suspect it at least > gives us the sizes of buffers that we should be passing to the various > methods. There are two tools bmfparse and bmf2mof. Difference is just output format. Important are WmiDataId and WmiMethodId qualifiers. Those define ids are what are passed to kernel function wmi_evaluate_method(). Ids are processed by corresponding WMxx ACPI function. So instead of wmi_evaluate_method(guid, instance, method_id, acpi_in, acpi_out); it should be possible to call: wmi_evaluate_method_name(class, name, input_params, output_params); (once somebody implement wmi_evaluate_method_name function) It is more readable in code to use class and function names instead of some guids and random meaningless numbers. Also it would allow to check size of input buffer (or types). E.g. BDat data_in; BDat data_out; // fill data_in.Bytes wmi_evaluate_method_name("BFn", "DoBFn", &data_in, &data_out); // output is in data_out.Bytes could be translated to: wmi_evaluate_method("A80593CE-A997-11DA-B012-B622A1EF5492", 0, 1, acpi_in, acpi_out); Sometimes method_id is random number and hard to guess it. One of possible solution is to trace ACPI calls on Windows, another is decode that BMOF buffer and take correct method_id. I will probably write another one tool which prints just important WMI functions and their mapping to WMI ids + input/output parameters. Without all other MOF data which are not relevant to ACPI-WMI. > class WMIEvent : __ExtrinsicEvent { > }; > > [WMI, Locale("MS\0x409"), Description("QDATA"), > guid("{ABBC0F60-8EA1-11d1-00A0-C90629100000}")] > class QDat { > [WmiDataId(1), read, write, Description("qdata")] uint8 Bytes[128]; > }; > > [WMI, Dynamic, Provider("WmiProv"), Locale("MS\0x409"), > Description("BIOS WMI Query"), > guid("{8D9DDCBC-A997-11DA-B012-B622A1EF5492}")] > class WMI_Query { > [key, read] String InstanceName; > [read] Boolean Active; > [WmiDataId(1), read, write, Description("BIOS WMI info")] QDat QDATA; > }; > > [WMI, Locale("MS\0x409"), Description("Data"), > guid("{a3776ce0-1e88-11db-a98b-0800200c9a66}")] > class BDat { > [WmiDataId(1), read, write, Description("data")] uint8 Bytes[4096]; > }; > > [WMI, Dynamic, Provider("WmiProv"), Locale("MS\0x409"), > Description("Interface"), > guid("{A80593CE-A997-11DA-B012-B622A1EF5492}")] > class BFn { > [key, read] String InstanceName; > [read] Boolean Active; > > [WmiMethodId(1), Implemented, read, write, Description("Do BFn")] > void DoBFn([in, Description("Fn buf"), ID(0)] BDat Data, [out, > Description("Fn buf"), ID(0)] BDat Data); > }; > > [WMI, Dynamic, Provider("WmiProv"), Locale("MS\0x409"), > Description("Event"), guid("{9DBB5994-A997-11DA-B012-B622A1EF5492}")] > class BIOSEvent : WmiEvent { > [key, read] String InstanceName; > [read] Boolean Active; > [WmiDataId(1), read, write, Description("Ev buf")] QDat Data; > }; -- Pali Rohár pali.rohar@gmail.com