sha*_base_init() series functions has implemented the initialization
of the hash context, this commit use sha*_base_init() function to
replace repeated implementations.
Signed-off-by: Tianjia Zhang
---
arch/mips/cavium-octeon/crypto/octeon-sha1.c | 17 +---
.../mips/cavium-octeon/crypto/oct
sha*_base_init() series functions has implemented the initialization
of the hash context, this commit use sha*_base_init() function to
replace repeated implementations.
Signed-off-by: Tianjia Zhang
---
arch/powerpc/crypto/sha1-spe-glue.c | 17 ++--
arch/powerpc/crypto/sha1.c
sha*_base_init() series functions has implemented the initialization
of the hash context, this commit use sha*_base_init() function to
replace repeated implementations.
Signed-off-by: Tianjia Zhang
---
arch/sparc/crypto/sha1_glue.c | 14 ++---
arch/sparc/crypto/sha256_glue.c | 37 +++--
This series of patches is mainly for repetitive code cleaning. The sha
algorithm has provided generic context initialization implementation.
The context initialization code in the optimized implementation of each
platform is a repetitive code and can be deleted. The sha*_base_init()
series of funct
crypto_sha256_init() and sha256_base_init() are the same repeated
implementations, remove the crypto_sha256_init() in generic
implementation, sha224 is the same process.
Signed-off-by: Tianjia Zhang
---
crypto/sha256_generic.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(
In the init functions of sha512 and sha384, the initial hash value
use macros instead of numbers.
Signed-off-by: Tianjia Zhang
---
arch/s390/crypto/sha512_s390.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/s390/crypto/sha512_s390.c
From: Jason Wang
> Sent: 20 December 2021 03:24
>
> The strlcpy should not be used because it doesn't limit the source
> length. So that it will lead some potential bugs.
>
> But the strscpy doesn't require reading memory from the src string
> beyond the specified "count" bytes, and since the ret
On Thu, Dec 9, 2021 at 5:58 PM 王擎 wrote:
>
>
> >> From: Wang Qing
> >>
> >> of_find_device_by_node() takes a reference to the embedded struct device
> >> which needs to be dropped when error return.
> >
> >...
> >
> >>data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
> >>
On Sat, Dec 18 2021 at 21:25, Cédric Le Goater wrote:
> On 12/18/21 11:25, Thomas Gleixner wrote:
>> On Fri, Dec 17 2021 at 15:30, Nathan Chancellor wrote:
>>> On Fri, Dec 10, 2021 at 11:19:26PM +0100, Thomas Gleixner wrote:
>>> I just bisected a boot failure on my AMD test desktop to this patch a
On Fri, Dec 17, 2021 at 04:14:00PM -0600, Rob Herring wrote:
> "spidev" is not a real device, but a Linux implementation detail. It has
> never been documented either. The kernel has WARNed on the use of it for
> over 6 years. Time to remove its usage from the tree.
Reviwed-by: Mark Brown
Thanks
From: Thierry Reding
The unit-address for the Maxim MAX1237 ADCs on XPedite5200 boards don't
match the value in the "reg" property and cause a DTC warning.
Signed-off-by: Thierry Reding
---
arch/powerpc/boot/dts/xpedite5200.dts | 2 +-
arch/powerpc/boot/dts/xpedite5200_xmon.dts | 2 +-
2
This series implements livepatch on PPC32 and implements
CONFIG_DYNAMIC_FTRACE_WITH_ARGS to simplify ftracing.
v2:
- Fix problem with strict modules RWX
- Convert powerpc to CONFIG_DYNAMIC_FTRACE_WITH_ARGS
- Convert function graph tracing to C
- Refactor PPC32 versus PPC64
Signed-off-by: Christop
Trying to build livepatch on powerpc/32 results in:
kernel/livepatch/core.c: In function 'klp_resolve_symbols':
kernel/livepatch/core.c:221:23: warning: cast to pointer from integer
of different size [-Wint-to-pointer-cast]
221 | sym = (Elf64_Sym *)sechdr
CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS is required to test
direct tramp.
Signed-off-by: Christophe Leroy
---
kernel/trace/trace_selftest.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
index afd937a46496..
Livepatching a loaded module involves applying relocations through
apply_relocate_add(), which attempts to write to read-only memory when
CONFIG_STRICT_MODULE_RWX=y.
R_PPC_ADDR16_LO, R_PPC_ADDR16_HI, R_PPC_ADDR16_HA and R_PPC_REL24 are
the types generated by the kpatch-build userspace tool or klp-
PPC32 mcount() caller already saves LR on stack,
no need to save it again.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/trace/ftrace_32.S | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/powerpc/kernel/trace/ftrace_32.S
b/arch/powerpc/kernel/trace/ftrace_32.S
index 0a02c0cb
return_to_handler() was copied from PPC64. For PPC32 it
just needs to save r3 and r4, and doesn't require any nop
after the bl.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/trace/ftrace_32.S | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/arch/pow
In order to implement CONFIG_DYNAMIC_FTRACE_WITH_ARGS, change
ftrace_caller() stack layout to match struct pt_regs.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/ftrace.h | 39 +--
arch/powerpc/kernel/trace/ftrace_32.S | 29 +---
2 files
In order to implement CONFIG_DYNAMIC_FTRACE_WITH_ARGS, change ftrace_caller()
to handle LIVEPATCH the same way as frace_caller_regs().
Signed-off-by: Christophe Leroy
---
.../powerpc/kernel/trace/ftrace_64_mprofile.S | 25 ++-
1 file changed, 19 insertions(+), 6 deletions(-)
dif
Implement CONFIG_DYNAMIC_FTRACE_WITH_ARGS. It accelerates the call
of livepatching.
Also note that powerpc being the last one to convert to
CONFIG_DYNAMIC_FTRACE_WITH_ARGS, it will now be possible to remove
klp_arch_set_pc() on all architectures.
Signed-off-by: Christophe Leroy
---
arch/powerpc
PPC64 needs some special logic to properly set up the TOC.
See commit 85baa095497f ("powerpc/livepatch: Add live patching support
on ppc64le") for details.
PPC32 doesn't have TOC so it doesn't need that logic, so adding
LIVEPATCH support is straight forward.
Add CONFIG_LIVEPATCH_64 and move livep
ftrace_enable_ftrace_graph_caller() and
ftrace_disable_ftrace_graph_caller() have common code.
They will have even more common code after following patch.
Refactor into a single ftrace_modify_ftrace_graph_caller() function.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/trace/ftrace.c
Modify function graph tracer to be handled directly by the standard
ftrace caller.
This is made possible as powerpc now supports
CONFIG_DYNAMIC_FTRACE_WITH_ARGS.
This change simplifies the call of function graph ftrace.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/ftrace.h
PPC64 mprofile versions and PPC32 are very similar.
Modify PPC64 version so that if can be reused for PPC32.
Signed-off-by: Christophe Leroy
---
.../powerpc/kernel/trace/ftrace_64_mprofile.S | 73 +--
1 file changed, 51 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/k
Functions in ftrace_32.S are common with PPC64.
Reuse the ones defined for PPC64 with slight modification
when required.
Signed-off-by: Christophe Leroy
---
arch/powerpc/kernel/trace/Makefile| 7 +-
arch/powerpc/kernel/trace/ftrace_32.S | 152 --
.../trace/
While commit a4e92ce8e4c8 ("powerpc/fadump: Reservationless firmware
assisted dump"), introduced Linux kernel's Contiguous Memory Allocator
(CMA) based reservation for fadump, it came with the assumption that
the memory remains reserved even if CMA activation fails. This
assumption ensures no kerne
Commit 072355c1cf2d ("mm/cma: expose all pages to the buddy if
activation of an area fails") started exposing all pages to buddy
allocator on CMA activation failure. But there can be CMA users that
want to handle the reserved memory differently on CMA allocation
failure. Provide an option to opt ou
With commit a4e92ce8e4c8 ("powerpc/fadump: Reservationless firmware
assisted dump"), Linux kernel's Contiguous Memory Allocator (CMA)
based reservation was introduced in fadump. That change was aimed at
using CMA to let applications utilize the memory reserved for fadump
while blocking it from bein
On Sat, Dec 18, 2021 at 01:20:04PM -0800, Yury Norov wrote:
> Kernel code calls bitmap_weight() to compare the weight of bitmap with
> a given number. We can do it more efficiently with bitmap_weight_{eq, ...}
> because conditional bitmap_weight may stop traversing the bitmap earlier,
> as soon as
On 12/11/21 5:28 PM, Stefan Berger wrote:
> Fix the following crash on kexec by checking chip->ops for a NULL pointer
> in tpm_chip_start() and returning an error code if this is the case.
>
> BUG: Kernel NULL pointer dereference on read at 0x0060
> Faulting instruction address: 0xc099
On 12/20/21 19:39, Tyrel Datwyler wrote:
On 12/11/21 5:28 PM, Stefan Berger wrote:
Fix the following crash on kexec by checking chip->ops for a NULL pointer
in tpm_chip_start() and returning an error code if this is the case.
BUG: Kernel NULL pointer dereference on read at 0x0060
Faulting
On Mon, Dec 20, 2021 at 08:05:58PM -0500, Stefan Berger wrote:
> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
> index ddaeceb7e109..4cb908349b31 100644
> +++ b/drivers/char/tpm/tpm-chip.c
> @@ -473,15 +473,8 @@ static void tpm_del_char_device(struct tpm_chip *chip)
>
On 12/20/21 20:13, Jason Gunthorpe wrote:
On Mon, Dec 20, 2021 at 08:05:58PM -0500, Stefan Berger wrote:
diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
index ddaeceb7e109..4cb908349b31 100644
+++ b/drivers/char/tpm/tpm-chip.c
@@ -473,15 +473,8 @@ static void tpm_del_ch
On 12/20/21 5:05 PM, Stefan Berger wrote:
>
> On 12/20/21 19:39, Tyrel Datwyler wrote:
>> On 12/11/21 5:28 PM, Stefan Berger wrote:
>>> Fix the following crash on kexec by checking chip->ops for a NULL pointer
>>> in tpm_chip_start() and returning an error code if this is the case.
>>>
>>> BUG: Ke
On 12/20/21 5:31 PM, Stefan Berger wrote:
>
> On 12/20/21 20:13, Jason Gunthorpe wrote:
>> On Mon, Dec 20, 2021 at 08:05:58PM -0500, Stefan Berger wrote:
>>
>>> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
>>> index ddaeceb7e109..4cb908349b31 100644
>>> +++ b/drivers/char
Static variables do not need to be initialised to 0, because compiler
will initialise all uninitialised statics to 0. Thus, remove the
unneeded initializations.
Signed-off-by: Xiang wangx
---
arch/powerpc/platforms/powermac/nvram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --gi
On 12/20/21 18:29, Cédric Le Goater wrote:
> On 12/20/21 02:23, Alexey Kardashevskiy wrote:
>> At the moment KVM on PPC creates 4 types of entries under the kvm debugfs:
>> 1) "%pid-%fd" per a KVM instance (for all platforms);
>> 2) "vm%pid" (for PPC Book3s HV KVM);
>> 3) "vm%u_vcpu%u_timing" (f
This allows compiling the upstream Linux with the upstream llvm with one fix on
top;
https://reviews.llvm.org/D115419
This is based on sha1
798527287598 Michael Ellerman "Automatic merge of 'next' into merge (2021-12-14
00:12)".
Please comment. Thanks.
Alan Modra (1):
powerpc/toc: PowerPC6
From: Alan Modra
This patch future-proofs the kernel against linker changes that might
put the toc pointer at some location other than .got+0x8000, by
replacing __toc_start+0x8000 with .TOC. throughout. If the kernel's
idea of the toc pointer doesn't agree with the linker, bad things
happen.
pr
From: Daniel Axtens
LLVM's integrated assembler does not like either -Wa,-mpower4
or -Wa,-many. So just don't pass them if they're not supported.
Signed-off-by: Daniel Axtens
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/Makefile | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
It is used just once and does not really help with readability, remove it.
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/kernel/exceptions-64s.S | 17 +++--
1 file changed, 3 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S
b/arch/powerpc/kern
From: Daniel Axtens
The LLVM integrated assembler really does not like us reassigning things
to the same label:
:7:9: error: invalid reassignment of non-absolute variable
'fs_label'
This happens across a bunch of platforms:
https://github.com/ClangBuiltLinux/linux/issues/1043
https://github.co
The dssall ("Data Stream Stop All") instruction is obsolete altogether
with other Data Cache Instructions since ISA 2.03 (year 2006).
LLVM IAS does not support it but PPC970 seems to be using it.
This switches dssall to .long as there is no much point in fixing LLVM.
Signed-off-by: Alexey Kardash
The llvm integrated assembler does not recognise the ISA 2.05 tlbiel
version. Work around it by switching to .long when an old arch level
detected.
Signed-off-by: Daniel Axtens
[aik: did "Eventually do this more smartly"]
Signed-off-by: Alexey Kardashevskiy
---
arch/powerpc/include/asm/ppc-opco
44 matches
Mail list logo
