Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 28 Nov 2022 15:27:54 +0200
From:   Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To:     Gerald Loacker <gerald.loacker@wolfvision.net>
Cc:     linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org, Jonathan Cameron <jic23@kernel.org>,
        Lars-Peter Clausen <lars@metafoo.de>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Jakob Hauser <jahau@rocketmail.com>,
        Linus Walleij <linus.walleij@linaro.org>,
        Nikita Yushchenko <nikita.yoush@cogentembedded.com>,
        Michael Riesch <michael.riesch@wolfvision.net>
Subject: Re: [PATCH v3 1/3] iio: add struct declarations for iio types
Message-ID: <Y4S3WnYWVnmiVFc+@smile.fi.intel.com>
References: <20221125083526.2422900-1-gerald.loacker@wolfvision.net>
 <20221125083526.2422900-2-gerald.loacker@wolfvision.net>
 <Y4CcspD1xkmhmWbh@smile.fi.intel.com>
 <Y4CgiMd4XQMV4KFV@smile.fi.intel.com>
 <a55e73f7-4daf-6892-34dc-61c6f6581d8e@wolfvision.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a55e73f7-4daf-6892-34dc-61c6f6581d8e@wolfvision.net>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Precedence: bulk

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