Fix multiple build errors or warnings for POWERPC.
These are mostly fixes for resource_size_t printk format warnings.
One patch is for RTAS, which requires GENERIC_ALLOCATOR.
Subject: [PATCH 1/4] clk: mpc512x: fix resource printk format warning
Subject: [PATCH 2/4] powerpc: wii: fix resource print
Use "%pa" format specifier for resource_size_t to avoid a compiler
printk format warning.
../arch/powerpc/sysdev/tsi108_pci.c: In function 'tsi108_setup_pci':
../include/linux/kern_levels.h:5:25: error: format '%x' expects argument of
type 'unsigned int', but argument 2 has type 'resource_size_t'
The RTAS work area allocator uses code that is built by
GENERIC_ALLOCATOR, so the PSERIES Kconfig should select the
required Kconfig symbol to fix multiple build errors.
powerpc64-linux-ld: arch/powerpc/platforms/pseries/rtas-work-area.o: in
function `.rtas_work_area_allocator_init':
rtas-work-ar
Use "%pa" format specifier for resource_size_t to avoid compiler
printk format warnings.
../arch/powerpc/platforms/embedded6xx/flipper-pic.c: In function
'flipper_pic_init':
../include/linux/kern_levels.h:5:25: error: format '%x' expects argument of
type 'unsigned int', but argument 2 has type '
Use "%pa" format specifier for resource_size_t to avoid a compiler
printk format warning.
../arch/powerpc/platforms/512x/clock-commonclk.c: In function
'mpc5121_clk_provide_backwards_compat':
../arch/powerpc/platforms/512x/clock-commonclk.c:989:44: error: format '%x'
expects argument of type 'un
On Fri, Feb 17, 2023 at 9:27 AM Sean Christopherson wrote:
>
> On Thu, Feb 16, 2023, Yu Zhao wrote:
> > diff --git a/arch/x86/include/asm/kvm_host.h
> > b/arch/x86/include/asm/kvm_host.h
> > index 6aaae18f1854..d2995c9e8f07 100644
> > --- a/arch/x86/include/asm/kvm_host.h
> > +++ b/arch/x86/inclu
On Fri, Feb 17, 2023 at 9:00 AM Sean Christopherson wrote:
>
> On Fri, Feb 17, 2023, Oliver Upton wrote:
> > Hi Yu,
> >
> > scripts/get_maintainers.pl is your friend for getting the right set of
> > emails for a series :) Don't know about others, but generally I would
> > prefer to be Cc'ed on an
Murphy Zhou writes:
> On Wed, Feb 22, 2023 at 10:35 AM Bagas Sanjaya wrote:
>> On 2/22/23 07:55, Murphy Zhou wrote:
>> > [ 59.558339] [ cut here ]
>> > [ 59.558361] kernel BUG at arch/powerpc/kernel/syscall.c:34!
>> > [ 59.558373] Oops: Exception in kernel mode, sig:
Hi Sathvika,
>
> Just one question though. Went through the code again and I think
> that this place shouldn't be proper to insert a SYM_FUNC_END
> because we haven't entered the guest at this point and the name
> of the function is kvmppc_hv_entry which I think implies that
> this SYM_FUNC_END s
On Fri, Feb 17, 2023 at 2:09 AM Oliver Upton wrote:
>
> Hi Yu,
>
> scripts/get_maintainers.pl is your friend for getting the right set of
> emails for a series :) Don't know about others, but generally I would
> prefer to be Cc'ed on an entire series (to gather context) than just an
> individual p
> You are correct, the patch is wrong because it fails to account for IO
> accesses.
Okay, I looked at the PowerPC ISA and found:
"The memory barrier provides an ordering function for the storage accesses
caused by Load, Store,and dcbz instructions that are executed by the processor
executing th
Nathan Chancellor writes:
> On Wed, Feb 22, 2023 at 05:00:37PM +1100, Michael Ellerman wrote:
>> When KASAN/KCSAN are enabled clang generates .text.asan/tsan sections.
>> Because they are not mentioned in the linker script warnings are
>> generated, and when orphan handling is set to error that be
On 2023-02-22 20:16:10, Paul E. McKenney wrote:
> On Thu, Feb 23, 2023 at 09:31:48AM +0530, Kautuk Consul wrote:
> > On 2023-02-22 09:47:19, Paul E. McKenney wrote:
> > > On Wed, Feb 22, 2023 at 02:33:44PM +0530, Kautuk Consul wrote:
> > > > A link from ibm.com states:
> > > > "Ensures that all ins
On Thu, Feb 23, 2023 at 09:31:48AM +0530, Kautuk Consul wrote:
> On 2023-02-22 09:47:19, Paul E. McKenney wrote:
> > On Wed, Feb 22, 2023 at 02:33:44PM +0530, Kautuk Consul wrote:
> > > A link from ibm.com states:
> > > "Ensures that all instructions preceding the call to __lwsync
> > > complete b
On 2023-02-23 14:51:25, Michael Ellerman wrote:
> Hi Paul,
>
> "Paul E. McKenney" writes:
> > On Wed, Feb 22, 2023 at 02:33:44PM +0530, Kautuk Consul wrote:
> >> A link from ibm.com states:
> >> "Ensures that all instructions preceding the call to __lwsync
> >> complete before any subsequent sto
On 2023-02-22 09:47:19, Paul E. McKenney wrote:
> On Wed, Feb 22, 2023 at 02:33:44PM +0530, Kautuk Consul wrote:
> > A link from ibm.com states:
> > "Ensures that all instructions preceding the call to __lwsync
> > complete before any subsequent store instructions can be executed
> > on the proce
On Fri, Feb 17, 2023 at 2:00 AM Marc Zyngier wrote:
>
> On Fri, 17 Feb 2023 04:21:28 +,
> Yu Zhao wrote:
> >
> > On Thu, Feb 16, 2023 at 9:12 PM Yu Zhao wrote:
> > >
> > > This patch adds kvm_arch_test_clear_young() for the vast majority of
> > > VMs that are not pKVM and run on hardware tha
Hi Paul,
"Paul E. McKenney" writes:
> On Wed, Feb 22, 2023 at 02:33:44PM +0530, Kautuk Consul wrote:
>> A link from ibm.com states:
>> "Ensures that all instructions preceding the call to __lwsync
>> complete before any subsequent store instructions can be executed
>> on the processor that exec
LEDS_TRIGGER_DISK depends on ATA, so selecting LEDS_TRIGGER_DISK
when ATA is not set/enabled causes a Kconfig warning:
WARNING: unmet direct dependencies detected for LEDS_TRIGGER_DISK
Depends on [n]: NEW_LEDS [=y] && LEDS_TRIGGERS [=y] && ATA [=n]
Selected by [y]:
- ADB_PMU_LED_DISK [=y] &&
LEDS_TRIGGER_DISK depends on ATA, so selecting LEDS_TRIGGER_DISK
when ATA is not set/enabled causes a Kconfig warning:
WARNING: unmet direct dependencies detected for LEDS_TRIGGER_DISK
Depends on [n]: NEW_LEDS [=y] && LEDS_TRIGGERS [=y] && ATA [=n]
Selected by [y]:
- ADB_PMU_LED_DISK [=y] &&
On Wed, Feb 22, 2023 at 10:35 AM Bagas Sanjaya wrote:
>
> On 2/22/23 07:55, Murphy Zhou wrote:
> > Hi,
> >
> > [ 59.558339] [ cut here ]
> > [ 59.558361] kernel BUG at arch/powerpc/kernel/syscall.c:34!
> > [ 59.558373] Oops: Exception in kernel mode, sig: 5 [#1]
> > [
On Wed, 22 Feb 2023 00:42:48 +0100
Erhard Furtner wrote:
> Got this now the 2nd time in row on my G5 11.2 trying to copy a btrfs
> partition via gparted:
Also happens on kernel 6.1.12:
[...]
[ cut here ]
WARNING: CPU: 1 PID: 34 at arch/powerpc/kernel/exceptions-64s.S:28
On Wednesday 22 February 2023 15:42:47 Christophe Leroy 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.
>
>
> 2023年2月22日 17:24，Robin Murphy 写道：
[...]
>
> AFAICS, all you should actually need is a single self-contained addition
> here, something like:
>
> + /*
> + * DT-based MIPS doesn't use OF_DMA_DEFAULT_COHERENT, but
> + * might override the system-wide default at runtime.
> + */
> +#if def
On Wed, Feb 22, 2023 at 02:33:44PM +0530, Kautuk Consul wrote:
> A link from ibm.com states:
> "Ensures that all instructions preceding the call to __lwsync
> complete before any subsequent store instructions can be executed
> on the processor that executed the function. Also, it ensures that
>
On 2023-02-22 13:37, Jiaxun Yang wrote:
As for now all arches have dma_default_coherent matched with default
DMA coherency for of devices, so there is no need to have a standalone
config option.
This also fixes a case that for some MIPS platforms, coherency information
is not carried in devicetr
On Wed, Feb 22, 2023 at 05:00:37PM +1100, Michael Ellerman wrote:
> When KASAN/KCSAN are enabled clang generates .text.asan/tsan sections.
> Because they are not mentioned in the linker script warnings are
> generated, and when orphan handling is set to error that becomes a build
> error, eg:
>
>
On Wed, Jan 18, 2023 at 04:35:22PM +0100, Andrzej Hajda wrote:
> Andrzej Hajda (7):
> arch: rename all internal names __xchg to __arch_xchg
> linux/include: add non-atomic version of xchg
> arch/*/uprobes: simplify arch_uretprobe_hijack_return_addr
> llist: simplify __llist_del_all
> io_
On Wed, Feb 22, 2023 at 04:20:16PM +, Jiaxun Yang wrote:
> > 2023年2月22日 16:02，Conor Dooley 写道：
> > On Wed, Feb 22, 2023 at 03:55:19PM +, Jiaxun Yang wrote:
> >>> 2023年2月22日 14:50，Conor Dooley 写道：
> >>> On Wed, Feb 22, 2023 at 01:37:11PM +, Jiaxun Yang wrote:
> For riscv our assum
> 2023年2月22日 16:02，Conor Dooley 写道：
>
> On Wed, Feb 22, 2023 at 03:55:19PM +, Jiaxun Yang wrote:
>>
>>
>>> 2023年2月22日 14:50，Conor Dooley 写道：
>>>
>>> On Wed, Feb 22, 2023 at 01:37:11PM +, Jiaxun Yang wrote:
For riscv our assumption is unless a device states it is non-coherent,
On Wed, Feb 22, 2023 at 03:55:19PM +, Jiaxun Yang wrote:
>
>
> > 2023年2月22日 14:50，Conor Dooley 写道：
> >
> > On Wed, Feb 22, 2023 at 01:37:11PM +, Jiaxun Yang wrote:
> >> For riscv our assumption is unless a device states it is non-coherent,
> >> we take it to be DMA coherent.
> >>
> >>
> 2023年2月22日 14:50，Conor Dooley 写道：
>
> On Wed, Feb 22, 2023 at 01:37:11PM +, Jiaxun Yang wrote:
>> For riscv our assumption is unless a device states it is non-coherent,
>> we take it to be DMA coherent.
>>
>> For devicetree probed devices that have been true since very begining
>> with
On Wed, Feb 22, 2023 at 01:37:11PM +, Jiaxun Yang wrote:
> For riscv our assumption is unless a device states it is non-coherent,
> we take it to be DMA coherent.
>
> For devicetree probed devices that have been true since very begining
> with OF_DMA_DEFAULT_COHERENT selected.
>
> Signed-off-
mpc85xx_qe_par_io_init() is a stub when CONFIG_QUICC_ENGINE is not set.
CONFIG_UCC_GETH and CONFIG_SERIAL_QE depend on CONFIG_QUICC_ENGINE.
Remove #ifdef CONFIG_QUICC_ENGINE
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 2 --
1 file changed, 2 deletions(-)
di
From: Pali Rohár
This moves machine descriptions and all related code for all P2020 boards
into new p2020.c source file.
This is preparation for code de-duplication and
providing one unified machine description for all P2020 boards. In
follow-up patches would be copied functions refactored and si
From: Pali Rohár
Splits mpic and i8259 initialization codes into separate functions.
Use 'if (IS_ENABLED(CONFIG_PPC_I8259))' instead of '#ifdef CONFIG_PPC_I8259'.
Signed-off-by: Pali Rohár
[chleroy: Put into own C file]
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/85xx/Makefile
Reduce number of lines in the call to mpic_alloc().
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 18 ++
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 16 +---
2 files changed, 11 insertions(+), 23 deletions(-)
diff --git a/arch/powerp
From: Pali Rohár
In order to share between DS and P2020.
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/85xx/Makefile | 3 +-
arch/powerpc/platforms/85xx/mpc85xx.h | 6 +++
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 32
arch/powerpc/platforms/85xx/mpc85xx_u
From: Pali Rohár
Combine machine descriptions and code of all P2020 boards into just one
generic unified P2020 machine description. This allows kernel to boot on
any P2020-based board with P2020 DTS file without need to patch kernel and
define a new machine description in 85xx powerpc platform di
Avoid conflict with other functions, rename mpc85xx_rdb_setup_arch()
to p1023_rdb_setup_arch(), same for mpc85xx_rdb_pic_init().
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/85xx/p1023_rdb.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/pl
DBG() macro is defined at three places while used only
one time at one place.
Replace its only use by a pr_debug() and remove the macro.
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 10 +-
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 7 ---
arch/po
No need to BUG() in case mpic_alloc() fails. Use WARN_ON().
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 4 +++-
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 4 +++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85
From: Pali Rohár
Make just one .setup_arch and one .init_IRQ callback implementation for all
P2020 board code. This deduplicate repeated and same code.
Signed-off-by: Pali Rohár
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/85xx/mpc85xx.h | 5 ---
arch/powerpc/platforms/85xx
From: Pali Rohár
"fsl,P2020RDB-PC" compatible string was present in Turris 1.x DTS file just
because Linux kernel required it for proper detection of P2020 processor
during boot.
This was quite a hack as CZ.NIC Turris 1.x is not compatible with
Freescale P2020-RDB-PC board.
Now when kernel has
All necessary items are declared all the time, no need to use
a #ifdef CONFIG_PPC_I8259.
Refactor CONFIG_PPC_I8259 actions into a dedicated init function.
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 37 +---
1 file changed, 20 insertions(+)
Use a single line for uli_exclude_device()
Add uli_exclude_device() prototype in ppc-pci.h
Remove that prototype from mpc85xx_ds.c
Make uli_pirq_to_irq[] static as it is used only in that file.
Signed-off-by: Christophe Leroy
---
arch/powerpc/include/asm/ppc-pci.h | 2 ++
arch/powerpc/p
From: Pali Rohár
This moves machine descriptions and all related code for all P2020 boards
into new p2020.c source file.
This is preparation for code de-duplication and
providing one unified machine description for all P2020 boards. In
follow-up patches would be copied functions refactored and si
All necessary items are declared all the time, no need to use
a #ifdef CONFIG_PCI.
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/85xx/mpc85xx_ds.c
b/arch/powerpc/plat
From: Pali Rohár
Generic unified P2020 machine description which supports all P2020-based
boards is now in separate file p2020.c. So create a separate config option
CONFIG_PPC_P2020 for it.
Previously machine descriptions for P2020 boards were enabled by
CONFIG_MPC85xx_DS or CONFIG_MPC85xx_RDB o
Use pr_debug() instead of printk(KERN_DEBUG
Use pr_err() instead of printk(KERN_ERR
Use pr_info() instead of printk(KERN_INFO or printk("
Signed-off-by: Christophe Leroy
---
arch/powerpc/platforms/85xx/mpc85xx_ds.c | 6 +++---
arch/powerpc/platforms/85xx/mpc85xx_rdb.c | 2 +-
2 files changed, 4
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 CZ.NIC Turris 1.1 board with has Freescale P2020 processor.
Kerne
Le 22/02/2023 à 08:52, Pali Rohár a écrit :
> On Wednesday 22 February 2023 06:39:07 Christophe Leroy wrote:
>> Hi,
>>
>> Le 21/02/2023 à 23:07, Pali Rohár a écrit :
>>> Hello Christophe! Could you look at this v3 series?
>>> I addressed those small issues and hopefully it should be ready.
>>> It
On 2023-02-22 13:04, Jiaxun Yang wrote:
2023年2月22日 12:55，Robin Murphy 写道：
On 2023-02-21 19:55, Jiaxun Yang wrote:
2023年2月21日 19:46，Robin Murphy 写道：
On 2023-02-21 18:15, Jiaxun Yang wrote:
2023年2月21日 17:54，Christoph Hellwig 写道：
Can you explain the motivation here? Also why riscv patche
As for now all arches have dma_default_coherent matched with default
DMA coherency for of devices, so there is no need to have a standalone
config option.
This also fixes a case that for some MIPS platforms, coherency information
is not carried in devicetree and kernel will override dma_default_co
For riscv our assumption is unless a device states it is non-coherent,
we take it to be DMA coherent.
For devicetree probed devices that have been true since very begining
with OF_DMA_DEFAULT_COHERENT selected.
Signed-off-by: Jiaxun Yang
---
arch/riscv/kernel/setup.c | 3 +++
1 file changed, 3
dma_default_coherent was decleared unconditionally at kernel/dma/mapping.c
but only decleared when any of non-coherent options is enabled in dma-map-ops.h.
Guard the declaration in mapping.c with non-coherent options and provide
a fallback definition.
Signed-off-by: Jiaxun Yang
---
include/linu
Hi all,
This series split out second half of my previous series
"[PATCH 0/4] MIPS DMA coherence fixes".
It intends to use dma_default_coherent to determine the default coherency of
devicetree probed devices instead of hardcoding it with Kconfig options.
For some MIPS systems, dma_default_coheren
> 2023年2月22日 12:55，Robin Murphy 写道：
>
> On 2023-02-21 19:55, Jiaxun Yang wrote:
>>> 2023年2月21日 19:46，Robin Murphy 写道：
>>>
>>> On 2023-02-21 18:15, Jiaxun Yang wrote:
> 2023年2月21日 17:54，Christoph Hellwig 写道：
>
> Can you explain the motivation here? Also why riscv patches are at
On 2023-02-21 19:55, Jiaxun Yang wrote:
2023年2月21日 19:46，Robin Murphy 写道：
On 2023-02-21 18:15, Jiaxun Yang wrote:
2023年2月21日 17:54，Christoph Hellwig 写道：
Can you explain the motivation here? Also why riscv patches are at
the end of a mips fіxes series?
Ah sorry for any confusion.
So the
+cc linux-kbuild, llvm, Nathan, Nick
On 2/15/23 15:36, Alexandre Ghiti wrote:
From: Alexandre Ghiti
This config allows to compile 64b kernel as PIE and to relocate it at
any virtual address at runtime: this paves the way to KASLR.
Runtime relocation is possible since relocation metadata are em
On 2/22/23 16:13, Murphy Zhou wrote:
> next-20230221
>
> I'll try powerpc/next.
>
OK, but next time when you reply, don't top-post; reply inline
with appropriate context instead.
--
An old man doll... just what I always wanted! - Clara
Hi,
Ping on the series.
Arnd, Andrew is there anything more I can do to push the process forward?
Regards
Andrzej
On 18.01.2023 16:35, Andrzej Hajda wrote:
Hi all,
The helper is tiny and there are advices we can live without it, so
I want to present few arguments why it would be good to have
> >> I'd have preferred with 'asm volatile' though.
> > Sorry about that! That wasn't the intent of this patch.
> > Probably another patch series should change this manner of #defining
> > assembly.
>
> Why adding new line wrong then have to have another patch to make them
> right ?
>
> When you
Le 22/02/2023 à 10:46, Kautuk Consul a écrit :
>>
>> Reviewed-by: Christophe Leroy
> Thanks!
>>
>>> ---
>>>arch/powerpc/include/asm/barrier.h | 7 +++
>>>1 file changed, 7 insertions(+)
>>>
>>> diff --git a/arch/powerpc/include/asm/barrier.h
>>> b/arch/powerpc/include/asm/barrier.h
>
On Wed, Feb 22, 2023 at 09:44:54AM +, Christophe Leroy wrote:
>
>
> Le 22/02/2023 à 10:30, Kautuk Consul a écrit :
> > Again, could some IBM/non-IBM employees do basic sanity kernel load
> > testing on PPC64 UP and SMP systems for this patch?
> > would deeply appreciate it! :-)
>
> And can '
>
> Reviewed-by: Christophe Leroy
Thanks!
>
> > ---
> > arch/powerpc/include/asm/barrier.h | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/arch/powerpc/include/asm/barrier.h
> > b/arch/powerpc/include/asm/barrier.h
> > index b95b666f0374..e088dacc0ee8 100644
> > --- a/
Le 22/02/2023 à 10:30, Kautuk Consul a écrit :
> Again, could some IBM/non-IBM employees do basic sanity kernel load
> testing on PPC64 UP and SMP systems for this patch?
> would deeply appreciate it! :-)
And can 'non-IBM' 'non employees' do something ? :)
>
> Thanks again!
>
Did you try on
Le 22/02/2023 à 10:03, Kautuk Consul a écrit :
> A link from ibm.com states:
> "Ensures that all instructions preceding the call to __lwsync
> complete before any subsequent store instructions can be executed
> on the processor that executed the function. Also, it ensures that
> all load in
Again, could some IBM/non-IBM employees do basic sanity kernel load
testing on PPC64 UP and SMP systems for this patch?
would deeply appreciate it! :-)
Thanks again!
next-20230221
I'll try powerpc/next.
On Wed, Feb 22, 2023 at 10:35 AM Bagas Sanjaya wrote:
>
> On 2/22/23 07:55, Murphy Zhou wrote:
> > Hi,
> >
> > [ 59.558339] [ cut here ]
> > [ 59.558361] kernel BUG at arch/powerpc/kernel/syscall.c:34!
> > [ 59.558373] Oops: Exce
Sorry, sent the wrong patch!
Please ignore this one.
Sending the v2 in another email.
On Wed, Feb 22, 2023 at 02:31:12PM +0530, Kautuk Consul wrote:
> A link from ibm.com states:
> "Ensures that all instructions preceding the call to __lwsync
> complete before any subsequent store instructions ca
A link from ibm.com states:
"Ensures that all instructions preceding the call to __lwsync
complete before any subsequent store instructions can be executed
on the processor that executed the function. Also, it ensures that
all load instructions preceding the call to __lwsync complete before
any
A link from ibm.com states:
"Ensures that all instructions preceding the call to __lwsync
complete before any subsequent store instructions can be executed
on the processor that executed the function. Also, it ensures that
all load instructions preceding the call to __lwsync complete before
any
> No, I don't mean to use the existing #ifdef/elif/else.
>
> Define an #ifdef /#else dedicated to xmb macros.
>
> Something like that:
>
> @@ -35,9 +35,15 @@
>* However, on CPUs that don't support lwsync, lwsync actually maps to a
>* heavy-weight sync, so smp_wmb() can be a lighter-wei
Le 22/02/2023 à 09:16, Kautuk Consul a écrit :
> On Wed, Feb 22, 2023 at 07:02:34AM +, Christophe Leroy wrote:
>>
>>
>> Le 22/02/2023 à 07:01, Kautuk Consul a écrit :
>>> A link from ibm.com states:
>>> "Ensures that all instructions preceding the call to __lwsync
>>>complete before any s
On Wed, Feb 22, 2023 at 08:28:19AM +, Christophe Leroy wrote:
>
>
> Le 22/02/2023 à 09:21, Kautuk Consul a écrit :
> >> On Wed, Feb 22, 2023 at 07:02:34AM +, Christophe Leroy wrote:
> +/* Redefine rmb() to lwsync. */
> >>>
> >>> WHat's the added value of this comment ? Isn't it obvio
Le 22/02/2023 à 09:21, Kautuk Consul a écrit :
>> On Wed, Feb 22, 2023 at 07:02:34AM +, Christophe Leroy wrote:
+/* Redefine rmb() to lwsync. */
>>>
>>> WHat's the added value of this comment ? Isn't it obvious in the line
>>> below that rmb() is being defined to lwsync ? Please avoid us
> On Wed, Feb 22, 2023 at 07:02:34AM +, Christophe Leroy wrote:
> > > +/* Redefine rmb() to lwsync. */
> >
> > WHat's the added value of this comment ? Isn't it obvious in the line
> > below that rmb() is being defined to lwsync ? Please avoid useless comments.
> Sure.
Sorry, forgot to add th
On Wed, Feb 22, 2023 at 07:02:34AM +, Christophe Leroy wrote:
>
>
> Le 22/02/2023 à 07:01, Kautuk Consul a écrit :
> > A link from ibm.com states:
> > "Ensures that all instructions preceding the call to __lwsync
> > complete before any subsequent store instructions can be executed
> > on
79 matches
Mail list logo
