linux-kernel - Re: [PATCH v10 08/13] regulator: bd718x7: Split driver to common and bd718x7 specific parts

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] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 20 Jan 2020 07:06:16 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     "lee.jones@...aro.org" <lee.jones@...aro.org>
CC:     "dmurphy@...com" <dmurphy@...com>,
        "linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>,
        "linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
        "mazziesaccount@...il.com" <mazziesaccount@...il.com>,
        "mturquette@...libre.com" <mturquette@...libre.com>,
        "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linus.walleij@...aro.org" <linus.walleij@...aro.org>,
        "a.zummo@...ertech.it" <a.zummo@...ertech.it>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "bgolaszewski@...libre.com" <bgolaszewski@...libre.com>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        "sboyd@...nel.org" <sboyd@...nel.org>,
        "pavel@....cz" <pavel@....cz>,
        "jacek.anaszewski@...il.com" <jacek.anaszewski@...il.com>,
        "broonie@...nel.org" <broonie@...nel.org>
Subject: Re: [PATCH v10 08/13] regulator: bd718x7: Split driver to common
 and bd718x7 specific parts

Hello,

On Fri, 2020-01-17 at 13:40 +0000, Lee Jones wrote:
> On Fri, 17 Jan 2020, Vaittinen, Matti wrote:
> > > >  
> > > > +enum {
> > > > +	ROHM_DVS_LEVEL_UNKNOWN,
> > > > +	ROHM_DVS_LEVEL_RUN,
> > > > +	ROHM_DVS_LEVEL_IDLE,
> > > > +	ROHM_DVS_LEVEL_SUSPEND,
> > > > +	ROHM_DVS_LEVEL_LPSR,
> > > > +#define ROHM_DVS_LEVEL_MAX ROHM_DVS_LEVEL_LPSR
> > > 
> > > Haven't seen this before.  Is it legit?
> > > 
> > 
> > I don't know why it wouldn't be :) I kind of grew used to that when
> > I
> > still did some networking stuff.
> 
> Networking it not a good example.
> 
> It's full of odd little quirks to the standard styling.

That was quite a strong wording... Some people might disagree :)

Anyways, as far as I know the preprocessor does not care about where
the preprocessor directives are placed. It just goes through the file
sequentially and macro definitions take effect at the place you write
them. And actual compiler does not see the directive - just code which
has been replaced. So from C point of view I see no problem here. From
coding conventions or guidelines point of view - well, that's more of
your territory ;)

> > What about:
> > >      ROHM_DVS_LEVEL_MAX = ROHM_DVS_LEVEL_LPSR
> > 
> > Anyways, I don't see why define wouldn't be Ok here - but sure it
> > can
> > be changed if you insist ;) Just let me know if you can accept the
> > define or not :)
> 
> Let's go for not in this instance. :D

Ok. I sent v11 where this has been changed as you suggested :)

Br,
	--Matti