* Re: [PATCH 5/6] KVM: PPC: Book3S HV: Add support for compat CPU capabilities for KVM on PowerNV
From: Harsh Prateek Bora @ 2026-05-05 9:49 UTC (permalink / raw)
To: Amit Machhiwal, linuxppc-dev, Madhavan Srinivasan
Cc: Vaibhav Jain, Nicholas Piggin, Michael Ellerman,
Christophe Leroy (CS GROUP), kvm, linux-kernel
In-Reply-To: <20260430054906.94431-6-amachhiw@linux.ibm.com>
On 30/04/26 11:19 am, Amit Machhiwal wrote:
> Currently, when booting a compatibility-mode KVM guest (L1) on a PowerNV
> hypervisor (L0), the guest runs with the expected processor
> compatibility level. However, when booting a nested KVM guest (L2)
> inside the L1, QEMU derives the CPU model from the raw host PVR and
> attempts to run the nested guest at that level, instead of honoring the
> compatibility mode of the L1.
>
> Extend host CPU compatibility capability reporting to support nested
> virtualization on PowerNV systems (PAPR nested API v1).
>
> For nested API v2 (PowerVM), compatibility capabilities are obtained
> from the hypervisor via the H_GUEST_GET_CAPABILITIES hcall. This
> information is not available on PowerNV systems.
>
> For nested API v1, derive the compatibility capabilities from the L1
> guest by reading the "cpu-version" property from the device tree, which
> reflects the effective (logical) processor compatibility level. Map this
> value to the corresponding compatibility capability bitmap.
>
> Introduce a helper to translate CPU version values into compatibility
> capability bits and integrate it into kvmppc_get_compat_cpu_caps().
>
> This allows userspace to query host CPU compatibility modes on both
> PowerVM and PowerNV platforms via the KVM_PPC_GET_COMPAT_CAPS ioctl.
>
> Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
> ---
> arch/powerpc/kvm/book3s_hv.c | 37 +++++++++++++++++++++++++++++++++++-
> 1 file changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index d602d90111d1..25d05f1ccb72 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -6516,16 +6516,51 @@ static bool kvmppc_hash_v3_possible(void)
> return true;
> }
>
> +static int kvmppc_map_compat_capabilities(const __be32 cpu_version,
> + unsigned long *capabilities)
> +{
> + switch (cpu_version) {
> + case PVR_ARCH_31_P11:
> + *capabilities |= H_GUEST_CAP_POWER11;
Should this be:
+ *capabilities |= H_GUEST_CAP_POWER11 |
+ H_GUEST_CAP_POWER10 |
+ H_GUEST_CAP_POWER9;
Likewise, the remaining as applicable?
> + break;
> + case PVR_ARCH_31:
> + *capabilities |= H_GUEST_CAP_POWER10;
> + break;
> + case PVR_ARCH_300:
> + *capabilities |= H_GUEST_CAP_POWER9;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
>
> static int kvmppc_get_compat_cpu_caps(struct kvm_ppc_compat_caps *host_caps)
> {
>
> + struct device_node *np;
> unsigned long capabilities = 0;
> + const __be32 *prop = NULL;
> long rc = -EINVAL;
> + u32 cpu_version;
>
> if (kvmhv_on_pseries()) {
Commit title says PowerNV, but here were are doing only for PowerVM?
> - if (kvmhv_is_nestedv2())
> + if (kvmhv_is_nestedv2()) {
> rc = plpar_guest_get_capabilities(0, &capabilities);
> + } else {
> + for_each_node_by_type(np, "cpu") {
> + prop = of_get_property(np, "cpu-version", NULL);
> + if (prop) {
> + cpu_version = be32_to_cpup(prop);
> + break;
> + }
> + }
> + if (!prop)
> + return -EINVAL;
> + rc = kvmppc_map_compat_capabilities(cpu_version,
> + &capabilities);
> + }
> host_caps->compat_capabilities = capabilities;
> }
>
^ permalink raw reply
* Re: [PATCH 6/6] KVM: PPC: Document KVM_PPC_GET_COMPAT_CAPS ioctl
From: Harsh Prateek Bora @ 2026-05-05 9:55 UTC (permalink / raw)
To: Amit Machhiwal, linuxppc-dev, Madhavan Srinivasan
Cc: Vaibhav Jain, Paolo Bonzini, Jonathan Corbet, Shuah Khan, kvm,
linux-kernel, linux-doc
In-Reply-To: <20260430054906.94431-7-amachhiw@linux.ibm.com>
On 30/04/26 11:19 am, Amit Machhiwal wrote:
> Add documentation for the KVM_PPC_GET_COMPAT_CAPS ioctl to the KVM API
> documentation.
>
> The ioctl exposes host processor compatibility modes supported for
> nested KVM guests on PowerPC systems.
>
> Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
> ---
> Documentation/virt/kvm/api.rst | 35 ++++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 52bbbb553ce1..7a10c3c6cbf1 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -6555,6 +6555,41 @@ KVM_S390_KEYOP_SSKE
>
> .. _kvm_run:
>
> +4.145 KVM_PPC_GET_COMPAT_CAPS
> +-----------------------------
> +:Capability: KVM_CAP_PPC_COMPAT_CAPS
> +:Architectures: powerpc
> +:Type: vm ioctl
> +:Parameters: struct kvm_ppc_compat_caps (out)
> +:Returns:
> + 0 on successful completion,
> + -EFAULT if ``struct kvm_ppc_compat_caps`` cannot be written
-EINVAL also needs to be documented?
> +
> +IBM POWER system server-based processors provide a compatibility mode feature
> +where an Nth generation processor can operate in modes consistent with earlier
> +generations such as (N-1) and (N-2).
> +
> +This ioctl provides userspace with information about the CPU compatibility modes
> +supported by the current host processor for booting the nested KVM guests on
> +PowerNV (KVM nested APIv1) and PowerVM (KVM nested APIv2) platforms.
> +
> +::
> +
> + struct kvm_ppc_compat_caps {
> + __u32 flags;
> + __u64 compat_capabilities; /* Capabilities supported by the host */
> + };
> +
> +The ``compat_capabilities`` bit field describes the processor compatibility
> +modes supported by the host. For example, the following bits indicate support
> +for specific processor modes.
> +
> +::
> +
> + bit 1: KVM guests can run in Power9 processor mode
> + bit 2: KVM guests can run in Power10 processor mode
> + bit 3: KVM guests can run in Power11 processor mode
May be use H_GUEST_CAP_POWER9 and friends ?
> +
> 5. The kvm_run structure
> ========================
>
^ permalink raw reply
* RE: [PATCH net] net: wan: fsl_uhdlc_hdlc: fix dma_rmb usage in hdlc_rx_done
From: Holger Brunck @ 2026-05-05 10:11 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP), netdev@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org, andrew+netdev@lunn.ch,
qiang.zhao@nxp.com, horms@kernel.org
In-Reply-To: <07fc37e5-7815-48ed-8632-62e896f8f6ad@kernel.org>
>
> Le 05/05/2026 à 10:14, Holger Brunck a écrit :
> >>
> >> Le 04/05/2026 à 17:56, Holger Brunck a écrit :
> >>> If dma_rmb is used it has to be done after reading bd_status and
> >>> checking if R_E_S is zero. Therefore we need to move it into the while loop.
> >>
> >> Can you give more details ? Why does dma_rmb() has to be done after
> >> reading bd_status and checking if R_E_S is zero ?
> >>
> >
> > when R_E_S is zero in the status of the buffer descriptor it means the
> > buffer is filled with data from the device. Now the CPU owns the
> > descriptor. Now we should execute the dma_rmb to be sure that we read the
> data correctly.
> > And this we need to redo for each buffer descriptor which is filled
> > with data, that’s why it must be done within the for loop and not before and
> after.
>
> We enter hdlc_rx_done() after an interrupt which triggers scheduling of
> ucc_hdlc_poll(). I think dma_rmb() is needed _before_ reading the first status,
> otherwise it might read an erroneous status.
>
we end up in hdlc_rx_done also if a TX interrupt was triggered due to the NAPI layer.
If RX bd_status is still 1 we would read a pending RX packet next time. So the dma_rmb()
before is not necessary. But if we have read a zero in bd_status we need to be sure that
the data written from the QE to RAM is fully available. That is why I think doing it after
reading the status is correct here.
> Once we are here the interrupt has been cleared so any new buffer will trigger a
> new interrupt and call again this function. Therefore I don't think it is worth the
> cost of a dma_rmb() inside the loop.
>
Yes, but while we are in the for loop the QE might have written the next packet to
the memory in background and sets the bd_status to zero. And if this is the
case we need again make sure that the memory we read is correct.
For example the following driver does the same AFAIU.
drivers/net/ethernet/intel/e1000e/netdev.c
from line 1524 ff
It first reads the status for the RX packet then does dma_rmb() and then reads
the data itself. And it is done within the while loop as any further available packet
may have arrived just now and we need to be sure that the data is valid.
Best regards
Holger
^ permalink raw reply
* Re: [PATCH v1 0/6] objtool: Fixup alternate feature relative addresses
From: Peter Zijlstra @ 2026-05-05 11:40 UTC (permalink / raw)
To: Sathvika Vasireddy
Cc: nathan, nsc, maddy, mpe, npiggin, chleroy, jpoimboe, ojeda,
masahiroy, lossin, tamird, thomas.weissschuh, rostedt,
ihor.solodrai, thuth, pmladek, aliceryhl, elver, kees, legion,
ardb, yuxuan.zuo, alexghiti, alexandre.chartre, bp, linux-kbuild,
linux-kernel, linuxppc-dev
In-Reply-To: <20260505084628.17940-1-sv@linux.ibm.com>
On Tue, May 05, 2026 at 02:16:22PM +0530, Sathvika Vasireddy wrote:
> This patch series implements build-time fixup of alternate feature
> relative addresses for powerpc.
>
> Previously, Nicholas Piggin proposed a build-time solution using a
> custom PowerPC tool [1], which provided the foundation for this approach.
> The current implementation leverages objtool's existing ELF parsing
> infrastructure to do the same.
>
> This patchset applies atop powerpc/merge branch.
>
> [1] Original PowerPC tool approach:
> http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20170521010130.13552-1-npiggin@gmail.com/
>
> Testing:
> Build and Boot tested on ppc64le, ppc64be, and ppc32be configs.
>
> Sathvika Vasireddy (6):
> objtool/powerpc: Add build-time fixup of alternate feature branch
> targets
> objtool: Set ELF_F_LAYOUT flag to preserve vmlinux segment layout
> objtool: Fix "can't find starting instruction" warnings on vmlinux
> objtool/powerpc: Skip jump destination analysis and unnanotated
> intra-function call warnings for --ftr-fixup
> kbuild: Add objtool integration for PowerPC feature fixups
> powerpc: Enable build-time feature fixup processing by default
Ooh, so 2/3 are because you're not running objtool on vmlinux.o, but
you're running it later in the link stage?
AFAICT ELF_F_LAYOUT should not hurt the normal objtool run, but it
shouldn't be needed either, because we run much earlier, before sections
are placed.
And that also explains why you're the first to have trouble with 'can't
find starting instruction'. vmlinux.o will have unplaced sections that
are all relative 0.
Hmm... perhaps this ftr fixup should be its own command, like klp. Not
munged into check thing. Josh?
^ permalink raw reply
* Re: [PATCH V5 2/2] tools/perf: Add kernel-doc comment to auxtrace_record__init() function
From: Adrian Hunter @ 2026-05-05 13:29 UTC (permalink / raw)
To: Athira Rajeev, acme, jolsa, mpetlan, tmricht, maddy, irogers,
namhyung
Cc: linux-perf-users, linuxppc-dev, hbathini, Tejas.Manhas1,
Tanushree.Shah, shivani
In-Reply-To: <20260504151321.12346-2-atrajeev@linux.ibm.com>
On 04/05/2026 18:13, Athira Rajeev wrote:
> Add documentation comment describing the parameters
> and return code for auxtrace_record__init() in util/auxtrace.c
>
> Signed-off-by: Athira Rajeev <atrajeev@linux.ibm.com>
Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
> Changelog:
> v4 > v5:
> Addressed review comment from Namhyung:
> - Used original placement for __maybe_unused as
> "struct evlist *evlist __maybe_unused"
> - Added return code expectation on success case
>
> v3 -> v4:
> Addressed review comment from Sashiko:
> Update return value expectation for fail as
> non zero return err code.
>
> v2 -> v3:
> Addressed review comment from Sashiko:
> Update return value expectation for success and fail
> correctly.
>
> tools/perf/util/auxtrace.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/tools/perf/util/auxtrace.c b/tools/perf/util/auxtrace.c
> index a224687ffbc1..a9f007d47c0b 100644
> --- a/tools/perf/util/auxtrace.c
> +++ b/tools/perf/util/auxtrace.c
> @@ -896,6 +896,21 @@ int auxtrace_parse_aux_action(struct evlist *evlist)
> return 0;
> }
>
> +/**
> + * auxtrace_record__init - Initialize an AUX area tracing record.
> + * @evlist: The list of events to check for AUX area tracing event.
> + * @err: Pointer to an integer to store return code.
> + *
> + * This function looks through the @evlist to determine which AUX area
> + * tracing hardware is being used and initializes the auxtrace_record
> + * structure.
> + *
> + * Return:
> + * a) A pointer to the struct auxtrace_record with @err = 0 on success.
> + * b) NULL with @err = 0 if no AUX area tracing event is found/supported
> + * (not considered an error).
> + * c) NULL with non-zero @err on actual auxtrace_record__init failure.
> + */
> struct auxtrace_record *__weak
> auxtrace_record__init(struct evlist *evlist __maybe_unused, int *err)
> {
^ permalink raw reply
* Re: [PATCH v1 1/6] objtool/powerpc: Add build-time fixup of alternate feature branch targets
From: Peter Zijlstra @ 2026-05-05 14:45 UTC (permalink / raw)
To: Sathvika Vasireddy
Cc: nathan, nsc, maddy, mpe, npiggin, chleroy, jpoimboe, ojeda,
masahiroy, lossin, tamird, thomas.weissschuh, rostedt,
ihor.solodrai, thuth, pmladek, aliceryhl, elver, kees, legion,
ardb, yuxuan.zuo, alexghiti, alexandre.chartre, bp, linux-kbuild,
linux-kernel, linuxppc-dev
In-Reply-To: <20260505084628.17940-2-sv@linux.ibm.com>
On Tue, May 05, 2026 at 02:16:23PM +0530, Sathvika Vasireddy wrote:
> switch (opcode) {
> + case 16:
Like case 18 below, this wants a comment describing which instruction
this is; bclr ?
> + if (ins & 1)
> + typ = INSN_OTHER;
> + else
> + typ = INSN_JUMP_CONDITIONAL;
> + imm = ins & 0xfffc;
> + if (imm & 0x8000)
> + imm -= 0x10000;
> + insn->immediate = imm | aa;
> + break;
> +
> case 18: /* b[l][a] */
> if (ins == 0x48000005) /* bl .+4 */
> typ = INSN_OTHER;
^ permalink raw reply
* Re: [PATCH v1 1/6] objtool/powerpc: Add build-time fixup of alternate feature branch targets
From: Peter Zijlstra @ 2026-05-05 14:49 UTC (permalink / raw)
To: Sathvika Vasireddy
Cc: nathan, nsc, maddy, mpe, npiggin, chleroy, jpoimboe, ojeda,
masahiroy, lossin, tamird, thomas.weissschuh, rostedt,
ihor.solodrai, thuth, pmladek, aliceryhl, elver, kees, legion,
ardb, yuxuan.zuo, alexghiti, alexandre.chartre, bp, linux-kbuild,
linux-kernel, linuxppc-dev
In-Reply-To: <20260505144539.GX3126523@noisy.programming.kicks-ass.net>
On Tue, May 05, 2026 at 04:45:39PM +0200, Peter Zijlstra wrote:
> On Tue, May 05, 2026 at 02:16:23PM +0530, Sathvika Vasireddy wrote:
> > switch (opcode) {
> > + case 16:
>
> Like case 18 below, this wants a comment describing which instruction
> this is; bclr ?
Also, isn't that typically used for return, suggesting at least
something should have INSN_RETURN on?
> > + if (ins & 1)
> > + typ = INSN_OTHER;
> > + else
> > + typ = INSN_JUMP_CONDITIONAL;
> > + imm = ins & 0xfffc;
> > + if (imm & 0x8000)
> > + imm -= 0x10000;
> > + insn->immediate = imm | aa;
> > + break;
> > +
> > case 18: /* b[l][a] */
> > if (ins == 0x48000005) /* bl .+4 */
> > typ = INSN_OTHER;
^ permalink raw reply
* Re: [PATCH v1 1/6] objtool/powerpc: Add build-time fixup of alternate feature branch targets
From: Christophe Leroy (CS GROUP) @ 2026-05-05 15:48 UTC (permalink / raw)
To: Peter Zijlstra, Sathvika Vasireddy
Cc: nathan, nsc, maddy, mpe, npiggin, jpoimboe, ojeda, masahiroy,
lossin, tamird, thomas.weissschuh, rostedt, ihor.solodrai, thuth,
pmladek, aliceryhl, elver, kees, legion, ardb, yuxuan.zuo,
alexghiti, alexandre.chartre, bp, linux-kbuild, linux-kernel,
linuxppc-dev
In-Reply-To: <20260505144949.GO3102924@noisy.programming.kicks-ass.net>
Le 05/05/2026 à 16:49, Peter Zijlstra a écrit :
> On Tue, May 05, 2026 at 04:45:39PM +0200, Peter Zijlstra wrote:
>> On Tue, May 05, 2026 at 02:16:23PM +0530, Sathvika Vasireddy wrote:
>>> switch (opcode) {
>>> + case 16:
>>
>> Like case 18 below, this wants a comment describing which instruction
>> this is; bclr ?
No, it is bc/bca/bcl/bcla, it is quite similar to type 18 which is
b/ba/bl/bla, but that's a conditional branch to a 14-bit offset while
type 18 is a non-conditional branch to a 24-bit offset (10 bits are the
conditional in the bc, hence the reduced offset size).
>
> Also, isn't that typically used for return, suggesting at least
> something should have INSN_RETURN on?
>
bclr (which is the return INSN_RETURN) has type 19
By the way you can have a look at
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/bfa8364da047d8610a09458a1cd924a0566aedbb.1736955567.git.christophe.leroy@csgroup.eu/
That patch has all the objtool decoding. By the way objtool is missing a
INSN_CONDITIONAL_RETURN, also see
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/537e5d8f181b1f1c2b8918f1aefa1dba3f972c03.1736955567.git.christophe.leroy@csgroup.eu/
>>> + if (ins & 1)
>>> + typ = INSN_OTHER;
>>> + else
>>> + typ = INSN_JUMP_CONDITIONAL;
>>> + imm = ins & 0xfffc;
>>> + if (imm & 0x8000)
>>> + imm -= 0x10000;
>>> + insn->immediate = imm | aa;
>>> + break;
>>> +
>>> case 18: /* b[l][a] */
>>> if (ins == 0x48000005) /* bl .+4 */
>>> typ = INSN_OTHER;
^ permalink raw reply
* Re: [PATCH v1 1/6] objtool/powerpc: Add build-time fixup of alternate feature branch targets
From: Segher Boessenkool @ 2026-05-05 15:56 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Sathvika Vasireddy, nathan, nsc, maddy, mpe, npiggin, chleroy,
jpoimboe, ojeda, masahiroy, lossin, tamird, thomas.weissschuh,
rostedt, ihor.solodrai, thuth, pmladek, aliceryhl, elver, kees,
legion, ardb, yuxuan.zuo, alexghiti, alexandre.chartre, bp,
linux-kbuild, linux-kernel, linuxppc-dev
In-Reply-To: <20260505144539.GX3126523@noisy.programming.kicks-ass.net>
Hi!
On Tue, May 05, 2026 at 04:45:39PM +0200, Peter Zijlstra wrote:
> On Tue, May 05, 2026 at 02:16:23PM +0530, Sathvika Vasireddy wrote:
> > switch (opcode) {
> > + case 16:
>
> Like case 18 below, this wants a comment describing which instruction
> this is; bclr ?
Yes. It is 19/16, b[c]lr (primary opcode 19, secondary opcode 16).
Where is it described what INSN_RETURN actually means for objtool? Not
in the header file :-(
For PowerPC, all three of b[c]lr[l], b[c]ctr[l], and b[c]tar[l] are
indirect jumps, to an address in a register. They do absolutely nothing
typically done in a function epilog, like "return" insns in some other
archs do. But the BH field ("branch hint") in the instruction helps
predict the control flow involving the insn as something in a call and
return pattern :-)
Segher
^ permalink raw reply
* Re: [PATCH] lib/crypto: powerpc/md5: Drop powerpc optimized MD5 code
From: Christophe Leroy (CS GROUP) @ 2026-05-05 16:34 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, linux-kernel, Ard Biesheuvel, Jason A . Donenfeld,
Herbert Xu, linuxppc-dev, Nicholas Piggin, Michael Ellerman,
Madhavan Srinivasan
In-Reply-To: <20260504180044.GC2291@sol>
Le 04/05/2026 à 20:00, Eric Biggers a écrit :
> On Mon, May 04, 2026 at 03:28:24PM +0200, Christophe Leroy (CS GROUP) wrote:
>> Hi Eric,
>>
>> Le 04/05/2026 à 06:14, Eric Biggers a écrit :
>>> Earlier the decision was made to keep this code for a while, despite no
>>> other architectures having optimized MD5 code anymore, because of
>>> someone using it via AF_ALG via libkcapi-hasher
>>> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fr%2Ff0d771d5-ed70-444c-957a-ad4c16f6c115%40csgroup.eu%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C8fce00ee4e5a497f0d8808deaa074073%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639135145289986833%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=cS5krthqFluqLlSXBy4Dv0h34gms0bIYRUVfWetoAdg%3D&reserved=0)
>>>
>>> However, with AF_ALG itself now being on its way out due to its
>>> continuous stream of security vulnerabilities
>>> (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fr%2F20260430011544.31823-1-ebiggers%40kernel.org%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C8fce00ee4e5a497f0d8808deaa074073%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639135145290017177%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=bMbQdEM%2FQYmgz7lelwXuKepC2dZCvKz6Pa6ixwlGtrk%3D&reserved=0),
>>> it's time to be a bit more forceful with nudging people towards
>>> userspace crypto code. It's always been the better solution anyway, and
>>> it's much more efficient if properly optimized code is used.
>>
>> Ok, why not, but what do you propose as an alternative ? Let me explain the
>> situation.
>>
>> We have two versions of boards:
>> - One with powerpc MPC885E, which embeds a SECURITY Engine called TALITOS
>> for offloading crypto operations
>> - One with powerpc MPC866, which doesn't have the security engine.
>>
>> To use the security engine, our software use the AF_ALG interface (via
>> libkcapi).
>>
>> Our software has to run on both boards, we can't afford two different
>> versions of the software and the software shall have no dead code. Therefore
>> we rely on the capability of the kernel to do the hash by itself when the
>> TALITOS in not available.
>>
>> The kernel has always been the place where we do board specific stuff, not
>> the application. I can't see why the application would have to ask the
>> kernel when the Talitos is there and have to do the hashing by itself when
>> the Talitos is not there.
>>
>> I'm really concerned with the optimised MD5 going away now, and I'm also
>> wondering what will be the way to splice a file into the kernel and get it's
>> MD-5 hash from the TALITOS if AF_ALG goes away in medium-term.
>>
>> What is the way forward ? I'm open to any suggestion as I really can't see
>> where to go for now.
>>
>> But please don't remove powerpc MD5 before we find an alternative solution.
>>
>> Thanks
>> Christophe
>
> I think I gave the solution in the commit message already, no? Take the
> same MD5 code and run it in userspace. It will be even faster than
> invoking that code via AF_ALG.
>
> Yes, the selection of software vs "security" engine (if you actually
> still need the latter, which in reality you probably don't) would then
> occur in userspace. But selecting an implementation in userspace isn't
> unusual. It's no different from how different CPU features are handled
> in userspace.
>
> Anyway, please don't confuse this patch (which only affects performance)
> with full removal of AF_ALG (which would be a hard break, and won't
> occur until quite far in the future). This patch is just a nudge in the
> right direction, and a cleanup of the kernel's powerpc support to be
> aligned with all the other architectures. So I do believe we should
> proceed with this patch.
But this cleanup is a huge performance regression. If it had been a few
% why not, but here we are talking about 30% more time. And userspace is
even worse, see below. I really doubt that porting the ASM
implementation into userspace will make the regression disappear.
Lets give a summary on performance:
With the TALITOS security engine embedded on powerpc 885:
root@miae:~# time md5sum avion.au
6513851d6109d42477b20cd56bf57f28 avion.au
real 0m 0.71s
user 0m 0.00s
sys 0m 0.38s
With kernel PPC MD5:
root@miae:~# time md5sum avion.au
6513851d6109d42477b20cd56bf57f28 avion.au
real 0m 1.01s
user 0m 0.01s
sys 0m 1.00s
With kernel generic MD5:
root@miae:~# time md5sum avion.au
6513851d6109d42477b20cd56bf57f28 avion.au
real 0m 1.31s
user 0m 0.01s
sys 0m 1.30s
With userspace MD5:
root@miae:~# time ./busybox md5sum avion.au
6513851d6109d42477b20cd56bf57f28 avion.au
real 0m 2.38s
user 0m 1.99s
sys 0m 0.38s
Now, we are talking about MD5 which is obsolete and being replaced in
our systems by SHA256. So a commit message ressembling to the one in
commit 23e5c306a207 ("lib/crypto: sparc: Drop optimized MD5 code") would
be better as a justification for the removal.
With the commit message modified to explain that MD5 is obsolete and
using it is risky as you explained in the Sparc commit message, you can
add Acked-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
But please consider the above performance comparison when addressing the
AF_ALG removal.
By the way, what are your plans for SHA1 ? I think SHA1 should likely go
away as well for the same reason.
Christophe
^ permalink raw reply
* Re: [PATCH] lib/crypto: powerpc/md5: Drop powerpc optimized MD5 code
From: Christophe Leroy (CS GROUP) @ 2026-05-05 16:34 UTC (permalink / raw)
To: Ard Biesheuvel, Eric Biggers, linux-crypto
Cc: linux-kernel, Jason A . Donenfeld, Herbert Xu, linuxppc-dev,
Nicholas Piggin, Michael Ellerman, Madhavan Srinivasan
In-Reply-To: <112bf0af-1551-4d3e-ab15-e5dea3fc2435@app.fastmail.com>
Le 04/05/2026 à 15:56, Ard Biesheuvel a écrit :
> Hello Christophe,
>
> On Mon, 4 May 2026, at 15:28, Christophe Leroy (CS GROUP) wrote:
> ...
>> I'm really concerned with the optimised MD5 going away now, and I'm also
>> wondering what will be the way to splice a file into the kernel and get
>> it's MD-5 hash from the TALITOS if AF_ALG goes away in medium-term.
>>
>> What is the way forward ? I'm open to any suggestion as I really can't
>> see where to go for now.
>>
>
> AF_ALG was created to give user space access to crypto accelerators that
> require privileged execution, for sharing between clients, and for managing
> DMA etc.
>
> The fact that kernel crypto code that does not have this requirement was
> exposed via AF_ALG too is a historical accident, and this is causing the
> pain that Eric describes wrt attack surface etc.
>
> It sounds like you have constructed a vertically integrated system where
> the kernel provides the fallback when the Talitos engine is not available
> via AF_ALG.
>
> This fallback does not need to live in the kernel, and it would be much
> better (as well as more efficient) if user space would implemented MD5
> itself if the Talitos cannot be accessed via AF_ALG. In user space, you
> can use any implementation you like, generic or asm accelerated. This is
> what all other architectures already implement, in OpenSSL etc.
>
> Claiming that your user space software must only implement one code path,
> and that punting this to the kernel is therefore required is not a
> technical argument: this is just policy on your part that the community
> is not bound to.
>
> However, deprecating AF_ALG does not mean that we will ever be able to
> remove it entirely. Especially the crypto accelerators that cannot be
> accessed by user space in any other way will remain supported as long
> as needed for legacy use cases.
>
> But I think we should consider libkcapi as a general purpose crypto
> library deprecated too, as well as any other use of AF_ALG in lieu of
> user space libraries. It is not the kernel's job to execute user space
> code that can easily execute non-privileged as well.
>
> I suppose there will be more discussion soon about AF_ALG deprecation
> for software crypto. It is likely that we will need to come up with
> an allowlist of algorithms, in order to limit the attack surface to those
> algorithms (such as your MD5) that are known to be relied upon by user space,
> rather than any random combination of all the buggy template code and
> null_ciphers etc.
>
> Do you have any use cases where MD5 is a bottle neck, and the generic
> implementation is too slow?
Well, our boards are used in air trafic control voice communication
systems, every millisecond is worth it and every performance degradation
must be explained, justified, etc ....
Christophe
^ permalink raw reply
* Re: [PATCH] lib/crypto: powerpc/md5: Drop powerpc optimized MD5 code
From: Eric Biggers @ 2026-05-05 17:14 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP)
Cc: linux-crypto, linux-kernel, Ard Biesheuvel, Jason A . Donenfeld,
Herbert Xu, linuxppc-dev, Nicholas Piggin, Michael Ellerman,
Madhavan Srinivasan
In-Reply-To: <ac6b9bcf-0106-49fd-82ff-20ccc5612fa1@kernel.org>
On Tue, May 05, 2026 at 06:34:00PM +0200, Christophe Leroy (CS GROUP) wrote:
> With userspace MD5:
>
> root@miae:~# time ./busybox md5sum avion.au
> 6513851d6109d42477b20cd56bf57f28 avion.au
> real 0m 2.38s
> user 0m 1.99s
> sys 0m 0.38s
Again, that's an unoptimized md5sum implementation, specifically
busybox's which is designed for size rather than speed. You'll just
need to replace it with a speed-optimized one, if that's what you need.
As I said, you can even reuse the same asm file, as it doesn't contain
any privileged instructions. However, there might be even faster code
out there (a GitHub search might be worthwhile). The code that's in the
kernel often isn't the fastest code that's available/possible.
> Now, we are talking about MD5 which is obsolete and being replaced in our
> systems by SHA256. So a commit message ressembling to the one in commit
> 23e5c306a207 ("lib/crypto: sparc: Drop optimized MD5 code") would be better
> as a justification for the removal.
Sure, I'll update the commit message to cover that too.
> By the way, what are your plans for SHA1 ? I think SHA1 should likely go
> away as well for the same reason.
Eventually the same thing will happen, but it will be some years in the
future.
- Eric
^ permalink raw reply
* [PATCH v3] powerpc/g5: Enable all windfarms by default
From: Linus Walleij @ 2026-05-05 18:47 UTC (permalink / raw)
To: Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP)
Cc: linuxppc-dev, linux-kernel, Linus Walleij
The G5 defconfig is clearly intended for the G5 Powermac
series, and that should enable all the available
windfarm drivers, or the machine will overheat a short
while after booting and shut itself down, which is
annoying.
Signed-off-by: Linus Walleij <linusw@kernel.org>
---
I wonder why this never gets applied. Am I doing something wrong?
Is the patch stupid? No-one cares?
---
Changes in v3:
- Rebased on v7.1-rc1
- Link to v2: https://lore.kernel.org/r/20260120-powermac-g5-config-v2-1-cd8f1c8bfbae@kernel.org
Changes in v2:
- Rebased on v6.19-rc1
- Link to v1: https://lore.kernel.org/r/20251205-powermac-g5-config-v1-1-8609aa97c1c0@kernel.org
To: Madhavan Srinivasan <maddy@linux.ibm.com>
To: Michael Ellerman <mpe@ellerman.id.au>
To: Nicholas Piggin <npiggin@gmail.com>
To: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
---
arch/powerpc/configs/g5_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/powerpc/configs/g5_defconfig b/arch/powerpc/configs/g5_defconfig
index 04bbb37f5978..f74ccc06f4c1 100644
--- a/arch/powerpc/configs/g5_defconfig
+++ b/arch/powerpc/configs/g5_defconfig
@@ -85,6 +85,8 @@ CONFIG_PMAC_SMU=y
CONFIG_MAC_EMUMOUSEBTN=y
CONFIG_WINDFARM=y
CONFIG_WINDFARM_PM81=y
+CONFIG_WINDFARM_PM72=y
+CONFIG_WINDFARM_RM31=y
CONFIG_WINDFARM_PM91=y
CONFIG_WINDFARM_PM112=y
CONFIG_WINDFARM_PM121=y
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20251205-powermac-g5-config-69128e93d584
Best regards,
--
Linus Walleij <linusw@kernel.org>
^ permalink raw reply related
* Re: [PATCH] powerpc/pseries/iommu: Add TCEs for 16GB pages when RAM is pre-mapped
From: Harsh Prateek Bora @ 2026-05-05 18:49 UTC (permalink / raw)
To: Gaurav Batra, maddy; +Cc: linuxppc-dev, ritesh.list, donettom, vaibhav, sbhat
In-Reply-To: <20260504205459.39185-1-gbatra@linux.ibm.com>
On 05/05/26 2:24 am, Gaurav Batra wrote:
> @@ -2431,7 +2437,7 @@ static int iommu_mem_notifier(struct notifier_block *nb, unsigned long action,
> spin_lock(&dma_win_list_lock);
> list_for_each_entry(window, &dma_win_list, list) {
> if (window->direct && (arg->start_pfn << PAGE_SHIFT) <
> - ddw_memory_hotplug_max()) {
> + pseries_ddw_max_ram) {
> ret |= tce_setrange_multi_pSeriesLP(arg->start_pfn,
> arg->nr_pages, window->prop);
I think not only start_pfn, but end_pfn also needs to be within allowed
range, which may require clamping arg->nr_pages if crossing the limits.
> }
> @@ -2444,7 +2450,7 @@ static int iommu_mem_notifier(struct notifier_block *nb, unsigned long action,
> spin_lock(&dma_win_list_lock);
> list_for_each_entry(window, &dma_win_list, list) {
> if (window->direct && (arg->start_pfn << PAGE_SHIFT) <
> - ddw_memory_hotplug_max()) {
> + pseries_ddw_max_ram) {
> ret |= tce_clearrange_multi_pSeriesLP(arg->start_pfn,
> arg->nr_pages, window->prop);
> }
^ permalink raw reply
* Re: [PATCH] powerpc/pseries/iommu: Add TCEs for 16GB pages when RAM is pre-mapped
From: Gaurav Batra @ 2026-05-05 21:01 UTC (permalink / raw)
To: Harsh Prateek Bora, maddy
Cc: linuxppc-dev, ritesh.list, donettom, vaibhav, sbhat
In-Reply-To: <83e821e1-2a71-4d8e-a40a-59ed7b333e95@linux.ibm.com>
On 5/5/26 1:49 PM, Harsh Prateek Bora wrote:
>
>
> On 05/05/26 2:24 am, Gaurav Batra wrote:
>> @@ -2431,7 +2437,7 @@ static int iommu_mem_notifier(struct
>> notifier_block *nb, unsigned long action,
>> spin_lock(&dma_win_list_lock);
>> list_for_each_entry(window, &dma_win_list, list) {
>> if (window->direct && (arg->start_pfn << PAGE_SHIFT) <
>> - ddw_memory_hotplug_max()) {
>> + pseries_ddw_max_ram) {
>> ret |= tce_setrange_multi_pSeriesLP(arg->start_pfn,
>> arg->nr_pages, window->prop);
>
> I think not only start_pfn, but end_pfn also needs to be within allowed
> range, which may require clamping arg->nr_pages if crossing the limits.
The reason to only check for start_pfn is because the range given will
either be in the RAM or pmemory. It can never cross the boundary
>
>> }
>> @@ -2444,7 +2450,7 @@ static int iommu_mem_notifier(struct
>> notifier_block *nb, unsigned long action,
>> spin_lock(&dma_win_list_lock);
>> list_for_each_entry(window, &dma_win_list, list) {
>> if (window->direct && (arg->start_pfn << PAGE_SHIFT) <
>> - ddw_memory_hotplug_max()) {
>> + pseries_ddw_max_ram) {
>> ret |= tce_clearrange_multi_pSeriesLP(arg->start_pfn,
>> arg->nr_pages, window->prop);
>> }
>
^ permalink raw reply
* Re: [PATCH v6 04/24] PCI/sysfs: Use BAR length in pci_llseek_resource() when attr->size is zero
From: Bjorn Helgaas @ 2026-05-05 21:46 UTC (permalink / raw)
To: Krzysztof Wilczyński
Cc: Bjorn Helgaas, Manivannan Sadhasivam, Lorenzo Pieralisi,
Magnus Lindholm, Matt Turner, Richard Henderson, Christophe Leroy,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Dexuan Cui, Krzysztof Hałasa, Lukas Wunner,
Oliver O'Halloran, Saurabh Singh Sengar, Shuan He,
Srivatsa Bhat, Ilpo Järvinen, linux-pci, linux-alpha,
linuxppc-dev
In-Reply-To: <20260430232202.GA3577346@rocinante>
On Fri, May 01, 2026 at 08:32:30AM +0900, Krzysztof Wilczyński wrote:
> Hello,
>
> > The alternative would be separate llseek callbacks for both the legacy
> > and resource attributes, which we can add if this would be the preference
> > here.
>
> If we were to do this, then it would be as follows:
>
> static loff_t pci_llseek_resource(struct file *filep,
> struct kobject *kobj,
> const struct bin_attribute *attr,
> loff_t offset, int whence)
> {
> struct pci_dev *pdev = to_pci_dev(kobj_to_dev(kobj));
> int bar = (unsigned long)attr->private;
>
> return fixed_size_llseek(filep, offset, whence,
> pci_resource_len(pdev, bar));
> }
>
> static loff_t pci_llseek_resource_legacy(struct file *filep,
> struct kobject *kobj __always_unused,
> const struct bin_attribute *attr,
> loff_t offset, int whence)
> {
> return fixed_size_llseek(filep, offset, whence, attr->size);
> }
>
> Each callback would be placed within the corresponding #ifdef block, so one
> for HAVE_PCI_MMAP or ARCH_GENERIC_PCI_MMAP_RESOURCE, and the other for the
> legacy attributes, so behind the HAVE_PCI_LEGACY guard.
>
> Note, the names need to be different, as some architectures offer both
> type of resource files, like PowerPC, which defines both the HAVE_PCI_LEGACY
> and HAVE_PCI_MMAP.
>
> With this split, we can also drop the __maybe_unused annotation.
>
> While I wanted to keep the changes to only what was needed for the
> pci_llseek_resource() to cover both type of resources, it would be
> also fine to have two distinct callbacks, too.
Yes, I think this is much more readable than the "if (attr->size)"
check.
^ permalink raw reply
* Re: [PATCH v6 24/24] PCI/sysfs: Limit BAR resize attribute scope to platforms with PCI mmap
From: Bjorn Helgaas @ 2026-05-05 22:01 UTC (permalink / raw)
To: Krzysztof Wilczyński
Cc: Bjorn Helgaas, Manivannan Sadhasivam, Lorenzo Pieralisi,
Magnus Lindholm, Matt Turner, Richard Henderson, Christophe Leroy,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Dexuan Cui, Krzysztof Hałasa, Lukas Wunner,
Oliver O'Halloran, Saurabh Singh Sengar, Shuan He,
Srivatsa Bhat, Ilpo Järvinen, linux-pci, linux-alpha,
linuxppc-dev
In-Reply-To: <20260430020648.GA3923076@rocinante>
On Thu, Apr 30, 2026 at 11:51:28AM +0900, Krzysztof Wilczyński wrote:
> Hello,
>
> > The only platform without these aforementioned defines is Alpha, which is
> > conventional PCI only and cannot have ReBAR. So this guard removes dead
> > sysfs code on platforms where it can never be executed.
>
> Having a closer look:
>
> resource_resize_attr_is_visible()
> pci_rebar_get_current_size() <- returns -ENOTSUPP, so is_visible callback returns 0
> pci_rebar_find_pos()
> pos = pdev->rebar_cap <- set to 0 on a conventional PCI
> if (!pos)
> return -ENOTSUPP <- no ReBAR support
>
> The pdev->rebar_cap is set during PCI enumeration:
>
> pci_init_capabilities()
> pci_rebar_init()
> pdev->rebar_cap = pci_find_ext_capability()
> pci_find_next_ext_capability()
> if (dev->cfg_size <= PCI_CFG_SPACE_SIZE)
> return 0; <- dev->cfg_size set to 256 here for conventional PCI
>
> The PCI_CFG_SPACE_SIZE is 256 here.
>
> When the platform has support for PCI Express, the dev->cfg_size is then
> set to 4096. On an architecture that supports conventional PCI only (such
> as Alpha), the pdev->rebar_cap will be set to 0, the is_visible callback
> will then return 0, and the resize sysfs attribute is never created, as
> such, the __resource_resize_store() callback will never be executed.
>
> To make the connetion here to the #ifdef guards:
>
> For the pci_rebar_get_current_size() to return >= 0, the device needs
> PCI Express and extended configuration space support. As of today,
> every architecture with PCI Express support defines HAVE_PCI_MMAP or
> ARCH_GENERIC_PCI_MMAP_RESOURCE.
>
> I hope the reasoning here works.
We're talking about this #ifdef:
+#if defined(HAVE_PCI_MMAP) || defined(ARCH_GENERIC_PCI_MMAP_RESOURCE)
static ssize_t __resource_resize_show(struct device *dev, int n, char *buf)
...
+#endif
I follow the reasoning now but by next week I won't, so I think it
requires too much background knowledge. Future changes involving
HAVE_PCI_MMAP or ARCH_GENERIC_PCI_MMAP_RESOURCE could easily break
this.
IIUC it's basically doing what "#ifdef CONFIG_PCI_REBAR" or even
"#ifdef CONFIG_PCI_EXPRESS" would do, if we had such a thing.
How terrible would it be if we just accepted this dead code on Alpha?
^ permalink raw reply
* Re: [PATCH v6 04/24] PCI/sysfs: Use BAR length in pci_llseek_resource() when attr->size is zero
From: Krzysztof Wilczyński @ 2026-05-05 23:19 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Bjorn Helgaas, Manivannan Sadhasivam, Lorenzo Pieralisi,
Magnus Lindholm, Matt Turner, Richard Henderson, Christophe Leroy,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Dexuan Cui, Krzysztof Hałasa, Lukas Wunner,
Oliver O'Halloran, Saurabh Singh Sengar, Shuan He,
Srivatsa Bhat, Ilpo Järvinen, linux-pci, linux-alpha,
linuxppc-dev
In-Reply-To: <20260505214659.GA752301@bhelgaas>
Hello,
> > > The alternative would be separate llseek callbacks for both the legacy
> > > and resource attributes, which we can add if this would be the preference
> > > here.
> >
> > If we were to do this, then it would be as follows:
> >
> > static loff_t pci_llseek_resource(struct file *filep,
> > struct kobject *kobj,
> > const struct bin_attribute *attr,
> > loff_t offset, int whence)
> > {
> > struct pci_dev *pdev = to_pci_dev(kobj_to_dev(kobj));
> > int bar = (unsigned long)attr->private;
> >
> > return fixed_size_llseek(filep, offset, whence,
> > pci_resource_len(pdev, bar));
> > }
> >
> > static loff_t pci_llseek_resource_legacy(struct file *filep,
> > struct kobject *kobj __always_unused,
> > const struct bin_attribute *attr,
> > loff_t offset, int whence)
> > {
> > return fixed_size_llseek(filep, offset, whence, attr->size);
> > }
> >
> > Each callback would be placed within the corresponding #ifdef block, so one
> > for HAVE_PCI_MMAP or ARCH_GENERIC_PCI_MMAP_RESOURCE, and the other for the
> > legacy attributes, so behind the HAVE_PCI_LEGACY guard.
> >
> > Note, the names need to be different, as some architectures offer both
> > type of resource files, like PowerPC, which defines both the HAVE_PCI_LEGACY
> > and HAVE_PCI_MMAP.
> >
> > With this split, we can also drop the __maybe_unused annotation.
> >
> > While I wanted to keep the changes to only what was needed for the
> > pci_llseek_resource() to cover both type of resources, it would be
> > also fine to have two distinct callbacks, too.
>
> Yes, I think this is much more readable than the "if (attr->size)"
> check.
OK. I will switch to two llseek callbacks in the next version.
Thank you,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 24/24] PCI/sysfs: Limit BAR resize attribute scope to platforms with PCI mmap
From: Krzysztof Wilczyński @ 2026-05-05 23:42 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Bjorn Helgaas, Manivannan Sadhasivam, Lorenzo Pieralisi,
Magnus Lindholm, Matt Turner, Richard Henderson, Christophe Leroy,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Dexuan Cui, Krzysztof Hałasa, Lukas Wunner,
Oliver O'Halloran, Saurabh Singh Sengar, Shuan He,
Srivatsa Bhat, Ilpo Järvinen, linux-pci, linux-alpha,
linuxppc-dev
In-Reply-To: <20260505220135.GA752411@bhelgaas>
Hello,
> > > The only platform without these aforementioned defines is Alpha, which is
> > > conventional PCI only and cannot have ReBAR. So this guard removes dead
> > > sysfs code on platforms where it can never be executed.
> >
> > Having a closer look:
> >
> > resource_resize_attr_is_visible()
> > pci_rebar_get_current_size() <- returns -ENOTSUPP, so is_visible callback returns 0
> > pci_rebar_find_pos()
> > pos = pdev->rebar_cap <- set to 0 on a conventional PCI
> > if (!pos)
> > return -ENOTSUPP <- no ReBAR support
> >
> > The pdev->rebar_cap is set during PCI enumeration:
> >
> > pci_init_capabilities()
> > pci_rebar_init()
> > pdev->rebar_cap = pci_find_ext_capability()
> > pci_find_next_ext_capability()
> > if (dev->cfg_size <= PCI_CFG_SPACE_SIZE)
> > return 0; <- dev->cfg_size set to 256 here for conventional PCI
> >
> > The PCI_CFG_SPACE_SIZE is 256 here.
> >
> > When the platform has support for PCI Express, the dev->cfg_size is then
> > set to 4096. On an architecture that supports conventional PCI only (such
> > as Alpha), the pdev->rebar_cap will be set to 0, the is_visible callback
> > will then return 0, and the resize sysfs attribute is never created, as
> > such, the __resource_resize_store() callback will never be executed.
> >
> > To make the connetion here to the #ifdef guards:
> >
> > For the pci_rebar_get_current_size() to return >= 0, the device needs
> > PCI Express and extended configuration space support. As of today,
> > every architecture with PCI Express support defines HAVE_PCI_MMAP or
> > ARCH_GENERIC_PCI_MMAP_RESOURCE.
> >
> > I hope the reasoning here works.
>
> We're talking about this #ifdef:
>
> +#if defined(HAVE_PCI_MMAP) || defined(ARCH_GENERIC_PCI_MMAP_RESOURCE)
> static ssize_t __resource_resize_show(struct device *dev, int n, char *buf)
> ...
> +#endif
>
> I follow the reasoning now but by next week I won't, so I think it
> requires too much background knowledge. Future changes involving
> HAVE_PCI_MMAP or ARCH_GENERIC_PCI_MMAP_RESOURCE could easily break
> this.
>
> IIUC it's basically doing what "#ifdef CONFIG_PCI_REBAR" or even
> "#ifdef CONFIG_PCI_EXPRESS" would do, if we had such a thing.
We don't sadly have such guards at the moment, so using the guards like
HAVE_PCI_MMAP or ARCH_GENERIC_PCI_MMAP_RESOURCE would be the next best
thing. We already rely on these throughout the pci-sysfs.c already, and
will also rely on either for the static sysfs attributes, so if there was
some issues with either of these, if these "broke" somehow, then we would
have other more severe problems. Note, that architectures rely on these
macros to let us know about what "feature" is expected to be enabled, so to
speak, so I would imagine nobody would break this accidentally (famous last
words) and perhaps with extreme caution would do it on purpose.
> How terrible would it be if we just accepted this dead code on Alpha?
I would prefer not to build any dead code anywhere if it can be helped,
especially with as little as two lines of code added. Plus, most of the
code setting up resources that are not specific to Alpha, would have been
disabled using exactly the same guard as the one proposed to be added
here, not like this sets any precedent or adds something new.
That being said, I will drop this from the next version.
Thank you!
Krzysztof
^ permalink raw reply
* Re: [PATCH net] net: wan: fsl_ucc_hdlc: free tx_skbuff in uhdlc_memclean
From: Jakub Kicinski @ 2026-05-05 23:47 UTC (permalink / raw)
To: Holger Brunck
Cc: Christophe Leroy (CS GROUP), netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, andrew+netdev@lunn.ch,
qiang.zhao@nxp.com, horms@kernel.org
In-Reply-To: <AM0PR06MB103966EF99B706158C49CB3EAF73E2@AM0PR06MB10396.eurprd06.prod.outlook.com>
On Tue, 5 May 2026 08:33:34 +0000 Holger Brunck wrote:
> > I don't think you can just kfree() an skb like this.
> >
> > I think you have to call dev_kfree_skb_any() instead.
>
> yes you are right or at least dev_kfree_skb() as the error handling code in
> ucc_hdlc_tx does.
Please make it clear in the commit message how you discovered
the issue and how you tested your patches.
^ permalink raw reply
* Re: [PATCH net] net: wan: fsl_ucc_hdlc: fix indentation error
From: Jakub Kicinski @ 2026-05-05 23:48 UTC (permalink / raw)
To: Holger Brunck
Cc: Christophe Leroy (CS GROUP), netdev@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, andrew+netdev@lunn.ch,
qiang.zhao@nxp.com, horms@kernel.org
In-Reply-To: <AM0PR06MB103966A8283FD757F6C9459A0F73E2@AM0PR06MB10396.eurprd06.prod.outlook.com>
On Tue, 5 May 2026 08:16:01 +0000 Holger Brunck wrote:
> no not mandatory needed. I just saw that and thought that also such minor issues
> should be fixed. Can be abandoned.
Quoting documentation:
Clean-up patches
~~~~~~~~~~~~~~~~
Netdev discourages patches which perform simple clean-ups, which are not in
the context of other work. For example:
* Addressing ``checkpatch.pl``, and other trivial coding style warnings
* Addressing :ref:`Local variable ordering<rcs>` issues
* Conversions to device-managed APIs (``devm_`` helpers)
This is because it is felt that the churn that such changes produce comes
at a greater cost than the value of such clean-ups.
Conversely, spelling and grammar fixes are not discouraged.
See: https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#clean-up-patches
^ permalink raw reply
* Re: [PATCH net] net: wan: fsl_ucc_hdlc: return NETDEV_TX_OK if skb was freed
From: Jakub Kicinski @ 2026-05-06 1:22 UTC (permalink / raw)
To: Holger Brunck
Cc: netdev, linuxppc-dev, andrew+netdev, chleroy, qiang.zhao, horms
In-Reply-To: <20260504174406.2229693-1-holger.brunck@hitachienergy.com>
On Mon, 4 May 2026 19:44:06 +0200 Holger Brunck wrote:
> If the skb was freed in the ucc_hdlc_tx function and the packet marked
> as dropped we need to return NETDEV_TX_OK. Otherwise the above layer
> will try to requeue an already freed skb.
Is this really true? I thought negative returns mean drop.
^ permalink raw reply
* [PATCH V2] powerpc/text-patching: simplify the implementation of ppc_kallsyms_lookup_name()
From: Xie Yuanbin @ 2026-05-06 2:11 UTC (permalink / raw)
To: chleroy, maddy, mpe, npiggin, andriy.shevchenko, kees
Cc: linuxppc-dev, linux-kernel, lilinjie8, liaohua4, xieyuanbin1
ppc_kallsyms_lookup_name() is called only twice in the kernel code, and
the parameters are all constant strings. strnlen(name, KSYM_NAME_LEN) is
called inside ppc_kallsyms_lookup_name(), when the compiler detects that
KSYM_NAME_LEN is larger then the constant strings,
the following error will be triggered:
```log
CC arch/powerpc/kernel/optprobes.o
In file included from ./arch/powerpc/include/asm/kprobes.h:24,
from ./include/linux/kprobes.h:31,
from arch/powerpc/kernel/optprobes.c:8:
In function 'ppc_kallsyms_lookup_name',
inlined from 'arch_prepare_optimized_kprobe' at arch/powerpc/kernel/optprobes.c:209:21:
./arch/powerpc/include/asm/text-patching.h:232:13: error: 'strnlen' specified bound 512 exceeds source size 19 [-Werror=stringop-overread]
232 | if (strnlen(name, KSYM_NAME_LEN) >= KSYM_NAME_LEN)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function 'ppc_kallsyms_lookup_name',
inlined from 'arch_prepare_optimized_kprobe' at arch/powerpc/kernel/optprobes.c:210:22:
./arch/powerpc/include/asm/text-patching.h:232:13: error: 'strnlen' specified bound 512 exceeds source size 13 [-Werror=stringop-overread]
232 | if (strnlen(name, KSYM_NAME_LEN) >= KSYM_NAME_LEN)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
```
The error can be reproduced in the following ways:
Use lastest linux-next source, change ppc_kallsyms_lookup_name() to
__always_inline, use default ppc64_defconfig, set CONFIG_EXPERT=y,
CONFIG_PPC64_BIG_ENDIAN_ELF_ABI_V2=n, CONFIG_CC_OPTIMIZE_FOR_SIZE=y,
and use gcc-14 or a later version for compilation.
Since ppc_kallsyms_lookup_name() is called only twice in the kernel,
and the parameters are all constant strins, simplify the implementation
of ppc_kallsyms_lookup_name() and avoid calling strnlen().
Cc: Andy Shevchenko <andriy.shevchenko@intel.com>
Cc: Kees Cook <kees@kernel.org>
Suggested-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Signed-off-by: Xie Yuanbin <xieyuanbin1@huawei.com>
---
v1->v2: https://lore.kernel.org/20260205100517.292858-2-xieyuanbin1@huawei.com
- Not use strlen()
arch/powerpc/include/asm/text-patching.h | 50 ++++++++----------------
1 file changed, 17 insertions(+), 33 deletions(-)
diff --git a/arch/powerpc/include/asm/text-patching.h b/arch/powerpc/include/asm/text-patching.h
index e7f14720f630..2d3f698cb4f1 100644
--- a/arch/powerpc/include/asm/text-patching.h
+++ b/arch/powerpc/include/asm/text-patching.h
@@ -221,39 +221,23 @@ static inline unsigned long ppc_global_function_entry(void *func)
* - For ABIv1, we lookup the dot variant.
* - For ABIv2, we return the local entry point.
*/
-static inline unsigned long ppc_kallsyms_lookup_name(const char *name)
-{
- unsigned long addr;
-#ifdef CONFIG_PPC64_ELF_ABI_V1
- /* check for dot variant */
- char dot_name[1 + KSYM_NAME_LEN];
- bool dot_appended = false;
-
- if (strnlen(name, KSYM_NAME_LEN) >= KSYM_NAME_LEN)
- return 0;
-
- if (name[0] != '.') {
- dot_name[0] = '.';
- dot_name[1] = '\0';
- strlcat(dot_name, name, sizeof(dot_name));
- dot_appended = true;
- } else {
- dot_name[0] = '\0';
- strlcat(dot_name, name, sizeof(dot_name));
- }
- addr = kallsyms_lookup_name(dot_name);
- if (!addr && dot_appended)
- /* Let's try the original non-dot symbol lookup */
- addr = kallsyms_lookup_name(name);
-#elif defined(CONFIG_PPC64_ELF_ABI_V2)
- addr = kallsyms_lookup_name(name);
- if (addr)
- addr = ppc_function_entry((void *)addr);
-#else
- addr = kallsyms_lookup_name(name);
-#endif
- return addr;
-}
+static inline unsigned long __ppc_kallsyms_lookup_name(const char *name)
+{
+ unsigned long addr = kallsyms_lookup_name(name);
+
+ if (IS_ENABLED(CONFIG_PPC64_ELF_ABI_V1) && !addr)
+ addr = kallsyms_lookup_name(name + 1);
+ if (IS_ENABLED(CONFIG_PPC64_ELF_ABI_V2) && addr)
+ addr = ppc_function_entry((void *)addr);
+
+ return addr;
+}
+
+#ifdef CONFIG_PPC64_ELF_ABI_V1
+#define ppc_kallsyms_lookup_name(x) __ppc_kallsyms_lookup_name("." x)
+#else
+#define ppc_kallsyms_lookup_name(x) __ppc_kallsyms_lookup_name(x)
+#endif
/*
* Some instruction encodings commonly used in dynamic ftracing
--
2.53.0
^ permalink raw reply related
* [PATCH v2] lib/crypto: powerpc/md5: Drop powerpc optimized MD5 code
From: Eric Biggers @ 2026-05-06 3:00 UTC (permalink / raw)
To: linux-crypto
Cc: linux-kernel, Ard Biesheuvel, Jason A . Donenfeld, Herbert Xu,
linuxppc-dev, Michael Ellerman, Madhavan Srinivasan,
Nicholas Piggin, Christophe Leroy, Eric Biggers
MD5 is obsolete, is vulnerable to collision attacks, and is being
replaced by SHA-256 in new systems. It doesn't make sense to continue
to maintain architecture-optimized implementations of MD5. Effort
should be spent on modern algorithms.
Indeed, architecture-optimized MD5 code remains only for powerpc. It
was already removed from mips and sparc, and it never existed for any
other architecture (e.g. x86, arm, or arm64) in the first place.
Earlier the decision was made to keep the powerpc MD5 code for a while
anyway because of someone using it via AF_ALG via libkcapi-hasher
(https://lore.kernel.org/r/f0d771d5-ed70-444c-957a-ad4c16f6c115@csgroup.eu/)
However, with AF_ALG itself now being on its way out due to its
continuous stream of security vulnerabilities
(https://lore.kernel.org/r/20260430011544.31823-1-ebiggers@kernel.org/),
it's also time to be a bit more forceful with nudging people towards
userspace crypto code. It's always been the better solution anyway, and
it's much more efficient if properly optimized code is used.
Note that the md5-asm.S file contains no privileged instructions and
could be run in userspace just fine.
Thus, we now have two factors going against keeping the powerpc MD5
code. Different people might weigh these two factors differently, but I
think the two of them together make the removal the clear choice.
Let's remove it.
Acked-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---
This patch is intended to be taken via libcrypto-next
v2: reworked commit message
lib/crypto/Kconfig | 5 -
lib/crypto/Makefile | 4 -
lib/crypto/md5.c | 20 ++-
lib/crypto/powerpc/md5-asm.S | 235 -----------------------------------
lib/crypto/powerpc/md5.h | 12 --
5 files changed, 7 insertions(+), 269 deletions(-)
delete mode 100644 lib/crypto/powerpc/md5-asm.S
delete mode 100644 lib/crypto/powerpc/md5.h
diff --git a/lib/crypto/Kconfig b/lib/crypto/Kconfig
index d3904b72dae7..591c1c2a7fb3 100644
--- a/lib/crypto/Kconfig
+++ b/lib/crypto/Kconfig
@@ -129,15 +129,10 @@ config CRYPTO_LIB_MD5
tristate
help
The MD5 and HMAC-MD5 library functions. Select this if your module
uses any of the functions from <crypto/md5.h>.
-config CRYPTO_LIB_MD5_ARCH
- bool
- depends on CRYPTO_LIB_MD5 && !UML
- default y if PPC
-
config CRYPTO_LIB_MLDSA
tristate
select CRYPTO_LIB_SHA3
help
The ML-DSA library functions. Select this if your module uses any of
diff --git a/lib/crypto/Makefile b/lib/crypto/Makefile
index 4ad91f390038..f1e9bf89785f 100644
--- a/lib/crypto/Makefile
+++ b/lib/crypto/Makefile
@@ -185,14 +185,10 @@ clean-files += powerpc/ghashp8-ppc.S
################################################################################
obj-$(CONFIG_CRYPTO_LIB_MD5) += libmd5.o
libmd5-y := md5.o
-ifeq ($(CONFIG_CRYPTO_LIB_MD5_ARCH),y)
-CFLAGS_md5.o += -I$(src)/$(SRCARCH)
-libmd5-$(CONFIG_PPC) += powerpc/md5-asm.o
-endif # CONFIG_CRYPTO_LIB_MD5_ARCH
################################################################################
obj-$(CONFIG_CRYPTO_LIB_MLDSA) += libmldsa.o
libmldsa-y := mldsa.o
diff --git a/lib/crypto/md5.c b/lib/crypto/md5.c
index c4af57db0ea8..6bf130cfbbf9 100644
--- a/lib/crypto/md5.c
+++ b/lib/crypto/md5.c
@@ -1,11 +1,11 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
* MD5 and HMAC-MD5 library functions
*
- * md5_block_generic() is derived from cryptoapi implementation, originally
- * based on the public domain implementation written by Colin Plumb in 1993.
+ * md5_block() is derived from cryptoapi implementation, originally based on the
+ * public domain implementation written by Colin Plumb in 1993.
*
* Copyright (c) Cryptoapi developers.
* Copyright (c) 2002 James Morris <jmorris@intercode.com.au>
* Copyright 2025 Google LLC
*/
@@ -29,12 +29,12 @@ static const struct md5_block_state md5_iv = {
#define F4(x, y, z) (y ^ (x | ~z))
#define MD5STEP(f, w, x, y, z, in, s) \
(w += f(x, y, z) + in, w = rol32(w, s) + x)
-static void md5_block_generic(struct md5_block_state *state,
- const u8 data[MD5_BLOCK_SIZE])
+static void md5_block(struct md5_block_state *state,
+ const u8 data[MD5_BLOCK_SIZE])
{
u32 in[MD5_BLOCK_WORDS];
u32 a, b, c, d;
memcpy(in, data, MD5_BLOCK_SIZE);
@@ -117,25 +117,19 @@ static void md5_block_generic(struct md5_block_state *state,
state->h[1] += b;
state->h[2] += c;
state->h[3] += d;
}
-static void __maybe_unused md5_blocks_generic(struct md5_block_state *state,
- const u8 *data, size_t nblocks)
+static void md5_blocks(struct md5_block_state *state,
+ const u8 *data, size_t nblocks)
{
do {
- md5_block_generic(state, data);
+ md5_block(state, data);
data += MD5_BLOCK_SIZE;
} while (--nblocks);
}
-#ifdef CONFIG_CRYPTO_LIB_MD5_ARCH
-#include "md5.h" /* $(SRCARCH)/md5.h */
-#else
-#define md5_blocks md5_blocks_generic
-#endif
-
void md5_init(struct md5_ctx *ctx)
{
ctx->state = md5_iv;
ctx->bytecount = 0;
}
diff --git a/lib/crypto/powerpc/md5-asm.S b/lib/crypto/powerpc/md5-asm.S
deleted file mode 100644
index fa6bc440cf4a..000000000000
--- a/lib/crypto/powerpc/md5-asm.S
+++ /dev/null
@@ -1,235 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-or-later */
-/*
- * Fast MD5 implementation for PPC
- *
- * Copyright (c) 2015 Markus Stockhausen <stockhausen@collogia.de>
- */
-#include <asm/ppc_asm.h>
-#include <asm/asm-offsets.h>
-#include <asm/asm-compat.h>
-
-#define rHP r3
-#define rWP r4
-
-#define rH0 r0
-#define rH1 r6
-#define rH2 r7
-#define rH3 r5
-
-#define rW00 r8
-#define rW01 r9
-#define rW02 r10
-#define rW03 r11
-#define rW04 r12
-#define rW05 r14
-#define rW06 r15
-#define rW07 r16
-#define rW08 r17
-#define rW09 r18
-#define rW10 r19
-#define rW11 r20
-#define rW12 r21
-#define rW13 r22
-#define rW14 r23
-#define rW15 r24
-
-#define rT0 r25
-#define rT1 r26
-
-#define INITIALIZE \
- PPC_STLU r1,-INT_FRAME_SIZE(r1); \
- SAVE_GPRS(14, 26, r1) /* push registers onto stack */
-
-#define FINALIZE \
- REST_GPRS(14, 26, r1); /* pop registers from stack */ \
- addi r1,r1,INT_FRAME_SIZE
-
-#ifdef __BIG_ENDIAN__
-#define LOAD_DATA(reg, off) \
- lwbrx reg,0,rWP; /* load data */
-#define INC_PTR \
- addi rWP,rWP,4; /* increment per word */
-#define NEXT_BLOCK /* nothing to do */
-#else
-#define LOAD_DATA(reg, off) \
- lwz reg,off(rWP); /* load data */
-#define INC_PTR /* nothing to do */
-#define NEXT_BLOCK \
- addi rWP,rWP,64; /* increment per block */
-#endif
-
-#define R_00_15(a, b, c, d, w0, w1, p, q, off, k0h, k0l, k1h, k1l) \
- LOAD_DATA(w0, off) /* W */ \
- and rT0,b,c; /* 1: f = b and c */ \
- INC_PTR /* ptr++ */ \
- andc rT1,d,b; /* 1: f' = ~b and d */ \
- LOAD_DATA(w1, off+4) /* W */ \
- or rT0,rT0,rT1; /* 1: f = f or f' */ \
- addi w0,w0,k0l; /* 1: wk = w + k */ \
- add a,a,rT0; /* 1: a = a + f */ \
- addis w0,w0,k0h; /* 1: wk = w + k' */ \
- addis w1,w1,k1h; /* 2: wk = w + k */ \
- add a,a,w0; /* 1: a = a + wk */ \
- addi w1,w1,k1l; /* 2: wk = w + k' */ \
- rotrwi a,a,p; /* 1: a = a rotl x */ \
- add d,d,w1; /* 2: a = a + wk */ \
- add a,a,b; /* 1: a = a + b */ \
- and rT0,a,b; /* 2: f = b and c */ \
- andc rT1,c,a; /* 2: f' = ~b and d */ \
- or rT0,rT0,rT1; /* 2: f = f or f' */ \
- add d,d,rT0; /* 2: a = a + f */ \
- INC_PTR /* ptr++ */ \
- rotrwi d,d,q; /* 2: a = a rotl x */ \
- add d,d,a; /* 2: a = a + b */
-
-#define R_16_31(a, b, c, d, w0, w1, p, q, k0h, k0l, k1h, k1l) \
- andc rT0,c,d; /* 1: f = c and ~d */ \
- and rT1,b,d; /* 1: f' = b and d */ \
- addi w0,w0,k0l; /* 1: wk = w + k */ \
- or rT0,rT0,rT1; /* 1: f = f or f' */ \
- addis w0,w0,k0h; /* 1: wk = w + k' */ \
- add a,a,rT0; /* 1: a = a + f */ \
- addi w1,w1,k1l; /* 2: wk = w + k */ \
- add a,a,w0; /* 1: a = a + wk */ \
- addis w1,w1,k1h; /* 2: wk = w + k' */ \
- andc rT0,b,c; /* 2: f = c and ~d */ \
- rotrwi a,a,p; /* 1: a = a rotl x */ \
- add a,a,b; /* 1: a = a + b */ \
- add d,d,w1; /* 2: a = a + wk */ \
- and rT1,a,c; /* 2: f' = b and d */ \
- or rT0,rT0,rT1; /* 2: f = f or f' */ \
- add d,d,rT0; /* 2: a = a + f */ \
- rotrwi d,d,q; /* 2: a = a rotl x */ \
- add d,d,a; /* 2: a = a +b */
-
-#define R_32_47(a, b, c, d, w0, w1, p, q, k0h, k0l, k1h, k1l) \
- xor rT0,b,c; /* 1: f' = b xor c */ \
- addi w0,w0,k0l; /* 1: wk = w + k */ \
- xor rT1,rT0,d; /* 1: f = f xor f' */ \
- addis w0,w0,k0h; /* 1: wk = w + k' */ \
- add a,a,rT1; /* 1: a = a + f */ \
- addi w1,w1,k1l; /* 2: wk = w + k */ \
- add a,a,w0; /* 1: a = a + wk */ \
- addis w1,w1,k1h; /* 2: wk = w + k' */ \
- rotrwi a,a,p; /* 1: a = a rotl x */ \
- add d,d,w1; /* 2: a = a + wk */ \
- add a,a,b; /* 1: a = a + b */ \
- xor rT1,rT0,a; /* 2: f = b xor f' */ \
- add d,d,rT1; /* 2: a = a + f */ \
- rotrwi d,d,q; /* 2: a = a rotl x */ \
- add d,d,a; /* 2: a = a + b */
-
-#define R_48_63(a, b, c, d, w0, w1, p, q, k0h, k0l, k1h, k1l) \
- addi w0,w0,k0l; /* 1: w = w + k */ \
- orc rT0,b,d; /* 1: f = b or ~d */ \
- addis w0,w0,k0h; /* 1: w = w + k' */ \
- xor rT0,rT0,c; /* 1: f = f xor c */ \
- add a,a,w0; /* 1: a = a + wk */ \
- addi w1,w1,k1l; /* 2: w = w + k */ \
- add a,a,rT0; /* 1: a = a + f */ \
- addis w1,w1,k1h; /* 2: w = w + k' */ \
- rotrwi a,a,p; /* 1: a = a rotl x */ \
- add a,a,b; /* 1: a = a + b */ \
- orc rT0,a,c; /* 2: f = b or ~d */ \
- add d,d,w1; /* 2: a = a + wk */ \
- xor rT0,rT0,b; /* 2: f = f xor c */ \
- add d,d,rT0; /* 2: a = a + f */ \
- rotrwi d,d,q; /* 2: a = a rotl x */ \
- add d,d,a; /* 2: a = a + b */
-
-_GLOBAL(ppc_md5_transform)
- INITIALIZE
-
- mtctr r5
- lwz rH0,0(rHP)
- lwz rH1,4(rHP)
- lwz rH2,8(rHP)
- lwz rH3,12(rHP)
-
-ppc_md5_main:
- R_00_15(rH0, rH1, rH2, rH3, rW00, rW01, 25, 20, 0,
- 0xd76b, -23432, 0xe8c8, -18602)
- R_00_15(rH2, rH3, rH0, rH1, rW02, rW03, 15, 10, 8,
- 0x2420, 0x70db, 0xc1be, -12562)
- R_00_15(rH0, rH1, rH2, rH3, rW04, rW05, 25, 20, 16,
- 0xf57c, 0x0faf, 0x4788, -14806)
- R_00_15(rH2, rH3, rH0, rH1, rW06, rW07, 15, 10, 24,
- 0xa830, 0x4613, 0xfd47, -27391)
- R_00_15(rH0, rH1, rH2, rH3, rW08, rW09, 25, 20, 32,
- 0x6981, -26408, 0x8b45, -2129)
- R_00_15(rH2, rH3, rH0, rH1, rW10, rW11, 15, 10, 40,
- 0xffff, 0x5bb1, 0x895d, -10306)
- R_00_15(rH0, rH1, rH2, rH3, rW12, rW13, 25, 20, 48,
- 0x6b90, 0x1122, 0xfd98, 0x7193)
- R_00_15(rH2, rH3, rH0, rH1, rW14, rW15, 15, 10, 56,
- 0xa679, 0x438e, 0x49b4, 0x0821)
-
- R_16_31(rH0, rH1, rH2, rH3, rW01, rW06, 27, 23,
- 0x0d56, 0x6e0c, 0x1810, 0x6d2d)
- R_16_31(rH2, rH3, rH0, rH1, rW11, rW00, 18, 12,
- 0x9d02, -32109, 0x124c, 0x2332)
- R_16_31(rH0, rH1, rH2, rH3, rW05, rW10, 27, 23,
- 0x8ea7, 0x4a33, 0x0245, -18270)
- R_16_31(rH2, rH3, rH0, rH1, rW15, rW04, 18, 12,
- 0x8eee, -8608, 0xf258, -5095)
- R_16_31(rH0, rH1, rH2, rH3, rW09, rW14, 27, 23,
- 0x969d, -10697, 0x1cbe, -15288)
- R_16_31(rH2, rH3, rH0, rH1, rW03, rW08, 18, 12,
- 0x3317, 0x3e99, 0xdbd9, 0x7c15)
- R_16_31(rH0, rH1, rH2, rH3, rW13, rW02, 27, 23,
- 0xac4b, 0x7772, 0xd8cf, 0x331d)
- R_16_31(rH2, rH3, rH0, rH1, rW07, rW12, 18, 12,
- 0x6a28, 0x6dd8, 0x219a, 0x3b68)
-
- R_32_47(rH0, rH1, rH2, rH3, rW05, rW08, 28, 21,
- 0x29cb, 0x28e5, 0x4218, -7788)
- R_32_47(rH2, rH3, rH0, rH1, rW11, rW14, 16, 9,
- 0x473f, 0x06d1, 0x3aae, 0x3036)
- R_32_47(rH0, rH1, rH2, rH3, rW01, rW04, 28, 21,
- 0xaea1, -15134, 0x640b, -11295)
- R_32_47(rH2, rH3, rH0, rH1, rW07, rW10, 16, 9,
- 0x8f4c, 0x4887, 0xbc7c, -22499)
- R_32_47(rH0, rH1, rH2, rH3, rW13, rW00, 28, 21,
- 0x7eb8, -27199, 0x00ea, 0x6050)
- R_32_47(rH2, rH3, rH0, rH1, rW03, rW06, 16, 9,
- 0xe01a, 0x22fe, 0x4447, 0x69c5)
- R_32_47(rH0, rH1, rH2, rH3, rW09, rW12, 28, 21,
- 0xb7f3, 0x0253, 0x59b1, 0x4d5b)
- R_32_47(rH2, rH3, rH0, rH1, rW15, rW02, 16, 9,
- 0x4701, -27017, 0xc7bd, -19859)
-
- R_48_63(rH0, rH1, rH2, rH3, rW00, rW07, 26, 22,
- 0x0988, -1462, 0x4c70, -19401)
- R_48_63(rH2, rH3, rH0, rH1, rW14, rW05, 17, 11,
- 0xadaf, -5221, 0xfc99, 0x66f7)
- R_48_63(rH0, rH1, rH2, rH3, rW12, rW03, 26, 22,
- 0x7e80, -16418, 0xba1e, -25587)
- R_48_63(rH2, rH3, rH0, rH1, rW10, rW01, 17, 11,
- 0x4130, 0x380d, 0xe0c5, 0x738d)
- lwz rW00,0(rHP)
- R_48_63(rH0, rH1, rH2, rH3, rW08, rW15, 26, 22,
- 0xe837, -30770, 0xde8a, 0x69e8)
- lwz rW14,4(rHP)
- R_48_63(rH2, rH3, rH0, rH1, rW06, rW13, 17, 11,
- 0x9e79, 0x260f, 0x256d, -27941)
- lwz rW12,8(rHP)
- R_48_63(rH0, rH1, rH2, rH3, rW04, rW11, 26, 22,
- 0xab75, -20775, 0x4f9e, -28397)
- lwz rW10,12(rHP)
- R_48_63(rH2, rH3, rH0, rH1, rW02, rW09, 17, 11,
- 0x662b, 0x7c56, 0x11b2, 0x0358)
-
- add rH0,rH0,rW00
- stw rH0,0(rHP)
- add rH1,rH1,rW14
- stw rH1,4(rHP)
- add rH2,rH2,rW12
- stw rH2,8(rHP)
- add rH3,rH3,rW10
- stw rH3,12(rHP)
- NEXT_BLOCK
-
- bdnz ppc_md5_main
-
- FINALIZE
- blr
diff --git a/lib/crypto/powerpc/md5.h b/lib/crypto/powerpc/md5.h
deleted file mode 100644
index 540b08e34d1d..000000000000
--- a/lib/crypto/powerpc/md5.h
+++ /dev/null
@@ -1,12 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0-or-later */
-/*
- * MD5 optimized for PowerPC
- */
-
-void ppc_md5_transform(u32 *state, const u8 *data, size_t nblocks);
-
-static void md5_blocks(struct md5_block_state *state,
- const u8 *data, size_t nblocks)
-{
- ppc_md5_transform(state->h, data, nblocks);
-}
base-commit: 74fe02ce122a6103f207d29fafc8b3a53de6abaf
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] powerpc/pseries/iommu: Add TCEs for 16GB pages when RAM is pre-mapped
From: Harsh Prateek Bora @ 2026-05-06 4:04 UTC (permalink / raw)
To: Gaurav Batra, maddy; +Cc: linuxppc-dev, ritesh.list, donettom, vaibhav, sbhat
In-Reply-To: <d8448246-f296-44d1-ac95-a80984e78c7e@linux.ibm.com>
On 06/05/26 2:31 am, Gaurav Batra wrote:
>
> On 5/5/26 1:49 PM, Harsh Prateek Bora wrote:
>>
>>
>> On 05/05/26 2:24 am, Gaurav Batra wrote:
>>> @@ -2431,7 +2437,7 @@ static int iommu_mem_notifier(struct
>>> notifier_block *nb, unsigned long action,
>>> spin_lock(&dma_win_list_lock);
>>> list_for_each_entry(window, &dma_win_list, list) {
>>> if (window->direct && (arg->start_pfn << PAGE_SHIFT) <
>>> - ddw_memory_hotplug_max()) {
>>> + pseries_ddw_max_ram) {
>>> ret |= tce_setrange_multi_pSeriesLP(arg->start_pfn,
>>> arg->nr_pages, window->prop);
>>
>> I think not only start_pfn, but end_pfn also needs to be within allowed
>> range, which may require clamping arg->nr_pages if crossing the limits.
> The reason to only check for start_pfn is because the range given will
> either be in the RAM or pmemory. It can never cross the boundary
Usually as an API, we do not trust the caller, hence the check for
start_pfn. However, if at all we need to go ahead with that assumption,
may be document that as a code comment and/or in the commit log also?
>>
>>> }
>>> @@ -2444,7 +2450,7 @@ static int iommu_mem_notifier(struct
>>> notifier_block *nb, unsigned long action,
>>> spin_lock(&dma_win_list_lock);
>>> list_for_each_entry(window, &dma_win_list, list) {
>>> if (window->direct && (arg->start_pfn << PAGE_SHIFT) <
>>> - ddw_memory_hotplug_max()) {
>>> + pseries_ddw_max_ram) {
>>> ret |= tce_clearrange_multi_pSeriesLP(arg->start_pfn,
>>> arg->nr_pages, window->prop);
>>> }
>>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox