Re: [PATCH v2] powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536
On Fri, 2013-11-22 at 14:51 -0600, Kumar Gala wrote: drivers/gpio/gpio-mpc8xxx.c | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/gpio/gpio-mpc8xxx.c b/drivers/gpio/gpio-mpc8xxx.c index 914e859..d7d6d72 100644 --- a/drivers/gpio/gpio-mpc8xxx.c +++ b/drivers/gpio/gpio-mpc8xxx.c @@ -70,10 +70,14 @@ static int mpc8572_gpio_get(struct gpio_chip *gc, unsigned int gpio) u32 val; struct of_mm_gpio_chip *mm = to_of_mm_gpio_chip(gc); struct mpc8xxx_gpio_chip *mpc8xxx_gc = to_mpc8xxx_gpio_chip(mm); + u32 out_mask, out_shadow; - val = in_be32(mm-regs + GPIO_DAT) ~in_be32(mm-regs + GPIO_DIR); + out_mask = in_be32(mm-regs + GPIO_DIR); - return (val | mpc8xxx_gc-data) mpc8xxx_gpio2mask(gpio); + val = in_be32(mm-regs + GPIO_DAT) ~out_mask; + out_shadow = mpc8xxx_gc-data out_mask; + + return (val | out_shadow) mpc8xxx_gpio2mask(gpio); } I really think a comment is worth adding here about why we do this. - k Hi, Kumar, Thanks for your comment. In fact, there already had some comments above the function: /* Workaround GPIO 1 errata on MPC8572/MPC8536. The status of GPIOs * defined as output cannot be determined by reading GPDAT register, * so we use shadow data register instead. The status of input pins * is determined by reading GPDAT register. */ Best Regards, Liu Gang ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [V3 01/10] perf: New conditional branch filter criteria in branch stack sampling
On 11/26/2013 11:36 AM, m...@ellerman.id.au wrote:
Ideally your commit subject would contain a verb, preferably in the present
tense.
I think simply perf: Add PERF_SAMPLE_BRANCH_COND would be clearer.
Sure, will change it.
On Wed, 2013-16-10 at 06:56:48 UTC, Anshuman Khandual wrote:
POWER8 PMU based BHRB supports filtering for conditional branches.
This patch introduces new branch filter PERF_SAMPLE_BRANCH_COND which
will extend the existing perf ABI. Other architectures can provide
this functionality with either HW filtering support (if present) or
with SW filtering of instructions.
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
Reviewed-by: Stephane Eranian eran...@google.com
---
include/uapi/linux/perf_event.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/uapi/linux/perf_event.h
b/include/uapi/linux/perf_event.h
index 0b1df41..5da52b6 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -160,8 +160,9 @@ enum perf_branch_sample_type {
PERF_SAMPLE_BRANCH_ABORT_TX = 1U 7, /* transaction aborts */
PERF_SAMPLE_BRANCH_IN_TX= 1U 8, /* in transaction */
PERF_SAMPLE_BRANCH_NO_TX= 1U 9, /* not in transaction */
+PERF_SAMPLE_BRANCH_COND = 1U 10, /* conditional branches */
-PERF_SAMPLE_BRANCH_MAX = 1U 10, /* non-ABI */
+PERF_SAMPLE_BRANCH_MAX = 1U 11, /* non-ABI */
};
This no longer applies against Linus' tree, you'll need to rebase it.
Okay
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [V3 02/10] powerpc, perf: Enable conditional branch filter for POWER8
On 11/26/2013 11:36 AM, m...@ellerman.id.au wrote:
On Wed, 2013-16-10 at 06:56:49 UTC, Anshuman Khandual wrote:
Enables conditional branch filter support for POWER8
utilizing MMCRA register based filter and also invalidates
a BHRB branch filter combination involving conditional
branches.
Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com
---
arch/powerpc/perf/power8-pmu.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c
index 2ee4a70..6e28587 100644
--- a/arch/powerpc/perf/power8-pmu.c
+++ b/arch/powerpc/perf/power8-pmu.c
@@ -580,11 +580,21 @@ static u64 power8_bhrb_filter_map(u64
branch_sample_type)
if (branch_sample_type PERF_SAMPLE_BRANCH_IND_CALL)
return -1;
+/* Invalid branch filter combination - HW does not support */
+if ((branch_sample_type PERF_SAMPLE_BRANCH_ANY_CALL)
+(branch_sample_type PERF_SAMPLE_BRANCH_COND))
+return -1;
What this doesn't make obvious is that the hardware doesn't support any
combinations. It just happens that these are the only two possibilities we
allow, and so this is the only combination we have to disallow.
if (branch_sample_type PERF_SAMPLE_BRANCH_ANY_CALL) {
pmu_bhrb_filter |= POWER8_MMCRA_IFM1;
return pmu_bhrb_filter;
}
+if (branch_sample_type PERF_SAMPLE_BRANCH_COND) {
+pmu_bhrb_filter |= POWER8_MMCRA_IFM3;
+return pmu_bhrb_filter;
+}
+
/* Every thing else is unsupported */
return -1;
}
I think it would be clearer if we actually checked for the possibilities we
allow and let everything else fall through, eg:
/* Ignore user/kernel/hv bits */
branch_sample_type = ~PERF_SAMPLE_BRANCH_PLM_ALL;
if (branch_sample_type == PERF_SAMPLE_BRANCH_ANY)
return 0;
if (branch_sample_type == PERF_SAMPLE_BRANCH_ANY_CALL)
return POWER8_MMCRA_IFM1;
if (branch_sample_type == PERF_SAMPLE_BRANCH_COND)
return POWER8_MMCRA_IFM3;
return -1;
Please look at the 9th patch (power8, perf: Change BHRB branch filter
configuration).
All these issues are taken care of in this patch. It clearly indicates that any
combination
of HW BHRB filters will not be supported in the PMU and hence zero out the HW
filter component
and processes all of those filters in the SW.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Problem reading and programming memory location...
Hi Anatolij, we have tried again… but the problem is still there… we are not able to read/write, not only CS4, but also CS1, CS2, CS3, etc… According to you, could we fix the problem if we include our Virtex FPGA in Device Tree? U-Boot has been patched (not by us), for CS4, with: +#define CONFIG_SYS_CS0_START CONFIG_SYS_FLASH_BASE +#define CONFIG_SYS_CS0_SIZECONFIG_SYS_FLASH_SIZE +#define CONFIG_SYS_CS0_CFG 0x000ADD00 +#define CONFIG_SYS_CS3_START 0x1000// +#define CONFIG_SYS_CS3_SIZE 0x0002// +#define CONFIG_SYS_CS3_CFG 0x0002DF00// + +#define CONFIG_SYS_CS4_START 0x1002// +#define CONFIG_SYS_CS4_SIZE 0x0002// +#define CONFIG_SYS_CS4_CFG 0x0002DC00// + +#define CONFIG_SYS_CS5_START 0x1100// +#define CONFIG_SYS_CS5_SIZE 0x0100// +#define CONFIG_SYS_CS5_CFG 0x0002DD00// + +#define CONFIG_SYS_CS_BURST0x +#define CONFIG_SYS_CS_DEADCYCLE0x + +#define CONFIG_SYS_RESET_ADDRESS 0xff00 but CONFIG_SYS_CS4_SIZE should be: 0x0001 ... Thank you Lorenzo On 19/nov/2013, at 10:45 PM, Anatolij Gustschin ag...@denx.de wrote: Hi Lorenzo, On Tue, 19 Nov 2013 11:20:24 +0100 neorf3k neor...@gmail.com wrote: Hello Anatolij, this is our code, used at University, but again it doesn’t work… How i told, the only information we have about that reg are: Chip select 4 specification: Lp_cs4 bus size: 8 bit bus control: 2 wait state R/W ACK disabled size allocated: 4 KByte Our Register 8 bit LP_cs4 (we want to write) cs4 offset: 0x001 is the byte in FPGA at offset 0x0 writable? In your code you currently test read/write access to the byte at offset 0x0. If the read/write access works under U-Boot, then maybe the chip select parameters for CS4 are configured differently in U-Boot. You can dump the Chip Select 4 configuration registers under U-Boot and compare. Is address- and data-bus to the FPGA multipexed? Another possible reason for non-working access could be that the configured CS4 range 0x1002 - 0x1003 overlaps with configured range for CS0, CS1, CS2 or CS3. Can you verify that no such overlapping exists. Thanks, Anatolij ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: : Kill CONFIG_MTD_PARTITIONS
This patch removes CONFIG_MTD_PARTITIONS in config files for powerpc. Because CONFIG_MTD_PARTITIONS was removed by commit 6a8a98b22b10f1560d5f90aded4a54234b9b2724. Signed-off-by: Eunbong Song eunb.s...@samsung.com --- arch/powerpc/configs/40x/acadia_defconfig|1 - arch/powerpc/configs/40x/ep405_defconfig |1 - arch/powerpc/configs/40x/kilauea_defconfig |1 - arch/powerpc/configs/40x/makalu_defconfig|1 - arch/powerpc/configs/40x/walnut_defconfig|1 - arch/powerpc/configs/44x/arches_defconfig|1 - arch/powerpc/configs/44x/bluestone_defconfig |1 - arch/powerpc/configs/44x/canyonlands_defconfig |1 - arch/powerpc/configs/44x/ebony_defconfig |1 - arch/powerpc/configs/44x/eiger_defconfig |1 - arch/powerpc/configs/44x/icon_defconfig |1 - arch/powerpc/configs/44x/iss476-smp_defconfig|1 - arch/powerpc/configs/44x/katmai_defconfig|1 - arch/powerpc/configs/44x/rainier_defconfig |1 - arch/powerpc/configs/44x/redwood_defconfig |1 - arch/powerpc/configs/44x/sequoia_defconfig |1 - arch/powerpc/configs/44x/taishan_defconfig |1 - arch/powerpc/configs/44x/warp_defconfig |1 - arch/powerpc/configs/52xx/cm5200_defconfig |1 - arch/powerpc/configs/52xx/motionpro_defconfig|1 - arch/powerpc/configs/52xx/pcm030_defconfig |1 - arch/powerpc/configs/52xx/tqm5200_defconfig |1 - arch/powerpc/configs/83xx/asp8347_defconfig |1 - arch/powerpc/configs/83xx/mpc8313_rdb_defconfig |1 - arch/powerpc/configs/83xx/mpc8315_rdb_defconfig |1 - arch/powerpc/configs/83xx/mpc836x_mds_defconfig |1 - arch/powerpc/configs/83xx/mpc836x_rdk_defconfig |1 - arch/powerpc/configs/83xx/sbc834x_defconfig |1 - arch/powerpc/configs/85xx/ksi8560_defconfig |1 - arch/powerpc/configs/85xx/ppa8548_defconfig |1 - arch/powerpc/configs/85xx/socrates_defconfig |1 - arch/powerpc/configs/85xx/tqm8540_defconfig |1 - arch/powerpc/configs/85xx/tqm8541_defconfig |1 - arch/powerpc/configs/85xx/tqm8548_defconfig |1 - arch/powerpc/configs/85xx/tqm8555_defconfig |1 - arch/powerpc/configs/85xx/tqm8560_defconfig |1 - arch/powerpc/configs/85xx/xes_mpc85xx_defconfig |1 - arch/powerpc/configs/86xx/gef_ppc9a_defconfig|1 - arch/powerpc/configs/86xx/gef_sbc310_defconfig |1 - arch/powerpc/configs/86xx/gef_sbc610_defconfig |1 - arch/powerpc/configs/86xx/mpc8610_hpcd_defconfig |1 - arch/powerpc/configs/86xx/sbc8641d_defconfig |1 - arch/powerpc/configs/c2k_defconfig |1 - arch/powerpc/configs/corenet64_smp_defconfig |1 - arch/powerpc/configs/linkstation_defconfig |1 - arch/powerpc/configs/mpc85xx_defconfig |1 - arch/powerpc/configs/mpc85xx_smp_defconfig |1 - arch/powerpc/configs/ppc40x_defconfig|1 - arch/powerpc/configs/ppc44x_defconfig|1 - arch/powerpc/configs/prpmc2800_defconfig |1 - arch/powerpc/configs/storcenter_defconfig|1 - arch/powerpc/configs/tqm8xx_defconfig|1 - 52 files changed, 0 insertions(+), 52 deletions(-) diff --git a/arch/powerpc/configs/40x/acadia_defconfig b/arch/powerpc/configs/40x/acadia_defconfig index ed3bab7..69e06ee 100644 --- a/arch/powerpc/configs/40x/acadia_defconfig +++ b/arch/powerpc/configs/40x/acadia_defconfig @@ -30,7 +30,6 @@ CONFIG_IP_PNP_BOOTP=y CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug CONFIG_CONNECTOR=y CONFIG_MTD=y -CONFIG_MTD_PARTITIONS=y CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_OF_PARTS=y CONFIG_MTD_CHAR=y diff --git a/arch/powerpc/configs/40x/ep405_defconfig b/arch/powerpc/configs/40x/ep405_defconfig index 17582a3..cf06d42 100644 --- a/arch/powerpc/configs/40x/ep405_defconfig +++ b/arch/powerpc/configs/40x/ep405_defconfig @@ -29,7 +29,6 @@ CONFIG_IP_PNP_BOOTP=y CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug CONFIG_CONNECTOR=y CONFIG_MTD=y -CONFIG_MTD_PARTITIONS=y CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_OF_PARTS=y CONFIG_MTD_CHAR=y diff --git a/arch/powerpc/configs/40x/kilauea_defconfig b/arch/powerpc/configs/40x/kilauea_defconfig index f2d4be9..5ff338f 100644 --- a/arch/powerpc/configs/40x/kilauea_defconfig +++ b/arch/powerpc/configs/40x/kilauea_defconfig @@ -32,7 +32,6 @@ CONFIG_IP_PNP_BOOTP=y CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug CONFIG_CONNECTOR=y CONFIG_MTD=y -CONFIG_MTD_PARTITIONS=y CONFIG_MTD_CMDLINE_PARTS=y CONFIG_MTD_OF_PARTS=y CONFIG_MTD_CHAR=y diff --git a/arch/powerpc/configs/40x/makalu_defconfig b/arch/powerpc/configs/40x/makalu_defconfig index 42b9793..84505e3 100644 --- a/arch/powerpc/configs/40x/makalu_defconfig +++ b/arch/powerpc/configs/40x/makalu_defconfig @@ -29,7 +29,6 @@ CONFIG_IP_PNP_BOOTP=y CONFIG_UEVENT_HELPER_PATH=/sbin/hotplug CONFIG_CONNECTOR=y CONFIG_MTD=y
Re: [PATCH 1/1] powerpc: Increase EEH recovery timeout for SR-IOV
On Mon, Nov 25, 2013 at 04:27:54PM -0600, Brian King wrote:
In order to support concurrent adapter firmware download
to SR-IOV adapters on pSeries, each VF will see an EEH event
where the slot will remain in the unavailable state for
the duration of the adapter firmware update, which can take
as long as 5 minutes. Extend the EEH recovery timeout to
account for this.
Signed-off-by: Brian King brk...@linux.vnet.ibm.com
Acked-by: Gavin Shan sha...@linux.vnet.ibm.com
---
arch/powerpc/kernel/eeh.c|2 +-
arch/powerpc/kernel/eeh_driver.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff -puN arch/powerpc/kernel/eeh.c~eeh_sriov_vf_delay
arch/powerpc/kernel/eeh.c
--- linux/arch/powerpc/kernel/eeh.c~eeh_sriov_vf_delay 2013-11-25
16:12:26.0 -0600
+++ linux-bjking1/arch/powerpc/kernel/eeh.c2013-11-25 16:12:26.0
-0600
@@ -84,7 +84,7 @@
#define EEH_MAX_FAILS 210
/* Time to wait for a PCI slot to report status, in milliseconds */
-#define PCI_BUS_RESET_WAIT_MSEC (60*1000)
+#define PCI_BUS_RESET_WAIT_MSEC (5*60*1000)
/* Platform dependent EEH operations */
struct eeh_ops *eeh_ops = NULL;
diff -puN arch/powerpc/kernel/eeh_driver.c~eeh_sriov_vf_delay
arch/powerpc/kernel/eeh_driver.c
--- linux/arch/powerpc/kernel/eeh_driver.c~eeh_sriov_vf_delay 2013-11-25
16:12:26.0 -0600
+++ linux-bjking1/arch/powerpc/kernel/eeh_driver.c 2013-11-25
16:12:26.0 -0600
@@ -468,7 +468,7 @@ static int eeh_reset_device(struct eeh_p
/* The longest amount of time to wait for a pci device
* to come back on line, in seconds.
*/
-#define MAX_WAIT_FOR_RECOVERY 150
+#define MAX_WAIT_FOR_RECOVERY 300
static void eeh_handle_normal_event(struct eeh_pe *pe)
{
Thanks,
Gavin
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[git pull] Please pull powerpc.git merge branch
Hi Linus !
Here are a few powerpc bug fixes post -rc1. The main thing that caused
problem was that CONFIG_CPU_LITTLE_ENDIAN got turned on with allyesconfig
and such, which is not a very good idea especially since it requires a
newer toolchain than what most people have. So we turned it into a
choice instead that defaults to big endian.
Cheers,
Ben.
The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
for you to fetch changes up to 721cb59e9d95eb7f47ec73711ed35ef85e1ea1ca:
powerpc/windfarm: Fix XServe G5 fan control Makefile issue (2013-11-27
11:35:47 +1100)
Adam Borowski (1):
powerpc/85xx: typo in dts: interupt (four devices)
Anton Blanchard (1):
powerpc: allyesconfig should not select CONFIG_CPU_LITTLE_ENDIAN
Benjamin Herrenschmidt (2):
Merge remote-tracking branch 'scott/master' into merge
powerpc/windfarm: Fix XServe G5 fan control Makefile issue
Chen Gang (1):
arch/powerpc/kernel: Use %12.12s instead of %12s to avoid memory overflow
Hari Bathini (1):
powerpc/kdump: Adding symbols in vmcoreinfo to facilitate dump filtering
LEROY Christophe (1):
powerpc/8xx: mfspr SPRN_TBRx in lieu of mftb/mftbu is not supported
Michael Neuling (2):
powerpc: Fix error when cross building TAGS cscope
powerpc/signals: Improved mark VSX not saved with small contexts fix
Scott Wood (1):
powerpc/booke: Only check for hugetlb in flush if vma != NULL
Tiejun Chen (1):
powerpc/corenet64: compile with CONFIG_E{5,6}500_CPU well
arch/powerpc/Makefile | 7 +++
arch/powerpc/boot/dts/xcalibur1501.dts| 4 ++--
arch/powerpc/boot/dts/xpedite5301.dts | 4 ++--
arch/powerpc/boot/dts/xpedite5330.dts | 4 ++--
arch/powerpc/boot/dts/xpedite5370.dts | 4 ++--
arch/powerpc/boot/util.S | 14 ++
arch/powerpc/include/asm/pgalloc-64.h | 1 +
arch/powerpc/include/asm/ppc_asm.h| 2 ++
arch/powerpc/include/asm/reg.h| 7 +++
arch/powerpc/include/asm/timex.h | 8
arch/powerpc/kernel/machine_kexec.c | 12
arch/powerpc/kernel/nvram_64.c| 2 +-
arch/powerpc/kernel/signal_32.c | 16 +++-
arch/powerpc/kernel/signal_64.c | 6 ++
arch/powerpc/kernel/vdso32/gettimeofday.S | 6 ++
arch/powerpc/mm/hugetlbpage-book3e.c | 3 +--
arch/powerpc/mm/tlb_nohash.c | 2 +-
arch/powerpc/platforms/Kconfig.cputype| 20 +---
drivers/macintosh/Makefile| 1 +
19 files changed, 99 insertions(+), 24 deletions(-)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/3] powerpc: use the jump label for cpu_has_feature
On Mon, 2013-09-02 at 13:45 +0800, Kevin Hao wrote:
The cpu features are fixed once the probe of cpu features are done.
And the function cpu_has_feature() does be used in some hot path.
The checking of the cpu features for each time of invoking of
cpu_has_feature() seems suboptimal. This tries to reduce this
overhead of this check by using jump label. But we can only use
the jump label for this check only after the execution of
jump_label_init(), so we introduce another jump label to
still do the feature check by default before all the cpu
feature jump labels are initialized.
So I was looking at these and ...
+static inline int cpu_has_feature(unsigned long feature)
+{
+ if (CPU_FTRS_ALWAYS feature)
+ return 1;
+
+ if (!(CPU_FTRS_POSSIBLE | feature))
+ return 0;
+
+ if (static_key_false(cpu_feat_keys_enabled)) {
+ int i = __builtin_ctzl(feature);
+
+ return static_key_false(cpu_feat_keys[i]);
+ } else
+ return !!(cur_cpu_spec-cpu_features feature);
+}
This is gross :-)
Have you checked the generated code ? I'm worried that we end up hitting
at least 2 branches every time, which might be enough to defeat the
purposes even if they are unconditional in term of performance and
code size...
Cheers,
Ben.
+#else
static inline int cpu_has_feature(unsigned long feature)
{
return (CPU_FTRS_ALWAYS feature) ||
@@ -10,5 +36,6 @@ static inline int cpu_has_feature(unsigned long feature)
cur_cpu_spec-cpu_features
feature);
}
+#endif
#endif /* __ASM_POWERPC_CPUFEATURE_H */
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 597d954..50bd216 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -21,6 +21,7 @@
#include asm/prom.h/* for PTRRELOC on ARCH=ppc */
#include asm/mmu.h
#include asm/setup.h
+#include asm/cpufeatures.h
struct cpu_spec* cur_cpu_spec = NULL;
EXPORT_SYMBOL(cur_cpu_spec);
@@ -2258,3 +2259,25 @@ struct cpu_spec * __init identify_cpu(unsigned long
offset, unsigned int pvr)
return NULL;
}
+
+#ifdef CONFIG_JUMP_LABEL
+struct static_key cpu_feat_keys[MAX_CPU_FEATURES];
+struct static_key cpu_feat_keys_enabled;
+
+static __init int cpu_feat_keys_init(void)
+{
+ int i;
+
+ for (i = 0; i MAX_CPU_FEATURES; i++) {
+ unsigned long f = 1 i;
+
+ if (cur_cpu_spec-cpu_features f)
+ static_key_slow_inc(cpu_feat_keys[i]);
+ }
+
+ static_key_slow_inc(cpu_feat_keys_enabled);
+
+ return 0;
+}
+early_initcall(cpu_feat_keys_init);
+#endif
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
