From: Eric Biggers
Instead of providing crypto_shash algorithms for the arch-optimized
SHA-256 code, instead implement the SHA-256 library. This is much
simpler, it makes the SHA-256 library functions be arch-optimized, and
it fixes the longstanding issue where the arch-optimized SHA-256 was
dis
From: Eric Biggers
Instead of providing crypto_shash algorithms for the arch-optimized
SHA-256 code, instead implement the SHA-256 library. This is much
simpler, it makes the SHA-256 library functions be arch-optimized, and
it fixes the longstanding issue where the arch-optimized SHA-256 was
dis
From: Eric Biggers
sha256_base.h is no longer used, so remove it.
Signed-off-by: Eric Biggers
---
include/crypto/sha256_base.h | 183 ---
1 file changed, 183 deletions(-)
delete mode 100644 include/crypto/sha256_base.h
diff --git a/include/crypto/sha256_base.h
From: Eric Biggers
Since arch/sparc/crypto/opcodes.h is now needed outside the
arch/sparc/crypto/ directory, move it into arch/sparc/include/asm/ so
that it can be included as .
Signed-off-by: Eric Biggers
---
arch/sparc/crypto/aes_asm.S | 3 +--
arch/sparc/crypto/aes_glue.c
From: Eric Biggers
Follow best practices by changing the length parameters to size_t and
explicitly specifying the length of the output digest arrays.
Signed-off-by: Eric Biggers
---
include/crypto/sha2.h | 8
lib/crypto/sha256.c | 8
2 files changed, 8 insertions(+), 8 del
From: Eric Biggers
Instead of providing crypto_shash algorithms for the arch-optimized
SHA-256 code, instead implement the SHA-256 library. This is much
simpler, it makes the SHA-256 library functions be arch-optimized, and
it fixes the longstanding issue where the arch-optimized SHA-256 was
dis
From: Eric Biggers
Instead of providing crypto_shash algorithms for the arch-optimized
SHA-256 code, instead implement the SHA-256 library. This is much
simpler, it makes the SHA-256 library functions be arch-optimized, and
it fixes the longstanding issue where the arch-optimized SHA-256 was
dis
From: Eric Biggers
As has been done for various other algorithms, rework the design of the
SHA-256 library to support arch-optimized implementations, and make
crypto/sha256.c expose both generic and arch-optimized shash algorithms
that wrap the library functions.
This allows users of the SHA-256
From: Eric Biggers
Instead of providing crypto_shash algorithms for the arch-optimized
SHA-256 code, instead implement the SHA-256 library. This is much
simpler, it makes the SHA-256 library functions be arch-optimized, and
it fixes the longstanding issue where the arch-optimized SHA-256 was
dis
From: Eric Biggers
Instead of providing crypto_shash algorithms for the arch-optimized
SHA-256 code, instead implement the SHA-256 library. This is much
simpler, it makes the SHA-256 library functions be arch-optimized, and
it fixes the longstanding issue where the arch-optimized SHA-256 was
dis
From: Eric Biggers
Instead of providing crypto_shash algorithms for the arch-optimized
SHA-256 code, instead implement the SHA-256 library. This is much
simpler, it makes the SHA-256 library functions be arch-optimized, and
it fixes the longstanding issue where the arch-optimized SHA-256 was
dis
From: Eric Biggers
Since kernel-mode NEON sections are now preemptible on arm64, there is
no longer any need to limit the length of them.
Signed-off-by: Eric Biggers
---
arch/arm64/crypto/sha256-glue.c | 19 ++-
1 file changed, 2 insertions(+), 17 deletions(-)
diff --git a/arc
This is based on cryptodev commit bf0b4f15267ca404 plus the series
https://lore.kernel.org/linux-crypto/20250422152716.5923-1-ebigg...@kernel.org/.
It can also be retrieved from:
git fetch
https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git sha256-lib-v1
Following the example
In preparation for making the kmalloc family of allocators type aware,
we need to make sure that the returned type from the allocation matches
the type of the variable being assigned. (Before, the allocator would
always return "void *", which can be implicitly cast to any pointer type.)
The assign
The following macros were introduced in power5+-pmu via
commit aabbaa6036fd ("perfcounters/powerpc: add support
for POWER5+ processors")
MMCR1_TTM2SEL_SH, MMCR1_TTMSEL_MSK, MMCR1_TD_CP_DBG1SEL_SH,
MMCR1_TD_CP_DBG2SEL_SH, MMCR1_TD_CP_DBG3SEL_SH, MMCR1_GRS_L2SEL_MSK,
MMCR1_GRS_L3SEL_MSK, MMCR1_GRS_M
The following macros were introduced in power9-pmu via
commit 8c002dbd05ee ("powerpc/perf: Power9 PMU support")
POWER9_MMCRA_IFM2, POWER9_MMCRA_IFM3
Removing the above macros as they are defined but never used.
Co-developed-by: Anjali K
Signed-off-by: Anjali K
Signed-off-by: Likhitha Korrapati
The following macros were introduced in power8-pmu via
commit b1113557fb5f ("powerpc/perf: Define BHRB generic functions, data
and flags for POWER8")
POWER8_MMCRA_IFM2, POWER8_MMCRA_IFM3
Removing the above macros as they are defined but never used.
Co-developed-by: Anjali K
Signed-off-by: Anjal
The following macros were introduced in power7-pmu via
commit 4da52960fd1a ("perf_counters: powerpc: Add
support for POWER7 processors")
PM_PMC_MSKS, PM_COMBINE_MSKS, MMCR1_TTM1SEL_SH,
MMCR1_TTM2SEL_SH, MMCR1_TTM3SEL_SH, MMCR1_TTMSEL_MSK,
MMCR1_L2SEL_MSK, MMCR1_PMC2_COMBINE_SH, MMCR1_PMC3_COMBINE_
The following macros were introduced in power5-pmu via
commit 742bd95ba96e ("perfcounters/powerpc: Add
support for POWER5 processors")
MMCR1_TTM2SEL_SH, MMCR1_TTMSEL_MSK, MMCR1_TD_CP_DBG1SEL_SH
MMCR1_TD_CP_DBG2SEL_SH, MMCR1_TD_CP_DBG3SEL_SH, MMCR1_GRS_L2SEL_MSK
MMCR1_GRS_L3SEL_MSK, MMCR1_GRS_MCSEL
The macro MMCR1_PMCSEL_MSK was introduced in power6-pmu via
commit f78628374a13 ("powerpc/perf_counter: Add support
for POWER6") but never used.
The usage of macro PM_SUBUNIT_MSKS was removed in commit ab7ef2e50a55
("perf_counter: powerpc: allow use of limited-function counters")
and failed to rem
The following macros were introduced in ppc970-pmu via
commit 16b067993dee ("powerpc/perf_counter: Add
support for PPC970 family")
PM_NONE, PM_LSU1U, MMCR0_PMC2SEL_SH, MMCR_PMCSEL_MSK
MMCR1_TTM0SEL_SH, MMCR1_TTMSEL_MSK, MMCR1_TD_CP_DBG1SEL_SH
MMCR1_TD_CP_DBG2SEL_SH, MMCR1_TD_CP_DBG3SEL_SH, MMCR1_P
The patch set below is work done to list all macros defined in c files
that are not in use anymore. Thereby categorising these macros as dead
macros. Use scripts to identify these macros along with
commit-ids. Patch set consists of patches targeting a file in
arch/powerpc/perf which has unused macr
On Thu, 13 Mar 2025 11:43:15 + Alessandro Carminati
wrote:
> Some unit tests intentionally trigger warning backtraces by passing bad
> parameters to kernel API functions. Such unit tests typically check the
> return value from such calls, not the existence of the warning backtrace.
I've had
The commit 9576730d0e6e ("KVM: PPC: select IRQ_BYPASS_MANAGER") enabled
IRQ_BYPASS_MANAGER when CONFIG_KVM was set. Subsequently, commit
c57875f5f9be ("KVM: PPC: Book3S HV: Enable IRQ bypass") enabled IRQ
bypass and added the necessary callbacks to create/remove the mappings
between host real IRQ a
On 2025-04-22 17:14:10, Christian Brauner wrote:
> On Tue, Apr 22, 2025 at 04:31:29PM +0200, Christian Brauner wrote:
> > On Thu, Mar 27, 2025 at 12:39:28PM +0100, Amir Goldstein wrote:
> > > On Thu, Mar 27, 2025 at 10:33 AM Andrey Albershteyn
> > > wrote:
> > > >
> > > > On 2025-03-23 09:56:25,
On Fri, Apr 25, 2025 at 08:19:02PM +0530, Athira Rajeev wrote:
> > On 14 Apr 2025, at 7:08 AM, Madhavan Srinivasan wrote:
> > On 4/7/25 5:38 PM, Venkat Rao Bagalkote wrote:
> >> On 07/04/25 12:10 am, Athira Rajeev wrote:
> On 6 Apr 2025, at 10:04 PM, Likhitha Korrapati
> wrote:
>
On 4/25/25 19:01, Sebastian Andrzej Siewior wrote:
On 2025-04-25 16:49:19 [+0530], Shrikanth Hegde wrote:
On 4/25/25 00:08, Sebastian Andrzej Siewior wrote:
On 2025-04-24 21:27:59 [+0530], Shrikanth Hegde wrote:
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index
On Fri, Apr 25, 2025 at 06:30:10PM +0300, Dan Carpenter wrote:
> Whatever happened with this thread from Feb.
> https://lore.kernel.org/all/20250207013117.104205-1-zhangzeku...@huawei.com/
>
> The issue was that people weren't expecting of_find_node_by_name() to
> drop the reference on the of_node
On 2025-04-25 19:54:56 [+0530], Shrikanth Hegde wrote:
> > > But looking at the semantics of usage of xfer_to_guest_mode_work
> > > I think using schedule is probably right over here.
> > > Correct me if i got it all wrong.
> >
> > No, if you do xfer_to_guest_mode_work() then it will invoke schedu
When a device is opened by a userspace driver, via VFIO interface, DMA
window is created. This DMA window has TCE Table and a corresponding
data for userview of
TCE table.
When the userspace driver closes the device, all the above infrastructure
is free'ed and the device control given back to kern
On Tue, Apr 08, 2025 at 10:52:11AM +0100, Kevin Brodsky wrote:
> In preparation for calling constructors for all kernel page tables
> while eliding unnecessary ptlock initialisation, let's pass down the
> associated mm to the PTE/PMD level ctors. (These are the two levels
> where ptlocks are used.)
On Tue, Apr 08, 2025 at 10:52:13AM +0100, Kevin Brodsky wrote:
> Since [1], constructors/destructors are expected to be called for
> all page table pages, at all levels and for both user and kernel
> pgtables. There is however one glaring exception: kernel PTEs are
> managed via separate helpers (p
On Fri, Apr 25, 2025 at 04:37:47PM +0200, Jan Stancek wrote:
> On Fri, Apr 25, 2025 at 03:40:55PM +0200, Thomas Weißschuh wrote:
>
>
>
> >
> > Some more information:
> >
> > The crash comes from the address arithmetic in "vc = &vc[CS_RAW]" going
> > wrong.
>
> That appears to be because it's
Whatever happened with this thread from Feb.
https://lore.kernel.org/all/20250207013117.104205-1-zhangzeku...@huawei.com/
The issue was that people weren't expecting of_find_node_by_name() to
drop the reference on the of_node. The patchset introduced a wrapper
which basically worked as expected e
> On 14 Apr 2025, at 7:08 AM, Madhavan Srinivasan wrote:
>
>
>
> On 4/7/25 5:38 PM, Venkat Rao Bagalkote wrote:
>>
>> On 07/04/25 12:10 am, Athira Rajeev wrote:
>>>
On 6 Apr 2025, at 10:04 PM, Likhitha Korrapati
wrote:
perf build break observed when using gcc 13-3 (F
> On 22 Apr 2025, at 2:41 PM, James Clark wrote:
>
>
>
> On 21/04/2025 4:41 am, Athira Rajeev wrote:
>> To pick up the changes in:
>> commit acea9943271b ("vdso: Address variable shadowing in macros")
>> Addressing this perf tools build warning:
>> diff -u tools/include/vdso/unaligned.h incl
On Fri, Apr 25, 2025 at 03:40:55PM +0200, Thomas Weißschuh wrote:
Some more information:
The crash comes from the address arithmetic in "vc = &vc[CS_RAW]" going wrong.
That appears to be because it's not doing any arithmetic, but using value
from some linker-generated symbol (I'll refer to
On Fri, Apr 25, 2025 at 12:03:14PM +0200, Jan Stancek wrote:
> On Fri, Apr 25, 2025 at 10:58 AM Thomas Weißschuh
> wrote:
> >
> > On Thu, Apr 24, 2025 at 11:57:02PM +0200, Jan Stancek wrote:
> > > On Thu, Apr 24, 2025 at 5:49 PM Thomas Weißschuh
> > > wrote:
> > > >
> > > > On Thu, Apr 24, 2025 a
Since it's not currently safe to take device_lock() in the IOMMU probe
path, that can race against really_probe() setting dev->driver before
attempting to bind. The race itself isn't so bad, since we're only
concerned with dereferencing dev->driver itself anyway, but sadly my
attempt to implement t
On 2025-04-25 16:49:19 [+0530], Shrikanth Hegde wrote:
> On 4/25/25 00:08, Sebastian Andrzej Siewior wrote:
> > On 2025-04-24 21:27:59 [+0530], Shrikanth Hegde wrote:
> > > > > diff --git a/arch/powerpc/kvm/book3s_hv.c
> > > > > b/arch/powerpc/kvm/book3s_hv.c
> > > > > index 19f4d298d..123539642 1
On 4/25/25 00:08, Sebastian Andrzej Siewior wrote:
On 2025-04-24 21:27:59 [+0530], Shrikanth Hegde wrote:
diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
index 19f4d298d..123539642 100644
--- a/arch/powerpc/kvm/book3s_hv.c
+++ b/arch/powerpc/kvm/book3s_hv.c
@@ -4901,
On Fri, Apr 25, 2025 at 10:58 AM Thomas Weißschuh
wrote:
>
> On Thu, Apr 24, 2025 at 11:57:02PM +0200, Jan Stancek wrote:
> > On Thu, Apr 24, 2025 at 5:49 PM Thomas Weißschuh
> > wrote:
> > >
> > > On Thu, Apr 24, 2025 at 04:10:04PM +0200, Jan Stancek wrote:
> > > > On Mon, Mar 03, 2025 at 12:11:
On Wed, Apr 23, 2025 at 05:20:36PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> The use of the term "glue" in filenames is a Crypto API-ism that does
> not show up elsewhere in lib/. I think adopting it there was a mistake.
> The library just uses standard functions, so the amount of code
On Thu, Apr 24, 2025 at 11:57:02PM +0200, Jan Stancek wrote:
> On Thu, Apr 24, 2025 at 5:49 PM Thomas Weißschuh
> wrote:
> >
> > On Thu, Apr 24, 2025 at 04:10:04PM +0200, Jan Stancek wrote:
> > > On Mon, Mar 03, 2025 at 12:11:10PM +0100, Thomas Weißschuh wrote:
> > > > From: Anna-Maria Behnsen
>
powerpcrandconfig-002-20250425gcc-9.3.0
powerpcrandconfig-003-20250424clang-21
powerpcrandconfig-003-20250425gcc-9.3.0
powerpc64 randconfig-001-20250424clang-21
powerpc64 randconfig-002-20250424clang-21
powerpc64 randconfig-003-20250424clang-21
--
0-DAY CI
45 matches
Mail list logo
