Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3572368imu; Mon, 28 Jan 2019 07:12:06 -0800 (PST) X-Google-Smtp-Source: ALg8bN6vCUpm93jFHAPkCptcYQMDbhwStBBOc8TwQkEQLIed+lQAnr32aUX/rIkU34tp57c2XQ2C X-Received: by 2002:a62:2547:: with SMTP id l68mr21977286pfl.131.1548688326164; Mon, 28 Jan 2019 07:12:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548688326; cv=none; d=google.com; s=arc-20160816; b=YGkFMLT5toPQNWepuvYU4IAmYoHi2ad3ba2jjYPFpkxpN+S8LMtXdsrtXOPfjp2RCl zgl/ioeaabrWqcG9yozQ05rgCMq7rukaFM74XSH3ETvHtE42SuLucFcxj99KxeoBm5vp QOSjow2I/2P6V1V8Uaj/x1rUf2zCvhXRhnkhKU+UXE76YFwEk2nKoLARHaGgRmm4mMqm 51d7e5DOoh+OwiTT2VPuTumbez8UWTcfUGM/17a5qKQlIpArkHKbzbDRVKQYb3cL0IEs YGMH1lqOnBh2NEb+od2oGKIdm6/fF+dxeEu18xAMDc7tMg/6/EkEczddIrKp8ZA77J0T 8iUQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=2xWjagOlqyML6frOpUgOejqid0d67oub8mBTQKLCw/4=; b=w/k/WTZTiy8wFboEFSgYZKPKC6hpQoTVdcIpEo3C36HH3bw2MSosslVWJWgEw14446 GrBAH9yoCxq+Je7AVqO5AoiWhHysSMTxYhEsdAuUj4rDN4EqOZE0EUUUSOLK+GiBj3p2 UjeUh4xu7nPc0tRzlfpaHPWJVIfIifvXSN+O/UvXqFww6wDWT/WtjtJeWpFVJFDWZL7f EKQdX7r0zytaXa/YAfcIKPMAwtWg/eJEmD/Mqh0I3BGheqqEHGOEJKeJ1OKdGjTvRt+D EYUgTKsk1lbGr2K0ObMbfAWnHEPXJ5ybfbEilIoCBGnJsawWwLznrm2BnPoZGKjuOHbk fSoA== 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 u7si34512733pfu.270.2019.01.28.07.11.50; Mon, 28 Jan 2019 07:12:06 -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 S1726862AbfA1PKE (ORCPT + 99 others); Mon, 28 Jan 2019 10:10:04 -0500 Received: from route-level1.fsdata.se ([89.221.252.216]:59591 "EHLO route-level1.fsdata.se" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726266AbfA1PKE (ORCPT ); Mon, 28 Jan 2019 10:10:04 -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; Mon, 28 Jan 2019 16:09:25 +0100 Received: from localhost (94.234.46.36) by DAG01.HMC.local (192.168.46.11) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 28 Jan 2019 16:09:21 +0100 Date: Mon, 28 Jan 2019 16:09:14 +0100 From: Mattias Jacobsson <2pi@mok.nu> To: Pali =?utf-8?B?Um9ow6Fy?= CC: Andy Shevchenko , Masahiro Yamada , , Darren Hart , Andy Shevchenko , Platform Driver , Linux Kernel Mailing List , <2pi@mok.nu> Subject: Re: [PATCH v2 2/3] platform/x86: wmi: add WMI support to MODULE_DEVICE_TABLE() Message-ID: <20190128150909.4r3tje5l34u5t2xs@mok.nu> References: <680df320c7263bdd35f87794ae12fb9a9ef3b71c.1548610407.git.2pi@mok.nu> <20190128140911.xsltdctpk3bya7ya@mok.nu> <20190128142701.xj4vwiind4ddbcj6@pali> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190128142701.xj4vwiind4ddbcj6@pali> X-Originating-IP: [94.234.46.36] X-ClientProxiedBy: PROXY04.HMC.local (192.168.46.54) 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 On 2019-01-28, Pali Roh?r wrote: > On Monday 28 January 2019 15:09:11 Mattias Jacobsson wrote: > > Hi, > > > > On 2019-01-27, Andy Shevchenko wrote: > > > On Sun, Jan 27, 2019 at 9:04 PM Mattias Jacobsson <2pi@mok.nu> wrote: > > > > > > > > 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. > > > > > > > +/* Looks like: wmi:guid */ > > > > +static int do_wmi_entry(const char *filename, void *symval, char *alias) > > > > +{ > > > > + DEF_FIELD_ADDR(symval, wmi_device_id, guid_string); > > > > + if (strlen(*guid_string) != WMI_GUID_STRING_LEN) { > > > > + warn("Invalid WMI device id 'wmi:%s' in '%s'\n", > > > > + *guid_string, filename); > > > > + return 0; > > > > + } > > > > > > > + if (snprintf(alias, 500, WMI_MODULE_PREFIX "%s", *guid_string) < 0) { > > > > > > What the point to use snprintf here with arbitrary buffer size if we > > > exactly know 2 facts: > > > 1. UUID string is 36 characters > > > 2. buffer is long enough > > > > > > ? > > > > As long as no one changes the code, not much. > > At least instead of hardcoded number 500, you should use pass size of alias: Just a note; 500 comes from a few lines below in the do_table() function. It is the actual size of alias we get in do_wmi_entry(). > > static int do_wmi_entry(const char *filename, void *symval, char *alias, size_t alias_size) > > if (snprintf(alias, alias_size, WMI_MODULE_PREFIX "%s", *guid_string) < 0) { That is a good idea, but requires changing all other entry points. I was thinking of defining a DO_ENTRY_ALIAS_SIZE macro to replace all/any 500 in file2alias.c. However that is a separate patch. > > Or pass buffer of constant size and then you do not need to use snprintf: > > #define ALIAS_SIZE (sizeof(WMI_MODULE_PREFIX)+WMI_GUID_STRING_LEN) I could use ALIAS_SIZE and add that to snprintf() instead of 500. While I guess it is unlikely that alias ever will be changed to be too short for us, using ALIAS_SIZE doesn't "guarantee" that we are within the bounds of alias if anything changes. > > static int do_wmi_entry(const char *filename, void *symval, char alias[ALIAS_SIZE]) > > This should not break even when code around changes. > > > > > > > > + warn("Could not generate all MODULE_ALIAS's in '%s'\n", > > > > + filename); > > > > + return 0; > > > > + } > > > > + return 1; > > > > +} > > > > > > -- > > > With Best Regards, > > > Andy Shevchenko > > > > Thanks, > > Mattias > > -- > Pali Roh?r > pali.rohar@gmail.com Thanks, Mattias