On Thu, Aug 13, 2020 at 01:28:29PM +0200, Stefan Roese wrote: > On 13.08.20 13:14, Andy Shevchenko wrote: > > On Thu, Aug 13, 2020 at 07:47:52AM +0200, Stefan Roese wrote: > > > Since commit 86cf1c82850f ("configs: Migrate CONFIG_NR_DRAM_BANKS") & > > > commit 999a772d9f24 ("Kconfig: Migrate CONFIG_NR_DRAM_BANKS"), > > > CONFIG_NR_DRAM_BANKS is always defined with a value (4 is default). > > > It makes no sense to still carry code that is guarded with > > > "#ifndef CONFIG_NR_DRAM_BANKS" (and similar). This patch removes > > > all these unreferenced code paths. > > > > ... > > > > > int pci_addr_cells, addr_cells, size_cells; > > > + struct bd_info *bd = gd->bd; > > > int cells_per_record; > > > const u32 *prop; > > > int len; > > > > > /* Add a region for our local memory */ > > > > > -#ifdef CONFIG_NR_DRAM_BANKS > > > - struct bd_info *bd = gd->bd; > > > - > > > > Can we leave assignment here? > > Sure. Just curious why? Is it recommended not to make the assignment > with the declaration?
Slightly easier to read and understand the code. I find it's hard when you need to spend additional 1,2...10 seconds to go around and see where this value comes from. Easy question to ask when you see such code: is this parameter evaluation (defensive programming) or some assignment happened earlier to check? -- With Best Regards, Andy Shevchenko