Re: [PATCH v4 07/17] xen/arm: introduce a helper to parse device tree processor node

[Michal Orzel <michal.orzel@xxxxxxx>]

On 25/04/2023 10:47, Jan Beulich wrote:
> 
> 
> On 25.04.2023 10:39, Michal Orzel wrote:
>> Hi Jan,
>>
>> On 25/04/2023 10:20, Jan Beulich wrote:
>>>
>>>
>>> On 25.04.2023 09:56, Henry Wang wrote:
>>>> From: Wei Chen <wei.chen@xxxxxxx>
>>>>
>>>> Processor NUMA ID information is stored in device tree's processor
>>>> node as "numa-node-id". We need a new helper to parse this ID from
>>>> processor node. If we get this ID from processor node, this ID's
>>>> validity still need to be checked. Once we got a invalid NUMA ID
>>>> from any processor node, the device tree will be marked as NUMA
>>>> information invalid.
>>>>
>>>> Since new helpers need to know the NUMA status, move the
>>>> enum dt_numa_status to the Arm NUMA header.
>>>>
>>>> Signed-off-by: Wei Chen <wei.chen@xxxxxxx>
>>>> Signed-off-by: Henry Wang <Henry.Wang@xxxxxxx>
>>>> ---
>>>> v3 -> v4:
>>>> 1. No change.
>>>> v2 -> v3:
>>>> 1. Move the enum dt_numa_status to the Arm NUMA header.
>>>> 2. Update the year in copyright to 2023.
>>>> v1 -> v2:
>>>> 1. Move numa_disabled from fdt_numa_processor_affinity_init
>>>>    to fdt_parse_numa_cpu_node.
>>>> 2. Move invalid NUMA id check to fdt_parse_numa_cpu_node.
>>>> 3. Return ENODATA for normal dtb without NUMA info.
>>>> 4. Use NUMA status helpers instead of SRAT functions.
>>>> ---
>>>>  xen/arch/arm/Makefile           |  1 +
>>>>  xen/arch/arm/include/asm/numa.h |  8 +++++
>>>>  xen/arch/arm/numa.c             |  8 +----
>>>>  xen/arch/arm/numa_device_tree.c | 64 +++++++++++++++++++++++++++++++++
>>>>  4 files changed, 74 insertions(+), 7 deletions(-)
>>>>  create mode 100644 xen/arch/arm/numa_device_tree.c
>>>
>>> As asked for in various other contexts, may I please ask that new files
>>> prefer dashes over underscores in their names? Additionally short but
>>> still descriptive names are imo to be generally preferred; in the case
>>> here how about numa-dt.c?
>>
>> Seeing that you made this request multiple times within the last months, 
>> maybe it would
>> be better to write it down in CODING_STYLE or CONTRIBUTING? Otherwise, you 
>> will keep making
>> these requests indefinitely without people being able to know things like 
>> that before pushing
>> new files (+ this always requires respin).
> 
> Well. I could make a try, but getting ./CODING_STYLE changed has proven
> to be difficult in the past, and I would prefer to not again sit on such
> a patch for months or years. IOW I've become quite hesitant to submit
> such patches, even more so for things which - imo - should go without
> saying.

I understand your point. It might be worth asking e.g. on a community call
to see what others think (for now I did not see any objections). It might be
that everyone is ok with it under good justification.

~Michal