[PATCH v4 1/9] CONFIG_NR_DRAM_BANKS: Remove unreferenced code as its always defined

[Andy Shevchenko]

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