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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1C146C433FE for ; Mon, 28 Nov 2022 13:28:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231756AbiK1N2F (ORCPT ); Mon, 28 Nov 2022 08:28:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54092 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230247AbiK1N2B (ORCPT ); Mon, 28 Nov 2022 08:28:01 -0500 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BC81B11C25; Mon, 28 Nov 2022 05:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669642080; x=1701178080; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=LVHrI4pHYy1NGHezAZoCXCIhn6PYcGb7Y9h61CR31MQ=; b=Kcn4rj1FFM2Hj32tND/uFs8XDARrQ89jfwgC2fKy1dEFAwosd/4UvXrA 0dxBy78YRafCZMCfFyKwHrkCvDa78y5SPNjYqkaWXmpbapRNDN79o5BTF b2cj9REs7iA50k4aiQNfeXr2Qr/CWDDD+eqtuiH9NOkR99CXMP9RlzPiC hSZ8imIuTqG+BLAlcybR9Lha6dfWvQHCyKsUTUPluIbJ//66SlCZWDI/P NTc9l6/jQ0C4qwHUK6BZMU/Z3NAnXOvY44x4s/MqxSpvkR8HQUDxz06pG EzMvgNyfJdesfwv71/KGAf/n+kJr3Yc2noDLPG1z2wRsHCgn0nkbIu0BB A==; X-IronPort-AV: E=McAfee;i="6500,9779,10545"; a="314866215" X-IronPort-AV: E=Sophos;i="5.96,200,1665471600"; d="scan'208";a="314866215" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Nov 2022 05:28:00 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6500,9779,10545"; a="768040124" X-IronPort-AV: E=Sophos;i="5.96,200,1665471600"; d="scan'208";a="768040124" Received: from smile.fi.intel.com ([10.237.72.54]) by orsmga004.jf.intel.com with ESMTP; 28 Nov 2022 05:27:56 -0800 Received: from andy by smile.fi.intel.com with local (Exim 4.96) (envelope-from ) id 1ozeAs-0019SR-1w; Mon, 28 Nov 2022 15:27:54 +0200 Date: Mon, 28 Nov 2022 15:27:54 +0200 From: Andy Shevchenko To: Gerald Loacker Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Jonathan Cameron , Lars-Peter Clausen , Rob Herring , Krzysztof Kozlowski , Jakob Hauser , Linus Walleij , Nikita Yushchenko , Michael Riesch Subject: Re: [PATCH v3 1/3] iio: add struct declarations for iio types Message-ID: References: <20221125083526.2422900-1-gerald.loacker@wolfvision.net> <20221125083526.2422900-2-gerald.loacker@wolfvision.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 28, 2022 at 01:18:04PM +0100, Gerald Loacker wrote: > Am 25.11.2022 um 12:01 schrieb Andy Shevchenko: > > On Fri, Nov 25, 2022 at 12:45:06PM +0200, Andy Shevchenko wrote: > >> On Fri, Nov 25, 2022 at 09:35:24AM +0100, Gerald Loacker wrote: ... > >>> +struct iio_val_int_plus_micro { > >>> + int val_int; > >>> + int val_micro; > >>> +}; > > > > Thinking more about naming, why not drop val_ completely? > > > > int integer; > > int micro; > > > > ? > > Yes, this sounds good to me. I think of adding only > > typedef struct { > int integer; > int micro; > } iio_val_int_plus_micro; > > for now, and one can add similar structures when needed, like > > typedef struct { > int integer; > int nano; > } iio_val_int_plus_nano; It's a rule to use _t for typedef:s in the kernel. That's why I suggested to leave struct definition and only typedef the same structures (existing) to new names (if needed). > or > typedef iio_val_int_plus_micro iio_val_int_plus_micro_db; This is better as explained above. > If you think it's better to add them all, I can do that, of course. > > >>> +struct iio_val_int_plus_nano { > >>> + int val_int; > >>> + int val_nano; > >>> +}; > >>> + > >>> +struct iio_val_int_plus_micro_db { > >>> + int val_int; > >> > >> int val_int_db; ? > >> > >>> + int val_micro_db; > >>> +}; > >> > >> Actually why can't we simply do > >> > >> typedef iio_val_int_plus_micro_db iio_val_int_plus_micro; > >> > >> ? -- With Best Regards, Andy Shevchenko