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

[Jan Beulich <jbeulich@xxxxxxxx>]

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.

Jan