On Sat, Jun 06, 2020 at 07:30:21AM +, Christophe Leroy wrote:
> devm_gpiod_get_index() doesn't return NULL but -ENOENT when the
> requested GPIO doesn't exist, leading to the following messages:
>
> [2.742468] gpiod_direction_input: invalid GPIO (errorpointer)
> [2.748147] can't set d
Architectures can have CONFIG_TRANSPARENT_HUGEPAGE enabled but
no THP support enabled based on platforms. For ex: with 4K
PAGE_SIZE ppc64 supports THP only with radix translation.
This results in below crash when running with hash translation and
4K PAGE_SIZE.
kernel BUG at arch/powerpc/include/a
Hi Prakhar,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on arm64/for-next/core]
[also build test WARNING on powerpc/next soc/for-next v5.7 next-20200605]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we
Hi Prakhar,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on powerpc/next soc/for-next v5.7 next-20200605]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also sug
el.org/pub/scm/linux/kernel/git/arm64/linux.git
for-next/core
config: arm64-randconfig-r012-20200607 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
e429cffd4f228f70c1d9df0e5d77c08590dd9766)
reproduce (this is a W=1 build):
w
Add Documentation regarding the ima-kexec-buffer node in
the chosen node documentation
Signed-off-by: Prakhar Srivastava
---
Documentation/devicetree/bindings/chosen.txt | 17 +
1 file changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/chosen.txt
b/Docum
IMA during kexec(kexec file load) verifies the kernel signature and measures
the signature of the kernel. The signature in the logs can be used to verfiy
the
authenticity of the kernel. The logs don not get carried over kexec and thus
remote attesation cannot verify the signature of the running k
This patch moves the non-architecture specific code out of powerpc and
adds to security/ima.
Update the arm64 and powerpc kexec file load paths to carry the IMA measurement
logs.
Signed-off-by: Prakhar Srivastava
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/ima.h
Christian Zigotzky writes:
> On 04 June 2020 at 7:15 pm, Christophe Leroy wrote:
>> Yes today's linux-next boots on my powerpc 8xx board.
>>
>> Christophe
> Hello Christophe,
>
> Thanks for testing.
>
> I was able to perform a 'git bisect' [1] and identified the bad commit.
> [2] I reverted this
Hi All,
It seems, someone has fixed the boot issue. The latest Git kernel boots
on my PowerPC machines.
Thanks,
Christian
On 05 June 2020 at 6:23 pm, Christian Zigotzky wrote:
On 04 June 2020 at 7:15 pm, Christophe Leroy wrote:
Yes today's linux-next boots on my powerpc 8xx board.
Christo
This patch implements support for PDSM request 'PAPR_PDSM_HEALTH'
that returns a newly introduced 'struct nd_papr_pdsm_health' instance
containing dimm health information back to user space in response to
ND_CMD_CALL. This functionality is implemented in newly introduced
papr_pdsm_health() that que
'seq_buf' provides a very useful abstraction for writing to a string
buffer without needing to worry about it over-flowing. However even
though the API has been stable for couple of years now its still not
exported to kernel loadable modules limiting its usage.
Hence this patch proposes update to
Since papr_scm_ndctl() can be called from outside papr_scm, its
exposed to the possibility of receiving NULL as value of 'cmd_rc'
argument. This patch updates papr_scm_ndctl() to protect against such
possibility by assigning it pointer to a local variable in case cmd_rc
== NULL.
Finally the patch
Introduce support for PAPR NVDIMM Specific Methods (PDSM) in papr_scm
module and add the command family NVDIMM_FAMILY_PAPR to the white list
of NVDIMM command sets. Also advertise support for ND_CMD_CALL for the
nvdimm command mask and implement necessary scaffolding in the module
to handle ND_CMD_
Implement support for fetching nvdimm health information via
H_SCM_HEALTH hcall as documented in Ref[1]. The hcall returns a pair
of 64-bit bitmap, bitwise-and of which is then stored in
'struct papr_scm_priv' and subsequently partially exposed to
user-space via newly introduced dimm specific attri
Add documentation to 'papr_hcalls.rst' describing the bitmap flags
that are returned from H_SCM_HEALTH hcall as per the PAPR-SCM
specification.
Cc: "Aneesh Kumar K . V"
Cc: Dan Williams
Cc: Michael Ellerman
Cc: Ira Weiny
Acked-by: Ira Weiny
Signed-off-by: Vaibhav Jain
---
Changelog:
v10..v1
Changes since v10 [1]:
* Changed the definition of 'struct nd_papr_pdsm_health' to a maximal
struct 184 bytes which can be extended in future with newly
introduced 'extension_flags'
* Fixed a suspicious conversion from u64 to u8 in papr_pdsm_health
that was preventing correct initialization o
ISA v3.1 does not support the SAO storage control attribute required to
implement PROT_SAO. PROT_SAO was used by specialised system software
(Lx86) that has been discontinued for about 7 years, and is not thought
to be used elsewhere, so removal should not cause problems.
We rather remove it than
The subpage_prot syscall was added for specialised system software
(Lx86) that has been discontinued for about 7 years, and is not thought
to be used elsewhere, so disable it by default.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/configs/powernv
Relocating kernel at runtime is done very early in the boot process, so
it is not convenient to check for relocations there and react in case a
relocation was not expected.
There exists a script in scripts/ that extracts the relocations from
vmlinux that is then used at postlink to check the reloc
Relocating kernel at runtime is done very early in the boot process, so
it is not convenient to check for relocations there and react in case a
relocation was not expected.
Powerpc architecture has a script that allows to check at compile time
for such unexpected relocations: extract the common lo
This config allows to compile the kernel as PIE and to relocate it at
any virtual address at runtime: this paves the way to KASLR and to 4-level
page table folding at runtime. Runtime relocation is possible since
relocation metadata are embedded into the kernel.
Note that relocating at runtime int
This is a preparatory patch for relocatable kernel.
The kernel used to be linked at PAGE_OFFSET address and used to be loaded
physically at the beginning of the main memory. Therefore, we could use
the linear mapping for the kernel mapping.
But the relocated kernel base address will be different
This patchset originally implemented relocatable kernel support but now
also moves the kernel mapping into the vmalloc zone.
The first patch explains why we need to move the k
24 matches
Mail list logo