From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753889AbcBVI4z (ORCPT ); Mon, 22 Feb 2016 03:56:55 -0500 Received: from mail-lb0-f178.google.com ([209.85.217.178]:35983 "EHLO mail-lb0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753375AbcBVI4y (ORCPT ); Mon, 22 Feb 2016 03:56:54 -0500 Date: Mon, 22 Feb 2016 09:56:50 +0100 From: =?utf-8?B?TWljaGHFgiBLxJlwaWXFhA==?= To: Darren Hart Cc: Matthew Garrett , Pali =?utf-8?B?Um9ow6Fy?= , Darek Stojaczyk , platform-driver-x86@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 3/5] dell-wmi: enable receiving WMI events on Dell Vostro V131 Message-ID: <20160222085650.GA8322@eudyptula.hq.kempniu.pl> References: <20160121090401.GR7192@pali> <1455634230-1487-1-git-send-email-kernel@kempniu.pl> <1455634230-1487-4-git-send-email-kernel@kempniu.pl> <20160220012457.GC23707@dvhart-mobl5.amr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160220012457.GC23707@dvhart-mobl5.amr.corp.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > > /* > > * Certain keys are flagged as KE_IGNORE. All of these are either > > * notifications (rather than requests for change) or are also sent > > @@ -513,6 +533,7 @@ static int __init dell_wmi_init(void) > > { > > int err; > > acpi_status status; > > + struct calling_interface_buffer *buffer; > > Please place the longest line first, and move int err to the last declaration. > When changing declarations of local variables, please use "Reverse Christmas > Tree" order (longest line to shortest line) wherever possible. Thanks, I'll keep that in mind for the future, though putting the WMI-enabling SMBIOS request in a separate function renders the need for the buffer variable in dell_wmi_init() void, so v4 won't touch this area any more. > Pali's point about documenting the hardcoded values and eliminating the code > duplication with a function (inline) is a good one. I plan to only put a comment next to 0x51534554 as 0x10000 is apparently just something pulled out of a hat (as the link provided in the commit message proves) and input[3] should be self-explanatory due to the name of the variable whose value is put into it. By the way, is there any kernel-wide or subsystem-wide policy for marking a function inline? I mean, this is hardly time-critical code, so is your suggestion to make it inline just a preference or am I unaware of some rule? > Otherwise, this series looks good to me. Looking forward to merging v4. I'll try to post a v4 within the next couple of days. -- Best regards, Michał Kępień