Hi Abhishek,
kernel test robot noticed the following build errors:
[auto build test ERROR on powerpc/next]
[also build test ERROR on powerpc/fixes linus/master v6.9 next-20240516]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
Hi Abhishek,
kernel test robot noticed the following build errors:
[auto build test ERROR on powerpc/next]
[also build test ERROR on powerpc/fixes linus/master v6.9 next-20240516]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
allmodconfig gcc
i386 allnoconfig gcc
i386 allyesconfig gcc
i386 buildonly-randconfig-001-20240516 clang
i386 buildonly-randconfig-001-20240517 clang
i386 buildonly-randconfig-002-20240516 clang
i386
On Tue, May 14, 2024 at 11:54 PM Krishna Kumar wrote:
>
> There is an issue with the hotplug operation when it's done on the
> bridge/switch slot. The bridge-port and devices behind the bridge, which
> become offline by hot-unplug operation, don't get hot-plugged/enabled by
> doing hot-plug operat
Hi Gautam,
kernel test robot noticed the following build errors:
[auto build test ERROR on powerpc/topic/ppc-kvm]
[also build test ERROR on powerpc/next powerpc/fixes kvm/queue
mst-vhost/linux-next linus/master v6.9 next-20240516]
[cannot apply to kvm/linux-next]
[If your patch is applied to
trace ]---
# bad: [dbd9e2e056d8577375ae4b31ada94f8aa3769e8a] Add linux-next specific files
for 20240516
git bisect start 'next/master'
# status: waiting for good commit(s), bad commit known
# good: [8c06da67d0bd3139a97f301b4aa9c482b9d4f29e] Merge tag
'livepatching-for-
On Wed, May 15, 2024 at 1:19 PM Borislav Petkov wrote:
>
> On Wed, May 15, 2024 at 12:19:16PM -0700, Axel Rasmussen wrote:
> > An unprivileged process can allocate a VMA, use the userfaultfd API to
> > install one of these PTE markers, and then register a no-op SIGBUS
> > handler. Now it can acces
Hi!
On Thu, May 16, 2024 at 10:06:58PM +1000, Michael Ellerman wrote:
> Andy Polyakov writes:
> >>> +.abiversion 2
> >>
> >> I'd prefer that was left to the compiler flags.
> >
> > Problem is that it's the compiler that is responsible for providing this
> > directive in the intermediate .s p
On Wed, May 15, 2024 at 10:29:56AM +0200, Andy Polyakov wrote:
> >+static void cswap(fe51 p, fe51 q, unsigned int bit)
>
> The "c" in cswap stands for "constant-time," and the problem is that
> contemporary compilers have exhibited the ability to produce
> non-constant-time machine code as resul
Defined CRYPTO_CURVE25519_PPC64 to support X25519 for ppc64le.
Added new module curve25519-ppc64le for X25519.
Signed-off-by: Danny Tsen
---
arch/powerpc/crypto/Kconfig | 11 +++
arch/powerpc/crypto/Makefile | 2 ++
2 files changed, 13 insertions(+)
diff --git a/arch/powerpc/crypto/K
X25519 core functions to handle scalar multiplication for ppc64le.
Signed-off-by: Danny Tsen
---
arch/powerpc/crypto/curve25519-ppc64le-core.c | 299 ++
1 file changed, 299 insertions(+)
create mode 100644 arch/powerpc/crypto/curve25519-ppc64le-core.c
diff --git a/arch/powerpc/
This patch series provide X25519 support for ppc64le with a new module
curve25519-ppc64le.
The implementation is based on CRYPTOGAMs perl output from x25519-ppc64.pl.
(see https://github.com/dot-asm/cryptogams/)
Modified and added 4 supporting functions.
This patch has passed the selftest by runn
Use the perl output of x25519-ppc64.pl from CRYPTOGAMs
(see https://github.com/dot-asm/cryptogams/) and added four
supporting functions, x25519_fe51_sqr_times, x25519_fe51_frombytes,
x25519_fe51_tobytes and x25519_cswap.
Signed-off-by: Danny Tsen
---
arch/powerpc/crypto/curve25519-ppc64le_asm.S
On 15. 05. 24 15:34, Shengjiu Wang wrote:
On Wed, May 15, 2024 at 6:46 PM Jaroslav Kysela wrote:
On 15. 05. 24 12:19, Takashi Iwai wrote:
On Wed, 15 May 2024 11:50:52 +0200,
Jaroslav Kysela wrote:
On 15. 05. 24 11:17, Hans Verkuil wrote:
Hi Jaroslav,
On 5/13/24 13:56, Jaroslav Kysela wrot
On 15. 05. 24 22:33, Nicolas Dufresne wrote:
Hi,
GStreamer hat on ...
Le mercredi 15 mai 2024 à 12:46 +0200, Jaroslav Kysela a écrit :
On 15. 05. 24 12:19, Takashi Iwai wrote:
On Wed, 15 May 2024 11:50:52 +0200,
Jaroslav Kysela wrote:
On 15. 05. 24 11:17, Hans Verkuil wrote:
Hi Jaroslav,
For printing dump_trace, use existing stats_print()
function.
Signed-off-by: Abhishek Dubey
---
tools/perf/builtin-report.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index dcd93ee5fc24..3cabd5b0bfec 100644
--
This is an adaptation of commit f3a112c0c40d ("x86,rethook,kprobes:
Replace kretprobe with rethook on x86") to Power.
Replaces the kretprobe code with rethook on Power. With this patch,
kretprobe on Power uses the rethook instead of kretprobe specific
trampoline code.
Reference to other archs:
co
Hi,
+.abiversion2
I'd prefer that was left to the compiler flags.
Problem is that it's the compiler that is responsible for providing this
directive in the intermediate .s prior invoking the assembler. And there
is no assembler flag to pass through -Wa.
Hmm, right. But none of our exis
With some compilers/configs fadump_setup_param_area() isn't inlined into
its caller (which is __init), leading to a section mismatch warning:
WARNING: modpost: vmlinux: section mismatch in reference:
fadump_setup_param_area+0x200 (section: .text.fadump_setup_param_area)
-> memblock_phys_allo
On Wed, May 15, 2024 at 03:54:10PM +0200, Elinor Montmasson wrote:
> Add new optional DT property "cpu-system-clock-direction-out" to set
> sysclk direction as "out" for the CPU DAI when using the generic codec.
> It is set for both Tx and Rx.
> If not set, the direction is "in".
> The way the dire
In the current design, a numa-node is made online only if
that node is attached to cpu/memory. With this design, if
any PCI/IO device is found to be attached to a numa-node
which is not online then the numa-node id of the corresponding
PCI/IO device is set to NUMA_NO_NODE(-1). This design may
negat
Hi,
On NUMA aware system, we make a numa-node online only if that node is
attached to cpu/memory. However it's possible that we have some PCI/IO
device affinitized to a numa-node which is not currently online. In such
case we set the numa-node id of the corresponding PCI device to -1
(NUMA_NO_
On Wed, May 15, 2024 at 03:54:09PM +0200, Elinor Montmasson wrote:
> Add an optional DT clock "cpu_sysclk" to get the CPU DAI system-clock
> frequency when using the generic codec.
> It is set for both Tx and Rx.
> The way the frequency value is used is up to the CPU DAI driver
> implementation.
On Wed, May 15, 2024 at 03:54:11PM +0200, Elinor Montmasson wrote:
> Add documentation about new dts bindings following new support
> for compatible "fsl,imx-audio-generic".
>audio-codec:
> -$ref: /schemas/types.yaml#/definitions/phandle
> -description: The phandle of an audio codec
>
Andy Polyakov writes:
> Hi,
>
>>> +.abiversion2
>>
>> I'd prefer that was left to the compiler flags.
>
> Problem is that it's the compiler that is responsible for providing this
> directive in the intermediate .s prior invoking the assembler. And there
> is no assembler flag to pass throu
Hi Andy,
I learned something here. Will fix this. Thanks.
-Danny
On 5/16/24 3:38 AM, Andy Polyakov wrote:
Hi,
+.abiversion 2
I'd prefer that was left to the compiler flags.
Problem is that it's the compiler that is responsible for providing
this directive in the intermediate .s pri
On 5/15/24 11:53 PM, Michael Ellerman wrote:
Hi Danny,
Danny Tsen writes:
Use the perl output of x25519-ppc64.pl from CRYPTOGAMs and added three
supporting functions, x25519_fe51_sqr_times, x25519_fe51_frombytes
and x25519_fe51_tobytes.
For other algorithms we have checked-in the perl scrip
Hi,
+.abiversion2
I'd prefer that was left to the compiler flags.
Problem is that it's the compiler that is responsible for providing this
directive in the intermediate .s prior invoking the assembler. And there
is no assembler flag to pass through -Wa. If concern is ABI neutrality,
t
28 matches
Mail list logo
