Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp3929310imj; Tue, 19 Feb 2019 12:01:33 -0800 (PST) X-Google-Smtp-Source: AHgI3Ibh9zdwtyhprw1oKRSvlz1bruixXBKc82pjkdqfmNejf0iUyOwzImQ9Vk3LQ/hWm4XvowVL X-Received: by 2002:a63:2706:: with SMTP id n6mr24841474pgn.352.1550606493717; Tue, 19 Feb 2019 12:01:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550606493; cv=none; d=google.com; s=arc-20160816; b=oAheoaTKywwL8xAdAkbOUJi0Dw409RdIjwdltqj6UamJDAfJJXZahte7wZ2wQ4MRcO ND89XaDLB9MayjpHV7yxc9JXhecJ/9eBZ6ZCnATwmqZfwLLTED7L0W1keWZjIrvyqYU3 s/FE/POglN0iYpZUcobUvzfXfevJruAFzjrfY9TAq5LjOrPAXlbTzWyLCWSBWrK+0r6h qP6xYGrg+ffHLLHudJZff/zYf9vDQz97TBF3zrmW9a/8iHXdDIux17sxx0D5GGpVSKGS tRwdCZAI/HHTia6UfDKE/2lLavr7wXKtOH+aDpxOnJKzAFkkhnoisxl8yJm1vwGD1JOh 067Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=zJdu6L9EVycn7W0duq6scSLZl3XVzQGwz76jH9twK8w=; b=qR+IHfrEpIph/oqWkwiQTw+/Iy2qZNS3knJMGufap7NnOZXkYMu7b/O4e5obfyqC+C ESO9kEktl5nQBh1YvbKetpu4L7K2MCFfZH1xl98FaE5V2/edk9efXNuGNdOtMLrJ62Ky mzNMDiIU9S7/Qi9GxXQdWIxRlXxqq2rqL4QsmR1xFuvRrBHy9cMf0DhzdOe/F4F9IBZu jBTFg2VnqS2ak7FYLP+NtW7Lh0Z63eXZ4tZAKDL2Su7MnKKvFZtzKqnP5PyCwZeXcM8U FMJn7vGUM7B/WqVUUr7hiFWtm/F4opRk+UuV+yPUwxEP1TXt9bbho7eWjgNEdatllvQa aMzA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mok.nu Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x129si1948550pgx.253.2019.02.19.12.01.18; Tue, 19 Feb 2019 12:01:33 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mok.nu Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729578AbfBSUAi (ORCPT + 99 others); Tue, 19 Feb 2019 15:00:38 -0500 Received: from route-level1.fsdata.se ([89.221.252.216]:49358 "EHLO route-level1.fsdata.se" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727766AbfBSUAi (ORCPT ); Tue, 19 Feb 2019 15:00:38 -0500 Received: from DAG01.HMC.local (192.168.46.11) by EDGE01LEVEL1.hmc.local (192.168.46.33) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 19 Feb 2019 21:00:06 +0100 Received: from localhost (94.234.42.81) by DAG01.HMC.local (192.168.46.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Feb 2019 21:00:11 +0100 From: Mattias Jacobsson <2pi@mok.nu> To: , , , , CC: <2pi@mok.nu>, , Subject: [PATCH v4 2/8] platform/x86: wmi: add WMI support to MODULE_DEVICE_TABLE() Date: Tue, 19 Feb 2019 20:59:50 +0100 Message-ID: <082d3d38b7dde6050b6b3e518ada439eade65b2c.1550603967.git.2pi@mok.nu> X-Mailer: git-send-email 2.20.1 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [94.234.42.81] X-ClientProxiedBy: PROXY05.HMC.local (192.168.46.55) To DAG01.HMC.local (192.168.46.11) Received-SPF: Neutral (EDGE01LEVEL1.hmc.local: 192.168.46.11 is neither permitted nor denied by domain of 2pi@mok.nu) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The kernel provides the macro MODULE_DEVICE_TABLE() where driver authors can specify their device type and their array of device_ids and thereby trigger the generation of the appropriate MODULE_ALIAS() output. This is opposed to having to specify one MODULE_ALIAS() for each device. The WMI device type is currently not supported. While using MODULE_DEVICE_TABLE() does increase the complexity as well as spreading out the implementation across the kernel, it does come with some benefits too; * It makes different drivers look more similar; if you can specify the array of device_ids any device type specific input to MODULE_ALIAS() will automatically be generated for you. * It helps each driver avoid keeping multiple versions of the same information in sync. That is, both the array of device_ids and the potential multitude of MODULE_ALIAS()'s. Add WMI support to MODULE_DEVICE_TABLE() by adding info about struct wmi_device_id in devicetable-offsets.c and add a WMI entry point in file2alias.c. The type argument for MODULE_DEVICE_TABLE(type, name) is wmi. Suggested-by: Pali Rohár Signed-off-by: Mattias Jacobsson <2pi@mok.nu> --- What do you think about writing it this way now, pretty much the same as before, but now using the macro ALIAS_SIZE instead of a hardcoded value? Also, as I mentioned before, I've submitted the ALIAS_SIZE patch and have recieved a question on which tree the patch should be go through. See the original question on [1]. I don't mind either way, do you have a preference on this? [1]: https://lore.kernel.org/lkml/CAK7LNAQZ7PDZ4+uZu-FT4V8yw9oUGz6e++9xSshWJvALj3gN0Q@mail.gmail.com -- scripts/mod/devicetable-offsets.c | 3 +++ scripts/mod/file2alias.c | 23 +++++++++++++++++++++++ 2 files changed, 26 insertions(+) diff --git a/scripts/mod/devicetable-offsets.c b/scripts/mod/devicetable-offsets.c index 293004499b4d..99276a422e77 100644 --- a/scripts/mod/devicetable-offsets.c +++ b/scripts/mod/devicetable-offsets.c @@ -225,5 +225,8 @@ int main(void) DEVID_FIELD(typec_device_id, svid); DEVID_FIELD(typec_device_id, mode); + DEVID(wmi_device_id); + DEVID_FIELD(wmi_device_id, guid_string); + return 0; } diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c index afe22af20d7d..6dedc31a4925 100644 --- a/scripts/mod/file2alias.c +++ b/scripts/mod/file2alias.c @@ -37,6 +37,7 @@ typedef unsigned char __u8; typedef struct { __u8 b[16]; } uuid_le; +#define UUID_STRING_LEN 36 /* Big exception to the "don't include kernel headers into userspace, which * even potentially has different endianness and word sizes, since @@ -1290,6 +1291,27 @@ static int do_typec_entry(const char *filename, void *symval, char *alias) return 1; } +/* Looks like: wmi:guid */ +static int do_wmi_entry(const char *filename, void *symval, char *alias) +{ + int len; + DEF_FIELD_ADDR(symval, wmi_device_id, guid_string); + + if (strlen(*guid_string) != UUID_STRING_LEN) { + warn("Invalid WMI device id 'wmi:%s' in '%s'\n", + *guid_string, filename); + return 0; + } + + len = snprintf(alias, ALIAS_SIZE, WMI_MODULE_PREFIX "%s", *guid_string); + if (len < 0 || len >= ALIAS_SIZE) { + warn("Could not generate all MODULE_ALIAS's in '%s'\n", + filename); + return 0; + } + return 1; +} + /* Does namelen bytes of name exactly match the symbol? */ static bool sym_is(const char *name, unsigned namelen, const char *symbol) { @@ -1360,6 +1382,7 @@ static const struct devtable devtable[] = { {"fslmc", SIZE_fsl_mc_device_id, do_fsl_mc_entry}, {"tbsvc", SIZE_tb_service_id, do_tbsvc_entry}, {"typec", SIZE_typec_device_id, do_typec_entry}, + {"wmi", SIZE_wmi_device_id, do_wmi_entry}, }; /* Create MODULE_ALIAS() statements. -- 2.20.1