> On 22 Apr 2024, at 11:24, Julien Grall <jul...@xen.org> wrote:
>
> Hi,
>
> On 22/04/2024 10:26, Michal Orzel wrote:
>> On 22/04/2024 10:07, Luca Fancellu wrote:
>>>
>>>
>>> Hi Michal,
>>>
>>>>> + for ( cells = reg, i = 0; cells < reg + nr_cells; i++, cells +=
>>>>> reg_size )
>>>>> + {
>>>>> + u64 start = dt_read_number(cells, addrcells);
>>>> We should no longer use Linux derived types like u64. Use uint64_t.
>>>>
>>>>> + u64 size = dt_read_number(cells + addrcells, sizecells);
>>>>> +
>>>>> + dt_dprintk(" Bank %d: %#"PRIx64"->%#"PRIx64"\n",
>>>>> + i, start, start + size);
>>>> i is unsigned so the correct format specifier should be %u
>>>
>>> Right, should have been more careful when copying the code from above
>>>
>>>>>
>>>>> +void __init shm_mem_node_fill_reg_range(const struct kernel_info *kinfo,
>>>>> + __be32 *reg, int *nr_cells,
>>>>> + int addrcells, int sizecells)
>>>>> +{
>>>>> + const struct membanks *mem = &kinfo->shm_mem.common;
>>>>> + unsigned int i;
>>>>> + __be32 *cells;
>>>>> +
>>>>> + BUG_ON(!nr_cells || !reg);
>>>>> +
>>>>> + cells = ®[*nr_cells];
>>>>> + for ( i = 0; i < mem->nr_banks; i++ )
>>>>> + {
>>>>> + u64 start = mem->bank[i].start;
>>>> ditto
>>>
>>> Will fix, here paddr_t should be ok isn’t it?
>> yes
>>>
>>>>
>>>> Rest LGTM:
>>>> Reviewed-by: Michal Orzel <michal.or...@amd.com>
>>>
>>> Thanks, I will send the next one shortly.
>> I don't think there is a need to respin the whole series just for these
>> fixes.
>> You should wait for the committers opinion.
>
> AFAICT, there are multiple changes requested in various line. So I would
> rather prefer if this is respinned.
>
> If this is the only patch that requires to change. You could send a new one
> in reply-to this patch. I think b4 is clever enough to pick up the new
> version in that case.
All the other patches are already reviewed by Michal, if you agree with his
review it’s ok for me to respin only this one
Cheers,
Luca
>
> Cheers,
>
> --
> Julien Grall
