[PATCH] Documentation: xfs: consolidate XFS docs into its own subdirectory

XFS docs are currently in upper-level Documentation/filesystems. Although these are currently 4 docs, they are already outstanding as a group and can be moved to its own subdirectory. Consolidate them into Documentation/filesystems/xfs/. Signed-off-by: Bagas Sanjaya --- Documentation/filesystem

Re: [PATCH] Documentation: xfs: consolidate XFS docs into its own subdirectory

On 21/11/2023 10:56, Bagas Sanjaya wrote: XFS docs are currently in upper-level Documentation/filesystems. Although these are currently 4 docs, they are already outstanding as a group and can be moved to its own subdirectory. Consolidate them into Documentation/filesystems/xfs/. Signed-off-by

Re: [PATCH] Documentation: xfs: consolidate XFS docs into its own subdirectory

On Tue, Nov 21, 2023 at 11:16:16AM +0100, Vegard Nossum wrote: > > On 21/11/2023 10:56, Bagas Sanjaya wrote: > > XFS docs are currently in upper-level Documentation/filesystems. > > Although these are currently 4 docs, they are already outstanding as > > a group and can be moved to its own subdire

Re: [PATCH RFC 10/22] drivers: base: Move cpu_dev_init() after node_dev_init()

On Mon, Nov 13, 2023 at 08:00:19AM +, Russell King (Oracle) wrote: > On Mon, Nov 13, 2023 at 10:58:46AM +1000, Gavin Shan wrote: > > > > > > On 11/7/23 20:30, Russell King (Oracle) wrote: > > > From: James Morse > > > > > > NUMA systems require the node descriptions to be ready before CPUs

Re: [PATCH RFC 08/22] drivers: base: Implement weak arch_unregister_cpu()

On Tue, Nov 07, 2023 at 10:29:59AM +, Russell King wrote: > From: James Morse > > Add arch_unregister_cpu() to allow the ACPI machinery to call > unregister_cpu(). This is enough for arm64, riscv and loongarch, but > needs to be overridden by x86 and ia64 who need to do more work. > > CC: Je

[PATCH 00/21] Initial cleanups for vCPU hotplug

Hi, Rather than posting the entire set of vCPU kernel patches, this is a subset of those patches which I hope will be able to be appropriately queued for the next merge window. I am also hoping that nothing here is covered by Rafael's concerns he alluded to in his response to the RFC v3 series. T

[PATCH 01/21] arch_topology: Make register_cpu_capacity_sysctl() tolerant to late CPUs

From: James Morse register_cpu_capacity_sysctl() adds a property to sysfs that describes the CPUs capacity. This is done from a subsys_initcall() that assumes all possible CPUs are registered. With CPU hotplug, possible CPUs aren't registered until they become present, (or for arm64 enabled). Th

[PATCH 04/21] Loongarch: remove arch_*register_cpu() exports

arch_register_cpu() and arch_unregister_cpu() are not used by anything that can be a module - they are used by drivers/base/cpu.c and drivers/acpi/acpi_processor.c, neither of which can be a module. Remove the exports. Reviewed-by: Gavin Shan Signed-off-by: Russell King (Oracle) --- arch/loong

[PATCH 02/21] x86: intel_epb: Don't rely on link order

From: James Morse intel_epb_init() is called as a subsys_initcall() to register cpuhp callbacks. The callbacks make use of get_cpu_device() which will return NULL unless register_cpu() has been called. register_cpu() is called from topology_init(), which is also a subsys_initcall(). This is frag

[PATCH 03/21] x86/topology: remove arch_*register_cpu() exports

arch_register_cpu() and arch_unregister_cpu() are not used by anything that can be a module - they are used by drivers/base/cpu.c and drivers/acpi/acpi_processor.c, neither of which can be a module. Remove the exports. Reviewed-by: Gavin Shan Signed-off-by: Russell King (Oracle) --- arch/x86/k

[PATCH 06/21] drivers: base: Use present CPUs in GENERIC_CPU_DEVICES

From: James Morse Three of the five ACPI architectures create sysfs entries using register_cpu() for present CPUs, whereas arm64, riscv and all GENERIC_CPU_DEVICES do this for possible CPUs. Registering a CPU is what causes them to show up in sysfs. It makes very little sense to register all po

[PATCH 07/21] drivers: base: Allow parts of GENERIC_CPU_DEVICES to be overridden

From: James Morse Architectures often have extra per-cpu work that needs doing before a CPU is registered, often to determine if a CPU is hotpluggable. To allow the ACPI architectures to use GENERIC_CPU_DEVICES, move the cpu_register() call into arch_register_cpu(), which is made __weak so archi

[PATCH 05/21] ACPI: Move ACPI_HOTPLUG_CPU to be disabled on arm64 and riscv

From: James Morse Neither arm64 nor riscv support physical hotadd of CPUs that were not present at boot. For arm64 much of the platform description is in static tables which do not have update methods. arm64 does support HOTPLUG_CPU, which is backed by a firmware interface to turn CPUs on and off

[PATCH 09/21] drivers: base: add arch_cpu_is_hotpluggable()

The differences between architecture specific implementations of arch_register_cpu() are down to whether the CPU is hotpluggable or not. Rather than overriding the weak version of arch_register_cpu(), provide a function that can be used to provide this detail instead. Reviewed-by: Shaoqin Huang S

[PATCH 08/21] drivers: base: Implement weak arch_unregister_cpu()

From: James Morse Add arch_unregister_cpu() to allow the ACPI machinery to call unregister_cpu(). This is enough for arm64, riscv and loongarch, but needs to be overridden by x86 and ia64 who need to do more work. CC: Jean-Philippe Brucker Signed-off-by: James Morse Reviewed-by: Shaoqin Huang

[PATCH 11/21] drivers: base: Print a warning instead of panic() when register_cpu() fails

From: James Morse loongarch, mips, parisc, riscv and sh all print a warning if register_cpu() returns an error. Architectures that use GENERIC_CPU_DEVICES call panic() instead. Errors in this path indicate something is wrong with the firmware description of the platform, but the kernel is able t

[PATCH 10/21] drivers: base: Move cpu_dev_init() after node_dev_init()

From: James Morse NUMA systems require the node descriptions to be ready before CPUs are registered. This is so that the node symlinks can be created in sysfs. Currently no NUMA platform uses GENERIC_CPU_DEVICES, meaning that CPUs are registered by arch code, instead of cpu_dev_init(). Move cpu

[PATCH 12/21] arm64: setup: Switch over to GENERIC_CPU_DEVICES using arch_register_cpu()

From: James Morse To allow ACPI's _STA value to hide CPUs that are present, but not available to online right now due to VMM or firmware policy, the register_cpu() call needs to be made by the ACPI machinery when ACPI is in use. This allows it to hide CPUs that are unavailable from sysfs. Switch

[PATCH 13/21] arm64: convert to arch_cpu_is_hotpluggable()

Convert arm64 to use the arch_cpu_is_hotpluggable() helper rather than arch_register_cpu(). Reviewed-by: Shaoqin Huang Reviewed-by: Gavin Shan Signed-off-by: Russell King (Oracle) --- arch/arm64/kernel/setup.c | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/arm

[PATCH 14/21] x86/topology: Switch over to GENERIC_CPU_DEVICES

From: James Morse Now that GENERIC_CPU_DEVICES calls arch_register_cpu(), which can be overridden by the arch code, switch over to this to allow common code to choose when the register_cpu() call is made. x86's struct cpus come from struct x86_cpu, which has no other members or users. Remove thi

[PATCH 15/21] x86/topology: use weak version of arch_unregister_cpu()

Since the x86 version of arch_unregister_cpu() is the same as the weak version, drop the x86 specific version. Reviewed-by: Gavin Shan Signed-off-by: Russell King (Oracle) --- Changes since RFC v3: * Adapt to removal of EXPORT_SYMBOL()s --- arch/x86/kernel/topology.c | 5 - 1 file changed,

[PATCH 17/21] LoongArch: Switch over to GENERIC_CPU_DEVICES

From: James Morse Now that GENERIC_CPU_DEVICES calls arch_register_cpu(), which can be overridden by the arch code, switch over to this to allow common code to choose when the register_cpu() call is made. This allows topology_init() to be removed. This is an intermediate step to the logic being

[PATCH 18/21] LoongArch: Use the __weak version of arch_unregister_cpu()

From: James Morse LoongArch provides its own arch_unregister_cpu(). This clears the hotpluggable flag, then unregisters the CPU. It isn't necessary to clear the hotpluggable flag when unregistering a cpu. unregister_cpu() writes NULL to the percpu cpu_sys_devices pointer, meaning cpu_is_hotplugg

[PATCH 16/21] x86/topology: convert to use arch_cpu_is_hotpluggable()

Convert x86 to use the arch_cpu_is_hotpluggable() helper rather than arch_register_cpu(). Reviewed-by: Gavin Shan Signed-off-by: Russell King (Oracle) --- arch/x86/kernel/topology.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/arch/x86/kernel/topology.c b/arch/x86/

[PATCH 19/21] LoongArch: convert to use arch_cpu_is_hotpluggable()

Convert loongarch to use the arch_cpu_is_hotpluggable() helper rather than arch_register_cpu(). Also remove the export as nothing should be using arch_register_cpu() outside of the core kernel/acpi code. Reviewed-by: Gavin Shan Signed-off-by: Russell King (Oracle) --- arch/loongarch/kernel/topo

[PATCH 20/21] riscv: Switch over to GENERIC_CPU_DEVICES

From: James Morse Now that GENERIC_CPU_DEVICES calls arch_register_cpu(), which can be overridden by the arch code, switch over to this to allow common code to choose when the register_cpu() call is made. This allows topology_init() to be removed. This is an intermediate step to the logic being

[PATCH 21/21] riscv: convert to use arch_cpu_is_hotpluggable()

Convert riscv to use the arch_cpu_is_hotpluggable() helper rather than arch_register_cpu(). Acked-by: Palmer Dabbelt Reviewed-by: Gavin Shan Signed-off-by: Russell King (Oracle) --- arch/riscv/kernel/setup.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/arch/riscv/

[PATCH v6 05/13] x86/bugs: Rename RETPOLINE to MITIGATION_RETPOLINE

CPU mitigations config entries are inconsistent, and names are hard to related. There are concrete benefits for both users and developers of having all the mitigation config options living in the same config namespace. The mitigation options should have consistency and start with MITIGATION. Rena

Re: [PATCH] Documentation: xfs: consolidate XFS docs into its own subdirectory

Hi Bagas, kernel test robot noticed the following build warnings: [auto build test WARNING on 98b1cc82c4affc16f5598d4fa14b1858671b2263] url: https://github.com/intel-lab-lkp/linux/commits/Bagas-Sanjaya/Documentation-xfs-consolidate-XFS-docs-into-its-own-subdirectory/20231121-180057 base

Re: [PATCH] Documentation: xfs: consolidate XFS docs into its own subdirectory

entation-xfs-consolidate-XFS-docs-into-its-own-subdirectory/20231121-180057 > base: 98b1cc82c4affc16f5598d4fa14b1858671b2263 > patch link: > https://lore.kernel.org/r/20231121095658.28254-1-bagasdotme%40gmail.com > patch subject: [PATCH] Documentation: xfs: consolidate X