hi Ard: > > The following is schematic diagram of the program before and after the > > modification. > > > > Before: > > if (memstart_addr + linear_region_size < memblock_end_of_DRAM()) {} --(a) > > if (memory_limit != PHYS_ADDR_MAX) {} --(b) > > if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && phys_initrd_size) {} --(c) > > if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {} --(d)* > > > > After: > > if (memstart_addr + linear_region_size < memblock_end_of_DRAM()) {} --(a) > > if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {} --(d)* > > if (memory_limit != PHYS_ADDR_MAX) {} --(b) > > if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && phys_initrd_size) {} --(c) > > > > After grouping modification of memstart_address by moving linear region > > randomization ahead of memory_init, driver can safely using macro, > > __phys_to_virt, in (b) or (c), if necessary. > > > > Why is this an advantage?
1st, by putting (d) right behind (a), driver can safely uses macro, __phys_to_virt that depends on memstart_address, in (b) and (c) if necessary. That means: (a) (d) ----- finish modification of memstart_address -------- (b) --> can safely use __phys_to_virt (c) --> can safely use __phys_to_virt 2nd, it can make current driver more concise. Letting (d) right behind (a), as below v3 patch shows, https://lkml.org/lkml/2019/4/8/683 it can put initrd_start/initrd_end to be calculated only when linear mapping check pass and concise the driver by eliminating "if (IS_ENABLED(CONFIG_BLK_DEV_INITRD) && phys_initrd_size) " as patch shows. Thanks for your message.