[U-Boot] [PATCH v3 1/4] lib: fdtdec: Add new variable ram_start to global data

[Marek Vasut]

On 06/25/2018 02:56 PM, Tom Rini wrote:
> On Mon, Jun 25, 2018 at 08:15:34AM +0200, Michal Simek wrote:
>> Hi,
>>
>> On 22.6.2018 21:28, Simon Glass wrote:
>>> Hi,
>>>
>>> On 22 June 2018 at 01:41, Michal Simek <michal.simek at xilinx.com> wrote:
>>>> Hi Simon,
>>>>
>>>> On 18.6.2018 08:18, Siva Durga Prasad Paladugu wrote:
>>>>> Added new variable ram_start to global data structure for holding
>>>>> the start address of first bank of RAM, and then use this ram_start
>>>>> for calculating ram_top properly. This patch fixes the erroneous
>>>>> calculation of ram_top incase of non zero ram start address.
>>>>> This patch also renames fdtdec_setup_memory_size() to
>>>>> fdtdec_setup_mem_size_start() as this routine now takes care
>>>>> of memory size and start.
>>>>>
>>>>> Signed-off-by: Siva Durga Prasad Paladugu <siva.durga.paladugu at xilinx.com>
>>>>> Signed-off-by: Michal Simek <michal.simek at xilinx.com>
>>>>> ---
>>>>> Changes from v2:
>>>>> - Used new varibale ram_start
>>>>> - Rename fdtdec_setup_memory_size
>>>>>
>>>>> Changes from v1:
>>>>> - None
>>>>> ---
>>>>>  arch/arm/mach-mvebu/arm64-common.c                       |  2 +-
>>>>>  board/emulation/qemu-arm/qemu-arm.c                      |  2 +-
>>>>>  board/renesas/alt/alt.c                                  |  2 +-
>>>>>  board/renesas/blanche/blanche.c                          |  2 +-
>>>>>  board/renesas/draak/draak.c                              |  2 +-
>>>>>  board/renesas/eagle/eagle.c                              |  2 +-
>>>>>  board/renesas/gose/gose.c                                |  2 +-
>>>>>  board/renesas/koelsch/koelsch.c                          |  2 +-
>>>>>  board/renesas/lager/lager.c                              |  2 +-
>>>>>  board/renesas/porter/porter.c                            |  2 +-
>>>>>  board/renesas/salvator-x/salvator-x.c                    |  2 +-
>>>>>  board/renesas/silk/silk.c                                |  2 +-
>>>>>  board/renesas/stout/stout.c                              |  2 +-
>>>>>  board/renesas/ulcb/ulcb.c                                |  2 +-
>>>>>  board/st/stm32f429-discovery/stm32f429-discovery.c       |  2 +-
>>>>>  board/st/stm32f429-evaluation/stm32f429-evaluation.c     |  2 +-
>>>>>  board/st/stm32f469-discovery/stm32f469-discovery.c       |  2 +-
>>>>>  board/st/stm32h743-disco/stm32h743-disco.c               |  2 +-
>>>>>  board/st/stm32h743-eval/stm32h743-eval.c                 |  2 +-
>>>>>  board/xilinx/zynq/board.c                                |  2 +-
>>>>>  board/xilinx/zynqmp/zynqmp.c                             |  2 +-
>>>>>  board/xilinx/zynqmp_r5/board.c                           |  2 +-
>>>>>  common/board_f.c                                         |  4 ++--
>>>>>  include/asm-generic/global_data.h                        |  1 +
>>>>>  include/fdtdec.h                                         | 16 +++++++++-------
>>>>>  lib/fdtdec.c                                             |  3 ++-
>>>>>  tools/patman/func_test.py                                |  2 +-
>>>>>  tools/patman/test/0000-cover-letter.patch                |  2 +-
>>>>>  ...orrect-cast-for-sandbox-in-fdtdec_setup_memory_.patch |  4 ++--
>>>>>  tools/patman/test/test01.txt                             |  2 +-
>>>>>  30 files changed, 41 insertions(+), 37 deletions(-)
>>>
>>> [...]
>>>
>>>> sjg: Do you see any issue with this patch?
>>>
>>> I think it is OK. Would like to get more people to look at it though.
>>>
>>>>
>>>> I can't see the reason for fixing tools/patman but I will wait for you.
>>>
>>> Changing patman tests is OK with me. Keeps thing consistent.
>>
>> thanks Simon.
>>
>> Tom: Do you see any issue with this change?
> 
> Yes, thanks.  You can take it via your tree once Marek has had a chance
> to test things.
> 
> Reviewed-by: Tom Rini <trini at konsulko.com>

I'd rather like the rename in a separate patch, since that makes it hard
to review. I don't see how "This patch fixes the erroneous
calculation of ram_top incase of non zero ram start address." thought,
maybe it's hidden in this mega-patch.

-- 
Best regards,
Marek Vasut