cpufeatures merge candidate
Subsystems (3)
Nicholas Piggin
reviewercover cpufeatures merge candidate
I expect this will require still some more changes, but I think it's getting close to polished. Intention is to make it default off and unsupported at the initial merge, to give a new more weeks to test then freeze the format.
I included the firmware cpufeatures patch here as well.
Thanks,
Nick
Nicholas Piggin
reviewerPATCH 1/3 powerpc/64s: POWER9 no LPCR VRMASD bits
POWER9/ISAv3 has no VRMASD field in LPCR. Don't set reserved bits.
--- arch/powerpc/kernel/cpu_setup_power.S | 21 ++++++++++++--------- 1 file changed, 12 insertions(+), 9 deletions(-)
arch/powerpc/kernel/cpu_setup_power.S +12 -9
@@ -29,7 +29,7 @@ _GLOBAL(__setup_cpu_power7) li r0,0 mtspr SPRN_LPID,r0 mfspr r3,SPRN_LPCR - bl __init_LPCR + bl __init_LPCR_ISA206 bl __init_tlb_power7 mtlr r11 blr
@@ -42,7 +42,7 @@ _GLOBAL(__restore_cpu_power7) li r0,0 mtspr SPRN_LPID,r0 mfspr r3,SPRN_LPCR - bl __init_LPCR + bl __init_LPCR_ISA206 bl __init_tlb_power7 mtlr r11 blr
@@ -59,7 +59,7 @@ _GLOBAL(__setup_cpu_power8) mtspr SPRN_LPID,r0 mfspr r3,SPRN_LPCR ori r3, r3, LPCR_PECEDH - bl __init_LPCR + bl __init_LPCR_ISA206 bl __init_HFSCR bl __init_tlb_power8 bl __init_PMU_HV
@@ -80,7 +80,7 @@ _GLOBAL(__restore_cpu_power8) mtspr SPRN_LPID,r0 mfspr r3,SPRN_LPCR ori r3, r3, LPCR_PECEDH - bl __init_LPCR + bl __init_LPCR_ISA206 bl __init_HFSCR bl __init_tlb_power8 bl __init_PMU_HV
@@ -103,7 +103,7 @@ _GLOBAL(__setup_cpu_power9) or r3, r3, r4 LOAD_REG_IMMEDIATE(r4, LPCR_UPRT | LPCR_HR) andc r3, r3, r4 - bl __init_LPCR + bl __init_LPCR_ISA300 bl __init_HFSCR bl __init_tlb_power9 bl __init_PMU_HV
@@ -126,7 +126,7 @@ _GLOBAL(__restore_cpu_power9) or r3, r3, r4 LOAD_REG_IMMEDIATE(r4, LPCR_UPRT | LPCR_HR) andc r3, r3, r4 - bl __init_LPCR + bl __init_LPCR_ISA300 bl __init_HFSCR bl __init_tlb_power9 bl __init_PMU_HV
@@ -144,7 +144,7 @@ __init_hvmode_206: std r5,CPU_SPEC_FEATURES(r4) blr -__init_LPCR: +__init_LPCR_ISA206: /* Setup a sane LPCR: * Called with initial LPCR in R3 *
@@ -157,6 +157,11 @@ __init_LPCR: * * Other bits untouched for now */ + li r5,0x10 + rldimi r3,r5, LPCR_VRMASD_SH, 64-LPCR_VRMASD_SH-5 + + /* POWER9 has no VRMASD */ +__init_LPCR_ISA300: li r5,1 rldimi r3,r5, LPCR_LPES_SH, 64-LPCR_LPES_SH-2 ori r3,r3,(LPCR_PECE0|LPCR_PECE1|LPCR_PECE2)
@@ -165,8 +170,6 @@ __init_LPCR: clrrdi r3,r3,1 /* clear HDICE */ li r5,4 rldimi r3,r5, LPCR_VC_SH, 0 - li r5,0x10 - rldimi r3,r5, LPCR_VRMASD_SH, 64-LPCR_VRMASD_SH-5 mtspr SPRN_LPCR,r3 isync blr
Signature · 1 line
2.11.0
Nicholas Piggin
reviewerPATCH 2/3 of/fdt: introduce of_scan_flat_dt_subnodes and of_get_flat_dt_phandle
In reply to Nicholas PigginIntroduce primitives for FDT parsing. These will be used for powerpc cpufeatures node scanning, which has quite complex structure but should be processed early.
--- drivers/of/fdt.c | 38 ++++++++++++++++++++++++++++++++++++++ include/linux/of_fdt.h | 6 ++++++ 2 files changed, 44 insertions(+)
drivers/of/fdt.c +38 -0
@@ -754,6 +754,36 @@ int __init of_scan_flat_dt(int (*it)(unsigned long node, }/** +* of_scan_flat_dt_subnodes - scan sub-nodes of a node call callback on each. +* @it: callback function +* @data: context data pointer +* +* This function is used to scan sub-nodes of a node. +*/ +int __init of_scan_flat_dt_subnodes (unsigned long parent, +int (*it)(unsigned long node, +const char *uname, +void *data), +void *data) +{ +const void *blob = initial_boot_params; +int node; + +fdt_for_each_subnode (node, blob, parent) { +const char *pathp; +int rc; + + pathp =fdt_get_name (blob, node,NULL ); +if (*pathp =='/' ) + pathp =kbasename (pathp); + rc =it (node, pathp, data); +if (rc) +return rc; + } +return 0 ; +} + +/** * of_get_flat_dt_subnode_by_name - get the subnode by given name * * @node: the parent node
@@ -812,6 +842,14 @@ int __init of_flat_dt_match(unsigned long node, const char *const *compat)return of_fdt_match (initial_boot_params, node, compat); } +/** +* of_get_flat_dt_prop - Given a node in the flat blob, return the phandle +*/ +uint32_t __init of_get_flat_dt_phandle (unsigned long node) +{ +return fdt_get_phandle (initial_boot_params, node); +} +struct fdt_scan_status {const char *name;int namelen;
include/linux/of_fdt.h +6 -0
@@ -54,6 +54,11 @@ extern char __dtb_end[];extern int of_scan_flat_dt (int (*it)(unsigned long node,const char *uname,int depth,void *data),void *data); +extern int of_scan_flat_dt_subnodes (unsigned long node, +int (*it)(unsigned long node, +const char *uname, +void *data), +void *data);extern int of_get_flat_dt_subnode_by_name (unsigned long node,const char *uname); extern const void *of_get_flat_dt_prop(unsigned long node, const char *name,
@@ -62,6 +67,7 @@ extern int of_flat_dt_is_compatible(unsigned long node, const char *name);extern int of_flat_dt_match (unsigned long node,const char *const *matches);extern unsigned long of_get_flat_dt_root (void );extern int of_get_flat_dt_size (void ); +extern uint32_t of_get_flat_dt_phandle (unsigned long node);extern int early_init_dt_scan_chosen (unsigned long node,const char *uname,int depth,void *data);
Signature · 1 line
2.11.0
Nicholas Piggin
reviewerPATCH 3/3 powerpc/64s: cpufeatures: add initial implementation for cpufeatures
In reply to Nicholas PigginThe /cpus/features dt binding describes architected CPU features along with some compatibility, privilege, and enablement properties that allow flexibility with discovering and enabling capabilities.
Presence of this feature implies a base level of functionality, then additional feature nodes advertise the presence of new features.
A given feature and its setup procedure is defined once and used by all CPUs which are compatible by that feature. Features that follow a supported "prescription" can be enabled by a hypervisor or OS that does not understand them natively.
One difference with features after this patch is that PPC_FEATURE2_EBB is set independent of PMU init. EBB facility is more general than PMU, so I think this is reasonable.
---
Since last post:
- Looked at XIVE patches compatibility. There is a dependency there now on LPCR setup (HEIC, LPES, etc).
- Split vector-scalar feature from vector
- Get cpu_name from cputable if exists, for /proc/cpuinfo compatibility.
Testing under mambo shows a few differences with POWER8, but they all seem to be mambo related:
- HFSCR bit 54 and 57 are now clear (mambo sets at init)
- PMAO_BUG is set. This is due to mambo setting architected POWER8 mode and POWER8E PVR. Current kernels lose PMAO_BUG bit.
- CI_LARGE_PAGE is now set (mambo boot does not set it for some reason, haven't looked at why).
Under POWER9 I haven't found differences.
.../devicetree/bindings/powerpc/cpufeatures.txt | 264 +++++++++ arch/powerpc/Kconfig | 16 + arch/powerpc/include/asm/cpu_has_feature.h | 4 +- arch/powerpc/include/asm/cpufeatures.h | 57 ++ arch/powerpc/include/asm/cputable.h | 2 + arch/powerpc/include/asm/reg.h | 1 + arch/powerpc/kernel/Makefile | 1 + arch/powerpc/kernel/cpufeatures.c | 631 +++++++++++++++++++++ arch/powerpc/kernel/cputable.c | 37 +- arch/powerpc/kernel/prom.c | 333 ++++++++++- arch/powerpc/kernel/setup-common.c | 2 +- arch/powerpc/kernel/setup_64.c | 15 +- 12 files changed, 1346 insertions(+), 17 deletions(-) create mode 100644 Documentation/devicetree/bindings/powerpc/cpufeatures.txt create mode 100644 arch/powerpc/include/asm/cpufeatures.h create mode 100644 arch/powerpc/kernel/cpufeatures.c
Documentation/devicetree/bindings/powerpc/cpufeatures.txt new file +264 -0
@@ -0,0 +1,264 @@ +powerpc cpu features binding +============================ + +The device tree describes supported CPU features as nodes containing +compatibility and enablement information as properties. + +The binding specifies features common to all CPUs in the system. +Heterogeneous CPU features are not supported at present (such could be added +by providing nodes with additional features and linking those to particular +CPUs). + +This binding is intended to provide fine grained control of CPU features at +all levels of the stack (firmware, hypervisor, OS, userspace), with the +ability for new CPU features to be used by some components without all +components being upgraded (e.g., a new floating point instruction could be +used by userspace math library without upgrading kernel and hypervisor). + +The binding is passed to the hypervisor by firmware. The hypervisor must +remove any features that require hypervisor enablement but that it does not +enable. It must remove any features that depend on removed features. It may +pass remaining features usable to the OS and PR to guests, depending on +configuration policy (not specified here). + +The modified binding is passed to the guest by hypervisor, with HV bit +cleared from the usable-mask and the hv-support and hfscr-bit properties +removed. The guest must similarly rmeove features that require OS enablement +that it does not enable. The OS may pass PR usable features to userspace via +ELF AUX vectors AT_HWCAP, AT_HWCAP2, AT_HWCAP3, etc., or use some other +method (outside the scope of this specification). + +The binding will specify a "base" level of features that will be present +when the cpu features binding exists. Additional features will be explicitly +specified. + +/cpus/features node binding +--------------------------- + +Node: features + +Description: Container of CPU feature nodes. + +The node name must be "features" and it must be a child of the node "/cpus". + +The node is optional but should be provided by new firmware. + +Each child node of cpufeatures represents an architected CPU feature (e.g., +a new set of vector instructions) or an important CPU performance +characteristic (e.g., fast unaligned memory operations). The specification +of each feature (instructions, registers, exceptions, etc.) will be +documented with device tree bindings. + +As a rough guide, features should be based on functional groups of changes, +those that share common enablement requirements, that share particular +registers or functionality. For example, "POWER9" would be too general, and +a new feature for every instruction would be too specific. The "summary of +changes" preface in Power ISA specification is a good guideline for the +architected features. + +Features should be "positive" where possible. For example the presence of a +feature node should indicate the presence of a new CPU feature (e.g., a +new instruction or register). An errata workaround for example would then +remove that feature from the device tree to disable it. "Negative" features +may be unavoidable in some cases. + +Properties: + +- device_type + Usage: required + Value type: string + Definition: "cpu-features" + +- isa + Usage: required + Value type: <u32> + Definition: + + isa that the CPU is currently running in. This provides instruction set + compatibility, less the individual feature nodes. For example, an ISA v3.0 + implementation that lacks the "transactional-memory" cpufeature node + should not use transactional memory facilities. + + Value corresponds to the "Power ISA Version" multiplied by 1000. + For example, <3000> corresponds to Version 3.0, <2070> to Version 2.07. + The minor digit is available for revisions. + +/cpus/features/feature node bindings +------------------------------------ + +Node: A string describing an architected CPU feature, e.g., "vsx". + +Description: An architected feature supported by the CPUs. + +The name of the node will follow a convention such that software will +match known features by a string comparison with the node name. Presence +of the node indicates the feature is available to use (XXX: could +advertise all supported by hardware, with disabled/enabled status +property). + +The name of the child node corresponds to the name of the feature. +Software will detect known features by string matching. + +Properties: + +- isa + Usage: required + Value type: <u32> + Definition: + + First level of the Power ISA that the feature appears in. + Software should filter out features when constraining the + environment to a particular ISA version. + + Value is defined similarly to /cpus/features/isa + +- usable-mask + Usage: required + Value type: <u32> bit mask + Definition: + Bit numbers are LSB0 + bit 0 - PR (problem state / user mode) + bit 1 - OS (privileged state) + bit 2 - HV (hypervisor state) + All other bits reserved and should be zero. + + This property describes the privilege levels and/or software components + that can use the feature. + + If bit 0 is set, then the hwcap-bit-nr property will exist. + + Reserved bits must be treated as the feature being unsupported. + +- hv-support + Usage: optional + Value type: <u32> + Definition: + 1 - Custom + 2 - HFSCR + Other values reserved. + + This property describes the HV privilege state support required to + enable the feature. If the property does not exist then no support is + required. + + If the value of this property is 1, then the hypervisor must have + explicit support for this feature. + + If the value of this property is 2, then the hfscr-bit-nr property + will exist. + + Reserved values must be treated as the feature being unsupported. + +- os-support + Usage: optional + Value type: <u32> + Definition: + 1 - Custom + 2 - FSCR + Other values reserved. + + This property describes the OS privilege state support required to + enable the feature. If the property does not exist then no support is + required. + + If the value of this property is 1, then the operating system must + have explicit support for this feature. + + If the value of this property is 2, then the fscr-bit-nr property will + exist. + + Reserved values must be treated as the feature being unsupported. + +- hfscr-bit-nr + Usage: optional + Value type: <u32> + Definition: HFSCR bit position (LSB0) + + This property exists when the hv-support property value is 2. This + property describes the bit number in the HFSCR register that the + hypervisor must set in order to enable this feature. + +- fscr-bit-nr + Usage: optional + Value type: <u32> + Definition: FSCR bit position (LSB0) + + This property exists when the os-support property value is 2. This + property describes the bit number in the FSCR register that the + operating system must set in order to enable this feature. + +- hwcap-bit-nr + Usage: optional + Value type: <u32> + Definition: AUX vector bit position (LSB0) + + This property may exist when the usable-mask property value has bit 0 + (PR) set. This property describes the bit number that should be set in + the ELF AUX hardware capability vectors in order to advertise this + feature to userspace. Bits 0-31 correspond to bits 0-31 in AT_HWCAP + vector. Bits 32-63 correspond to 0-31 in AT_HWCAP2 vector, and so on. + Missing AT_HWCAPx vectors implies that the feature is not enabled or + can not be advertised. Operating systems may provide a number of + unassigned hardware capability bits to allow for new features to be + advertised. + + Some properties representing features created before this binding are + advertised to userspace without a one-to-one hwcap bit number may not + specify this bit. Operating system will handle those bits specifically. + All new features usable by userspace will have a hwcap-bit-nr property. + +- dependencies + Usage: optional + Value type: <prop-encoded-array> + Definition: + + If this property exists then it is a list of phandles to cpu feature + nodes that must be enabled for this feature to be enabled. + + +Example +------- + + /cpus/features { + device_type = "cpu-features"; + + isa = <3020>; + + darn { + isa = <3000>; + usable-mask = <1 | 2 | 4>; + hwcap-bit-nr = <xx>; + }; + + scv { + isa = <3000>; + usable-mask = <1 | 2>; + os-support = <1>; + hwcap-bit-nr = <xx>; + }; + + stop { + isa = <3000>; + usable-mask = <2 | 4>; + hv-support = <1>; + os-support = <1>; + }; + + vsx2 (hypothetical) { + isa = <3010>; + usable-mask = <1 | 2 | 4>; + hv-support = <1>; + os-support = <1>; + hwcap-bit-nr = <xx>; + }; + + vsx2-newinsns { + isa = <3020>; + usable-mask = <1 | 2 | 4>; + os-support = <2>; + fscr-bit-nr = <xx>; + hwcap-bit-nr = <xx>; + dependencies = <&vsx2>; + }; + + };
arch/powerpc/Kconfig +16 -0
@@ -330,6 +330,22 @@ source "arch/powerpc/platforms/Kconfig" menu "Kernel options" +config PPC_CPUFEATURES_DT + bool "cpufeatures cpu setup and device tree support (UNSTABLE)" + depends on PPC_BOOK3S_64 + default n + ---help--- + cpufeatures is a proposed new device tree binding for describing + CPU compatibility and features. Saying y here will attempt to use + cpufeatures binding if the firmware provides it. This binding is + not stable, so a kernel built with this option may not function + properly with future firmware. + +config PPC_CPUFEATURES_ENABLE_UNKNOWN + bool "cpufeatures pass through unknown features to guest/userspace" + depends on PPC_CPUFEATURES_DT + default y + config HIGHMEM bool "High memory support" depends on PPC32
arch/powerpc/include/asm/cpu_has_feature.h +2 -2
@@ -1,5 +1,5 @@ -#ifndef __ASM_POWERPC_CPUFEATURES_H -#define __ASM_POWERPC_CPUFEATURES_H +#ifndef __ASM_POWERPC_CPU_HAS_FEATURE_H +#define __ASM_POWERPC_CPU_HAS_FEATURE_H#ifndef __ASSEMBLY__
arch/powerpc/include/asm/cpufeatures.h new file +57 -0
57 lines not on this page · raw message
arch/powerpc/include/asm/cputable.h +2 -0
@@ -118,7 +118,9 @@ extern struct cpu_spec *cur_cpu_spec;extern unsigned int __start___ftr_fixup, __stop___ftr_fixup; +extern void set_cur_cpu_spec (struct cpu_spec *s);extern struct cpu_spec *identify_cpu (unsigned long offset,unsigned int pvr); +extern void identify_cpu_name (unsigned int pvr);extern void do_feature_fixups (unsigned long value,void *fixup_start,void *fixup_end);
arch/powerpc/include/asm/reg.h +1 -0
@@ -365,6 +365,7 @@#define LPCR_MER_SH 11#define LPCR_GTSE ASM_CONST(0x0000000000000400)/* Guest Translation Shootdown Enable */ #define LPCR_TC ASM_CONST(0x0000000000000200)/* Translation control */ +#define LPCR_HEIC ASM_CONST(0x0000000000000010)/* Hypervisor External Interrupt Control */ #define LPCR_LPES 0x0000000c#define LPCR_LPES0 ASM_CONST(0x0000000000000008)/* LPAR Env selector 0 */ #define LPCR_LPES1 ASM_CONST(0x0000000000000004)/* LPAR Env selector 1 */
arch/powerpc/kernel/Makefile +1 -0
@@ -58,6 +58,7 @@ obj-$(CONFIG_PPC_RTAS) += rtas.o rtas-rtc.o $(rtaspci-y-y) obj-$(CONFIG_PPC_RTAS_DAEMON) += rtasd.o obj-$(CONFIG_RTAS_FLASH) += rtas_flash.o obj-$(CONFIG_RTAS_PROC) += rtas-proc.o +obj-$(CONFIG_PPC_CPUFEATURES_DT) += cpufeatures.o obj-$(CONFIG_EEH) += eeh.o eeh_pe.o eeh_dev.o eeh_cache.o \ eeh_driver.o eeh_event.o eeh_sysfs.o obj-$(CONFIG_GENERIC_TBSYNC) += smp-tbsync.o
arch/powerpc/kernel/cpufeatures.c new file +631 -0
631 lines not on this page · raw message
arch/powerpc/kernel/cputable.c +35 -2
@@ -23,7 +23,9 @@#include <asm/mmu.h> #include <asm/setup.h> -struct cpu_spec * cur_cpu_spec =NULL ; +static struct cpu_spec the_cpu_spec__read_mostly ; + +struct cpu_spec * cur_cpu_spec__read_mostly =NULL ;EXPORT_SYMBOL (cur_cpu_spec);/* The platform string corresponding to the real PVR */
@@ -2179,7 +2181,15 @@ static struct cpu_spec __initdata cpu_specs[] = {#endif /* CONFIG_E500 */ }; -static struct cpu_spec the_cpu_spec; +void __init set_cur_cpu_spec (struct cpu_spec *s) +{ +struct cpu_spec *t = &the_cpu_spec; + + t =PTRRELOC (t); + *t = *s; + + *PTRRELOC (&cur_cpu_spec) = &the_cpu_spec; +}static struct cpu_spec *__init setup_cpu_spec (unsigned long offset,struct cpu_spec *s)
@@ -2266,6 +2276,29 @@ struct cpu_spec * __init identify_cpu(unsigned long offset, unsigned int pvr)return NULL ; } +/* +* Used by cpufeatures to get the name for CPUs with a PVR table. +* If they don't hae a PVR table, cpufeatures gets the name from +* cpu device-tree node. +*/ +void __init identify_cpu_name (unsigned int pvr) +{ +struct cpu_spec *s = cpu_specs; +struct cpu_spec *t = &the_cpu_spec; +int i; + + s =PTRRELOC (s); + t =PTRRELOC (t); + +for (i =0 ; i <ARRAY_SIZE (cpu_specs); i++,s++) { +if ((pvr & s->pvr_mask) == s->pvr_value) { + t->cpu_name = s->cpu_name; +return ; + } + } +} + +#ifdef CONFIG_JUMP_LABEL_FEATURE_CHECKS struct static_key_true cpu_feature_keys[NUM_CPU_FTR_KEYS ] = { [0 ... NUM_CPU_FTR_KEYS - 1] = STATIC_KEY_TRUE_INIT
arch/powerpc/kernel/prom.c +322 -11
369 lines not on this page · raw message
arch/powerpc/kernel/setup-common.c +1 -1
@@ -256,7 +256,7 @@ static int show_cpuinfo(struct seq_file *m, void *v)seq_printf (m,"processor\t: %lu\n" , cpu_id);seq_printf (m,"cpu\t\t: " ); -if (cur_cpu_spec->pvr_mask) +if (cur_cpu_spec->pvr_mask && cur_cpu_spec->cpu_name)seq_printf (m,"%s" , cur_cpu_spec->cpu_name);else seq_printf (m,"unknown (%08x)" , pvr);
arch/powerpc/kernel/setup_64.c +14 -1
@@ -49,6 +49,7 @@#include <asm/paca.h> #include <asm/time.h> #include <asm/cputable.h> +#include <asm/cpufeatures.h> #include <asm/sections.h> #include <asm/btext.h> #include <asm/nvram.h>
@@ -274,8 +275,17 @@ void __init early_setup(unsigned long dt_ptr)/* -------- printk is _NOT_ safe to use here ! ------- */ -/* Identify CPU type */ +#ifdef CONFIG_PPC_CPUFEATURES_DT +/* Setup flat device-tree pointer */ + initial_boot_params =__va (dt_ptr); +if (early_init_devtree_check_cpu_features_exists ()) +cpufeatures_setup_cpu (); +else +/* Legacy table-based approach when /cpus/features is missing */ +identify_cpu (0 ,mfspr (SPRN_PVR )); +#else identify_cpu (0 ,mfspr (SPRN_PVR )); +#endif /* Assume we're on cpu 0 for now. Don't write to the paca yet! */ initialise_paca (&boot_paca,0 );
@@ -541,6 +551,9 @@ void __init initialize_cache_info(void) dcache_bsize = ppc64_caches.l1d.block_size; icache_bsize = ppc64_caches.l1i.block_size; + cur_cpu_spec->dcache_bsize = dcache_bsize; + cur_cpu_spec->icache_bsize = icache_bsize; +DBG (" <- initialize_cache_info()\n" ); }
Signature · 1 line
2.11.0
Nicholas Piggin
reviewerPATCH 1/1 cpufeatures: add base and POWER8, POWER9 /cpus/features dt
In reply to Nicholas PigginThis is the skiboot patch included here if anyone wants to test or review. I've put more of the feature documentation into this patch, so I haven't duplicated it on the Linux side -- firmware will be canonical definition.
--- core/Makefile.inc | 2 +- core/cpufeatures.c | 888 +++++++++++++++++++++++++++++++++++++++++++++++++++++ core/device.c | 7 + core/init.c | 1 + include/device.h | 1 + include/skiboot.h | 5 + 6 files changed, 903 insertions(+), 1 deletion(-) create mode 100644 core/cpufeatures.c
core/Makefile.inc +1 -1
@@ -8,7 +8,7 @@ CORE_OBJS += pci-opal.o fast-reboot.o device.o exceptions.o trace.o affinity.o CORE_OBJS += vpd.o hostservices.o platform.o nvram.o nvram-format.o hmi.o CORE_OBJS += console-log.o ipmi.o time-utils.o pel.o pool.o errorlog.o CORE_OBJS += timer.o i2c.o rtc.o flash.o sensor.o ipmi-opal.o -CORE_OBJS += flash-subpartition.o bitmap.o buddy.o pci-quirk.o +CORE_OBJS += flash-subpartition.o bitmap.o buddy.o pci-quirk.o cpufeatures.o ifeq ($(SKIBOOT_GCOV),1) CORE_OBJS += gcov-profiling.o
core/cpufeatures.c new file +888 -0
888 lines not on this page · raw message
core/device.c +7 -0
@@ -598,6 +598,13 @@ u32 dt_property_get_cell(const struct dt_property *prop, u32 index)return fdt32_to_cpu (((const u32 *)prop->prop)[index]); } +void dt_property_set_cell (struct dt_property *prop,u32 index,u32 val) +{ +assert (prop->len >= (index+1 )*sizeof (u32)); +/* Always aligned, so this works. */ + ((u32 *)prop->prop)[index] =cpu_to_fdt32 (val); +} +/* First child of this node. */ struct dt_node *dt_first (const struct dt_node *root) {
core/init.c +1 -0
@@ -790,6 +790,7 @@ void __noreturn __nomcount main_cpu_entry(const void *fdt) }else {dt_expand (fdt); } +dt_add_cpufeatures (dt_root);/* Now that we have a full devicetree, verify that we aren't on fire. */ per_thread_sanity_checks ();
include/device.h +1 -0
@@ -125,6 +125,7 @@ void dt_check_del_prop(struct dt_node *node, const char *name);/* Warning: moves *prop! */ void dt_resize_property (struct dt_property **prop,size_t len); +void dt_property_set_cell (struct dt_property *prop,u32 index,u32 val);u32 dt_property_get_cell (const struct dt_property *prop,u32 index);/* First child of this node. */
include/skiboot.h +5 -0
@@ -184,6 +184,11 @@ extern void start_kernel_secondary(uint64_t entry) __noreturn;/* Get description of machine from HDAT and create device-tree */ extern int parse_hdat (bool is_opal); +struct dt_node ; + +/* Add /cpus/features node for boot environment that passes an fdt */ +extern void dt_add_cpufeatures (struct dt_node *root); +/* Root of device tree. */ extern struct dt_node *dt_root;
Signature · 1 line
2.11.0