From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5593CC43381 for ; Tue, 19 Mar 2019 15:00:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2EEE82146E for ; Tue, 19 Mar 2019 15:00:10 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727815AbfCSPAJ (ORCPT ); Tue, 19 Mar 2019 11:00:09 -0400 Received: from mga06.intel.com ([134.134.136.31]:41509 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726579AbfCSPAI (ORCPT ); Tue, 19 Mar 2019 11:00:08 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Mar 2019 08:00:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.58,498,1544515200"; d="scan'208";a="215528954" Received: from smile.fi.intel.com (HELO smile) ([10.237.72.86]) by orsmga001.jf.intel.com with ESMTP; 19 Mar 2019 07:59:59 -0700 Received: from andy by smile with local (Exim 4.92) (envelope-from ) id 1h6GDe-0006Gl-4O; Tue, 19 Mar 2019 16:59:58 +0200 Date: Tue, 19 Mar 2019 16:59:58 +0200 From: Andy Shevchenko To: "Life is hard, and then you die" Cc: Dmitry Torokhov , Henrik Rydberg , Lukas Wunner , Federico Lorenzi , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/2] Input: add Apple SPI keyboard and trackpad driver. Message-ID: <20190319145958.GI9224@smile.fi.intel.com> References: <20190221105609.5710-1-ronald@innovation.ch> <20190221105609.5710-3-ronald@innovation.ch> <20190226092059.GV9224@smile.fi.intel.com> <20190227072958.GA10349@innovation.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20190227072958.GA10349@innovation.ch> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 26, 2019 at 11:29:58PM -0800, Life is hard, and then you die wrote: > On Tue, Feb 26, 2019 at 11:20:59AM +0200, Andy Shevchenko wrote: > > On Thu, Feb 21, 2019 at 02:56:09AM -0800, Ronald Tschalär wrote: > > > +config KEYBOARD_APPLESPI > > > + tristate "Apple SPI keyboard and trackpad" > > > > > + depends on ACPI && SPI && EFI > > > > I would rather want to see separate line for SPI... > > > > > + depends on X86 || COMPILE_TEST > > > > ...like here > > > > depends on SPI > > Sure. Generally, what is the criteria/rule here for splitting > conjunctions into separate 'depends'? Rule of common sense. For example UEFI and ACPI may have some relations, SPI and ACPI kinda orthogonal. > > + #define DEV(applespi) (&(applespi)->spi->dev) > > > + if (memcmp(applespi->tx_status, status_ok, APPLESPI_STATUS_SIZE)) { > > > > > + dev_warn(DEV(applespi), "Error writing to device: %*ph\n", > > > > Hmm... DEV() is too generic name for custom macro. And frankly I don't think > > it's good to have in the first place. > > Yeah, I've been having trouble coming up with a better (but still > succinct) name - CORE_DEV()? RAW_DEV()? DEV_OF()? However, because > this expression is used in many places throughout the driver (mostly, > but not only, for logging statements) I feel like it's good to factor > it out. But I'll defer to your . Please remove this macro for good. Otherwise big subsystems / drivers usually do something like #define foo_err(...) dev_err(...) ... Don't know if it would help here, the driver is standalone and not so big. > > > +static void > > > +applespi_remap_fn_key(struct keyboard_protocol *keyboard_protocol) > > > +{ > > > + unsigned char tmp; > > > > > + unsigned long *modifiers = > > > + (unsigned long *)&keyboard_protocol->modifiers; > > > > I would leave it on one online despite checkpatch warning (also, instead of > > (unsigned long *) the (void *) might be used as a small trick). > > > > > + > > > + if (!fnremap || fnremap > ARRAY_SIZE(applespi_controlcodes) || > > > + !applespi_controlcodes[fnremap - 1]) > > > + return; > > > + > > > + tmp = keyboard_protocol->fn_pressed; > > > + keyboard_protocol->fn_pressed = test_bit(fnremap - 1, modifiers); > > > + if (tmp) > > > > > + __set_bit(fnremap - 1, modifiers); > > > + else > > > + __clear_bit(fnremap - 1, modifiers); > > > > Oh, this is not good. modifiers should be really unsigned long bounary, > > otherwise it is potential overflow. > > > > Best to fix is to define them as unsigned long in the first place. > > Can't do that directly, because keyboard_protocol->modifiers is a > field in the data received from the device, i.e. defined by that > protocol. Instead I could make a copy of the modifiers and pass that > around separately (i.e. in addition to the keyboard_protocol struct). > > However, the implied size assertions here would basically still apply: > > MAX_MODIFIERS == sizeof(keyboard_protocol->modifiers) * 8 > ARRAY_SIZE(applespi_controlcodes) == sizeof(keyboard_protocol->modifiers) * 8 > > (hmm, MAX_MODIFIERS is really redundant - getting rid of it...) > > Would using compiletime_assert()'s be an acceptable alternate approach > here? It would serve to both document the size constraint and to > protect against overflow due to an error in some future edit. E.g. > > applespi_remap_fn_key(struct keyboard_protocol *keyboard_protocol) > { > unsigned char tmp; > unsigned long *modifiers = (void *)&keyboard_protocol->modifiers; > + > + compiletime_assert(ARRAY_SIZE(applespi_controlcodes) == > + sizeof_field(struct keyboard_protocol, modifiers) * 8, > + "applespi_controlcodes has wrong number of entries"); > > if (!fnremap || fnremap > ARRAY_SIZE(applespi_controlcodes) || > !applespi_controlcodes[fnremap - 1]) > return; > > tmp = keyboard_protocol->fn_pressed; > keyboard_protocol->fn_pressed = test_bit(fnremap - 1, modifiers); > if (tmp) > > __set_bit(fnremap - 1, modifiers); > else > __clear_bit(fnremap - 1, modifiers); > } Perhaps, simple __set_bit(b, x) -> x |= BIT(b); __clear_bit(b, x) -> x &= ~BIT(b); ? > > > +} -- With Best Regards, Andy Shevchenko