linux-kernel - Re: [PATCH v2 2/2] iio: magnetometer: add ti tmag5273 driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20221123175639.00000ede@Huawei.com>
Date:   Wed, 23 Nov 2022 17:56:39 +0000
From:   Jonathan Cameron <Jonathan.Cameron@...wei.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
CC:     Gerald Loacker <gerald.loacker@...fvision.net>,
        <linux-iio@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        Jonathan Cameron <jic23@...nel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Nikita Yushchenko <nikita.yoush@...entembedded.com>,
        Jakob Hauser <jahau@...ketmail.com>,
        Michael Riesch <michael.riesch@...fvision.net>
Subject: Re: [PATCH v2 2/2] iio: magnetometer: add ti tmag5273 driver

On Wed, 23 Nov 2022 15:39:57 +0200
Andy Shevchenko <andriy.shevchenko@...ux.intel.com> wrote:

> On Wed, Nov 23, 2022 at 10:58:47AM +0100, Gerald Loacker wrote:
> > Am 21.11.2022 um 15:04 schrieb Andy Shevchenko:  
> > > On Mon, Nov 21, 2022 at 01:35:42PM +0100, Gerald Loacker wrote:  
> 
> ...
> 
> > >> +static const struct {
> > >> +	unsigned int scale_int;
> > >> +	unsigned int scale_micro;  
> > > 
> > > Can we have a separate patch to define this one eventually in the (one of) IIO
> > > generic headers? It's a bit pity that every new driver seems to reinvent the
> > > wheel.
> > >   
> > >> +} tmag5273_scale_table[4][2] = {
> > >> +	{ { 0, 0 }, { 0, 0 } },
> > >> +	{ { 0, 12200 }, { 0, 24400 } },
> > >> +	{ { 0, 40600 }, { 0, 81200 } },
> > >> +	{ { 0, 0 }, { 0, 0 } },
> > >> +};  
> > >   
> > 
> > I'm thinking of defining structs for all similar types of IIO output
> > formats in iio.h like this:
> > 
> > 
> > struct iio_val_int_plus_micro {
> > 	int val_int;
> > 	int val_micro;
> > };
> > 
> > struct iio_val_int_plus_nano {
> > 	int val_int;
> > 	int val_nano;
> > };
> > 
> > struct iio_val_int_plus_micro_db {
> > 	int val_int;
> > 	int val_micro_db;
> > };  
> 
> ...
> 
> > struct iio_val_fractional {
> > 	int dividend;
> > 	int divisor;
> > };  
> 
> This one...
> 
> > struct iio_val_fractional_log2 {
> > 	int dividend;
> > 	int divisor;
> > };  
> 
> ...and this one repeat struct s32_fract (or u32_fract, whatever suits better).
> 
> > Do you agree?  
> 
> Me, yes, but you need a blessing by maintainers of IIO.

I'm not 100% convinced it matters, particularly as one of the two typical
use paths has to cast them to an int * anyway (as it can take any of the
above, or a 1D array of ints).  However, if it makes drivers a little
easier to read then fair enough.  I'm not keen to see a brute force
set of patches updating existing drivers that treat them as simple array
of ints though.  Fine to convert any drivers with a local equivalent of these
structures defined.

Jonathan