| Message ID | 1362596377-5827-15-git-send-email-benoit.thebaudeau@advansee.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Albert ARIBAUD |
| Headers | show |
-----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-----
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
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
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
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
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
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
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
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
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
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
-----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-----
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
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
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
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
-----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-----
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
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.
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,
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/;
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(+)