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
> 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
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 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: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
> 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
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
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
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
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!
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
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
>
> 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/
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 '
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
>
> >> 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
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
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
+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 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
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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(+)
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
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
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
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
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
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
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
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
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
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
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
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-
> 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 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日 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 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
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 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 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 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
>
> 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 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.
>
>
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 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]
> > [
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] &&
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
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
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 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 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-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
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
> 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
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
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
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:
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
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
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
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 '
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 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'
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
79 matches
Mail list logo
