* Re: [GIT PULL] EDAC updates for 4.
@ 2015-06-24 12:14 Linus Torvalds
2015-06-24 12:30 ` Borislav Petkov
0 siblings, 1 reply; 6+ messages in thread
From: Linus Torvalds @ 2015-06-24 12:14 UTC (permalink / raw)
To: Borislav Petkov
Cc: Linux Kernel Mailing List, linux-edac, the arch/x86 maintainers
On Jun 24, 2015 00:40, "Borislav Petkov" <bp@suse.de> wrote:
>
> > The patches are based on 4.1-rc1. If it doesn't work on top of that,
> > then that means that you clearly have tested *none* of this. Which
> > just makes me go "yeah, I'm not pulling untested crap".
>
> Of course it has been tested but with the relevant tip branches merged.
No. I refuse to touch this crap.
What you are telling me is that the tree you sent me doesn't actually
work. Something else works, and that something else doesn't even
bisect, because even that something else only works at certain points.
You really expect me to take crap like that? Hell no.
If your stuff isn't self-sufficient, then it's not something I want to
ever pull. If the top of the tree you ask me to pull doesn't work (and
quite frankly, every commit leading to it) then it's bad and unusable.
This shows such a fundamental misunderstanding of what you should send
me that in starting to doubt all your other pull requests. How many of
them worked by our luck? If you are not testing what you actually send
me, I simply don't want to pull from you. It's that simple.
And no, this is not fixable by *you* doing the merge, and then sending
me the end result. That is still completely broken, since if something
goes wrong and things get bisected, there are points that don't work.
Yes, yes, "bugs happen", and there are always going to be points that
don't work just because something went wrong. But it's one thing to
have an unintentional bug, and another thing to do it on _purpose_.
Linus
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [GIT PULL] EDAC updates for 4.
2015-06-24 12:14 [GIT PULL] EDAC updates for 4 Linus Torvalds
@ 2015-06-24 12:30 ` Borislav Petkov
2015-06-24 12:40 ` Linus Torvalds
0 siblings, 1 reply; 6+ messages in thread
From: Borislav Petkov @ 2015-06-24 12:30 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, linux-edac, the arch/x86 maintainers
On Wed, Jun 24, 2015 at 05:14:34AM -0700, Linus Torvalds wrote:
> This shows such a fundamental misunderstanding of what you should send
> me that in starting to doubt all your other pull requests. How many of
> them worked by our luck? If you are not testing what you actually send
> me, I simply don't want to pull from you. It's that simple.
Ok, now this is really uncalled for.
I made the mistake of having the RAS x86 stuff going through tip - as it
always does - and have the drivers/edac/ changes in the EDAC tree.
But I have always merged the tip/x86/ras branch which contained the x86
changes into the EDAC tree when testing. Basically what I should've done
with the pull request too.
And dammit, I did test the hell of this thing. Like everything else I'm
testing. I'm trying to do my best but I can only try.
If there's anything I can do to stop you from doubting my pull requests,
please let me know.
Thanks.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [GIT PULL] EDAC updates for 4.
2015-06-24 12:30 ` Borislav Petkov
@ 2015-06-24 12:40 ` Linus Torvalds
2015-06-24 13:01 ` Linus Torvalds
0 siblings, 1 reply; 6+ messages in thread
From: Linus Torvalds @ 2015-06-24 12:40 UTC (permalink / raw)
To: Borislav Petkov
Cc: Linux Kernel Mailing List, linux-edac, the arch/x86 maintainers
On Wed, Jun 24, 2015 at 5:30 AM, Borislav Petkov <bp@suse.de> wrote:
>
> Ok, now this is really uncalled for.
No, it really isn't.
You still seem to be in denial:
> And dammit, I did test the hell of this thing. Like everything else I'm
> testing. I'm trying to do my best but I can only try.
NO YOU DID NOT! Stop claiming that.
You didn't actually test what you sent me. YOU TESTED SOMETHING
ENTIRELY DIFFERENT.
Do you really not see the difference? Because that's a honking big difference.
What needs to happen is:
- you get rid of all the commits that don't work as-is in your tree.
If there is a commit that depends on something that isn't in your
tree, that commit needs to be gone.
- I can then merge that subset that actually works on its own.
And then, eventually, the commits that depend on other code, need to
be rebased and re-tested on top of what they depend on. Because we
don't *merge* dependencies after-the-fact. That just means that parts
of the tree never worked.
In the future, if you have code that depends on other non-merged
branches, you should make separate branches for that code, and base it
on top of the code it depends on.
You *never* do what you apparently did here, which was to pick a
random point in the past that wasn't even sufficient for the code you
wanted to test, and then say "in order for this code to work, it needs
to be merged with something else".
Linus
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [GIT PULL] EDAC updates for 4.
2015-06-24 12:40 ` Linus Torvalds
@ 2015-06-24 13:01 ` Linus Torvalds
2015-06-24 13:15 ` Borislav Petkov
0 siblings, 1 reply; 6+ messages in thread
From: Linus Torvalds @ 2015-06-24 13:01 UTC (permalink / raw)
To: Borislav Petkov
Cc: Linux Kernel Mailing List, linux-edac, the arch/x86 maintainers
On Wed, Jun 24, 2015 at 5:40 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> You didn't actually test what you sent me. YOU TESTED SOMETHING
> ENTIRELY DIFFERENT.
Btw, it worries me that not only are you in denial about this,
apparently you have always done it:
"But I have always merged the tip/x86/ras branch which contained the x86
changes into the EDAC tree when testing. Basically what I should've done
with the pull request too"
because this shows that your workflow is just fundamentally broken.
You should test *YOUR* branch. That's the primary thing. Make sure
your code works and makes sense, and nothing else really matters.
Sure, feel free to go ahead and also test whatever other combinations
(more testing is never wrong), but those are very definitely
secondary, and aren't nearly as important. And it is never a
_replacement_ for testing your branch, it is always a "in addition
to".
I'd much rather you test the thing you send me twice as much, and
*never* test any combination, than seeing that you primarily test
combinations with other branches.
And yes, if it then turns out that there are often interactions with
other branches that means that the integrated thing doesn't work (even
after the individual branches have been tested extensively and work on
their own), then sure, that can be a problem.
Those kinds of problems are fairly unusual, but they tend to mean that
multiple people are stepping on each others toes. It isn't all that
different from "those two development trees often cause conflicts",
and usually means that either the code needs some re-organization so
that people can work better independently, or it means that the
different branches really are working on the same thing, and perhaps
need to be working more closely together.
But generally, the *less* intertwined you are, the better off you are.
It's usually much better to try to have different branches and
developers be as independent as possible, so that they don't get
serialization issues.
Linus
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [GIT PULL] EDAC updates for 4.
2015-06-24 13:01 ` Linus Torvalds
@ 2015-06-24 13:15 ` Borislav Petkov
2015-06-24 17:13 ` [GIT PULL] EDAC updates for 4.2 - v2 Borislav Petkov
0 siblings, 1 reply; 6+ messages in thread
From: Borislav Petkov @ 2015-06-24 13:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, linux-edac, the arch/x86 maintainers
On Wed, Jun 24, 2015 at 06:01:41AM -0700, Linus Torvalds wrote:
> On Wed, Jun 24, 2015 at 5:40 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > You didn't actually test what you sent me. YOU TESTED SOMETHING
> > ENTIRELY DIFFERENT.
>
> Btw, it worries me that not only are you in denial about this,
> apparently you have always done it:
>
> "But I have always merged the tip/x86/ras branch which contained the x86
> changes into the EDAC tree when testing. Basically what I should've done
> with the pull request too"
"always" meant during the 4.1-rc cycle, of course. Only for this
release.
> because this shows that your workflow is just fundamentally broken.
>
> You should test *YOUR* branch. That's the primary thing. Make sure
> your code works and makes sense, and nothing else really matters.
>
> Sure, feel free to go ahead and also test whatever other combinations
> (more testing is never wrong), but those are very definitely
> secondary, and aren't nearly as important. And it is never a
> _replacement_ for testing your branch, it is always a "in addition
> to".
Ok, understood.
> I'd much rather you test the thing you send me twice as much, and
> *never* test any combination, than seeing that you primarily test
> combinations with other branches.
>
> And yes, if it then turns out that there are often interactions with
> other branches that means that the integrated thing doesn't work (even
> after the individual branches have been tested extensively and work on
> their own), then sure, that can be a problem.
>
> Those kinds of problems are fairly unusual, but they tend to mean that
> multiple people are stepping on each others toes. It isn't all that
> different from "those two development trees often cause conflicts",
> and usually means that either the code needs some re-organization so
> that people can work better independently, or it means that the
> different branches really are working on the same thing, and perhaps
> need to be working more closely together.
>
> But generally, the *less* intertwined you are, the better off you are.
> It's usually much better to try to have different branches and
> developers be as independent as possible, so that they don't get
> serialization issues.
Yeah, so as I said earlier, in hindsight, I should've stuck the error
injection stuff completely into tip as it depends on it. But we carry it
in drivers/edac/ for some archaic reason or because it was easier this
way at the time. In the meantime, it depends so much on x86 facilities
that it actually belongs into arch/x86/ras/. I even had patches which
did that.
I'll try to dust them off for 4.2-rc maybe, let's see what happens.
In the meantime, I've zapped those two offending patches and am testing
a v2 pull request.
Thanks for explaining the situation, fully agreed and noted for the
future.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
^ permalink raw reply [flat|nested] 6+ messages in thread
* [GIT PULL] EDAC updates for 4.2 - v2
2015-06-24 13:15 ` Borislav Petkov
@ 2015-06-24 17:13 ` Borislav Petkov
0 siblings, 0 replies; 6+ messages in thread
From: Borislav Petkov @ 2015-06-24 17:13 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, linux-edac, the arch/x86 maintainers
On Wed, Jun 24, 2015 at 03:15:03PM +0200, Borislav Petkov wrote:
> In the meantime, I've zapped those two offending patches and am
> testing a v2 pull request.
Ok,
second try. I've zapped the commits which depended on stuff from tip,
ran standard *config builds and did some error injecting with the
affected module to make sure it still works as expected.
I've test-merged the pile with your tree from earlier today and there
are two conflicts. One in arch/arm64/boot/dts/apm/apm-storm.dtsi and one
in arch/x86/Kconfig. I'm adding how I've resolved them at the end, in
case it helps.
The arch/arm64/boot/dts/apm/apm-storm.dtsi resolve I tested by running
it through the DT-compiler (it is included in apm-mustang.dts):
$ dtc -I dts -O dtb arch/arm64/boot/dts/apm/apm-mustang.dts > test.dtb
$ file test.dtb
test.dtb: Device Tree Blob version 17, size=16933, boot CPU=0, string block size=665, DT structure block size=16212
and by running it by ARM people for sanity-checking.
Thanks and sorry for causing that confusion earlier. It won't happen
again.
----------------------------------------------------------------
The following changes since commit b787f68c36d49bb1d9236f403813641efa74a031:
Linux 4.1-rc1 (2015-04-26 17:59:10 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bp/bp.git tags/edac_for_4.2_2
for you to fetch changes up to 043b43180efee8dcc41dde5ca710827b26d17510:
EDAC: Update Documentation/edac.txt (2015-06-24 18:17:40 +0200)
----------------------------------------------------------------
EDAC changes, v2:
* New APM X-Gene SoC EDAC driver (Loc Ho)
* AMD error injection module improvements (Aravind Gopalakrishnan)
* Altera Arria 10 support (Thor Thayer)
* misc fixes and cleanups all over the place
----------------------------------------------------------------
Alan Tull (1):
EDAC, altera: Do not allow suspend when EDAC is enabled
Aravind Gopalakrishnan (5):
EDAC, mce_amd_inj: Use MCE_INJECT_GET macro for bank node too
EDAC, mce_amd_inj: Read out number of MCE banks from the hardware
EDAC, mce_amd_inj: Modify flags attribute to use string arguments
EDAC, mce_amd_inj: Add individual permissions field to dfs_node
EDAC, mce_amd_inj: Add README file
Arnd Bergmann (1):
EDAC, xgene: Fix cpuid abuse
Borislav Petkov (6):
EDAC: Cleanup atomic_scrub mess
EDAC, edac_stub: Drop arch-specific include
EDAC, mce_amd_inj: Cleanup and simplify README
EDAC, mce_amd_inj: Move bit preparations before the injection
EDAC, mce_amd_inj: Set MISCV on injection
EDAC: Update Documentation/edac.txt
Johannes Thumshirn (1):
MAINTAINERS: Change Johannes Thumshirn's email address
Loc Ho (5):
arm64: Enable EDAC on ARM64
MAINTAINERS: Add entry for APM X-Gene SoC EDAC driver
Documentation: Add documentation for the APM X-Gene SoC EDAC DTS binding
EDAC: Add APM X-Gene SoC EDAC driver
arm64: Add APM X-Gene SoC EDAC DTS entries
Rami Rosen (1):
EDAC: Fix typos in Documentation/edac.txt
Thor Thayer (5):
EDAC, altera: Do not build it as a module
EDAC, altera: Generalize driver to use DT Memory size
EDAC, altera: Refactor for Altera CycloneV SoC
EDAC, altera: Add Arria10 EDAC support
arm: socfpga: dts: Add Arria10 SDRAM EDAC DTS support
York Sun (2):
EDAC, mpc8xxx: Adapt for FSL SoC
EDAC, mpc85xx: Extend error address to 64 bit
kbuild test robot (1):
EDAC, mce_amd_inj: Make inj_type static
.../bindings/arm/altera/socfpga-sdram-edac.txt | 2 +-
.../devicetree/bindings/edac/apm-xgene-edac.txt | 79 ++
Documentation/edac.txt | 289 +++--
MAINTAINERS | 17 +-
arch/arm/Kconfig | 2 +
arch/arm/boot/dts/socfpga_arria10.dtsi | 11 +
arch/arm/include/asm/edac.h | 5 +-
arch/arm64/Kconfig | 1 +
arch/arm64/boot/dts/apm/apm-storm.dtsi | 83 ++
arch/mips/Kconfig | 1 +
arch/mips/include/asm/edac.h | 4 +-
arch/powerpc/Kconfig | 2 +
arch/powerpc/include/asm/edac.h | 4 +-
arch/tile/Kconfig | 1 +
arch/tile/include/asm/edac.h | 29 -
arch/x86/Kconfig | 2 +
arch/x86/include/asm/edac.h | 2 +-
drivers/edac/Kconfig | 22 +-
drivers/edac/Makefile | 1 +
drivers/edac/altera_edac.c | 381 +++---
drivers/edac/altera_edac.h | 201 ++++
drivers/edac/edac_mc.c | 9 +-
drivers/edac/edac_stub.c | 1 -
drivers/edac/mce_amd_inj.c | 177 ++-
drivers/edac/mpc85xx_edac.c | 10 +-
drivers/edac/mpc85xx_edac.h | 1 +
drivers/edac/xgene_edac.c | 1215 ++++++++++++++++++++
27 files changed, 2175 insertions(+), 377 deletions(-)
create mode 100644 Documentation/devicetree/bindings/edac/apm-xgene-edac.txt
delete mode 100644 arch/tile/include/asm/edac.h
create mode 100644 drivers/edac/altera_edac.h
create mode 100644 drivers/edac/xgene_edac.c
Merge conflicts:
---
diff --cc arch/arm64/boot/dts/apm/apm-storm.dtsi
index d8f3a1c65ecd,577799f0c5a3..0bb287ca0a98
--- a/arch/arm64/boot/dts/apm/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm/apm-storm.dtsi
@@@ -374,28 -374,89 +374,111 @@@
};
};
+ msi: msi@79000000 {
+ compatible = "apm,xgene1-msi";
+ msi-controller;
+ reg = <0x00 0x79000000 0x0 0x900000>;
+ interrupts = < 0x0 0x10 0x4
+ 0x0 0x11 0x4
+ 0x0 0x12 0x4
+ 0x0 0x13 0x4
+ 0x0 0x14 0x4
+ 0x0 0x15 0x4
+ 0x0 0x16 0x4
+ 0x0 0x17 0x4
+ 0x0 0x18 0x4
+ 0x0 0x19 0x4
+ 0x0 0x1a 0x4
+ 0x0 0x1b 0x4
+ 0x0 0x1c 0x4
+ 0x0 0x1d 0x4
+ 0x0 0x1e 0x4
+ 0x0 0x1f 0x4>;
+ };
+
+ csw: csw@7e200000 {
+ compatible = "apm,xgene-csw", "syscon";
+ reg = <0x0 0x7e200000 0x0 0x1000>;
+ };
+
+ mcba: mcba@7e700000 {
+ compatible = "apm,xgene-mcb", "syscon";
+ reg = <0x0 0x7e700000 0x0 0x1000>;
+ };
+
+ mcbb: mcbb@7e720000 {
+ compatible = "apm,xgene-mcb", "syscon";
+ reg = <0x0 0x7e720000 0x0 0x1000>;
+ };
+
+ efuse: efuse@1054a000 {
+ compatible = "apm,xgene-efuse", "syscon";
+ reg = <0x0 0x1054a000 0x0 0x20>;
+ };
+
+ edac@78800000 {
+ compatible = "apm,xgene-edac";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ regmap-csw = <&csw>;
+ regmap-mcba = <&mcba>;
+ regmap-mcbb = <&mcbb>;
+ regmap-efuse = <&efuse>;
+ reg = <0x0 0x78800000 0x0 0x100>;
+ interrupts = <0x0 0x20 0x4>,
+ <0x0 0x21 0x4>,
+ <0x0 0x27 0x4>;
+
+ edacmc@7e800000 {
+ compatible = "apm,xgene-edac-mc";
+ reg = <0x0 0x7e800000 0x0 0x1000>;
+ memory-controller = <0>;
+ };
+
+ edacmc@7e840000 {
+ compatible = "apm,xgene-edac-mc";
+ reg = <0x0 0x7e840000 0x0 0x1000>;
+ memory-controller = <1>;
+ };
+
+ edacmc@7e880000 {
+ compatible = "apm,xgene-edac-mc";
+ reg = <0x0 0x7e880000 0x0 0x1000>;
+ memory-controller = <2>;
+ };
+
+ edacmc@7e8c0000 {
+ compatible = "apm,xgene-edac-mc";
+ reg = <0x0 0x7e8c0000 0x0 0x1000>;
+ memory-controller = <3>;
+ };
+
+ edacpmd@7c000000 {
+ compatible = "apm,xgene-edac-pmd";
+ reg = <0x0 0x7c000000 0x0 0x200000>;
+ pmd-controller = <0>;
+ };
+
+ edacpmd@7c200000 {
+ compatible = "apm,xgene-edac-pmd";
+ reg = <0x0 0x7c200000 0x0 0x200000>;
+ pmd-controller = <1>;
+ };
+
+ edacpmd@7c400000 {
+ compatible = "apm,xgene-edac-pmd";
+ reg = <0x0 0x7c400000 0x0 0x200000>;
+ pmd-controller = <2>;
+ };
+
+ edacpmd@7c600000 {
+ compatible = "apm,xgene-edac-pmd";
+ reg = <0x0 0x7c600000 0x0 0x200000>;
+ pmd-controller = <3>;
+ };
+ };
+
pcie0: pcie@1f2b0000 {
status = "disabled";
device_type = "pci";
diff --cc arch/x86/Kconfig
index 7e39f9b22705,482c160a9fe9..8e0b76ad8350
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@@ -17,111 -22,61 +17,113 @@@ config X86_6
### Arch settings
config X86
def_bool y
- select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI
- select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
+ select ACPI_LEGACY_TABLES_LOOKUP if ACPI
+ select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI
+ select ANON_INODES
+ select ARCH_CLOCKSOURCE_DATA
+ select ARCH_DISCARD_MEMBLOCK
+ select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS
+ select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FAST_MULTIPLIER
select ARCH_HAS_GCOV_PROFILE_ALL
+ select ARCH_HAS_SG_CHAIN
+ select ARCH_HAVE_NMI_SAFE_CMPXCHG
+ select ARCH_MIGHT_HAVE_ACPI_PDC if ACPI
select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_MIGHT_HAVE_PC_SERIO
- select HAVE_AOUT if X86_32
- select HAVE_UNSTABLE_SCHED_CLOCK
- select ARCH_SUPPORTS_NUMA_BALANCING if X86_64
- select ARCH_SUPPORTS_INT128 if X86_64
- select HAVE_IDE
- select HAVE_OPROFILE
- select HAVE_PCSPKR_PLATFORM
- select HAVE_PERF_EVENTS
- select HAVE_IOREMAP_PROT
- select HAVE_KPROBES
- select HAVE_MEMBLOCK
- select HAVE_MEMBLOCK_NODE_MAP
- select ARCH_DISCARD_MEMBLOCK
- select ARCH_WANT_OPTIONAL_GPIOLIB
+ select ARCH_SUPPORTS_ATOMIC_RMW
+ select ARCH_SUPPORTS_INT128 if X86_64
+ select ARCH_SUPPORTS_NUMA_BALANCING if X86_64
+ select ARCH_USE_BUILTIN_BSWAP
+ select ARCH_USE_CMPXCHG_LOCKREF if X86_64
+ select ARCH_USE_QUEUED_RWLOCKS
+ select ARCH_USE_QUEUED_SPINLOCKS
select ARCH_WANT_FRAME_POINTERS
- select HAVE_DMA_ATTRS
- select HAVE_DMA_CONTIGUOUS
- select HAVE_KRETPROBES
+ select ARCH_WANT_IPC_PARSE_VERSION if X86_32
+ select ARCH_WANT_OPTIONAL_GPIOLIB
+ select BUILDTIME_EXTABLE_SORT
+ select CLKEVT_I8253
+ select CLKSRC_I8253 if X86_32
+ select CLOCKSOURCE_VALIDATE_LAST_CYCLE
+ select CLOCKSOURCE_WATCHDOG
+ select CLONE_BACKWARDS if X86_32
+ select COMPAT_OLD_SIGACTION if IA32_EMULATION
+ select DCACHE_WORD_ACCESS
++ select EDAC_ATOMIC_SCRUB
++ select EDAC_SUPPORT
+ select GENERIC_CLOCKEVENTS
+ select GENERIC_CLOCKEVENTS_BROADCAST if X86_64 || (X86_32 && X86_LOCAL_APIC)
+ select GENERIC_CLOCKEVENTS_MIN_ADJUST
+ select GENERIC_CMOS_UPDATE
+ select GENERIC_CPU_AUTOPROBE
select GENERIC_EARLY_IOREMAP
- select HAVE_OPTPROBES
- select HAVE_KPROBES_ON_FTRACE
- select HAVE_FTRACE_MCOUNT_RECORD
- select HAVE_FENTRY if X86_64
+ select GENERIC_FIND_FIRST_BIT
+ select GENERIC_IOMAP
+ select GENERIC_IRQ_PROBE
+ select GENERIC_IRQ_SHOW
+ select GENERIC_PENDING_IRQ if SMP
+ select GENERIC_SMP_IDLE_THREAD
+ select GENERIC_STRNCPY_FROM_USER
+ select GENERIC_STRNLEN_USER
+ select GENERIC_TIME_VSYSCALL
+ select HAVE_ACPI_APEI if ACPI
+ select HAVE_ACPI_APEI_NMI if ACPI
+ select HAVE_ALIGNED_STRUCT_PAGE if SLUB
+ select HAVE_AOUT if X86_32
+ select HAVE_ARCH_AUDITSYSCALL
+ select HAVE_ARCH_HUGE_VMAP if X86_64 || X86_PAE
+ select HAVE_ARCH_JUMP_LABEL
+ select HAVE_ARCH_KASAN if X86_64 && SPARSEMEM_VMEMMAP
+ select HAVE_ARCH_KGDB
+ select HAVE_ARCH_KMEMCHECK
+ select HAVE_ARCH_SECCOMP_FILTER
+ select HAVE_ARCH_SOFT_DIRTY if X86_64
+ select HAVE_ARCH_TRACEHOOK
+ select HAVE_ARCH_TRANSPARENT_HUGEPAGE
+ select HAVE_BPF_JIT if X86_64
+ select HAVE_CC_STACKPROTECTOR
+ select HAVE_CMPXCHG_DOUBLE
+ select HAVE_CMPXCHG_LOCAL
+ select HAVE_CONTEXT_TRACKING if X86_64
select HAVE_C_RECORDMCOUNT
+ select HAVE_DEBUG_KMEMLEAK
+ select HAVE_DEBUG_STACKOVERFLOW
+ select HAVE_DMA_API_DEBUG
+ select HAVE_DMA_ATTRS
+ select HAVE_DMA_CONTIGUOUS
select HAVE_DYNAMIC_FTRACE
select HAVE_DYNAMIC_FTRACE_WITH_REGS
- select HAVE_FUNCTION_TRACER
- select HAVE_FUNCTION_GRAPH_TRACER
- select HAVE_FUNCTION_GRAPH_FP_TEST
- select HAVE_SYSCALL_TRACEPOINTS
- select SYSCTL_EXCEPTION_TRACE
- select HAVE_KVM
- select HAVE_ARCH_KGDB
- select HAVE_ARCH_TRACEHOOK
- select HAVE_GENERIC_DMA_COHERENT if X86_32
select HAVE_EFFICIENT_UNALIGNED_ACCESS
- select USER_STACKTRACE_SUPPORT
- select HAVE_REGS_AND_STACK_ACCESS_API
- select HAVE_DMA_API_DEBUG
- select HAVE_KERNEL_GZIP
+ select HAVE_FENTRY if X86_64
+ select HAVE_FTRACE_MCOUNT_RECORD
+ select HAVE_FUNCTION_GRAPH_FP_TEST
+ select HAVE_FUNCTION_GRAPH_TRACER
+ select HAVE_FUNCTION_TRACER
+ select HAVE_GENERIC_DMA_COHERENT if X86_32
+ select HAVE_HW_BREAKPOINT
+ select HAVE_IDE
+ select HAVE_IOREMAP_PROT
+ select HAVE_IRQ_EXIT_ON_IRQ_STACK if X86_64
+ select HAVE_IRQ_TIME_ACCOUNTING
select HAVE_KERNEL_BZIP2
+ select HAVE_KERNEL_GZIP
+ select HAVE_KERNEL_LZ4
select HAVE_KERNEL_LZMA
- select HAVE_KERNEL_XZ
select HAVE_KERNEL_LZO
- select HAVE_KERNEL_LZ4
- select HAVE_HW_BREAKPOINT
+ select HAVE_KERNEL_XZ
+ select HAVE_KPROBES
+ select HAVE_KPROBES_ON_FTRACE
+ select HAVE_KRETPROBES
+ select HAVE_KVM
+ select HAVE_LIVEPATCH if X86_64
+ select HAVE_MEMBLOCK
+ select HAVE_MEMBLOCK_NODE_MAP
select HAVE_MIXED_BREAKPOINTS_REGS
- select PERF_EVENTS
+ select HAVE_OPROFILE
+ select HAVE_OPTPROBES
+ select HAVE_PCSPKR_PLATFORM
+ select HAVE_PERF_EVENTS
select HAVE_PERF_EVENTS_NMI
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
---
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2015-06-24 17:14 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-24 12:14 [GIT PULL] EDAC updates for 4 Linus Torvalds
2015-06-24 12:30 ` Borislav Petkov
2015-06-24 12:40 ` Linus Torvalds
2015-06-24 13:01 ` Linus Torvalds
2015-06-24 13:15 ` Borislav Petkov
2015-06-24 17:13 ` [GIT PULL] EDAC updates for 4.2 - v2 Borislav Petkov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).