Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp964426ybi; Wed, 3 Jul 2019 07:17:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqwKKRlFte7b7rpI71+cFSpYuS0XcdI+FePFEt/S6wIGP0oThvJ0a+j04dj9A015RKfsUT0Z X-Received: by 2002:a17:902:1e6:: with SMTP id b93mr42619485plb.295.1562163454520; Wed, 03 Jul 2019 07:17:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1562163454; cv=none; d=google.com; s=arc-20160816; b=ZQRXUY5bskCRdQLhMYzr4JPsy6/0HjCYktBdxuCwfUoqhPxhJjF9dera1tYhlZzyyg A0vhAYaHVg+1uLLhLrS2OgQ67GUeD2u2hm+RIqzqzZo6124MGaYyGBz05ZSYqFLKiTI0 IJ6usB5t4D68pSPpAkWdcC71FDEVhOD73P4wLAX2xIhbFsgHRt5iFM7xUurCdOjUziql xn50jFQNgj+OGV0j1nSypEr/HOn0N+b8U3oJVXELNTNPthoMFT8TsDdtNIFJGeF2khw+ Ua/ARoANBsY+vWZBciCzMyWUH2aHqtK2Xqmrwq3chuawfuC8c95QQ1T0Tm6vPvUYJynw j17A== 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 :content-language:in-reply-to:mime-version:user-agent:date :message-id:references:cc:to:from:subject; bh=6u5ws8Id8+OIvXZj6pFHrzCH8JCrCng5PSoXUD8tCFw=; b=w2lk4M1RrR2oiUyhSIUhwXThoZs90t6nfW6E8WUkcgqfC3HIeMC81JB1igag/5qDl/ dQte13pBtBsIKTQ0QChEsy+S+tTI5ARfBvOIcmdOW9AGogB2cz8GQcK4oke8ole6QiPv 0zErts3WYxe6RPl/umJLHygapiuMB8Rg95TBz2VE0RE47Gx9XPvb8nZTiooIJhZn+Shk wXqfXDbvFLMhisEeai36m7s6e+zXTWQO2YiwaWkgn8Mjeg4X6tDbsphU3IkQtBSc8ut4 5V0TOeC4xAQetKaipFtCb05FUogUFk+ZfEJWiLuiQCGvOBjBitbuGZ1MbfndI37N5mQK 0uog== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h189si2626810pge.36.2019.07.03.07.17.18; Wed, 03 Jul 2019 07:17:34 -0700 (PDT) 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726870AbfGCOPh (ORCPT + 99 others); Wed, 3 Jul 2019 10:15:37 -0400 Received: from ns.iliad.fr ([212.27.33.1]:54618 "EHLO ns.iliad.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725830AbfGCOPh (ORCPT ); Wed, 3 Jul 2019 10:15:37 -0400 Received: from ns.iliad.fr (localhost [127.0.0.1]) by ns.iliad.fr (Postfix) with ESMTP id DDF88201DB; Wed, 3 Jul 2019 16:15:35 +0200 (CEST) Received: from [192.168.108.49] (freebox.vlq16.iliad.fr [213.36.7.13]) by ns.iliad.fr (Postfix) with ESMTP id C5B9620119; Wed, 3 Jul 2019 16:15:35 +0200 (CEST) Subject: Re: [PATCH v1] media: si2168: Refactor command setup code From: Marc Gonzalez To: =?UTF-8?Q?Jonathan_Neusch=c3=a4fer?= , Antti Palosaari , Mauro Carvalho Chehab Cc: linux-media , LKML , Bjorn Andersson , Brad Love References: <6a8f9a5b-2e88-8c26-440b-76af0d91eda6@free.fr> <20190702095109.GC22408@latitude> <6a644c94-f979-b656-472b-c7fe9303e08c@free.fr> Message-ID: <68ae0fde-ce8b-968d-853f-86eb5b1247aa@free.fr> Date: Wed, 3 Jul 2019 16:15:35 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <6a644c94-f979-b656-472b-c7fe9303e08c@free.fr> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP ; ns.iliad.fr ; Wed Jul 3 16:15:35 2019 +0200 (CEST) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/07/2019 14:47, Marc Gonzalez wrote: > Come to think of it, I'm really not a fan of "large" macro functions. > I'll outline a different option in v2. My idea is to use a trivial helper function to assign the 3 struct fields, and then a trivial macro to invoke the helper: static void cmd_setup(struct si2168_cmd *cmd, char *args, int wlen, int rlen) { memcpy(cmd->args, args, wlen); cmd->wlen = wlen; cmd->rlen = rlen; } #define CMD_SETUP(cmd, args, rlen) \ cmd_setup(cmd, args, sizeof(args) - 1, rlen) I think this way addresses all of your comments: - since we're using a real function, the compiler can perform type-checking, and the function's prototype is self-documenting. - no more funky __args and __rlen arguments - no local variables Note however, that drivers/media/tuners/si2157.c uses a different struct (struct si2157_cmd). Therefore, if we wanted to apply the same changes to si2157.c, we would have to define a common struct, and replace all the uses of struct si2157_cmd and struct si2168_cmd. That seemed too invasive to do without the maintainer's approval and guidance. Antti, do you Ack this new approach? It's not clear what HW is supported by drivers/media/dvb-frontends/si21xx.c (that's a very generic name). Regards.