talos-obmc-linux/Documentation, branch dev-5.0

hwmon: (pmbus/isl68137): Update ISL68137 to upstream

2019-04-19T02:29:09+00:00

Apply differences from hwmon review to bring the driver code to the same point. There were some key differences regarding attribute placement from the review, beyond the normal cleanup. OpenBMC-Staging-Count: 1 Signed-off-by: Patrick Venture [AJ: Rework subject] Signed-off-by: Andrew Jeffery

dt-binding: peci: add NPCM PECI documentation

2019-04-11T07:30:08+00:00

Added device tree binding documentation for Nuvoton BMC NPCM Platform Environment Control Interface(PECI). OpenBMC-Staging-Count: 1 Signed-off-by: Tomer Maimon Signed-off-by: Joel Stanley

Merge tag 'v5.0.7' into dev-5.0

2019-04-08T03:05:05+00:00

This is the 5.0.7 stable release Signed-off-by: Joel Stanley

ARM: 8833/1: Ensure that NEON code always compiles with Clang

2019-04-05T20:34:39+00:00

[ Upstream commit de9c0d49d85dc563549972edc5589d195cd5e859 ] While building arm32 allyesconfig, I ran into the following errors: arch/arm/lib/xor-neon.c:17:2: error: You should compile this file with '-mfloat-abi=softfp -mfpu=neon' In file included from lib/raid6/neon1.c:27: /home/nathan/cbl/prebuilt/lib/clang/8.0.0/include/arm_neon.h:28:2: error: "NEON support not enabled" Building V=1 showed NEON_FLAGS getting passed along to Clang but __ARM_NEON__ was not getting defined. Ultimately, it boils down to Clang only defining __ARM_NEON__ when targeting armv7, rather than armv6k, which is the '-march' value for allyesconfig. >From lib/Basic/Targets/ARM.cpp in the Clang source: // This only gets set when Neon instructions are actually available, unlike // the VFP define, hence the soft float and arch check. This is subtly // different from gcc, we follow the intent which was that it should be set // when Neon instructions are actually available. if ((FPU & NeonFPU) && !SoftFloat && ArchVersion >= 7) { Builder.defineMacro("__ARM_NEON", "1"); Builder.defineMacro("__ARM_NEON__"); // current AArch32 NEON implementations do not support double-precision // floating-point even when it is present in VFP. Builder.defineMacro("__ARM_NEON_FP", "0x" + Twine::utohexstr(HW_FP & ~HW_FP_DP)); } Ard Biesheuvel recommended explicitly adding '-march=armv7-a' at the beginning of the NEON_FLAGS definitions so that __ARM_NEON__ always gets definined by Clang. This doesn't functionally change anything because that code will only run where NEON is supported, which is implicitly armv7. Link: https://github.com/ClangBuiltLinux/linux/issues/287 Suggested-by: Ard Biesheuvel Signed-off-by: Nathan Chancellor Acked-by: Nicolas Pitre Reviewed-by: Nick Desaulniers Reviewed-by: Stefan Agner Signed-off-by: Russell King Signed-off-by: Sasha Levin

media: dt-bindings: aspeed-video: Add missing memory-region property

2019-04-04T02:22:10+00:00

Missed documenting this property in the initial commit. OpenBMC-Staging-Count: 1 Signed-off-by: Eddie James Signed-off-by: Joel Stanley

Merge tag 'v5.0.6' into dev-5.0

2019-04-03T04:44:30+00:00

This is the 5.0.6 stable release Signed-off-by: Joel Stanley

KVM: Reject device ioctls from processes other than the VM's creator

2019-04-03T04:27:38+00:00

commit ddba91801aeb5c160b660caed1800eb3aef403f8 upstream. KVM's API requires thats ioctls must be issued from the same process that created the VM. In other words, userspace can play games with a VM's file descriptors, e.g. fork(), SCM_RIGHTS, etc..., but only the creator can do anything useful. Explicitly reject device ioctls that are issued by a process other than the VM's creator, and update KVM's API documentation to extend its requirements to device ioctls. Fixes: 852b6d57dc7f ("kvm: add device control API") Cc: Signed-off-by: Sean Christopherson Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman

Merge tag 'v5.0.4' into dev-5.0

2019-03-24T23:49:05+00:00

This is the 5.0.4 stable release Signed-off-by: Joel Stanley

stable-kernel-rules.rst: add link to networking patch queue

2019-03-23T19:11:37+00:00

commit a41e8f25fa8f8f67360d88eb0eebbabe95a64bdf upstream. The networking maintainer keeps a public list of the patches being queued up for the next round of stable releases. Be sure to check there before asking for a patch to be applied so that you do not waste people's time. Signed-off-by: Greg Kroah-Hartman Acked-by: David S. Miller Signed-off-by: Jonathan Corbet Signed-off-by: Greg Kroah-Hartman

dma: Introduce dma_max_mapping_size()

2019-03-23T19:11:26+00:00

commit 133d624b1cee16906134e92d5befb843b58bcf31 upstream. The function returns the maximum size that can be mapped using DMA-API functions. The patch also adds the implementation for direct DMA and a new dma_map_ops pointer so that other implementations can expose their limit. Cc: stable@vger.kernel.org Reviewed-by: Konrad Rzeszutek Wilk Reviewed-by: Christoph Hellwig Signed-off-by: Joerg Roedel Signed-off-by: Michael S. Tsirkin Signed-off-by: Greg Kroah-Hartman