linux-kernel - Re: [PATCH 05/24] i2c: change to new flag variable

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]

Message-ID: <20100926180726.GD8191@haskell.muteddisk.com>
Date:	Sun, 26 Sep 2010 11:07:26 -0700
From:	matt mooney <mfm@...eddisk.com>
To:	Jean Delvare <khali@...ux-fr.org>
Cc:	kernel-janitors@...r.kernel.org,
	"Ben Dooks (embedded platforms)" <ben-linux@...ff.org>,
	linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-kbuild@...r.kernel.org
Subject: Re: [PATCH 05/24] i2c: change to new flag variable

On 09:29 Sun 26 Sep     , Jean Delvare wrote:
> On Sat, 25 Sep 2010 19:12:17 -0700, matt mooney wrote:
> > On 13:26 Sat 25 Sep     , Jean Delvare wrote:
> > > On Fri, 24 Sep 2010 12:17:15 -0700, matt mooney wrote:
> > > > Replace EXTRA_CFLAGS with ccflags-y.
> > > > 
> > > > Signed-off-by: matt mooney <mfm@...eddisk.com>
> > > > ---
> > > >  drivers/i2c/Makefile        |    4 +---
> > > >  drivers/i2c/algos/Makefile  |    4 +---
> > > >  drivers/i2c/busses/Makefile |    4 +---
> > > >  drivers/i2c/muxes/Makefile  |    4 +---
> > > >  4 files changed, 4 insertions(+), 12 deletions(-)
> > > > 
> > > > diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
> > > > index c00fd66..23ac61e 100644
> > > > --- a/drivers/i2c/Makefile
> > > > +++ b/drivers/i2c/Makefile
> > > > @@ -9,6 +9,4 @@ obj-$(CONFIG_I2C_CHARDEV)	+= i2c-dev.o
> > > >  obj-$(CONFIG_I2C_MUX)		+= i2c-mux.o
> > > >  obj-y				+= algos/ busses/ muxes/
> > > >  
> > > > -ifeq ($(CONFIG_I2C_DEBUG_CORE),y)
> > > > -EXTRA_CFLAGS += -DDEBUG
> > > > -endif
> > > > +ccflags-$(CONFIG_I2C_DEBUG_CORE) := -DDEBUG
> > > > diff --git a/drivers/i2c/algos/Makefile b/drivers/i2c/algos/Makefile
> > > > index 18b3e96..215303f 100644
> > > > --- a/drivers/i2c/algos/Makefile
> > > > +++ b/drivers/i2c/algos/Makefile
> > > > @@ -6,6 +6,4 @@ obj-$(CONFIG_I2C_ALGOBIT)	+= i2c-algo-bit.o
> > > >  obj-$(CONFIG_I2C_ALGOPCF)	+= i2c-algo-pcf.o
> > > >  obj-$(CONFIG_I2C_ALGOPCA)	+= i2c-algo-pca.o
> > > >  
> > > > -ifeq ($(CONFIG_I2C_DEBUG_ALGO),y)
> > > > -EXTRA_CFLAGS += -DDEBUG
> > > > -endif
> > > > +ccflags-$(CONFIG_I2C_DEBUG_ALGO) := -DDEBUG
> > > > diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
> > > > index c3ef492..033ad41 100644
> > > > --- a/drivers/i2c/busses/Makefile
> > > > +++ b/drivers/i2c/busses/Makefile
> > > > @@ -76,6 +76,4 @@ obj-$(CONFIG_I2C_STUB)		+= i2c-stub.o
> > > >  obj-$(CONFIG_SCx200_ACB)	+= scx200_acb.o
> > > >  obj-$(CONFIG_SCx200_I2C)	+= scx200_i2c.o
> > > >  
> > > > -ifeq ($(CONFIG_I2C_DEBUG_BUS),y)
> > > > -EXTRA_CFLAGS += -DDEBUG
> > > > -endif
> > > > +ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
> > > > diff --git a/drivers/i2c/muxes/Makefile b/drivers/i2c/muxes/Makefile
> > > > index bd83b52..6f49786 100644
> > > > --- a/drivers/i2c/muxes/Makefile
> > > > +++ b/drivers/i2c/muxes/Makefile
> > > > @@ -3,6 +3,4 @@
> > > >  
> > > >  obj-$(CONFIG_I2C_MUX_PCA954x)	+= pca954x.o
> > > >  
> > > > -ifeq ($(CONFIG_I2C_DEBUG_BUS),y)
> > > > -EXTRA_CFLAGS += -DDEBUG
> > > > -endif
> > > > +ccflags-$(CONFIG_I2C_DEBUG_BUS) := -DDEBUG
> > > 
> > > If this is the way the whole kernel is going, I have no objection. 
> > 
> > Sam had implemented these newer style flag variables a while back as an
> > eloquent way of handling conditional flags. A lot of newer (and some older)
> > modules and subsystems were using them already, so to provide uniformity and for
> > an eventual removal of the deprecated flags, I converted all remaining instances
> > to the newer style. (IMHO, I think it flows better with the way the rest of the
> > build system works.)
> 
> Fine with me. What's the planned merge path for this patch? Will you
> push all the patches upstream yourself, or do you expect me to pick
> this one?

I was hoping subsystem maintainers would pick them up, but a lot of the patches
have been acked without being applied. My new plan is to have the unapplied ones
go through the kbuild tree. So you can either pick it up or just ack it.

Thanks,
mfm
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/