Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1156798pxf; Thu, 18 Mar 2021 23:38:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJySy6ejUXqbIZidNigTtN1N07WEz8/mTrA2RHCEFHAUcoiDnlHTZ9iVLURsE4AfzrNycLHv X-Received: by 2002:a17:906:3643:: with SMTP id r3mr2531483ejb.527.1616135886327; Thu, 18 Mar 2021 23:38:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616135886; cv=none; d=google.com; s=arc-20160816; b=QUQbIjV3rCiXn/GyCVL/dB11lgOH7k+RtGzuLUoVm9ZMG4Qjdu101VHlrCY9WTQVH8 RoF0oiOf3F2SKVjAavQ7ANp9BxMbHxFWdWHDB5gxfUJrzVRPlDe+7FIxM2cYBjhi7FYH /7P2299/Wq35v4gIDNUp2IApKDbcyi97ozbxTgrlh7ULzulqZ8pRdiGQ548pnY1JasXd KwHgqmr3At3MJw2AtpOINlqODP0eHvw9DkRbzsGY9juqaYMmLBnqGjlrtmFcQsIOjHkJ cVQ8im28jgZr2RtnlRUDmEZgmAtGN8srbnzeDU+2FrmQcji3OandAIey6lPCuzbxiW4u ZFJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=q74zS7MVCJ6+mtqeFREbaTe1MM1sTAChPdcOZcYNJoc=; b=HNylihFSQbk7ARufxqZ7DMD2IbOOeXwDKPS0OCbqmVLXEJhAP4Lk9BEsJwRYLwmpNZ aNSW0nR+PvClHIFf8AlusE2qsK2il9rpPY3EKKzVM4r55bhT4HKqyyOkOX5HnsbVIvu9 YvXjfChnabXTrwPseJARRxnfI+QhsNj0MilikMhuZq0aYGYwvnkl0Jp1vat11Hq9sVr/ Ok4AS7e0QEvKnPFyCdEwEoZe6XzBglfagZqpor2vXd55zXdWF5AOlM5TqIReCPVcBsks JpA1i+ro+a9Bl77Jqb2bin2uVxyT7CCTbnyyi5SA2Be/pw+nwuaYNn4TE6Q5JYKI2grx Jwhw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=hAASVLc1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f26si3597843ejr.164.2021.03.18.23.37.44; Thu, 18 Mar 2021 23:38:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=hAASVLc1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234054AbhCSGgK (ORCPT + 99 others); Fri, 19 Mar 2021 02:36:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37852 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234060AbhCSGf6 (ORCPT ); Fri, 19 Mar 2021 02:35:58 -0400 Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C9AFFC06174A for ; Thu, 18 Mar 2021 23:35:57 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id k4so2493817plk.5 for ; Thu, 18 Mar 2021 23:35:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=q74zS7MVCJ6+mtqeFREbaTe1MM1sTAChPdcOZcYNJoc=; b=hAASVLc1qaPFBkm0SOus4f8qd39kCnEk0PbdJZ3TQPitcWEIcMlolwES9ZKoYwElP6 gyV61PlzPUTxGPh6WLqK2dxUEwap82S9tFnJmQDpiDzH6QTCDFIQeDPhIhNZ8SHBJDu6 Xo2qWse7VIxNUqT9I+JMbOvRCyI8crMEKoUgbs8Gak5y8fDjL09vgiCbAjM2ptbtEBXc vwYAEN5BGOW2d/V2l2C88P/YHD5GrR5lvfhmnpi1gFpQ1ADCfynkoJ/BRhY3JMuqEZ+7 bVSdhmx+3QBGsTOaMHcjfKBMMfmd2J6I6DpsnjMCxj4rbL+WIRFA9BPIr+yLs7Iul1Aw wEEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=q74zS7MVCJ6+mtqeFREbaTe1MM1sTAChPdcOZcYNJoc=; b=b/4ZbQA+a/hMpoWku+j9qnT3TbHLDvfoquS03uQtUzupowBUZ9pgehWzGwP/wbm/U/ A77DEgWBcHILnPcoM9G+0Hz1b2ylhNI1eldERJnVYC+TeP6MaHg/6Muowbyrbi89n759 GaqkqON0PP40O93jWD9eaNWXHmjQhkJwnqHbT5UWxmdM79opy47XNLoSYoSSl8R5XX8b o180N8ro0vl0z0MCoHot3hIqIOmuX1MMg4rc/j7qaOHHHQhtbbrY+3pfrbeGSola6Ngw A+YNCwCaYBCyb9zYeGo6YL4UuQC7OK9+4jo2lauBn6qH753nifxTsyym0C4X7FSJN0oJ Yp3A== X-Gm-Message-State: AOAM5329aueGKy9Vc/5LgpxfSh1K5Ck+iyaVFsU2s2ch5cgsdZyVJ5B6 NEqq4PDBsr16/b+tSON6W4KKlA== X-Received: by 2002:a17:90b:4a8b:: with SMTP id lp11mr8190251pjb.141.1616135757148; Thu, 18 Mar 2021 23:35:57 -0700 (PDT) Received: from localhost ([122.171.124.15]) by smtp.gmail.com with ESMTPSA id u2sm4057031pjy.14.2021.03.18.23.35.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Mar 2021 23:35:55 -0700 (PDT) Date: Fri, 19 Mar 2021 12:05:53 +0530 From: Viresh Kumar To: Jie Deng Cc: Arnd Bergmann , "Enrico Weigelt, metux IT consult" , Linux I2C , virtualization@lists.linux-foundation.org, Linux Kernel Mailing List , "Michael S. Tsirkin" , Wolfram Sang , Jason Wang , Wolfram Sang , Andy Shevchenko , conghui.chen@intel.com, kblaiech@mellanox.com, jarkko.nikula@linux.intel.com, Sergey Semin , Mike Rapoport , loic.poulain@linaro.org, Tali Perry , Uwe =?utf-8?Q?Kleine-K=C3=B6nig?= , Bjorn Andersson , yu1.wang@intel.com, shuo.a.liu@intel.com, Stefan Hajnoczi , Paolo Bonzini Subject: Re: [PATCH v8] i2c: virtio: add a virtio i2c frontend driver Message-ID: <20210319063553.eq5aorcyiame6u2e@vireshk-i7> References: <20210316074409.2afwsaeqxuwvj7bd@vireshk-i7> <0dfff1ac-50bb-b5bc-72ea-880fd52ed60d@metux.net> <20210319035435.a4reve77hnvjdzwk@vireshk-i7> <20210319054035.47tn747lkagpip6v@vireshk-i7> <834186be-71b1-a67c-8dee-b90527b459c8@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <834186be-71b1-a67c-8dee-b90527b459c8@intel.com> User-Agent: NeoMutt/20180716-391-311a52 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 19-03-21, 14:29, Jie Deng wrote: > I also see example drivers/i2c/busses/i2c-xiic.c. Some people might think > this way is more clearer than > > updating each member in probe. Basically, I think it's just a matter of > personal preference which doesn't Memory used by one instance of struct i2c_adapter (on arm64): struct i2c_adapter { struct module * owner; /* 0 8 */ unsigned int class; /* 8 4 */ /* XXX 4 bytes hole, try to pack */ const struct i2c_algorithm * algo; /* 16 8 */ void * algo_data; /* 24 8 */ const struct i2c_lock_operations * lock_ops; /* 32 8 */ struct rt_mutex bus_lock; /* 40 32 */ /* --- cacheline 1 boundary (64 bytes) was 8 bytes ago --- */ struct rt_mutex mux_lock; /* 72 32 */ int timeout; /* 104 4 */ int retries; /* 108 4 */ struct device dev; /* 112 744 */ /* XXX last struct has 7 bytes of padding */ /* --- cacheline 13 boundary (832 bytes) was 24 bytes ago --- */ long unsigned int locked_flags; /* 856 8 */ int nr; /* 864 4 */ char name[48]; /* 868 48 */ /* XXX 4 bytes hole, try to pack */ /* --- cacheline 14 boundary (896 bytes) was 24 bytes ago --- */ struct completion dev_released; /* 920 32 */ struct mutex userspace_clients_lock; /* 952 32 */ /* --- cacheline 15 boundary (960 bytes) was 24 bytes ago --- */ struct list_head userspace_clients; /* 984 16 */ struct i2c_bus_recovery_info * bus_recovery_info; /* 1000 8 */ const struct i2c_adapter_quirks * quirks; /* 1008 8 */ struct irq_domain * host_notify_domain; /* 1016 8 */ /* --- cacheline 16 boundary (1024 bytes) --- */ /* size: 1024, cachelines: 16, members: 19 */ /* sum members: 1016, holes: 2, sum holes: 8 */ /* paddings: 1, sum paddings: 7 */ }; So, this extra instance that i2c-xiic.c is creating (and that you want to create) is going to waste 1KB of memory and it will never be used. This is bad coding practice IMHO and it is not really about personal preference. -- viresh