- 15 Jun, 2021 22 commits
-
-
Christophe Leroy authored
Start using PPC_RAW_xx() macros where relevant. PPC_INST_SYNC is used to both represent the 'sync' instruction and the family of synchronisation instructions. Keep it for the later, maybe we'll change the name in the future to avoid confusion. Signed-off-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/0945c155d6cb113431185fc1296ac127359fe29b.1621506159.git.christophe.leroy@csgroup.eu
-
Christophe Leroy authored
Use PPC_RAW_xxx() macros instead of open coding assembly opcodes. Signed-off-by:
-
Christophe Leroy authored
To increase readability, use _Rx macros instead of __REG_Rx. Signed-off-by:
-
Christophe Leroy authored
Use PPC_RAW_MFLR() instead of open coding with PPC_INST_MFLR. Signed-off-by:
-
Christophe Leroy authored
Use PPC_RAW_MFLR() instead of open coding with PPC_INST_MFLR. Same for PPC_INST_NOP. Signed-off-by:
-
Christophe Leroy authored
On the road to remove all use of PPC_INST_xxx, replace PPC_INST_BLR by PPC_RAW_BLR(). Same for PPC_INST_NOP. Signed-off-by:
-
Christophe Leroy authored
To improve readability, use PPC_RAW_xx() macros instead of open coding. Those macros are self-explanatory so the comments can go as well. Signed-off-by:
-
Christophe Leroy authored
To improve readability, use PPC_RAW_xx() macros instead of open coding. Those macros are self-explanatory so the comments can go as well. Signed-off-by:
-
Christophe Leroy authored
Instead of open coding with PPC_INST_ defines, use PPC_RAW_() macros. It improves readability. Signed-off-by:
-
Christophe Leroy authored
Today we have __REG_Rx macros . They are mainly meant for internal use by macros __PPC_RA() and friends macros which allows uses like __PPC_RA(R12). When used with PPC_RAW_xx() macros, it gives a result which is not very readable. Add shorter macros _Rx in order to improve readability when used with PPC_RAW_xx() macros. Signed-off-by:
-
Christophe Leroy authored
At the time being, we have PPC_RAW_PLXVP() and PPC_RAW_PSTXVP() which provide a 64 bits value, and then it gets split by open coding to format it into a 'struct ppc_inst' instruction. Instead, define a PPC_RAW_xxx_P() and a PPC_RAW_xxx_S() to be used as is. Signed-off-by:
-
Christophe Leroy authored
_switch() saves and restores ALTIVEC and SPE status. For altivec this is redundant with what __switch_to() does with save_sprs() and restore_sprs() and giveup_all() before calling _switch(). Add support for SPI in save_sprs() and restore_sprs() and remove things from _switch(). Signed-off-by:
-
Christophe Leroy authored
Commit 328e7e48 ("powerpc: force inlining of csum_partial() to avoid multiple csum_partial() with GCC10") inlined csum_partial(). Now that csum_partial() is inlined, GCC outlines csum_add() when called by csum_partial(). c064fb28 <csum_add>: c064fb28: 7c 63 20 14 addc r3,r3,r4 c064fb2c: 7c 63 01 94 addze r3,r3 c064fb30: 4e 80 00 20 blr c0665fb8 <csum_add>: c0665fb8: 7c 63 20 14 addc r3,r3,r4 c0665fbc: 7c 63 01 94 addze r3,r3 c0665fc0: 4e 80 00 20 blr c066719c: 7c 9a c0 2e lwzx r4,r26,r24 c06671a0: 38 60 00 00 li r3,0 c06671a4: 7f 1a c2 14 add r24,r26,r24 c06671a8: 4b ff ee 11 bl c0665fb8 <csum_add> c06671ac: 80 98 00 04 lwz r4,4(r24) c06671b0: 4b ff ee 09 bl c0665fb8 <csum_add> c06671b4: 80 98 00 08 lwz r4,8(r24) c06671b8: 4b ff ee 01 bl c0665fb8 <csum_add> c06671bc: a0 98 00 0c lhz r4,12(r24) c06671c0: 4b ff ed f9 bl c0665fb8 <csum_add> c06671c4: 7c 63 18 f8 not r3,r3 c06671c8: 81 3f 00 68 lwz r9,104(r31) c06671cc: 81 5f 00 a0 lwz r10,160(r31) c06671d0: 7d 29 18 14 addc r9,r9,r3 c06671d4: 7d 29 01 94 addze r9,r9 c06671d8: 91 3f 00 68 stw r9,104(r31) c06671dc: 7d 1a 50 50 subf r8,r26,r10 c06671e0: 83 01 00 10 lwz r24,16(r1) c06671e4: 83 41 00 18 lwz r26,24(r1) The sum with 0 is useless, should have been skipped. And there is even one completely unused instance of csum_add(). In file included from ./include/net/checksum.h:22, from ./include/linux/skbuff.h:28, from ./include/linux/icmp.h:16, from net/ipv6/ip6_tunnel.c:23: ./arch/powerpc/include/asm/checksum.h: In function '__ip6_tnl_rcv': ./arch/powerpc/include/asm/checksum.h:94:22: warning: inlining failed in call to 'csum_add': call is unlikely and code size would grow [-Winline] 94 | static inline __wsum csum_add(__wsum csum, __wsum addend) | ^~~~~~~~ ./arch/powerpc/include/asm/checksum.h:172:31: note: called from here 172 | sum = csum_add(sum, (__force __wsum)*(const u32 *)buff); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./arch/powerpc/include/asm/checksum.h:94:22: warning: inlining failed in call to 'csum_add': call is unlikely and code size would grow [-Winline] 94 | static inline __wsum csum_add(__wsum csum, __wsum addend) | ^~~~~~~~ ./arch/powerpc/include/asm/checksum.h:177:31: note: called from here 177 | sum = csum_add(sum, (__force __wsum) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 178 | *(const u32 *)(buff + 4)); | ~~~~~~~~~~~~~~~~~~~~~~~~~ ./arch/powerpc/include/asm/checksum.h:94:22: warning: inlining failed in call to 'csum_add': call is unlikely and code size would grow [-Winline] 94 | static inline __wsum csum_add(__wsum csum, __wsum addend) | ^~~~~~~~ ./arch/powerpc/include/asm/checksum.h:183:31: note: called from here 183 | sum = csum_add(sum, (__force __wsum) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 184 | *(const u32 *)(buff + 8)); | ~~~~~~~~~~~~~~~~~~~~~~~~~ ./arch/powerpc/include/asm/checksum.h:94:22: warning: inlining failed in call to 'csum_add': call is unlikely and code size would grow [-Winline] 94 | static inline __wsum csum_add(__wsum csum, __wsum addend) | ^~~~~~~~ ./arch/powerpc/include/asm/checksum.h:186:31: note: called from here 186 | sum = csum_add(sum, (__force __wsum) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 187 | *(const u16 *)(buff + 12)); | ~~~~~~~~~~~~~~~~~~~~~~~~~~ Force inlining of csum_add(). 94c: 80 df 00 a0 lwz r6,160(r31) 950: 7d 28 50 2e lwzx r9,r8,r10 954: 7d 48 52 14 add r10,r8,r10 958: 80 aa 00 04 lwz r5,4(r10) 95c: 80 ff 00 68 lwz r7,104(r31) 960: 7d 29 28 14 addc r9,r9,r5 964: 7d 29 01 94 addze r9,r9 968: 7d 08 30 50 subf r8,r8,r6 96c: 80 aa 00 08 lwz r5,8(r10) 970: a1 4a 00 0c lhz r10,12(r10) 974: 7d 29 28 14 addc r9,r9,r5 978: 7d 29 01 94 addze r9,r9 97c: 7d 29 50 14 addc r9,r9,r10 980: 7d 29 01 94 addze r9,r9 984: 7d 29 48 f8 not r9,r9 988: 7c e7 48 14 addc r7,r7,r9 98c: 7c e7 01 94 addze r7,r7 990: 90 ff 00 68 stw r7,104(r31) In the non-inlined version, the first sum with 0 was performed. Here it is skipped. Signed-off-by:
Segher Boessenkool <segher@kernel.crashing.org> Signed-off-by:
-
Michael Ellerman authored
Merge our fixes branch which has a number of important fixes, notably the fix for initrd corruption, as well as the fixes for scv vs ptrace.
-
Finn Thain authored
This avoids an (optional) compiler warning: arch/powerpc/kernel/tau_6xx.c: In function 'TAU_init': arch/powerpc/kernel/tau_6xx.c:204:30: error: too many arguments for format [-Werror=format-extra-args] tau_workq = alloc_workqueue("tau", WQ_UNBOUND, 1, 0); Fixes: b1c6a0a1 ("powerpc/tau: Convert from timer to workqueue") Reported-by:Naresh Kamboju <naresh.kamboju@linaro.org> Signed-off-by:
Finn Thain <fthain@linux-m68k.org> Signed-off-by:
-
Michael Ellerman authored
Commit b0b3b2c7 ("powerpc: Switch to relative jump labels") switched us to using relative jump labels. That involves changing the code, target and key members in struct jump_entry to be relative to the address of the jump_entry, rather than absolute addresses. We have two static inlines that create a struct jump_entry, arch_static_branch() and arch_static_branch_jump(), as well as an asm macro ARCH_STATIC_BRANCH, which is used by the pseries-only hypervisor tracing code. Unfortunately we missed updating the key to be a relative reference in ARCH_STATIC_BRANCH. That causes a pseries kernel to have a handful of jump_entry structs with bad key values. Instead of being a relative reference they instead hold the full address of the key. However the code doesn't expect that, it still adds the key value to the address of the jump_entry (see jump_entry_key()) expecting to get a pointer to a key somewhere in kernel data. The table of jump_entry structs sits in rodata, which comes after the kernel text. In a typical build this will be somewhere around 15MB. The address of the key will be somewhere in data, typically around 20MB. Adding the two values together gets us a pointer somewhere around 45MB. We then call static_key_set_entries() with that bad pointer and modify some members of the struct static_key we think we are pointing at. A pseries kernel is typically ~30MB in size, so writing to ~45MB won't corrupt the kernel itself. However if we're booting with an initrd, depending on the size and exact location of the initrd, we can corrupt the initrd. Depending on how exactly we corrupt the initrd it can either cause the system to not boot, or just corrupt one of the files in the initrd. The fix is simply to make the key value relative to the jump_entry struct in the ARCH_STATIC_BRANCH macro. Fixes: b0b3b2c7 ("powerpc: Switch to relative jump labels") Reported-by:
Anastasia Kovaleva <a.kovaleva@yadro.com> Reported-by:
Roman Bolshakov <r.bolshakov@yadro.com> Reported-by:
Greg Kurz <groug@kaod.org> Reported-by:
Daniel Axtens <dja@axtens.net> Signed-off-by:
-
Christophe Leroy authored
arch/powerpc/Kbuild decend into arch/powerpc/perf/ only when CONFIG_PERF_EVENTS is selected, so there is not need to take CONFIG_PERF_EVENTS into account in arch/powerpc/perf/Makefile. Signed-off-by:
Michal Suchánek <msuchanek@suse.de> Signed-off-by:
-
Andy Shevchenko authored
If by some reason any of the headers will include ctype.h we will have a name collision. Avoid this by moving isspace() to the dedicate namespace. First appearance of the code is in the commit cf68787b ("powerpc/prom_init: Evaluate mem kernel parameter for early allocation"). Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> [mpe: Reformat prom_isxdigit() now that we allow longer lines] Signed-off-by:
-
Shaokun Zhang authored
Function 'event_ebb_init' and 'event_leader_ebb_init' are declared twice in the header file, so remove the repeated declaration. Signed-off-by:
Shaokun Zhang <zhangshaokun@hisilicon.com> Signed-off-by:
-
Baokun Li authored
Fixes gcc '-Wunused-but-set-variable' warning: # WARNING: Fixes tag on line 3 doesn't match correct format # WARNING: Fixes tag on line 3 doesn't match correct format # WARNING: Fixes tag on line 3 doesn't match correct format # WARNING: Fixes tag on line 3 doesn't match correct format # WARNING: Fixes tag on line 3 doesn't match correct format # WARNING: Fixes tag on line 3 doesn't match correct format arch/powerpc/platforms/cell/spider-pci.c: In function 'spiderpci_io_flush': arch/powerpc/platforms/cell/spider-pci.c:28:6: warning: variable ‘val’ set but not used [-Wunused-but-set-variable] It never used since introduction. Signed-off-by:
Baokun Li <libaokun1@huawei.com> Signed-off-by:
-
Baokun Li authored
Fixes gcc '-Wunused-but-set-variable' warning: # WARNING: Fixes tag on line 3 doesn't match correct format # WARNING: Fixes tag on line 3 doesn't match correct format # WARNING: Fixes tag on line 3 doesn't match correct format # WARNING: Fixes tag on line 3 doesn't match correct format # WARNING: Fixes tag on line 3 doesn't match correct format arch/powerpc/platforms/cell/spufs/switch.c: In function 'check_ppu_mb_stat': arch/powerpc/platforms/cell/spufs/switch.c:1660:6: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable] arch/powerpc/platforms/cell/spufs/switch.c: In function 'check_ppuint_mb_stat': arch/powerpc/platforms/cell/spufs/switch.c:1675:6: warning: variable ‘dummy’ set but not used [-Wunused-but-set-variable] It never used since introduction. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Tom Rix authored
With gcc 10.3, there is this compiler error: compiler.h:56:26: error: this statement may fall through mpc52xx_gpt.c:586:2: note: here 586 | case WDIOC_GETTIMEOUT: | ^~~~ So add the fallthrough pseudo keyword. Signed-off-by:Tom Rix <trix@redhat.com> Signed-off-by:
-
- 14 Jun, 2021 1 commit
-
-
Michael Ellerman authored
In commit 96d7a4e0 ("powerpc/signal64: Rewrite handle_rt_signal64() to minimise uaccess switches") the 64-bit signal code was rearranged to use user_write_access_begin/end(). As part of that change the call to copy_siginfo_to_user() was moved later in the function, so that it could be done after the user_write_access_end(). In particular it was moved after we modify regs->nip to point to the signal trampoline. That means if copy_siginfo_to_user() fails we exit handle_rt_signal64() with an error but with regs->nip modified, whereas previously we would not modify regs->nip until the copy succeeded. Returning an error from signal delivery but with regs->nip updated leaves the process in a sort of half-delivered state. We do immediately force a SEGV in signal_setup_done(), called from do_signal(), so the process should never run in the half-delivered state. However that SEGV is not delivered until we've gone around to do_notify_resume() again, so it's possible some tracing could observe the half-delivered state. There are other cases where we fail signal delivery with regs partly updated, eg. the write to newsp and SA_SIGINFO, but the latter at least is very unlikely to fail as it reads back from the frame we just wrote to. Looking at other arches they seem to be more careful about leaving regs unchanged until the copy operations have succeeded, and in general that seems like good hygenie. So although the current behaviour is not cleary buggy, it's also not clearly correct. So move the call to copy_siginfo_to_user() up prior to the modification of regs->nip, which is closer to the old behaviour, and easier to reason about. Fixes: 96d7a4e0 ("powerpc/signal64: Rewrite handle_rt_signal64() to minimise uaccess switches") Signed-off-by:
-
- 10 Jun, 2021 6 commits
-
-
Geoff Levand authored
Commit f959dcd6 (dma-direct: Fix potential NULL pointer dereference) added a null check on the dma_mask pointer of the kernel's device structure. Add a dma_mask variable to the ps3_dma_region structure and set the device structure's dma_mask pointer to point to this new variable. Fixes runtime errors like these: # WARNING: Fixes tag on line 10 doesn't match correct format # WARNING: Fixes tag on line 10 doesn't match correct format ps3_system_bus_match:349: dev=8.0(sb_01), drv=8.0(ps3flash): match WARNING: CPU: 0 PID: 1 at kernel/dma/mapping.c:151 .dma_map_page_attrs+0x34/0x1e0 ps3flash sb_01: ps3stor_setup:193: map DMA region failed Signed-off-by:
Geoff Levand <geoff@infradead.org> Signed-off-by:
-
Geoff Levand authored
To aid debugging PS3 boot problems change the log level of several PS3 device errors from pr_debug to pr_warn. Signed-off-by:
-
Geoff Levand authored
To aid debugging, add a new PS3 kernel config option PS3_VERBOSE_RESULT that, when enabled, will print more verbose messages for the result of LV1 hypercalls. Signed-off-by:
-
Geoff Levand authored
Change the PS3 linker script to align the DTB at 8 bytes, the same alignment as that of the of the 'generic' powerpc linker script. Signed-off-by:
-
Geoff Levand authored
Add a new sysfs entry /sys/firmware/ps3/fw-version that exports the PS3's firmware version. The firmware version is available through an LV1 hypercall, and we've been printing it to the boot log, but haven't provided an easy way for user utilities to get it. Signed-off-by:
-
Nathan Chancellor authored
A change in clang 13 results in the __lwsync macro being defined as __builtin_ppc_lwsync, which emits 'lwsync' or 'msync' depending on what the target supports. This breaks the build because of -Werror in arch/powerpc, along with thousands of warnings: In file included from arch/powerpc/kernel/pmc.c:12: In file included from include/linux/bug.h:5: In file included from arch/powerpc/include/asm/bug.h:109: In file included from include/asm-generic/bug.h:20: In file included from include/linux/kernel.h:12: In file included from include/linux/bitops.h:32: In file included from arch/powerpc/include/asm/bitops.h:62: arch/powerpc/include/asm/barrier.h:49:9: error: '__lwsync' macro redefined [-Werror,-Wmacro-redefined] #define __lwsync() __asm__ __volatile__ (stringify_in_c(LWSYNC) : : :"memory") ^ <built-in>:308:9: note: previous definition is here #define __lwsync __builtin_ppc_lwsync ^ 1 error generated. Undefine this macro so that the runtime patching introduced by commit 2d1b2027 ("powerpc: Fixup lwsync at runtime") continues to work properly with clang and the build no longer breaks. Cc: stable@vger.kernel.org Signed-off-by:Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
-
- 06 Jun, 2021 1 commit
-
-
Christophe Leroy authored
Commit b26e8f27 ("powerpc/mem: Move cache flushing functions into mm/cacheflush.c") removed asm/sparsemem.h which is required when CONFIG_MEMORY_HOTPLUG is selected to get the declaration of create_section_mapping(). Add it back. Fixes: b26e8f27 ("powerpc/mem: Move cache flushing functions into mm/cacheflush.c") Reported-by:
-
- 01 Jun, 2021 1 commit
-
-
Frederic Barrat authored
This reverts commit 3c0468d4. That commit was breaking alignment guarantees for the DMA address when allocating coherent mappings, as described in Documentation/core-api/dma-api-howto.rst It was also noticed by Mellanox' driver: [ 1515.763621] mlx5_core c002:01:00.0: mlx5_frag_buf_alloc_node:146:(pid 13402): unexpected map alignment: 0x0800000000c61000, page_shift=16 [ 1515.763635] mlx5_core c002:01:00.0: mlx5_cqwq_create:181:(pid 13402): mlx5_frag_buf_alloc_node() failed, -12 Fixes: 3c0468d4 ("powerpc/kernel/iommu: Align size for IOMMU_PAGE_SIZE() to save TCEs") Signed-off-by:
Frederic Barrat <fbarrat@linux.ibm.com> Reviewed-by:
Alexey Kardashevskiy <aik@ozlabs.ru> Signed-off-by:
-
- 28 May, 2021 3 commits
-
-
Nicholas Piggin authored
Similar to commit 25edcc50 ("KVM: PPC: Book3S HV: Save and restore FSCR in the P9 path"), ensure the P7/8 path saves and restores the host FSCR. The logic explained in that patch actually applies there to the old path well: a context switch can be made before kvmppc_vcpu_run_hv restores the host FSCR and returns. Now both the p9 and the p7/8 paths now save and restore their FSCR, it no longer needs to be restored at the end of kvmppc_vcpu_run_hv Fixes: b005255e ("KVM: PPC: Book3S HV: Context-switch new POWER8 SPRs") Cc: stable@vger.kernel.org # v3.14+ Signed-off-by:
Nicholas Piggin <npiggin@gmail.com> Reviewed-by:
Fabiano Rosas <farosas@linux.ibm.com> Signed-off-by:
-
Nicholas Piggin authored
real_vmalloc_addr() does not currently work for huge vmalloc, which is what the reverse map can be allocated with for radix host, hash guest. Extract the hugepage aware equivalent from eeh code into a helper, and convert existing sites including this one to use it. Fixes: 8abddd96 ("powerpc/64s/radix: Enable huge vmalloc mappings") Signed-off-by:
-
Naveen N. Rao authored
When checking if the probed instruction is the suffix of a prefixed instruction, we access the instruction at the previous word. If the probed instruction is the very first word of a module, we can end up trying to access an invalid page. Fix this by skipping the check for all instructions at the beginning of a page. Prefixed instructions cannot cross a 64-byte boundary and as such, we don't expect to encounter a suffix as the very first word in a page for kernel text. Even if there are prefixed instructions crossing a page boundary (from a module, for instance), the instruction will be illegal, so preventing probing on the suffix of such prefix instructions isn't worthwhile. Fixes: b4657f76 ("powerpc/kprobes: Don't allow breakpoints on suffixes") Cc: stable@vger.kernel.org # v5.8+ Reported-by:
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Signed-off-by:
-
- 23 May, 2021 6 commits
-
-
Nathan Lynch authored
hvterm_raw_put_chars() calls hvc_put_chars(), which may return -EAGAIN when the underlying hcall returns a "busy" status, but udbg_hvc_putc() doesn't handle this. When using xmon on a PowerVM guest, this can result in incomplete or garbled output when printing relatively large amounts of data quickly, such as when dumping the kernel log buffer. Call again on -EAGAIN. Signed-off-by:
Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by:
-
Nathan Lynch authored
Log buffer entries that are too long for dump_log_buf()'s small local buffer are: * silently discarded when a single-line entry is too long; kmsg_dump_get_line() returns true but sets &len to 0. * silently truncated to the last fitting new line when a multi-line entry is too long, e.g. register dumps from __show_regs(); this seems undetectable via the kmsg_dump API. xmon_printf()'s internal buffer is already 1KB; enlarge dump_log_buf()'s own buffer to match and make it statically allocated. Verified that this allows complete printing of register dumps on ppc64le with both CONFIG_PRINTK_TIME=y and CONFIG_PRINTK_CALLER=y. Signed-off-by:
-
Christophe Leroy authored
Commit 51c9c084 ("powerpc/kprobes: Implement Optprobes") implemented a powerpc specific version of optinsn in order to workaround the 32Mb limitation for direct branches. Instead of implementing a dedicated powerpc version, use the common optinsn and override the allocation and freeing functions. This also indirectly remove the CLANG warning about is_kprobe_ppc_optinsn_slot() not being use, and the powerpc will now benefit from commit 5b485629 ("kprobes, extable: Identify kprobes trampolines as kernel text area") Suggested-by:
Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by:
-
Christophe Leroy authored
Some architectures like powerpc require a non standard allocation of optinsn page, because module pages are too far from the kernel for direct branches. Define weak alloc_optinsn_page() and free_optinsn_page(), that fall back on alloc_insn_page() and free_insn_page() when not overridden by the architecture. Suggested-by:
-
Nick Desaulniers authored
Until clang-12, clang would attempt to assemble 32b powerpc assembler in 64b emulation mode when using a 64b target triple with -m32, leading to errors during the build of the compat VDSO. Simply disable all of CONFIG_COMPAT; users should upgrade to the latest release of clang for proper support. Suggested-by:
-
Nick Desaulniers authored
While looking at -Wundef warnings, the #if CONFIG_EEH stood out as a possible candidate to convert to #ifdef CONFIG_EEH. It seems that based on Kconfig dependencies it's not possible to build this file without CONFIG_EEH enabled, but based on upstream discussion, it's not clear yet that CONFIG_EEH should be enabled by default. For now, simply fix the -Wundef warning. Suggested-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
