[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v4 07/17] xen/arm: introduce a helper to parse device tree processor node
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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |