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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux SPI]     [Linux Kernel]     [Linux ARM (vger)]     [Linux ARM MSM]     [Linux Omap]     [Linux Arm]     [Linux Tegra]     [Fedora ARM]     [Linux for Samsung SOC]     [eCos]     [Linux Fastboot]     [Gcc Help]     [Git]     [DCCP]     [IETF Announce]     [Security]     [Linux MIPS]     [Yosemite Campsites]

  Powered by Linux