On Thu, Apr 27, 2023 at 11:09 AM Michael Ellerman wrote:
>
> Zhouyi Zhou writes:
> > On Tue, Apr 25, 2023 at 2:01 PM Zhouyi Zhou wrote:
> >> On Tue, Apr 25, 2023 at 6:07 AM Michael Ellerman
> >> wrote:
> ...
> >> >
> >> > There's 12.2.0 here:
> >> >
> >> > https://mirrors.edge.kernel.org/pu
Zhouyi Zhou writes:
> On Tue, Apr 25, 2023 at 2:01 PM Zhouyi Zhou wrote:
>> On Tue, Apr 25, 2023 at 6:07 AM Michael Ellerman wrote:
...
>> >
>> > There's 12.2.0 here:
>> >
>> > https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/12.2.0/
>> >
>> > https://mirrors.edge.kerne
been built successfully.
More configs may be tested in the coming days.
tested configs:
alphaallyesconfig gcc
alphabuildonly-randconfig-r001-20230426 gcc
alpha defconfig gcc
alpharandconfig-r012-20230426
successfully.
More configs may be tested in the coming days.
tested configs:
alphaallyesconfig gcc
alphabuildonly-randconfig-r002-20230426 gcc
alpha defconfig gcc
arc allyesconfig gcc
arc
Defined CRYPTO_CHACHA20_P10 and CRYPTO POLY1305_P10 in Kconfig to
support optimized implementation for Power10 and later CPU.
Added new module driver chacha-p10-crypto and poly1305-p10-crypto.
Signed-off-by: Danny Tsen
---
arch/powerpc/crypto/Kconfig | 26 ++
arch/power
Signed-off-by: Danny Tsen
---
arch/powerpc/crypto/chacha-p10-glue.c | 221 ++
1 file changed, 221 insertions(+)
create mode 100644 arch/powerpc/crypto/chacha-p10-glue.c
diff --git a/arch/powerpc/crypto/chacha-p10-glue.c
b/arch/powerpc/crypto/chacha-p10-glue.c
new file m
Improve overall performance of chacha20 encrypt and decrypt operations
for Power10 or later CPU.
Signed-off-by: Danny Tsen
---
arch/powerpc/crypto/chacha-p10le-8x.S | 842 ++
1 file changed, 842 insertions(+)
create mode 100644 arch/powerpc/crypto/chacha-p10le-8x.S
diff
Signed-off-by: Danny Tsen
---
arch/powerpc/crypto/poly1305-p10-glue.c | 186
1 file changed, 186 insertions(+)
create mode 100644 arch/powerpc/crypto/poly1305-p10-glue.c
diff --git a/arch/powerpc/crypto/poly1305-p10-glue.c
b/arch/powerpc/crypto/poly1305-p10-glue.c
new
This patch series provide an accelerated/optimized Chacha20 and Poly1305
implementation for Power10 or later CPU (ppc64le). This module
implements algorithm specified in RFC7539. The implementation
provides 3.5X better performance than the baseline for Chacha20 and
Poly1305 individually and 1.5X
Improve overall performance of Poly1305 for Power10 or later CPU.
Signed-off-by: Danny Tsen
---
arch/powerpc/crypto/poly1305-p10le_64.S | 1075 +++
1 file changed, 1075 insertions(+)
create mode 100644 arch/powerpc/crypto/poly1305-p10le_64.S
diff --git a/arch/powerpc/crypto
On Mon, Mar 06, 2023 at 11:01:52AM -0800, David Matlack wrote:
> This series refactors the KVM stats macros to reduce duplication and
> adds the support for choosing custom names for stats.
>
> Custom name makes it possible to decouple the userspace-visible stat
> names from their internal represe
On Tue, Apr 25, 2023 at 10:59 PM Nicholas Piggin wrote:
>
> Suggested-by: Linus Torvalds
I was all "what is Nick talking about", and had to follow the link to
remember that old discussion at all.
Patch obviously looks fine to me, I'll presumably be getting it at
some future point as part of a p
On 4/26/23 06:51, Vladimir Oltean wrote:
On Tue, Apr 25, 2023 at 04:22:32PM -0400, Sean Anderson wrote:
The features which do not work (major protocol changes) are disabled :)
If it would cause this series to be immediately merged, I would remove
KX/KR and 2.5G which are the only untested link
Peter Zijlstra writes:
> On Wed, Apr 26, 2023 at 09:44:22AM -0400, Joel Fernandes wrote:
>
>> How could you control which code paths don't have the stack protector?
>> Just curious.
>
> https://lkml.kernel.org/r/20230412-no_stackp-v2-0-116f9fe4b...@google.com
We also have some entire files disabl
On Wed, Apr 26, 2023 at 09:41:38AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, April 20, 2023 12:12 AM
> >
> > +static int iommu_init_driver(struct device *dev, const struct iommu_ops
> > *ops)
>
> would iommu_init_device() better fit the purpose?
Yeah.. that does se
On Wed, Apr 26, 2023 at 09:44:22AM -0400, Joel Fernandes wrote:
> How could you control which code paths don't have the stack protector?
> Just curious.
https://lkml.kernel.org/r/20230412-no_stackp-v2-0-116f9fe4b...@google.com
On Thu, Apr 20, 2023 at 12:23:11PM +0800, Baolu Lu wrote:
> On 4/20/23 12:11 AM, Jason Gunthorpe wrote:
> > diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
> > index dbaf3ed9012c45..a82516c8ea87ad 100644
> > --- a/drivers/iommu/iommu.c
> > +++ b/drivers/iommu/iommu.c
> > @@ -569,7 +569,6
On Wed, Apr 26, 2023 at 8:30 AM Michael Ellerman wrote:
>
> Joel Fernandes writes:
> > On Tue, Apr 25, 2023 at 6:58 AM Zhouyi Zhou wrote:
> ...
> >
> > Out of curiosity for PPC folks, why cannot 64-bit PPC use per-task
> > canary? Michael, is this an optimization? Adding Christophe as well
> > s
Joel Fernandes writes:
> On Tue, Apr 25, 2023 at 6:58 AM Zhouyi Zhou wrote:
...
>
> Out of curiosity for PPC folks, why cannot 64-bit PPC use per-task
> canary? Michael, is this an optimization? Adding Christophe as well
> since it came in a few years ago via the following commit:
I think Christ
On Mon, 06 Mar 2023 15:33:39 -0600, Nathan Lynch wrote:
> Proposed changes for the RTAS subsystem and client code.
>
> Fixes that are subject to backporting are at the front of the queue,
> followed by documentation and cleanups, with enhancements at the end.
>
> Noteworthy changes:
> * Change sy
On Mon, 20 Feb 2023 06:59:09 -0500, Paul Gortmaker wrote:
> [This RFC is proposed for v6.4 and hence is based off linux-next.]
>
> This series removes support for four e300 (MPC83xx) Freescale processor
> family evaluation boards that were added to the kernel in the 2006 era.
>
> These boards wer
On Fri, 24 Feb 2023 15:49:56 -0500, Paul Gortmaker wrote:
> [This RFC is proposed for v6.4 and hence is based off linux-next.]
>
> This series removes support for two PowerQUICC II (MPC82xx) Freescale
> processor family evaluation boards that were added to the kernel in
> approximately the 2003 er
On Sat, 25 Feb 2023 15:13:15 -0500, Paul Gortmaker wrote:
> [This RFC is proposed for v6.4 and hence is based off linux-next.]
>
> This is the final series in reducing our day to day cost of carrying rare
> evaluation platforms. It targets the e600 Freescale processor family.
>
> It starts with
On Sat, 08 Apr 2023 16:01:09 +0200, Pali Rohár wrote:
> This patch series unifies all P2020 boards and machine descriptions into
> one generic unified P2020 machine description. With this generic machine
> description, kernel can boot on any P2020-based board with correct DTS
> file.
>
> Tested on
On Sun, 09 Apr 2023 02:08:04 +0200, Pali Rohár wrote:
> This patch series contains cleanups for fsl_uli1575 driver.
>
> This patch series is prerequisite for another patch series:
> "powerpc/85xx: p2020: Create one unified machine description"
> https://lore.kernel.org/linuxppc-dev/20230408140122.
On Sat, 25 Mar 2023 22:28:56 +1000, Nicholas Piggin wrote:
> This series cleans up copy_thread and hopefully makes the code
> easier to understand. The big changes in patch 3 and 4 which use
> the switch stack instead of user int stack for restoring
> fn and args parameters for the new thread.
>
>
On Fri, 07 Apr 2023 14:09:24 +1000, Nicholas Piggin wrote:
> Use the preferred form of branch-and-link for finding the current
> address so objtool doesn't think it is an unannotated intra-function
> call.
>
>
Applied to powerpc/next.
[1/1] powerpc/boot: Fix crt0.S current address branch form
On Fri, 07 Apr 2023 14:09:09 +1000, Nicholas Piggin wrote:
> -mcpu=power10 will generate prefixed and pcrel code by default, which
> we do not support. The general kernel disables these with cflags, but
> those were missed for the boot wrapper.
>
>
Applied to powerpc/next.
[1/1] powerpc/boot: F
On Wed, 26 Apr 2023 15:58:37 +1000, Nicholas Piggin wrote:
> This series is against powerpc next. The first two patches are
> independent build fixes for recent patches. Patches 3-5 separate
> boot Makefile BOOTCFLAGS and BOOTASFLAGS and stops passing some
> C code generation flags to the assembler
On Sat, 08 Apr 2023 12:17:46 +1000, Nicholas Piggin wrote:
> This won't see a lot of real use until POWER10 is the oldest supported
> CPU for distros, but being as we're quite a unique user of toolchain I'd
> like to start ironing things out earlier rather than later. I'm making a
> list of observa
On Thu, 06 Apr 2023 10:51:30 -0700, Nathan Chancellor wrote:
> When building with W=1 after commit 80b6093b55e3 ("kbuild: add -Wundef
> to KBUILD_CPPFLAGS for W=1 builds"), the following warning occurs.
>
> In file included from arch/powerpc/kvm/bookehv_interrupts.S:26:
> arch/powerpc/kvm/../k
On Thu, 06 Apr 2023 22:21:18 +1000, Michael Ellerman wrote:
> check_return_regs_valid() is called from the middle of the irq exit
> handling, which is all notrace, so mark it notrace also.
>
>
Applied to powerpc/next.
[1/1] powerpc/irq: Mark check_return_regs_valid() notrace
https://git.k
On Tue, 11 Apr 2023 20:28:38 +1000, Michael Ellerman wrote:
> Add PPC_QEMU_E500 to corenet_base.config, which is then used to generate
> corenet64_smp_defconfig and corenet32_smp_defconfig.
>
> That then allows both those configs to build kernels that boot in qemu
> using the ppce500 machine type
On Thu, 20 Apr 2023 15:21:49 +1000, Michael Ellerman wrote:
> Some powernv machines use IGB for networking, so build the driver in to
> enable net booting such machines.
>
>
Applied to powerpc/next.
[1/1] powerpc/configs/powernv: Add IGB=y
https://git.kernel.org/powerpc/c/836a3de6b2bfe0b7
On Tue, 04 Apr 2023 20:28:47 +1000, Michael Ellerman wrote:
> The amdgpu driver builds some of its code with hard-float enabled,
> whereas the rest of the kernel is built with soft-float.
>
> When building with 64-bit long double, if soft-float and hard-float
> objects are linked together, the bui
On Fri, 24 Feb 2023 15:10:12 +1100, Andrew Donnellan wrote:
> Add a firmware feature flag, FW_FEATURE_PLPKS, to indicate availability of
> Platform KeyStore related hcalls.
>
> Check this flag in plpks_is_available() and pseries_plpks_init() before
> trying to make an hcall.
>
>
> [...]
Applied
On Wed, 29 Mar 2023 18:23:33 +1100, Michael Ellerman wrote:
> It's not necessary to prefix every command in archhelp with "@" (to
> supress echoing the command), because that is done by the top level
> Makefile when it evaluates archhelp.
>
>
Applied to powerpc/next.
[1/2] powerpc/Makefile: Don
On Thu, 20 Apr 2023 15:16:08 +1000, Michael Ellerman wrote:
> The ext4 code will mount ext2 filesystems, no need to build in both.
>
>
Applied to powerpc/next.
[1/2] powerpc/configs/64s: Use EXT4 to mount EXT2 filesystems
https://git.kernel.org/powerpc/c/e4c02c3e6c39c3866d517388f6bb431c47
On Thu, 06 Apr 2023 14:33:13 +1000, Benjamin Gray wrote:
> The randomness based DSCR tests currently have a low probability of doing
> any writes to the DSCR, making them inefficient in uncovering bugs.
>
> This series adds lockstep variants to these RNG tests, to ensure the happy
> path is always
On Fri, 07 Apr 2023 00:45:32 +1000, Michael Ellerman wrote:
> Code in the idle path is not allowed to be instrumented because RCU is
> disabled, see commit 0e985e9d2286 ("cpuidle: Add comments about
> noinstr/__cpuidle usage").
>
> Mark prep_irq_for_idle() __cpuidle, which is equivalent to noinstr
On Wed, 05 Apr 2023 14:23:16 +0930, Joel Stanley wrote:
> There are two copies of these defines. Keep the older ones as they have
> associated bit definitions.
>
>
Applied to powerpc/next.
[1/1] powerpc: Remove duplicate SPRN_HSRR definitions
https://git.kernel.org/powerpc/c/92cb1eff88a67
On Fri, 14 Apr 2023 23:23:44 +1000, Michael Ellerman wrote:
> Update ppc64_defconfig to account for symbols moving around, no actual
> changes.
>
>
Applied to powerpc/next.
[01/32] powerpc/configs/64s: Update defconfig for symbol movement
https://git.kernel.org/powerpc/c/cc876c7a245979
On Tue, Apr 25, 2023 at 04:22:32PM -0400, Sean Anderson wrote:
> The features which do not work (major protocol changes) are disabled :)
>
> If it would cause this series to be immediately merged, I would remove
> KX/KR and 2.5G which are the only untested link modes.
>
> That said, PCS support i
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> Have release fully clean up the iommu related parts of the struct device,
> no matter what state they are in.
>
> POWER creates iommu_groups without drivers attached, and the next patch
> removes the open-coding of this same c
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> These are not used outside iommu.c, they should not be available to
> modular code.
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> It makes logical sense that once the driver is attached to the device the
> sysfs links appear, even if we haven't fully created the group_device or
> attached the device to a domain.
>
> Fix the missing error handling on sysf
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> +static int iommu_init_driver(struct device *dev, const struct iommu_ops
> *ops)
would iommu_init_device() better fit the purpose?
otherwise,
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> Instead of returning the struct group_device and then later freeing it, do
> the entire free under the group->mutex and defer only putting the
> iommu_group.
>
> It is safe to remove the sysfs_links and free memory while holdi
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> This is the only caller, and it doesn't need the generality of the
> function. We already know there is no iommu_group, so it is simply two
> function calls.
>
> Moving it here allows the following patches to split the logic i
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> No reason to open code this, use the proper helper functions.
>
> Signed-off-by: Jason Gunthorpe
Reviewed-by: Kevin Tian
> From: Jason Gunthorpe
> Sent: Thursday, April 20, 2023 12:12 AM
>
> This is a step toward making __iommu_probe_device() self contained.
>
> It should, under proper locking, check if the device is already associated
> with an iommu driver and resolve parallel probes. All but one of the
> caller
From: Danny Tsen
> Sent: 24 April 2023 19:47
>
> Improve overall performance of chacha20 encrypt and decrypt operations
> for Power10 or later CPU.
>
> Signed-off-by: Danny Tsen
> ---
> arch/powerpc/crypto/chacha-p10le-8x.S | 842 ++
> 1 file changed, 842 insertions(+)
>
On Fri, 2022-11-04 at 17:51 +, Christophe Leroy wrote:
>
>
> Le 04/11/2022 à 18:27, Andrew Donnellan a écrit :
> > When CONFIG_VMAP_STACK is enabled, we set THREAD_SIZE to be at
> > least the
> > size of a page.
> >
> > There's a few bits of assembly in the book3s64 code that use
> > THREAD_
53 matches
Mail list logo
