Patchwork [U-Boot,v9,15/30] autoconfig.mk: Make it possible to define configs from other configs

login
register
mail settings
Submitter Benoît Thébaudeau
Date March 6, 2013, 6:59 p.m.
Message ID <1362596377-5827-15-git-send-email-benoit.thebaudeau@advansee.com>
Download mbox | patch
Permalink /patch/225592/
State Changes Requested
Delegated to: Albert ARIBAUD
Headers show

Comments

Benoît Thébaudeau - March 6, 2013, 6:59 p.m.
Give more flexibility to define configs that can be interpreted by make, e.g. to
define fallback values of configs like in the example below.

Before this change, the config lines:
 #define CONFIG_SPL_MAX_SIZE	2048
 #define CONFIG_SPL_PAD_TO	CONFIG_SPL_MAX_SIZE
would have been changed in autoconfig.mk into:
 CONFIG_SPL_MAX_SIZE=2048
 CONFIG_SPL_PAD_TO="CONFIG_SPL_MAX_SIZE"

Hence, a make recipe using as an argument to $(OBJCOPY):
 --pad-to=$(CONFIG_SPL_PAD_TO)
would have issued:
 --pad-to="CONFIG_SPL_MAX_SIZE"
which means nothing for $(OBJCOPY) and makes it fail.

Thanks to this change, the config lines above are changed in autoconfig.mk into:
 CONFIG_SPL_MAX_SIZE=2048
 CONFIG_SPL_PAD_TO=$(CONFIG_SPL_MAX_SIZE)

Hence, the make recipe above now issues:
 --pad-to=2048
as expected from the defined config.

Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>
---
Changes in v9:
 - Add detailed patch description.

Changes in v8:
 - New patch.

Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2: None

 tools/scripts/define2mk.sed |    2 ++
 1 file changed, 2 insertions(+)
Tom Rini - March 6, 2013, 9:06 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/06/2013 01:59 PM, Benoît Thébaudeau wrote:
> Give more flexibility to define configs that can be interpreted by
> make, e.g. to define fallback values of configs like in the example
> below.
> 
> Before this change, the config lines: #define CONFIG_SPL_MAX_SIZE
> 2048 #define CONFIG_SPL_PAD_TO	CONFIG_SPL_MAX_SIZE would have been
> changed in autoconfig.mk into: CONFIG_SPL_MAX_SIZE=2048 
> CONFIG_SPL_PAD_TO="CONFIG_SPL_MAX_SIZE"
> 
> Hence, a make recipe using as an argument to $(OBJCOPY): 
> --pad-to=$(CONFIG_SPL_PAD_TO) would have issued: 
> --pad-to="CONFIG_SPL_MAX_SIZE" which means nothing for $(OBJCOPY)
> and makes it fail.
> 
> Thanks to this change, the config lines above are changed in
> autoconfig.mk into: CONFIG_SPL_MAX_SIZE=2048 
> CONFIG_SPL_PAD_TO=$(CONFIG_SPL_MAX_SIZE)
> 
> Hence, the make recipe above now issues: --pad-to=2048 as expected
> from the defined config.
> 
> Signed-off-by: Benoît Thébaudeau <benoit.thebaudeau@advansee.com>

Reviewed-by: Tom Rini <trini@ti.com>

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRN6/MAAoJENk4IS6UOR1WACkQAJAPi/TwObDQvj+cUTlnkgju
51jVn9fgqENaTmDLtiq0yQrj50iIhCjHHJ9Bv6HK6lWjCDK9tjGStYoZsk6TH0Tp
M5rhRIUjEZBaceubShP9f9219xmtYVeIt/nC2E9w5QKAx3MHE3KpOMHw+pH3AC6g
Bayvt5+TlTrwRlxhUuANB9f5DOyF0FFpKzijWhF9iUzNp4S7hl+QqZpbh2qGSxVd
UgZmm43MTvPmhCf7JKjrYXCE/OLTW6poSkaLLEOUMhufipQ1JXAQkltFewmk2jDE
lBmQ16Kcwo68J9PMWLpGzpvAdCh2qkGCPPxr2zlwlpw2mSNLZTfKqguoX2BTvnZY
NJYQPOSZmBVhoF1+G6CJQE+8ukY4UxyBeG+gD2OPOL25oE4FSWLbMVWkx/slhIWt
ujcaW3pw0hGG/CjmQyO1O36raFZfFOkb3mGYwl5xH7cKnXPOMQcYGZ77JWbyyQRV
MTaeh9deyszgzecAJ5D6ZnqB7G6XvDKzcphZF3xPHuOMhKKn+03VHHz0vWS0GLT1
cEEymvSCtjID2fl7iRNp/WZ+EYS7EUb/9M9T8iaJ79wQHe6V0xikz62YbMe8NE6+
7DHuz8N00FdgFEGvtZFW33oXUpVEduTQbwCJwOVSo+tfJ60v48xdsVTvTbUM4QAo
Vf3gCKoyudLJtD67ffZs
=n8jq
-----END PGP SIGNATURE-----
Wolfgang Denk - March 7, 2013, 6:57 a.m.
Dear Benoît Thébaudeau,

In message <1362596377-5827-15-git-send-email-benoit.thebaudeau@advansee.com> you wrote:
>
> +	# ... and from configs defined from other configs
> +	s/="\(CONFIG_[A-Za-z0-9_][A-Za-z0-9_]*\)"/=$(\1)/;

Should we not remove the lower case letters here?  Such are not
supposed to be used in macro names.

Best regards,

Wolfgang Denk
Benoît Thébaudeau - March 7, 2013, 11:38 a.m.
Dear Wolfgang Denk,

On Thursday, March 7, 2013 7:57:13 AM, Wolfgang Denk wrote:
> Dear Benoît Thébaudeau,
> 
> In message <1362596377-5827-15-git-send-email-benoit.thebaudeau@advansee.com>
> you wrote:
> >
> > +	# ... and from configs defined from other configs
> > +	s/="\(CONFIG_[A-Za-z0-9_][A-Za-z0-9_]*\)"/=$(\1)/;
> 
> Should we not remove the lower case letters here?  Such are not
> supposed to be used in macro names.

I don't think so. They're indeed not supposed to be used, but there are perhaps
exceptions somewhere, and it's not the purpose of this script to enforce such a
rule. Also, note that lowercase letters are used in the main line filter of this
script too.

But if this is a strong requirement from you to remove lowercase letters here,
just tell me, and I'll make the change. In that case, should the main line
filter be changed too?

Best regards,
Benoît
Benoît Thébaudeau - March 7, 2013, 5:23 p.m.
Dear Wolfgang Denk,

On Thursday, March 7, 2013 12:38:04 PM, Benoît Thébaudeau wrote:
> Dear Wolfgang Denk,
> 
> On Thursday, March 7, 2013 7:57:13 AM, Wolfgang Denk wrote:
> > Dear Benoît Thébaudeau,
> > 
> > In message
> > <1362596377-5827-15-git-send-email-benoit.thebaudeau@advansee.com>
> > you wrote:
> > >
> > > +	# ... and from configs defined from other configs
> > > +	s/="\(CONFIG_[A-Za-z0-9_][A-Za-z0-9_]*\)"/=$(\1)/;
> > 
> > Should we not remove the lower case letters here?  Such are not
> > supposed to be used in macro names.
> 
> I don't think so. They're indeed not supposed to be used, but there are
> perhaps
> exceptions somewhere, and it's not the purpose of this script to enforce such
> a
> rule. Also, note that lowercase letters are used in the main line filter of
> this
> script too.
> 
> But if this is a strong requirement from you to remove lowercase letters
> here,
> just tell me, and I'll make the change. In that case, should the main line
> filter be changed too?

I've just performed a quick search, and there are many exceptions:

CONFIG_100MHz
CONFIG_200MHz
CONFIG_266MHz
CONFIG_300MHz
CONFIG_44x
CONFIG_4x
CONFIG_4xx
CONFIG_4xx_CONFIG_BLOCKSIZE
CONFIG_4xx_CONFIG_I2C_EEPROM_ADDR
CONFIG_4xx_CONFIG_I2C_EEPROM_OFFSET
CONFIG_4xx_DCACHE
CONFIG_50MHz
CONFIG_5xx
CONFIG_5xx_CONS_SCI1
CONFIG_5xx_CONS_SCI2
CONFIG_5xx_GCLK_FREQ
CONFIG_66MHz
CONFIG_74x
CONFIG_74xx
CONFIG_74xx_7xx
CONFIG_75MHz
CONFIG_75x
CONFIG_7xx
CONFIG_80MHz
CONFIG_82xx_CONS_SMC1
CONFIG_82xx_CONS_SMC2
CONFIG_8xx
CONFIG_8xx_BOOTDELAY
CONFIG_8xx_BUSCLOCK
CONFIG_8xx_CONS_
CONFIG_8xx_CONS_NONE
CONFIG_8xx_CONS_SCC1
CONFIG_8xx_CONS_SCC2
CONFIG_8xx_CONS_SCC3
CONFIG_8xx_CONS_SCC4
CONFIG_8xx_CONS_SCCx
CONFIG_8xx_CONS_SMC1
CONFIG_8xx_CONS_SMC2
CONFIG_8xx_CONS_SMCx
CONFIG_8xx_CPUCLK_DEFAULT
CONFIG_8xx_CPUCLOCK
CONFIG_8xx_GCLK_FREQ
CONFIG_8xx_OSCLK
CONFIG_8xx_TFTP_MODE
CONFIG_ARCH_GTA02_v1
CONFIG_ARCH_GTA02_v2
CONFIG_AT32UC3A0xxx
CONFIG_BAB7xx
CONFIG_BF50x
CONFIG_BF51x
CONFIG_BF52x
CONFIG_BF54x
CONFIG_BF60x
CONFIG_BOARD_EARLY_INIT_f
CONFIG_BUSMODE_60x
CONFIG_CCLK_DIV_not_defined_properly
CONFIG_CF_V4e
CONFIG_CLKIN_66MHz
CONFIG_CM41xx
CONFIG_DB_CR826_J30x_ON
CONFIG_DISPLAY_AER_xxxx
CONFIG_EBC_PPC4xx_IBM_VER1
CONFIG_EB_CPUx9K2_H_
CONFIG_ETHER_ON_FCCx
CONFIG_eTSEC_MDIO_BUS
CONFIG_FEL8xx_AT
CONFIG_galaxy5200_LOWBOOT
CONFIG_IB62x0_H
CONFIG_IDE_8xx_DIRECT
CONFIG_IDE_8xx_PCCARD
CONFIG_IP86x
CONFIG_M520x
CONFIG_M5301x
CONFIG_M547x
CONFIG_M548x
CONFIG_MB86R0x
CONFIG_MB86R0x_IOCLK
CONFIG_MCF520x
CONFIG_MCF5227x
CONFIG_MCF523x
CONFIG_MCF52x2
CONFIG_MCF5301x
CONFIG_MCF532x
CONFIG_MCF537x
CONFIG_MCF5441x
CONFIG_MCF5445x
CONFIG_MCF547x_8x
CONFIG_MPC512x_FEC
CONFIG_MPC5xxx
CONFIG_MPC5xxx_FEC
CONFIG_MPC5xxx_FEC_MII10
CONFIG_MPC5xxx_FEC_MII100
CONFIG_MPC5xxx_FEC_SEVENWIRE
CONFIG_MPC5xxx_MII10
CONFIG_MPC830x
CONFIG_MPC831x
CONFIG_MPC832x
CONFIG_MPC834x
CONFIG_MPC837x
CONFIG_MPC83xx
CONFIG_MPC85xx
CONFIG_MPC86x
CONFIG_MPC86xADS
CONFIG_MPC86xx
CONFIG_MPC8xxx_DISABLE_BPTR
CONFIG_nand
CONFIG_P3Mx
CONFIG_PCI_4xx_PTM_OVERWRITE
CONFIG_PDSP188x
CONFIG_PHYx_ADDR
CONFIG_PL01x_PORTS
CONFIG_PPC4xx_DDR_AUTOCALIBRATION
CONFIG_PPC4xx_DDR_METHOD_A
CONFIG_PPC4xx_EMAC
CONFIG_RTC_DS164x
CONFIG_RTC_DS174x
CONFIG_RTC_MPC8xx
CONFIG_SACSng
CONFIG_SDRAM_PPC4xx_DENALI_DDR2
CONFIG_SDRAM_PPC4xx_IBM_DDR
CONFIG_SDRAM_PPC4xx_IBM_DDR2
CONFIG_SDRAM_PPC4xx_IBM_SDRAM
CONFIG_SHARP_16x9
CONFIG_SHEEVA_88SV331xV5
CONFIG_spear300
CONFIG_spear310
CONFIG_spear320
CONFIG_SVM_SC8xx
CONFIG_SYS_4xx_CHIP_21_405EX_NO_SECURITY
CONFIG_SYS_4xx_CHIP_21_405EXr_NO_SECURITY
CONFIG_SYS_4xx_CHIP_21_405EXr_SECURITY
CONFIG_SYS_4xx_CHIP_21_405EX_SECURITY
CONFIG_SYS_4xx_CHIP_21_ERRATA
CONFIG_SYS_4xx_GPIO_TABLE
CONFIG_SYS_4xx_RESET_TYPE
CONFIG_SYS_60x_BR
CONFIG_SYS_60x_OR
CONFIG_SYS_8xx_CPUCLK_MAX
CONFIG_SYS_8xx_CPUCLK_MIN
CONFIG_SYS_BCR_60x
CONFIG_SYS_BRx_PRELIM
CONFIG_SYS_CMA_CSn_
CONFIG_SYS_CSn_BASE
CONFIG_SYS_CSn_CTRL
CONFIG_SYS_CSn_MASK
CONFIG_SYS_CSx_BASE
CONFIG_SYS_CSx_RO
CONFIG_SYS_CSx_SIZE
CONFIG_SYS_CSx_WIDTH
CONFIG_SYS_CSx_WS
CONFIG_SYS_DM36x_AB1CR
CONFIG_SYS_DM36x_AB2CR
CONFIG_SYS_DM36x_AWCCR
CONFIG_SYS_DM36x_DDR2_DDRPHYCR
CONFIG_SYS_DM36x_DDR2_PBBPR
CONFIG_SYS_DM36x_DDR2_SDBCR
CONFIG_SYS_DM36x_DDR2_SDRCR
CONFIG_SYS_DM36x_DDR2_SDTIMR
CONFIG_SYS_DM36x_DDR2_SDTIMR2
CONFIG_SYS_DM36x_PERI_CLK_CTRL
CONFIG_SYS_DM36x_PINMUX0
CONFIG_SYS_DM36x_PINMUX1
CONFIG_SYS_DM36x_PINMUX2
CONFIG_SYS_DM36x_PINMUX3
CONFIG_SYS_DM36x_PINMUX4
CONFIG_SYS_DM36x_PLL1_PLLDIV1
CONFIG_SYS_DM36x_PLL1_PLLDIV2
CONFIG_SYS_DM36x_PLL1_PLLDIV3
CONFIG_SYS_DM36x_PLL1_PLLDIV4
CONFIG_SYS_DM36x_PLL1_PLLDIV5
CONFIG_SYS_DM36x_PLL1_PLLDIV6
CONFIG_SYS_DM36x_PLL1_PLLDIV7
CONFIG_SYS_DM36x_PLL1_PLLDIV8
CONFIG_SYS_DM36x_PLL1_PLLDIV9
CONFIG_SYS_DM36x_PLL1_PLLM
CONFIG_SYS_DM36x_PLL1_PREDIV
CONFIG_SYS_DM36x_PLL2_PLLDIV1
CONFIG_SYS_DM36x_PLL2_PLLDIV2
CONFIG_SYS_DM36x_PLL2_PLLDIV3
CONFIG_SYS_DM36x_PLL2_PLLDIV4
CONFIG_SYS_DM36x_PLL2_PLLDIV5
CONFIG_SYS_DM36x_PLL2_PLLM
CONFIG_SYS_DM36x_PLL2_PREDIV
CONFIG_SYS_FLASH_LEGACY_256Kx8
CONFIG_SYS_FLASH_LEGACY_512Kx16
CONFIG_SYS_FLASH_LEGACY_512Kx8
CONFIG_SYS_FPGA_xxx
CONFIG_SYS_GPIO_nPWRON
CONFIG_SYS_GT_6426x
CONFIG_SYS_I2c_INIT_MPC5XXX
CONFIG_SYS_INIT_DCACHE_PBxAR
CONFIG_SYS_INIT_DCACHE_PBxCR
CONFIG_SYS_LBKs
CONFIG_SYS_MB862xx_CCF
CONFIG_SYS_MB862xx_MMR
CONFIG_SYS_MPC512x_USB_ADDR
CONFIG_SYS_MPC512x_USB_OFFSET
CONFIG_SYS_MPC83xx_DMA_ADDR
CONFIG_SYS_MPC83xx_DMA_OFFSET
CONFIG_SYS_MPC83xx_ESDHC_ADDR
CONFIG_SYS_MPC83xx_ESDHC_OFFSET
CONFIG_SYS_MPC83xx_USB_ADDR
CONFIG_SYS_MPC83xx_USB_OFFSET
CONFIG_SYS_MPC85xx_CPM_ADDR
CONFIG_SYS_MPC85xx_CPM_OFFSET
CONFIG_SYS_MPC85xx_DMA
CONFIG_SYS_MPC85xx_DMA1_OFFSET
CONFIG_SYS_MPC85xx_DMA2_OFFSET
CONFIG_SYS_MPC85xx_DMA_ADDR
CONFIG_SYS_MPC85xx_DMA_OFFSET
CONFIG_SYS_MPC85xx_ECM_ADDR
CONFIG_SYS_MPC85xx_ECM_OFFSET
CONFIG_SYS_MPC85xx_ESDHC_ADDR
CONFIG_SYS_MPC85xx_ESDHC_OFFSET
CONFIG_SYS_MPC85xx_ESPI_ADDR
CONFIG_SYS_MPC85xx_ESPI_OFFSET
CONFIG_SYS_MPC85xx_GPIO_ADDR
CONFIG_SYS_MPC85xx_GPIO_OFFSET
CONFIG_SYS_MPC85xx_GUTS_ADDR
CONFIG_SYS_MPC85xx_GUTS_OFFSET
CONFIG_SYS_MPC85xx_IFC_OFFSET
CONFIG_SYS_MPC85xx_L2_ADDR
CONFIG_SYS_MPC85xx_L2_OFFSET
CONFIG_SYS_MPC85xx_LBC_OFFSET
CONFIG_SYS_MPC85xx_PCI1_OFFSET
CONFIG_SYS_MPC85xx_PCI2_OFFSET
CONFIG_SYS_MPC85xx_PCIE
CONFIG_SYS_MPC85xx_PCIE1_OFFSET
CONFIG_SYS_MPC85xx_PCIE2_OFFSET
CONFIG_SYS_MPC85xx_PCIE3_OFFSET
CONFIG_SYS_MPC85xx_PCIE4_OFFSET
CONFIG_SYS_MPC85xx_PCIX2_ADDR
CONFIG_SYS_MPC85xx_PCIX2_OFFSET
CONFIG_SYS_MPC85xx_PCIX_ADDR
CONFIG_SYS_MPC85xx_PCIX_OFFSET
CONFIG_SYS_MPC85xx_PIC_OFFSET
CONFIG_SYS_MPC85xx_SATA
CONFIG_SYS_MPC85xx_SATA1_ADDR
CONFIG_SYS_MPC85xx_SATA1_OFFSET
CONFIG_SYS_MPC85xx_SATA2_ADDR
CONFIG_SYS_MPC85xx_SATA2_OFFSET
CONFIG_SYS_MPC85xx_SERDES1_ADDR
CONFIG_SYS_MPC85xx_SERDES1_OFFSET
CONFIG_SYS_MPC85xx_SERDES2_ADDR
CONFIG_SYS_MPC85xx_SERDES2_OFFSET
CONFIG_SYS_MPC85xx_USB
CONFIG_SYS_MPC85xx_USB1_OFFSET
CONFIG_SYS_MPC85xx_USB1_PHY_ADDR
CONFIG_SYS_MPC85xx_USB1_PHY_OFFSET
CONFIG_SYS_MPC85xx_USB2_OFFSET
CONFIG_SYS_MPC85xx_USB2_PHY_ADDR
CONFIG_SYS_MPC85xx_USB2_PHY_OFFSET
CONFIG_SYS_MPC85xx_USB_ADDR
CONFIG_SYS_MPC85xx_USB_OFFSET
CONFIG_SYS_MPC86xx_DMA_ADDR
CONFIG_SYS_MPC86xx_DMA_OFFSET
CONFIG_SYS_MPC86xx_PCI1_OFFSET
CONFIG_SYS_MPC86xx_PCI2_OFFSET
CONFIG_SYS_MPC86xx_PCIE1_OFFSET
CONFIG_SYS_MPC86xx_PCIE2_OFFSET
CONFIG_SYS_MPC86xx_PIC_OFFSET
CONFIG_SYS_MPC8xxx_DDR2_ADDR
CONFIG_SYS_MPC8xxx_DDR2_OFFSET
CONFIG_SYS_MPC8xxx_DDR3_ADDR
CONFIG_SYS_MPC8xxx_DDR3_OFFSET
CONFIG_SYS_MPC8xxx_DDR4_ADDR
CONFIG_SYS_MPC8xxx_DDR_ADDR
CONFIG_SYS_MPC8xxx_DDR_OFFSET
CONFIG_SYS_MPC8xxx_GUTS_ADDR
CONFIG_SYS_MPC8xxx_PIC_ADDR
CONFIG_SYS_MxMR_PTx
CONFIG_SYS_NS87308_BADDR_0x
CONFIG_SYS_ORx_PRELIM
CONFIG_SYS_PxDAT
CONFIG_SYS_PxDDR
CONFIG_SYS_PxPAR
CONFIG_SYS_QE_FW_IN_xxx
CONFIG_SYS_SDRAM_BASE1xx
CONFIG_SYS_SDRAM_tRC
CONFIG_SYS_SDRAM_tRCD
CONFIG_SYS_SDRAM_tRFC
CONFIG_SYS_SDRAM_tRP
CONFIG_SYS_SPI_UCODE_PATCh
CONFIG_SYS_SRIOn_MEM_PHYS
CONFIG_SYS_SRIOn_MEM_SIZE
CONFIG_SYS_SRIOn_MEM_VIRT
CONFIG_SYS_UECx_PHY_ADDR
CONFIG_SYS_xRn_PRELIM
CONFIG_TQM8xxL
CONFIG_TQM8xxM
CONFIG_USB_ETHER_xxx
CONFIG_usbtty
CONFIG_VIDEO_MB862xx
CONFIG_VIDEO_MB862xx_ACCEL
CONFIG_VIDEO_MB86R0xGDC

Best regards,
Benoît
Marek Vasut - March 8, 2013, 3:29 a.m.
Dear Wolfgang Denk,

> Dear Benoît Thébaudeau,
> 
> In message <1362596377-5827-15-git-send-email-benoit.thebaudeau@advansee.com> 
you wrote:
> > +	# ... and from configs defined from other configs
> > +	s/="\(CONFIG_[A-Za-z0-9_][A-Za-z0-9_]*\)"/=$(\1)/;
> 
> Should we not remove the lower case letters here?  Such are not
> supposed to be used in macro names.

btw. CONFIG_[[:alnum:]_]\+ is shorter ;-)

Best regards,
Marek Vasut
Wolfgang Denk - March 8, 2013, 5:25 a.m.
Dear Marek Vasut,

In message <201303080429.00780.marex@denx.de> you wrote:
> 
> > > +	# ... and from configs defined from other configs
> > > +	s/="\(CONFIG_[A-Za-z0-9_][A-Za-z0-9_]*\)"/=$(\1)/;
> > 
> > Should we not remove the lower case letters here?  Such are not
> > supposed to be used in macro names.
>
> btw. CONFIG_[[:alnum:]_]\+ is shorter ;-)

...and has the same issue of including the unwanted lower case
letters.

Best regards,

Wolfgang Denk
Benoît Thébaudeau - March 8, 2013, 11:57 a.m.
Dear Wolfgang Denk,

On Friday, March 8, 2013 6:25:19 AM, Wolfgang Denk wrote:
> Dear Marek Vasut,
> 
> In message <201303080429.00780.marex@denx.de> you wrote:
> > 
> > > > +	# ... and from configs defined from other configs
> > > > +	s/="\(CONFIG_[A-Za-z0-9_][A-Za-z0-9_]*\)"/=$(\1)/;
> > > 
> > > Should we not remove the lower case letters here?  Such are not
> > > supposed to be used in macro names.
> >
> > btw. CONFIG_[[:alnum:]_]\+ is shorter ;-)
> 
> ...and has the same issue of including the unwanted lower case
> letters.

Does it mean that you have also read my 2 messages and that you confirm that you
absolutely want this change despite the exiting configs with lowercase letters?

Best regards,
Benoît
Benoît Thébaudeau - March 8, 2013, 12:14 p.m.
Hi Marek,

On Friday, March 8, 2013 4:29:00 AM, Marek Vasut wrote:
> Dear Wolfgang Denk,
> 
> > Dear Benoît Thébaudeau,
> > 
> > In message
> > <1362596377-5827-15-git-send-email-benoit.thebaudeau@advansee.com>
> you wrote:
> > > +	# ... and from configs defined from other configs
> > > +	s/="\(CONFIG_[A-Za-z0-9_][A-Za-z0-9_]*\)"/=$(\1)/;
> > 
> > Should we not remove the lower case letters here?  Such are not
> > supposed to be used in macro names.
> 
> btw. CONFIG_[[:alnum:]_]\+ is shorter ;-)

and less portable: see commit 02409f8.

Best regards,
Benoît
Marek Vasut - March 8, 2013, 2:08 p.m.
Dear Wolfgang Denk,

> Dear Marek Vasut,
> 
> In message <201303080429.00780.marex@denx.de> you wrote:
> > > > +	# ... and from configs defined from other configs
> > > > +	s/="\(CONFIG_[A-Za-z0-9_][A-Za-z0-9_]*\)"/=$(\1)/;
> > > 
> > > Should we not remove the lower case letters here?  Such are not
> > > supposed to be used in macro names.
> > 
> > btw. CONFIG_[[:alnum:]_]\+ is shorter ;-)
> 
> ...and has the same issue of including the unwanted lower case
> letters.

What about the CONFIG_8xx_* variables then ? :)

Best regards,
Marek Vasut
Marek Vasut - March 8, 2013, 2:17 p.m.
Dear Benoît Thébaudeau,

> Hi Marek,
> 
> On Friday, March 8, 2013 4:29:00 AM, Marek Vasut wrote:
> > Dear Wolfgang Denk,
> > 
> > > Dear Benoît Thébaudeau,
> > > 
> > > In message
> > > <1362596377-5827-15-git-send-email-benoit.thebaudeau@advansee.com>
> > 
> > you wrote:
> > > > +	# ... and from configs defined from other configs
> > > > +	s/="\(CONFIG_[A-Za-z0-9_][A-Za-z0-9_]*\)"/=$(\1)/;
> > > 
> > > Should we not remove the lower case letters here?  Such are not
> > > supposed to be used in macro names.
> > 
> > btw. CONFIG_[[:alnum:]_]\+ is shorter ;-)
> 
> and less portable: see commit 02409f8.

$ echo -ne "=CONFIG_FOO\n=CONFIG_Bar\n=CONFIG_bAz\n" | sed 
"s/=\(CONFIG_[[:alnum:]_]\+\)/=$(\1)/"
-bash: 1: command not found
=CONFIG_FOO
=CONFIG_Bar
=CONFIG_bAz
$ uname -a
FreeBSD foo.bar.baz 8.3-RELEASE-p6 FreeBSD 8.3-RELEASE-p6 #9: Tue Feb 26 
17:05:09 CET 2013     foo@bar.baz.foo:/usr/obj/usr/src/sys/XXXXX  amd64

I dont exactly understand the commit message, it works on this freebsd box. I 
won't go digging through the CVSes to find when it was added though ;-)

Best regards,
Marek Vasut
Wolfgang Denk - March 8, 2013, 2:28 p.m.
Dear Marek,

In message <201303081508.49239.marex@denx.de> you wrote:
> 
> > > > Should we not remove the lower case letters here?  Such are not
> > > > supposed to be used in macro names.
> > > 
> > > btw. CONFIG_[[:alnum:]_]\+ is shorter ;-)
> > 
> > ...and has the same issue of including the unwanted lower case
> > letters.
> 
> What about the CONFIG_8xx_* variables then ? :)

Argh... well, actually these should be fixed.

Best regards,

Wolfgang Denk
Tom Rini - March 8, 2013, 2:40 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/08/2013 09:28 AM, Wolfgang Denk wrote:
> Dear Marek,
> 
> In message <201303081508.49239.marex@denx.de> you wrote:
>> 
>>>>> Should we not remove the lower case letters here?  Such are
>>>>> not supposed to be used in macro names.
>>>> 
>>>> btw. CONFIG_[[:alnum:]_]\+ is shorter ;-)
>>> 
>>> ...and has the same issue of including the unwanted lower case 
>>> letters.
>> 
>> What about the CONFIG_8xx_* variables then ? :)
> 
> Argh... well, actually these should be fixed.

I think the giant list from Benoit got lost.  It's a HUGE thing to
change.  I think we should just accept that config variables are mixed
case, or at least not block this patch on a very large unrelated fixup.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJROfh5AAoJENk4IS6UOR1WnEkQALMU7vrooNXtIVBaWh6Hri3y
wd+czZG+8u99c8qfos2VhMVIiFmO7aQWOw4qd3Isw1DI86MByG1FVzQrp3JSFCFV
79orvgFMbWKBKjZ9hKCgrWWy98ZEyZb6iRduOUfY9r1e1ZWbDz2TQQYpYi2HTt54
HOb3j6TV26VKtHX3oi+cRiNNBgmISFxixbxdy337++MSb/INn3mHNN3/WbB4VVFH
E5u7dD7XEU2uhqmLP3sqO38RAakX7OojptXUUlfXlFaCEUvx/4QXCwXwkKD5FW96
zUXCYfcfoM3NggAzd0RHOSH2qtsBvVdR6NurcnnOM379ceGFM+MZUFYt1VYP1Jhq
SZxLH/IV8QQ1t40q655aZBFdxOI1j3j5U0el/MTweEfi/2AXgBwgSDA0Qdn0cMfk
Hsx8jhW2BdsA5KvOCCDY4fOpyAZM+A+Up5+WnqUAiVXe6YkSED6Rg5RTg4yUIJT6
lvuF8V/oONGlLnoiUQp/OyhfLvNDjbEv3+pVIvByyTfTVUXLhqUnBe3zvfre5um8
hGjMJhzv+Qo5SybPADKIFhWPdz8P5AfKqS3cTYH02ficYAFXkiK6YVKXNnYfo+2d
n+WU8coJgMG5ayJGNul0lKxBfzn9ztZrX68D15SYs5MxL6cAHbKqQUbl++vaGHlO
5PCNuzBab+pvEgU1gX6X
=e6TD
-----END PGP SIGNATURE-----
Fabio Estevam - March 8, 2013, 2:54 p.m.
On Fri, Mar 8, 2013 at 11:40 AM, Tom Rini <trini@ti.com> wrote:

> I think the giant list from Benoit got lost.  It's a HUGE thing to
> change.  I think we should just accept that config variables are mixed
> case, or at least not block this patch on a very large unrelated fixup.

Agreed. Benoit's patch series contains 30 patches and it is at version 9.

It would be better to treat this fixup seperately.

Currently mx31pdk is broken in mainline and Benoit's series fixes it,
so hopefully this can make into 2013.04.

Regards,

Fabio Estevam
Wolfgang Denk - March 8, 2013, 3:16 p.m.
Dear Tom Rini,

In message <5139F87A.7000808@ti.com> you wrote:
> 
> >> What about the CONFIG_8xx_* variables then ? :)
> > 
> > Argh... well, actually these should be fixed.
> 
> I think the giant list from Benoit got lost.  It's a HUGE thing to
> change.  I think we should just accept that config variables are mixed
> case, or at least not block this patch on a very large unrelated fixup.

That's fine with me.

Best regards,

Wolfgang Denk
Stefano Babic - March 13, 2013, 8:01 a.m.
On 08/03/2013 15:54, Fabio Estevam wrote:
> On Fri, Mar 8, 2013 at 11:40 AM, Tom Rini <trini@ti.com> wrote:
> 
>> I think the giant list from Benoit got lost.  It's a HUGE thing to
>> change.  I think we should just accept that config variables are mixed
>> case, or at least not block this patch on a very large unrelated fixup.
> 
> Agreed. Benoit's patch series contains 30 patches and it is at version 9.
> 
> It would be better to treat this fixup seperately.
> 

Agree with you, this is my proposal to go on. I think we can also try to
split patches for area of competence, with patchsets for i.MX, for ARM
and for general. And maybe merging patches that are laready passed the
review.

For that, patches 1 until 9 are related to i.MX and mainly to the NAND
for i.MX. They get already Scott's ACK. IMHO they are independent from
the rest of the patchset and they can be merged now. My proposal is that
I merge this part and for the next iteration the number of patches will
be reduced ;-)

> Currently mx31pdk is broken in mainline and Benoit's series fixes it,
> so hopefully this can make into 2013.04.

Let's see what we can do ;-)

Regards,
Stefano Babic
Benoît Thébaudeau - March 13, 2013, 1:35 p.m.
Hi Stefano,

On Wednesday, March 13, 2013 9:01:47 AM, Stefano Babic wrote:
> On 08/03/2013 15:54, Fabio Estevam wrote:
> > On Fri, Mar 8, 2013 at 11:40 AM, Tom Rini <trini@ti.com> wrote:
> > 
> >> I think the giant list from Benoit got lost.  It's a HUGE thing to
> >> change.  I think we should just accept that config variables are mixed
> >> case, or at least not block this patch on a very large unrelated fixup.
> > 
> > Agreed. Benoit's patch series contains 30 patches and it is at version 9.
> > 
> > It would be better to treat this fixup seperately.
> > 
> 
> Agree with you, this is my proposal to go on. I think we can also try to
> split patches for area of competence, with patchsets for i.MX, for ARM
> and for general. And maybe merging patches that are laready passed the
> review.
> 
> For that, patches 1 until 9 are related to i.MX and mainly to the NAND
> for i.MX. They get already Scott's ACK. IMHO they are independent from
> the rest of the patchset and they can be merged now. My proposal is that
> I merge this part and for the next iteration the number of patches will
> be reduced ;-)
> 
> > Currently mx31pdk is broken in mainline and Benoit's series fixes it,
> > so hopefully this can make into 2013.04.
> 
> Let's see what we can do ;-)

Yes, it could be split as you suggest, but it has already been reviewed and
tested by several people, so I'm not sure if we still have to wait for anything
before applying. Albert seemed to agree for this v9 for the arm bits, but he has
not given his formal ack yet. Albert, is everything OK for you?

The sooner it is applied, the longer people will have to test before the
release.

Best regards,
Benoît
Tom Rini - March 13, 2013, 1:56 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 03/13/2013 09:35 AM, Benoît Thébaudeau wrote:
> Hi Stefano,
> 
> On Wednesday, March 13, 2013 9:01:47 AM, Stefano Babic wrote:
>> On 08/03/2013 15:54, Fabio Estevam wrote:
>>> On Fri, Mar 8, 2013 at 11:40 AM, Tom Rini <trini@ti.com>
>>> wrote:
>>> 
>>>> I think the giant list from Benoit got lost.  It's a HUGE
>>>> thing to change.  I think we should just accept that config
>>>> variables are mixed case, or at least not block this patch on
>>>> a very large unrelated fixup.
>>> 
>>> Agreed. Benoit's patch series contains 30 patches and it is at
>>> version 9.
>>> 
>>> It would be better to treat this fixup seperately.
>>> 
>> 
>> Agree with you, this is my proposal to go on. I think we can also
>> try to split patches for area of competence, with patchsets for
>> i.MX, for ARM and for general. And maybe merging patches that are
>> laready passed the review.
>> 
>> For that, patches 1 until 9 are related to i.MX and mainly to the
>> NAND for i.MX. They get already Scott's ACK. IMHO they are
>> independent from the rest of the patchset and they can be merged
>> now. My proposal is that I merge this part and for the next
>> iteration the number of patches will be reduced ;-)
>> 
>>> Currently mx31pdk is broken in mainline and Benoit's series
>>> fixes it, so hopefully this can make into 2013.04.
>> 
>> Let's see what we can do ;-)
> 
> Yes, it could be split as you suggest, but it has already been
> reviewed and tested by several people, so I'm not sure if we still
> have to wait for anything before applying. Albert seemed to agree
> for this v9 for the arm bits, but he has not given his formal ack
> yet. Albert, is everything OK for you?
> 
> The sooner it is applied, the longer people will have to test
> before the release.

I am not going to insist that the N different parts come in from N
different trees, as long as the relevant acks are present (and it
sounds like they are).  I will give the whole series another read
today just to be sure there's nothing popping out at me.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRQIWRAAoJENk4IS6UOR1WLToQAJzQlTf1c6XogQZq6YaCENAC
1cSyfAnD/+1FDtoEt1wxfSxDi77mgIifsig+ac6ZbtJAB9y1AsKudTOyJEI5TBgu
85FpSx4re7DLUqHaOgVV35bHNRLwfTM1vaxb4KJcfFqUGnIiVTpyerScPnFUDNpU
gz0LZh5ou4saK89oOWA3qbIHeADDNU/st0C05HjObkotCcPDOK0zPoAmc4T4WC03
lfUb23HYQh9OKK75MdW+UYOgNRIl9R0pqFNklujof5m2t5NrSJhp8xlfVZgUw571
G/Yn69n+VDmDrSrDorFL4dpvRZE69x+M07k7hYGg0R5ZKQcgZ/2iwCADMCnvshZa
t9V/ttPvOfTXCaEHi/gCe7u+CBjCu0FW7R9/2LWFImOw5qnYqR/D/Scf4WOgTaMi
xTksob1+rLJJ6dIzo/BFc0LlOpaKJTLmrpMiBwJmvPh9I2/wYUsbGRCS8nhFIfSf
o5GklP8CfiRKaIssS692ncxdGy7ZTFQo3txLSC+H8Kyjy72Kd6XwBBd7E7w4jhDh
iBxoDVgelwSLjjAV8zuRBSWO8ueGPe5qAicNfhoRhsJ/hUtwxMG1cO2kjFAhVsOC
ZtP56RvajKZBSnUk607iajZxuYcElTxKg8lL8PlugHemsTDBxZeiR/BQtmbqpzDs
rgtpehR2zx9Cx3SM8nnN
=xRZz
-----END PGP SIGNATURE-----
Stefano Babic - March 13, 2013, 4:44 p.m.
On 13/03/2013 14:35, Benoît Thébaudeau wrote:
> Hi Stefano,
> 

Hi Benoît,

>> For that, patches 1 until 9 are related to i.MX and mainly to the NAND
>> for i.MX. They get already Scott's ACK. IMHO they are independent from
>> the rest of the patchset and they can be merged now. My proposal is that
>> I merge this part and for the next iteration the number of patches will
>> be reduced ;-)
>>
>>> Currently mx31pdk is broken in mainline and Benoit's series fixes it,
>>> so hopefully this can make into 2013.04.
>>
>> Let's see what we can do ;-)
> 
> Yes, it could be split as you suggest, but it has already been reviewed and
> tested by several people, so I'm not sure if we still have to wait for anything
> before applying.

My proposal is only if we will not merge the whole patchset, making
easier another iteration if required - but it seems it is not.

> Albert seemed to agree for this v9 for the arm bits, but he has
> not given his formal ack yet. Albert, is everything OK for you?
> 
> The sooner it is applied, the longer people will have to test before the
> release.

I ask who should be in charge to merge the patchset - patches cover
different areas (at least i.MX, ARM and general). In patchwork they are
assigned to me - mainly due to the first part that is i.MX related. No
problem for me to merge them if we get all required ACKs.

Best regards,
Stefano
Tom Rini - March 13, 2013, 6:12 p.m.
On Wed, Mar 13, 2013 at 09:56:34AM -0400, Tom Rini wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 03/13/2013 09:35 AM, Beno??t Th??baudeau wrote:
> > Hi Stefano,
> > 
> > On Wednesday, March 13, 2013 9:01:47 AM, Stefano Babic wrote:
> >> On 08/03/2013 15:54, Fabio Estevam wrote:
> >>> On Fri, Mar 8, 2013 at 11:40 AM, Tom Rini <trini@ti.com>
> >>> wrote:
> >>> 
> >>>> I think the giant list from Benoit got lost.  It's a HUGE
> >>>> thing to change.  I think we should just accept that config
> >>>> variables are mixed case, or at least not block this patch on
> >>>> a very large unrelated fixup.
> >>> 
> >>> Agreed. Benoit's patch series contains 30 patches and it is at
> >>> version 9.
> >>> 
> >>> It would be better to treat this fixup seperately.
> >>> 
> >> 
> >> Agree with you, this is my proposal to go on. I think we can also
> >> try to split patches for area of competence, with patchsets for
> >> i.MX, for ARM and for general. And maybe merging patches that are
> >> laready passed the review.
> >> 
> >> For that, patches 1 until 9 are related to i.MX and mainly to the
> >> NAND for i.MX. They get already Scott's ACK. IMHO they are
> >> independent from the rest of the patchset and they can be merged
> >> now. My proposal is that I merge this part and for the next
> >> iteration the number of patches will be reduced ;-)
> >> 
> >>> Currently mx31pdk is broken in mainline and Benoit's series
> >>> fixes it, so hopefully this can make into 2013.04.
> >> 
> >> Let's see what we can do ;-)
> > 
> > Yes, it could be split as you suggest, but it has already been
> > reviewed and tested by several people, so I'm not sure if we still
> > have to wait for anything before applying. Albert seemed to agree
> > for this v9 for the arm bits, but he has not given his formal ack
> > yet. Albert, is everything OK for you?
> > 
> > The sooner it is applied, the longer people will have to test
> > before the release.
> 
> I am not going to insist that the N different parts come in from N
> different trees, as long as the relevant acks are present (and it
> sounds like they are).  I will give the whole series another read
> today just to be sure there's nothing popping out at me.

I've given everything a read-over and nothing jumps out at me.  I also
threw it (with a few imx things failing so I skipped) onto master and
built and booted my am335x_evm with it, so for the series:

Tested-by: Tom Rini <trini@ti.com>

And if Albert is happy, I'm happy to see it all come via u-boot-arm.
Albert ARIBAUD - March 16, 2013, 10:54 a.m.
Hi Tom,

On Wed, 13 Mar 2013 14:12:32 -0400, Tom Rini <trini@ti.com> wrote:

> On Wed, Mar 13, 2013 at 09:56:34AM -0400, Tom Rini wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > On 03/13/2013 09:35 AM, Beno??t Th??baudeau wrote:
> > > Hi Stefano,
> > > 
> > > On Wednesday, March 13, 2013 9:01:47 AM, Stefano Babic wrote:
> > >> On 08/03/2013 15:54, Fabio Estevam wrote:
> > >>> On Fri, Mar 8, 2013 at 11:40 AM, Tom Rini <trini@ti.com>
> > >>> wrote:
> > >>> 
> > >>>> I think the giant list from Benoit got lost.  It's a HUGE
> > >>>> thing to change.  I think we should just accept that config
> > >>>> variables are mixed case, or at least not block this patch on
> > >>>> a very large unrelated fixup.
> > >>> 
> > >>> Agreed. Benoit's patch series contains 30 patches and it is at
> > >>> version 9.
> > >>> 
> > >>> It would be better to treat this fixup seperately.
> > >>> 
> > >> 
> > >> Agree with you, this is my proposal to go on. I think we can also
> > >> try to split patches for area of competence, with patchsets for
> > >> i.MX, for ARM and for general. And maybe merging patches that are
> > >> laready passed the review.
> > >> 
> > >> For that, patches 1 until 9 are related to i.MX and mainly to the
> > >> NAND for i.MX. They get already Scott's ACK. IMHO they are
> > >> independent from the rest of the patchset and they can be merged
> > >> now. My proposal is that I merge this part and for the next
> > >> iteration the number of patches will be reduced ;-)
> > >> 
> > >>> Currently mx31pdk is broken in mainline and Benoit's series
> > >>> fixes it, so hopefully this can make into 2013.04.
> > >> 
> > >> Let's see what we can do ;-)
> > > 
> > > Yes, it could be split as you suggest, but it has already been
> > > reviewed and tested by several people, so I'm not sure if we still
> > > have to wait for anything before applying. Albert seemed to agree
> > > for this v9 for the arm bits, but he has not given his formal ack
> > > yet. Albert, is everything OK for you?
> > > 
> > > The sooner it is applied, the longer people will have to test
> > > before the release.
> > 
> > I am not going to insist that the N different parts come in from N
> > different trees, as long as the relevant acks are present (and it
> > sounds like they are).  I will give the whole series another read
> > today just to be sure there's nothing popping out at me.
> 
> I've given everything a read-over and nothing jumps out at me.  I also
> threw it (with a few imx things failing so I skipped) onto master and
> built and booted my am335x_evm with it, so for the series:
> 
> Tested-by: Tom Rini <trini@ti.com>
> 
> And if Albert is happy, I'm happy to see it all come via u-boot-arm.

As soon as ARM is back in sync with mainline, I'll start looking
into pulling this in.

Amicalement,

Patch

diff --git a/tools/scripts/define2mk.sed b/tools/scripts/define2mk.sed
index 13e2845..c641edf 100644
--- a/tools/scripts/define2mk.sed
+++ b/tools/scripts/define2mk.sed
@@ -24,6 +24,8 @@ 
 	s/="\([0-9][0-9]*\)"/=\1/;
 	# ... and from hex numbers
 	s/="\(0[Xx][0-9a-fA-F][0-9a-fA-F]*\)"/=\1/;
+	# ... and from configs defined from other configs
+	s/="\(CONFIG_[A-Za-z0-9_][A-Za-z0-9_]*\)"/=$(\1)/;
 	# Change '1' and empty values to "y" (not perfect, but
 	# supports conditional compilation in the makefiles
 	s/=$/=y/;