linux-kernel - Re: [PATCH v8 5/8] iio: adc: adi-axi-adc: add support for AXI ADC IP core

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Sun, 15 Mar 2020 09:23:24 +0000
From:   Jonathan Cameron <jic23@...nel.org>
To:     "Ardelean, Alexandru" <alexandru.Ardelean@...log.com>
Cc:     "Hennerich, Michael" <Michael.Hennerich@...log.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "lars@...afoo.de" <lars@...afoo.de>
Subject: Re: [PATCH v8 5/8] iio: adc: adi-axi-adc: add support for AXI ADC
 IP core

...

> > > > +#define REG_RSTN				0x0040  
> > > 
> > > Usual stuff: These should be prefixed with driver relevant prefix
> > > maybe ADI_AXI_  
> > 
> > my only concern [about the prefix] is that it makes the macro-names too long;
> > after re-looking at these reg definitions, what bothered me is that some of
> > the
> > bit-field-names collide; so i went with concatenanting reg-names + reg-
> > bitnames, 
> > which made them look too long [so i removed the prefix]
> > 
> > there's also the possibility of going back to the regmap-doc and shortening
> > these reg-name/bitnames;
> > but they've been like this for a while, and i admit going to the HDL team
> > makes
> > me sometimes lazy;
> > 
> > i'll re-add teh ADI_AXI prefix; and will see how these look  
> 
> i talked to HDL
> so, we'll have a round of renaming these [in the docs];
> 
> but now, i'm wondering if it's ok to drop the regs that are [currently] unused
> and add them when functionality gets later-added;

Absolutely.  Its in theory better to always do that, but sometimes it's
just easier to copy type the whole datasheet register map into a driver
so we tend to let it go.

> in the meantime, the names can be re-worked/shortened/prettify-ed;
> we'll also need to re-do an inventory of the current HDL IP cores and see how
> the regmaps hold-up/match against the docs;

I'd not worry too much on shortening these.  A bit of ugly code never
really hurt anyone if it's just a long define.

Of course, if it makes sense anyway, always good to tidy up naming.

Jonathan