* Re: [PATCH v2 10/45] drivers: tty: serial: zs: use devm_* functions
From: Greg KH @ 2019-03-15 14:26 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: linux-arm-msm, yamada.masahiro, macro, jacmet, festevam,
stefan.wahren, f.fainelli, bcm-kernel-feedback-list, linux-imx,
linux-serial, slemieux.tyco, andy.gross, tklauser, david.brown,
rjui, s.hauer, u.kleine-koenig, linuxppc-dev, vz, matthias.bgg,
andriy.shevchenko, baohua, sbranden, eric, richard.genoud,
Enrico Weigelt, metux IT consult, linux-kernel, kernel, shawnguo
In-Reply-To: <3734d588-6b9c-29e2-45b6-82e778f47602@metux.net>
On Fri, Mar 15, 2019 at 10:06:16AM +0100, Enrico Weigelt, metux IT consult wrote:
> On 14.03.19 23:52, Greg KH wrote:
> > On Thu, Mar 14, 2019 at 11:33:40PM +0100, Enrico Weigelt, metux IT consult wrote:
> >> Use the safer devm versions of memory mapping functions.
> >
> > What is "safer" about them?
>
> Garbage collection :)
At times, but not when you do not use the api correctly :)
> Several drivers didn't seem to clean up properly (maybe these're just
> used compiled-in, so nobody noticed yet).
Yes, there are lots of drivers for devices that are never unloaded or
removed from the system. The fact that no one has reported any problems
with them means that they are never used in situations like this.
> In general, I think devm_* should be the standard case, unless there's
> a really good reason to do otherwise.
No, you need to have a good reason why it needs to be changed, when you
can not verify that this actually resolves a problem. As this patch
shows, you just replaced one api call with another, so nothing changed
at all, except you actually took up more memory and logic to do the same
thing :(
> > Isn't the whole goal of the devm* functions such that you are not
> > required to call "release" on them?
>
> Looks that one slipped through, when I was doing that big bulk change
> in the middle of the night and not enough coffe ;-)
>
> One problem here is that many drivers do this stuff in request/release
> port, instead of probe/remove. I'm not sure yet, whether we should
> rewrite that. There're also cases which do request/release, but no
> ioremap (doing hardcoded register accesses), others do ioremap w/o
> request/release.
>
> IMHO, we should have a closer look at those and check whether that's
> really okay (just adding request/release blindly could cause trouble)
I agree, please feel free to audit these to verify they are all correct.
But that's not what you did here, so that's not a valid justification
for these patches to be accepted.
> > And also, why make the change, you aren't changing any functionality for
> > these old drivers at all from what I can tell (for the devm calls).
> > What am I missing here?
>
> Okay, there's a bigger story behind, you can't know yet. Finally, I'd
> like to move everything to using struct resource and corresponding
> helpers consistently, so most of the drivers would be pretty simple
> at that point. (there're of course special cases, like devices w/
> multiple register spaces, etc)
>
> Here's my wip branch:
>
> https://github.com/metux/linux/commits/wip/serial-res
>
> In this consolidation process, I'm trying to move everything to
> devm_*, to have it more generic (for now, I still need two versions
> of the request/release/ioremap/iounmap helpers - one w/ and one
> w/o devm).
Move everything in what part of the kernel? The whole kernel or just
one subsystem?
> My idea was moving to devm first, so it can be reviewed/tested
> independently, before moving forward. Smaller, easily digestable
> pieces should minimize the risk of breaking anything. But if you
> prefer having this things squashed together, just let me know.
Small pieces are required, that's fine, but those pieces need to have a
justification for why they should be accepted at all points along the
way.
> In the queue are also other minor cleanups like using dev_err()
> instead of printk(), etc. Should I send these separately ?
Of course.
> By the way: do you have some public branch where you're collecting
> accepted patches, which I could base mine on ? (tty.git/tty-next ?)
Yes, that is the tree and branch, but remember that none of my trees can
open up until after -rc1 is out.
thanks,
greg k-h
^ permalink raw reply
* [PATCH] powerpc: bpf: Fix generation of load/store DW instructions
From: Naveen N. Rao @ 2019-03-15 14:51 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Yauheni Kaliuta
Cc: bpf, linuxppc-dev, netdev
Yauheni Kaliuta pointed out that PTR_TO_STACK store/load verifier test
was failing on powerpc64 BE, and rightfully indicated that the PPC_LD()
macro is not masking away the last two bits of the offset per the ISA,
resulting in the generation of 'lwa' instruction instead of the intended
'ld' instruction.
Segher also pointed out that we can't simply mask away the last two bits
as that will result in loading/storing from/to a memory location that
was not intended.
This patch addresses this by using ldx/stdx if the offset is not
word-aligned. We load the offset into a temporary register (TMP_REG_2)
and use that as the index register in a subsequent ldx/stdx. We fix
PPC_LD() macro to mask off the last two bits, but enhance PPC_BPF_LL()
and PPC_BPF_STL() to factor in the offset value and generate the proper
instruction sequence. We also convert all existing users of PPC_LD() and
PPC_STD() to use these macros. All existing uses of these macros have
been audited to ensure that TMP_REG_2 can be clobbered.
Fixes: 156d0e290e96 ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF")
Cc: stable@vger.kernel.org # v4.9+
Reported-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/ppc-opcode.h | 2 ++
arch/powerpc/net/bpf_jit.h | 17 +++++------------
arch/powerpc/net/bpf_jit32.h | 4 ++++
arch/powerpc/net/bpf_jit64.h | 20 ++++++++++++++++++++
arch/powerpc/net/bpf_jit_comp64.c | 12 ++++++------
5 files changed, 37 insertions(+), 18 deletions(-)
diff --git a/arch/powerpc/include/asm/ppc-opcode.h b/arch/powerpc/include/asm/ppc-opcode.h
index c5698a523bb1..23f7ed796f38 100644
--- a/arch/powerpc/include/asm/ppc-opcode.h
+++ b/arch/powerpc/include/asm/ppc-opcode.h
@@ -302,6 +302,7 @@
/* Misc instructions for BPF compiler */
#define PPC_INST_LBZ 0x88000000
#define PPC_INST_LD 0xe8000000
+#define PPC_INST_LDX 0x7c00002a
#define PPC_INST_LHZ 0xa0000000
#define PPC_INST_LWZ 0x80000000
#define PPC_INST_LHBRX 0x7c00062c
@@ -309,6 +310,7 @@
#define PPC_INST_STB 0x98000000
#define PPC_INST_STH 0xb0000000
#define PPC_INST_STD 0xf8000000
+#define PPC_INST_STDX 0x7c00012a
#define PPC_INST_STDU 0xf8000001
#define PPC_INST_STW 0x90000000
#define PPC_INST_STWU 0x94000000
diff --git a/arch/powerpc/net/bpf_jit.h b/arch/powerpc/net/bpf_jit.h
index 549e9490ff2a..dcac37745b05 100644
--- a/arch/powerpc/net/bpf_jit.h
+++ b/arch/powerpc/net/bpf_jit.h
@@ -51,6 +51,8 @@
#define PPC_LIS(r, i) PPC_ADDIS(r, 0, i)
#define PPC_STD(r, base, i) EMIT(PPC_INST_STD | ___PPC_RS(r) | \
___PPC_RA(base) | ((i) & 0xfffc))
+#define PPC_STDX(r, base, b) EMIT(PPC_INST_STDX | ___PPC_RS(r) | \
+ ___PPC_RA(base) | ___PPC_RB(b))
#define PPC_STDU(r, base, i) EMIT(PPC_INST_STDU | ___PPC_RS(r) | \
___PPC_RA(base) | ((i) & 0xfffc))
#define PPC_STW(r, base, i) EMIT(PPC_INST_STW | ___PPC_RS(r) | \
@@ -65,7 +67,9 @@
#define PPC_LBZ(r, base, i) EMIT(PPC_INST_LBZ | ___PPC_RT(r) | \
___PPC_RA(base) | IMM_L(i))
#define PPC_LD(r, base, i) EMIT(PPC_INST_LD | ___PPC_RT(r) | \
- ___PPC_RA(base) | IMM_L(i))
+ ___PPC_RA(base) | ((i) & 0xfffc))
+#define PPC_LDX(r, base, b) EMIT(PPC_INST_LDX | ___PPC_RT(r) | \
+ ___PPC_RA(base) | ___PPC_RB(b))
#define PPC_LWZ(r, base, i) EMIT(PPC_INST_LWZ | ___PPC_RT(r) | \
___PPC_RA(base) | IMM_L(i))
#define PPC_LHZ(r, base, i) EMIT(PPC_INST_LHZ | ___PPC_RT(r) | \
@@ -85,17 +89,6 @@
___PPC_RA(a) | ___PPC_RB(b))
#define PPC_BPF_STDCX(s, a, b) EMIT(PPC_INST_STDCX | ___PPC_RS(s) | \
___PPC_RA(a) | ___PPC_RB(b))
-
-#ifdef CONFIG_PPC64
-#define PPC_BPF_LL(r, base, i) do { PPC_LD(r, base, i); } while(0)
-#define PPC_BPF_STL(r, base, i) do { PPC_STD(r, base, i); } while(0)
-#define PPC_BPF_STLU(r, base, i) do { PPC_STDU(r, base, i); } while(0)
-#else
-#define PPC_BPF_LL(r, base, i) do { PPC_LWZ(r, base, i); } while(0)
-#define PPC_BPF_STL(r, base, i) do { PPC_STW(r, base, i); } while(0)
-#define PPC_BPF_STLU(r, base, i) do { PPC_STWU(r, base, i); } while(0)
-#endif
-
#define PPC_CMPWI(a, i) EMIT(PPC_INST_CMPWI | ___PPC_RA(a) | IMM_L(i))
#define PPC_CMPDI(a, i) EMIT(PPC_INST_CMPDI | ___PPC_RA(a) | IMM_L(i))
#define PPC_CMPW(a, b) EMIT(PPC_INST_CMPW | ___PPC_RA(a) | \
diff --git a/arch/powerpc/net/bpf_jit32.h b/arch/powerpc/net/bpf_jit32.h
index dc50a8d4b3b9..21744d8aa053 100644
--- a/arch/powerpc/net/bpf_jit32.h
+++ b/arch/powerpc/net/bpf_jit32.h
@@ -122,6 +122,10 @@ DECLARE_LOAD_FUNC(sk_load_byte_msh);
#define PPC_NTOHS_OFFS(r, base, i) PPC_LHZ_OFFS(r, base, i)
#endif
+#define PPC_BPF_LL(r, base, i) do { PPC_LWZ(r, base, i); } while(0)
+#define PPC_BPF_STL(r, base, i) do { PPC_STW(r, base, i); } while(0)
+#define PPC_BPF_STLU(r, base, i) do { PPC_STWU(r, base, i); } while(0)
+
#define SEEN_DATAREF 0x10000 /* might call external helpers */
#define SEEN_XREG 0x20000 /* X reg is used */
#define SEEN_MEM 0x40000 /* SEEN_MEM+(1<<n) = use mem[n] for temporary
diff --git a/arch/powerpc/net/bpf_jit64.h b/arch/powerpc/net/bpf_jit64.h
index 3609be4692b3..47f441f351a6 100644
--- a/arch/powerpc/net/bpf_jit64.h
+++ b/arch/powerpc/net/bpf_jit64.h
@@ -68,6 +68,26 @@ static const int b2p[] = {
/* PPC NVR range -- update this if we ever use NVRs below r27 */
#define BPF_PPC_NVR_MIN 27
+/*
+ * WARNING: These can use TMP_REG_2 if the offset is not at word boundary,
+ * so ensure that it isn't in use already.
+ */
+#define PPC_BPF_LL(r, base, i) do { \
+ if ((i) % 4) { \
+ PPC_LI(b2p[TMP_REG_2], (i)); \
+ PPC_LDX(r, base, b2p[TMP_REG_2]); \
+ } else \
+ PPC_LD(r, base, i); \
+ } while(0)
+#define PPC_BPF_STL(r, base, i) do { \
+ if ((i) % 4) { \
+ PPC_LI(b2p[TMP_REG_2], (i)); \
+ PPC_STDX(r, base, b2p[TMP_REG_2]); \
+ } else \
+ PPC_STD(r, base, i); \
+ } while(0)
+#define PPC_BPF_STLU(r, base, i) do { PPC_STDU(r, base, i); } while(0)
+
#define SEEN_FUNC 0x1000 /* might call external helpers */
#define SEEN_STACK 0x2000 /* uses BPF stack */
#define SEEN_TAILCALL 0x4000 /* uses tail calls */
diff --git a/arch/powerpc/net/bpf_jit_comp64.c b/arch/powerpc/net/bpf_jit_comp64.c
index 4194d3cfb60c..21a1dcd4b156 100644
--- a/arch/powerpc/net/bpf_jit_comp64.c
+++ b/arch/powerpc/net/bpf_jit_comp64.c
@@ -252,7 +252,7 @@ static void bpf_jit_emit_tail_call(u32 *image, struct codegen_context *ctx, u32
* if (tail_call_cnt > MAX_TAIL_CALL_CNT)
* goto out;
*/
- PPC_LD(b2p[TMP_REG_1], 1, bpf_jit_stack_tailcallcnt(ctx));
+ PPC_BPF_LL(b2p[TMP_REG_1], 1, bpf_jit_stack_tailcallcnt(ctx));
PPC_CMPLWI(b2p[TMP_REG_1], MAX_TAIL_CALL_CNT);
PPC_BCC(COND_GT, out);
@@ -265,7 +265,7 @@ static void bpf_jit_emit_tail_call(u32 *image, struct codegen_context *ctx, u32
/* prog = array->ptrs[index]; */
PPC_MULI(b2p[TMP_REG_1], b2p_index, 8);
PPC_ADD(b2p[TMP_REG_1], b2p[TMP_REG_1], b2p_bpf_array);
- PPC_LD(b2p[TMP_REG_1], b2p[TMP_REG_1], offsetof(struct bpf_array, ptrs));
+ PPC_BPF_LL(b2p[TMP_REG_1], b2p[TMP_REG_1], offsetof(struct bpf_array, ptrs));
/*
* if (prog == NULL)
@@ -275,7 +275,7 @@ static void bpf_jit_emit_tail_call(u32 *image, struct codegen_context *ctx, u32
PPC_BCC(COND_EQ, out);
/* goto *(prog->bpf_func + prologue_size); */
- PPC_LD(b2p[TMP_REG_1], b2p[TMP_REG_1], offsetof(struct bpf_prog, bpf_func));
+ PPC_BPF_LL(b2p[TMP_REG_1], b2p[TMP_REG_1], offsetof(struct bpf_prog, bpf_func));
#ifdef PPC64_ELF_ABI_v1
/* skip past the function descriptor */
PPC_ADDI(b2p[TMP_REG_1], b2p[TMP_REG_1],
@@ -606,7 +606,7 @@ static int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
* the instructions generated will remain the
* same across all passes
*/
- PPC_STD(dst_reg, 1, bpf_jit_stack_local(ctx));
+ PPC_BPF_STL(dst_reg, 1, bpf_jit_stack_local(ctx));
PPC_ADDI(b2p[TMP_REG_1], 1, bpf_jit_stack_local(ctx));
PPC_LDBRX(dst_reg, 0, b2p[TMP_REG_1]);
break;
@@ -662,7 +662,7 @@ static int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
PPC_LI32(b2p[TMP_REG_1], imm);
src_reg = b2p[TMP_REG_1];
}
- PPC_STD(src_reg, dst_reg, off);
+ PPC_BPF_STL(src_reg, dst_reg, off);
break;
/*
@@ -709,7 +709,7 @@ static int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
break;
/* dst = *(u64 *)(ul) (src + off) */
case BPF_LDX | BPF_MEM | BPF_DW:
- PPC_LD(dst_reg, src_reg, off);
+ PPC_BPF_LL(dst_reg, src_reg, off);
break;
/*
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] powerpc: use $(origin ARCH) to select KBUILD_DEFCONFIG
From: Masahiro Yamada @ 2019-03-15 15:25 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Mathieu Malaterre, Paul Mackerras, linuxppc-dev, LKML
In-Reply-To: <87y35i9osc.fsf@concordia.ellerman.id.au>
On Thu, Mar 14, 2019 at 11:27 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
>
> Mathieu Malaterre <malat@debian.org> writes:
> > On Sat, Feb 16, 2019 at 3:26 AM Masahiro Yamada
> > <yamada.masahiro@socionext.com> wrote:
> >>
> >> On Sat, Feb 16, 2019 at 1:11 AM Mathieu Malaterre <malat@debian.org> wrote:
> >> >
> >> > On Fri, Feb 15, 2019 at 10:41 AM Masahiro Yamada
> >> > <yamada.masahiro@socionext.com> wrote:
> >> > >
> >> > > I often test all Kconfig commands for all architectures. To ease my
> >> > > workflow, I want 'make defconfig' at least working without any cross
> >> > > compiler.
> >> > >
> >> > > Currently, arch/powerpc/Makefile checks CROSS_COMPILE to decide the
> >> > > default defconfig source.
> >> > >
> >> > > If CROSS_COMPILE is unset, it is likely to be the native build, so
> >> > > 'uname -m' is useful to choose the defconfig. If CROSS_COMPILE is set,
> >> > > the user is cross-building (i.e. 'uname -m' is probably x86_64), so
> >> > > it falls back to ppc64_defconfig. Yup, make sense.
> >> > >
> >> > > However, I want to run 'make ARCH=* defconfig' without setting
> >> > > CROSS_COMPILE for each architecture.
> >> > >
> >> > > My suggestion is to check $(origin ARCH).
> >> > >
> >> > > When you cross-compile the kernel, you need to set ARCH from your
> >> > > environment or from the command line.
> >> > >
> >> > > For the native build, you do not need to set ARCH. The default in
> >> > > the top Makefile is used:
> >> > >
> >> > > ARCH ?= $(SUBARCH)
> >> > >
> >> > > Hence, $(origin ARCH) returns 'file'.
> >> > >
> >> > > Before this commit, 'make ARCH=powerpc defconfig' failed:
> >> >
> >> > In case you have not seen it, please check:
> >> >
> >> > http://patchwork.ozlabs.org/patch/1037835/
> >>
> >> I did not know that because I do not subscribe to ppc ML.
> >>
> >> Michael's patch looks good to me.
> >
> > OK
> >
> >>
> >> If you mimic x86, the following will work:
> >>
> >
> > Nice! Michael do you have a preference ?
>
> Yeah I don't like playing games with ARCH. Doing so means auto builders
> and other build scripts need to learn about the special rules for ARCH,
> which is a pain.
>
> So I'll merge my patch, which I think will also work for Masahiro's
> case.
>
> cheers
Yes, works for me.
Thanks!
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: Mac Mini G4 hang on boot with git master
From: Mathieu Malaterre @ 2019-03-15 16:18 UTC (permalink / raw)
To: Mark Cave-Ayland; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <cf3327d8-3e04-2f37-4734-5525a5b638b2@ilande.co.uk>
Mark,
On Fri, Mar 15, 2019 at 3:08 PM Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> wrote:
>
> Hi all,
>
> I've just done a git pull and rebuilt master on my Mac Mini G4 in order to test
> Michael's merge of my KVM PR fix, and unfortunately my kernel now hangs on boot :(
Ouch :(
> My last working git checkout was somewhere around the 5.0-rc stage, so I suspect it's
> something that's been merged for 5.1.
OK. My last kernel is also somewhere around here on same hardware.
> The hang occurs just after the boot console is disabled which makes me wonder if
> something is going wrong during PCI bus enumeration. Does anyone have an idea as to
> what may be causing this? I can obviously bisect it down, but on slow hardware it can
> take some time...
When doing git bisect I compile from my amd64 machine using:
make O=g4 ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- my_defconfig
make -j8 O=g4 ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- bindeb-pkg
scp *image*.deb macminig4:
On Debian simply install:
# apt-get install crossbuild-essential-powerpc
>
> ATB,
>
> Mark.
^ permalink raw reply
* Re: [RFC/WIP] powerpc: Fix 32-bit handling of MSR_EE on exceptions
From: Christophe Leroy @ 2019-03-15 17:10 UTC (permalink / raw)
To: Michael Ellerman, Benjamin Herrenschmidt,
linuxppc-dev@lists.ozlabs.org
Cc: Diana Craciun, Scott Wood, Nick Piggin, Laurentiu Tudor
In-Reply-To: <87pns6mtqe.fsf@concordia.ellerman.id.au>
On 02/05/2019 10:10 AM, Michael Ellerman wrote:
> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>> Le 20/12/2018 à 23:35, Benjamin Herrenschmidt a écrit :
>>>
>>>>> /*
>>>>> * MSR_KERNEL is > 0x10000 on 4xx/Book-E since it include MSR_CE.
>>>>> @@ -205,20 +208,46 @@ transfer_to_handler_cont:
>>>>> mflr r9
>>>>> lwz r11,0(r9) /* virtual address of handler */
>>>>> lwz r9,4(r9) /* where to go when done */
>>>>> +#if defined(CONFIG_PPC_8xx) && defined(CONFIG_PERF_EVENTS)
>>>>> + mtspr SPRN_NRI, r0
>>>>> +#endif
>>>>
>>>> That's not part of your patch, it's already in the tree.
>>>
>>> Yup rebase glitch.
>>>
>>> .../...
>>>
>>>> I tested it on the 8xx with the below changes in addition. No issue seen
>>>> so far.
>>>
>>> Thanks !
>>>
>>> I'll merge that in.
>>
>> I'm currently working on a refactorisation and simplification of
>> exception and syscall entry on ppc32.
>>
>> I plan to take your patch in my serie as it helps quite a bit. I hope
>> you don't mind. I expect to come out with a series this week.
>
> Ben's AFK so go ahead and pull it in to your series if that helps you.
>
>>> The main obscure area is that business with the irqsoff tracer and thus
>>> the need to create stack frames around calls to trace_hardirqs_* ... we
>>> do it in some places and not others, but I've not managed to make it
>>> crash either. I need to get to the bottom of that, and possibly provide
>>> proper macro helpers like ppc64 has to do it.
>>
>> I can't see anything special around this in ppc32 code. As far as I
>> understand, a stack frame is put in place when there is a need to
>> save and restore some volatile registers. At the places where nothing
>> needs to be saved, nothing is done. I think that's the normal way for
>> any function call, isn't it ?
>
> The concern was that the irqsoff tracer was doing
> __builtin_return_address(1) (or some number > 0) and that crashes if
> there aren't sufficiently many stack frames available.
>
> See ftrace_return_address.
>
> Possibly the answer is that we don't have CONFIG_FRAME_POINTER and so we
> get the empty version of that.
>
Yes indeed, ftrace_return_address(1) is not __builtin_return_address(1)
but 0ul as CONFIG_FRAME_POINTER is not defined. So the crash can't be
due to that as it would then crash regardless of whether we set a stack
frame or not.
And anyway, as far as I understand, if the stack is properly
initialised, __builtin_return_address(X) returns NULL and don't crash
when the top of backtrace is reached.
Do you have more details about the said crash ? I think we should file
an issue for it in our issue databse.
For the time being, I'll get rid of that unneccessary stack frame in
entry_32.S as part of my syscall prolog optimising series.
Christophe
^ permalink raw reply
* Re: [PATCH v2 15/16] KVM: introduce a KVM_DESTROY_DEVICE ioctl
From: Paolo Bonzini @ 2019-03-15 17:57 UTC (permalink / raw)
To: Cédric Le Goater, David Gibson
Cc: kvm, kvm-ppc, Paul Mackerras, linuxppc-dev
In-Reply-To: <da4d5f04-87d9-1202-72e1-16cfed972d5e@kaod.org>
On 13/03/19 09:02, Cédric Le Goater wrote:
> The 'destroy' method is currently used to destroy all devices when the
> VM is destroyed after the vCPUs have been freed.
>
> This new KVM ioctl exposes the same KVM device method. It acts as a
> software reset of the VM to 'destroy' selected devices when necessary
> and perform the required cleanups on the vCPUs. Called with the
> kvm->lock.
>
> The 'destroy' method could be improved by returning an error code.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Looks good to me.
Paolo
^ permalink raw reply
* Re: serial driver cleanups v2
From: Andy Shevchenko @ 2019-03-15 18:11 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: linux-arm-msm, Masahiro Yamada, macro, Peter Korsgaard,
Fabio Estevam, Stefan Wahren, Florian Fainelli,
bcm-kernel-feedback-list, dl-linux-imx, open list:SERIAL DRIVERS,
Uwe Kleine-König, Andy Gross, Tobias Klauser, David Brown,
Ray Jui, Sascha Hauer, slemieux.tyco,
open list:LINUX FOR POWERPC PA SEMI PWRFICIENT,
Vladimir Zapolskiy, Matthias Brugger,
Enrico Weigelt, metux IT consult, baohua, Scott Branden,
Eric Anholt, Richard Genoud, Greg Kroah-Hartman,
Linux Kernel Mailing List, Sascha Hauer, Shawn Guo
In-Reply-To: <afc51d27-3312-cdf4-68a5-4486db1d006b@metux.net>
On Fri, Mar 15, 2019 at 11:36:04AM +0100, Enrico Weigelt, metux IT consult wrote:
> On 15.03.19 10:12, Andy Shevchenko wrote:
>
> >> Part II will be about moving the mmio range from mapbase and
> >> mapsize (which are used quite inconsistently) to a struct resource
> >> and using helpers for that. But this one isn't finished yet.
> >> (if somebody likes to have a look at it, I can send it, too)
> >
> > Let's do that way you are preparing a branch somewhere and anounce
> > here as an RFC, since this was neither tested nor correct.
>
> Okay, here it is:
>
> I. https://github.com/metux/linux/tree/submit/serial-clean-v3
> --> general cleanups, as basis for II
>
> II. https://github.com/metux/linux/tree/wip/serial-res
> --> moving towards using struct resource consistently
>
> III. https://github.com/metux/linux/tree/hack/serial
> --> the final steps, which are yet completely broken
> (more a notepad for things still to do :o)
>
> The actual goal is generalizing the whole iomem handling, so individual
> usually just need to call some helpers that do most of the things.
> Finally, I also wanted to have all io region information consolidated
> in struct resource.
That's should be a selling point, not just conversion per se.
> > And selling point for many of them is not true: it doesn't make any
> > difference in the size in code, but increases a time to run
> > (devm_ioremap_resource() does more than plain devm_iomap() call).
>
> Okay, just seen it. Does the the runtime overhead cause any problems ?
You have to explain that in each commit message, that the change does bring a
possible new error message printed.
The performance side of the deal, you are lucky here, is not significant
because it's slow path.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: serial driver cleanups v2
From: Andy Shevchenko @ 2019-03-15 18:45 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: linux-arm-msm, Masahiro Yamada, macro, Peter Korsgaard,
Fabio Estevam, Stefan Wahren, Florian Fainelli,
bcm-kernel-feedback-list, dl-linux-imx, open list:SERIAL DRIVERS,
Uwe Kleine-König, Andy Gross, Tobias Klauser, David Brown,
Ray Jui, Sascha Hauer, slemieux.tyco,
open list:LINUX FOR POWERPC PA SEMI PWRFICIENT,
Vladimir Zapolskiy, Matthias Brugger,
Enrico Weigelt, metux IT consult, baohua, Scott Branden,
Eric Anholt, Richard Genoud, Greg Kroah-Hartman,
Linux Kernel Mailing List, Sascha Hauer, Shawn Guo
In-Reply-To: <d9ac8446-c7ff-6e57-5eaa-f1a09d549081@metux.net>
On Fri, Mar 15, 2019 at 8:44 PM Enrico Weigelt, metux IT consult
<lkml@metux.net> wrote:
> On 15.03.19 19:11, Andy Shevchenko wrote:
> OTOH, the name, IMHO, is a bit misleading. Any chance of ever changing
> it to a more clear name (eg. devm_request_and_ioremap_resource()) ?
Compare iomap vs. ioREmap.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: serial driver cleanups v2
From: Enrico Weigelt, metux IT consult @ 2019-03-15 18:41 UTC (permalink / raw)
To: Andy Shevchenko
Cc: linux-arm-msm, Masahiro Yamada, macro, Peter Korsgaard,
Fabio Estevam, Stefan Wahren, Florian Fainelli,
bcm-kernel-feedback-list, dl-linux-imx, open list:SERIAL DRIVERS,
Uwe Kleine-König, Andy Gross, Tobias Klauser, David Brown,
Ray Jui, Sascha Hauer, slemieux.tyco,
open list:LINUX FOR POWERPC PA SEMI PWRFICIENT,
Vladimir Zapolskiy, Matthias Brugger,
Enrico Weigelt, metux IT consult, baohua, Scott Branden,
Eric Anholt, Richard Genoud, Greg Kroah-Hartman,
Linux Kernel Mailing List, Sascha Hauer, Shawn Guo
In-Reply-To: <20190315181118.GF9224@smile.fi.intel.com>
On 15.03.19 19:11, Andy Shevchenko wrote:
>> The actual goal is generalizing the whole iomem handling, so individual
>> usually just need to call some helpers that do most of the things.
>> Finally, I also wanted to have all io region information consolidated
>> in struct resource.
>
> That's should be a selling point, not just conversion per se.
hmm, I never was good at selling :o
but I'll try anyways: it shall make the code smaller and easier to
read/understand.
does that count ?
> You have to explain that in each commit message, that the change does bring a
> possible new error message printed.
Ok, I wasn't aware of that. Yes, I missed to read the code of that
function carefully and didn't expect that it does more than just a dumb
wrapper around dev_ioremap() that picks out the params from struct
resource.
OTOH, the name, IMHO, is a bit misleading. Any chance of ever changing
it to a more clear name (eg. devm_request_and_ioremap_resource()) ?
> The performance side of the deal, you are lucky here, is not significant
> because it's slow path.
okay :)
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
^ permalink raw reply
* Re: [PATCH v2 10/45] drivers: tty: serial: zs: use devm_* functions
From: Enrico Weigelt, metux IT consult @ 2019-03-15 19:12 UTC (permalink / raw)
To: Greg KH
Cc: linux-arm-msm, yamada.masahiro, macro, jacmet, festevam,
stefan.wahren, f.fainelli, bcm-kernel-feedback-list, linux-imx,
linux-serial, slemieux.tyco, andy.gross, tklauser, david.brown,
rjui, s.hauer, u.kleine-koenig, linuxppc-dev, vz, matthias.bgg,
andriy.shevchenko, baohua, sbranden, eric, richard.genoud,
Enrico Weigelt, metux IT consult, linux-kernel, kernel, shawnguo
In-Reply-To: <20190315142628.GA30650@kroah.com>
On 15.03.19 15:26, Greg KH wrote:
> On Fri, Mar 15, 2019 at 10:06:16AM +0100, Enrico Weigelt, metux IT consult wrote:
>> On 14.03.19 23:52, Greg KH wrote:
>>> On Thu, Mar 14, 2019 at 11:33:40PM +0100, Enrico Weigelt, metux IT consult wrote:
>>>> Use the safer devm versions of memory mapping functions.
>>>
>>> What is "safer" about them?
>>
>> Garbage collection :)
>
> At times, but not when you do not use the api correctly :)
Okay, my fault that I didn't read the code careful enough :o
But still, I think the name is a bit misleading as it *sounds* as just
a wrapper around devm_ioremap() that just picks the params from a
struct resource. I guess we can't change the name easily ?
> Yes, there are lots of drivers for devices that are never unloaded or
> removed from the system. The fact that no one has reported any problems
> with them means that they are never used in situations like this.
So, never touch a running system ?
> No, you need to have a good reason why it needs to be changed, when you
> can not verify that this actually resolves a problem. As this patch
> shows, you just replaced one api call with another, so nothing changed
> at all, except you actually took up more memory and logic to do the same
> thing :(
Okay, I was on a wrong track here - I had the silly idea that it would
make things easier if we'd do it the same way everywhere.
>> IMHO, we should have a closer look at those and check whether that's
>> really okay (just adding request/release blindly could cause trouble)
>
> I agree, please feel free to audit these to verify they are all correct.
> But that's not what you did here, so that's not a valid justification
> for these patches to be accepted.
Understood. Assuming I've found some of these cases, shall I use devm
oder just add the missing release ?
>> In this consolidation process, I'm trying to move everything to
>> devm_*, to have it more generic (for now, I still need two versions
>> of the request/release/ioremap/iounmap helpers - one w/ and one
>> w/o devm).
>
> Move everything in what part of the kernel? The whole kernel or just
> one subsystem?
Just talking about the serial drivers.
>> My idea was moving to devm first, so it can be reviewed/tested
>> independently, before moving forward. Smaller, easily digestable
>> pieces should minimize the risk of breaking anything. But if you
>> prefer having this things squashed together, just let me know.
>
> Small pieces are required, that's fine, but those pieces need to have a
> justification for why they should be accepted at all points along the
> way.
Hmm, okay, in these cases, I agree there's no real justification if
we're not seeing it as an intermediate step to the upcoming stuff.
Having thought a bit more about this, my underlying dumbness was
setting everything on the devm horse when converting introducing the
helpers, and then splitted out the change to devm in even more patches
... Silly me, I better should have catched some sleep instead :o
>> In the queue are also other minor cleanups like using dev_err()
>> instead of printk(), etc. Should I send these separately ?
>
> Of course.
Ok. I'll collect those things in a separate branch and send out the
queue from time to time:
https://github.com/metux/linux/tree/wip/serial/charlady
>> By the way: do you have some public branch where you're collecting
>> accepted patches, which I could base mine on ? (tty.git/tty-next ?)
>
> Yes, that is the tree and branch, but remember that none of my trees can
> open up until after -rc1 is out.
So, within a merge window, you put everything else on hold ?
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
^ permalink raw reply
* Re: [PATCH] powerpc: bpf: Fix generation of load/store DW instructions
From: Daniel Borkmann @ 2019-03-16 0:30 UTC (permalink / raw)
To: Naveen N. Rao, Alexei Starovoitov, Yauheni Kaliuta
Cc: bpf, linuxppc-dev, netdev
In-Reply-To: <20190315145119.2776-1-naveen.n.rao@linux.vnet.ibm.com>
On 03/15/2019 03:51 PM, Naveen N. Rao wrote:
> Yauheni Kaliuta pointed out that PTR_TO_STACK store/load verifier test
> was failing on powerpc64 BE, and rightfully indicated that the PPC_LD()
> macro is not masking away the last two bits of the offset per the ISA,
> resulting in the generation of 'lwa' instruction instead of the intended
> 'ld' instruction.
>
> Segher also pointed out that we can't simply mask away the last two bits
> as that will result in loading/storing from/to a memory location that
> was not intended.
>
> This patch addresses this by using ldx/stdx if the offset is not
> word-aligned. We load the offset into a temporary register (TMP_REG_2)
> and use that as the index register in a subsequent ldx/stdx. We fix
> PPC_LD() macro to mask off the last two bits, but enhance PPC_BPF_LL()
> and PPC_BPF_STL() to factor in the offset value and generate the proper
> instruction sequence. We also convert all existing users of PPC_LD() and
> PPC_STD() to use these macros. All existing uses of these macros have
> been audited to ensure that TMP_REG_2 can be clobbered.
>
> Fixes: 156d0e290e96 ("powerpc/ebpf/jit: Implement JIT compiler for extended BPF")
> Cc: stable@vger.kernel.org # v4.9+
>
> Reported-by: Yauheni Kaliuta <yauheni.kaliuta@redhat.com>
> Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Applied, thanks!
^ permalink raw reply
* Re: [PATCH v2 10/45] drivers: tty: serial: zs: use devm_* functions
From: Greg KH @ 2019-03-16 3:26 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: linux-arm-msm, yamada.masahiro, macro, jacmet, festevam,
stefan.wahren, f.fainelli, bcm-kernel-feedback-list, linux-imx,
linux-serial, slemieux.tyco, andy.gross, tklauser, david.brown,
rjui, s.hauer, u.kleine-koenig, linuxppc-dev, vz, matthias.bgg,
andriy.shevchenko, baohua, sbranden, eric, richard.genoud,
Enrico Weigelt, metux IT consult, linux-kernel, kernel, shawnguo
In-Reply-To: <d81364fc-c5da-c1b2-f38a-3a23c701c50d@metux.net>
On Fri, Mar 15, 2019 at 08:12:47PM +0100, Enrico Weigelt, metux IT consult wrote:
> On 15.03.19 15:26, Greg KH wrote:
> > Yes, there are lots of drivers for devices that are never unloaded or
> > removed from the system. The fact that no one has reported any problems
> > with them means that they are never used in situations like this.
>
> So, never touch a running system ?
No, it's just that those systems do not allow those devices to be
removed because they are probably not on a removable bus.
> > No, you need to have a good reason why it needs to be changed, when you
> > can not verify that this actually resolves a problem. As this patch
> > shows, you just replaced one api call with another, so nothing changed
> > at all, except you actually took up more memory and logic to do the same
> > thing :(
>
> Okay, I was on a wrong track here - I had the silly idea that it would
> make things easier if we'd do it the same way everywhere.
"Consistent" is good, and valid, but touching old drivers that have few
users is always risky, and you need a solid reason to do so.
> >> IMHO, we should have a closer look at those and check whether that's
> >> really okay (just adding request/release blindly could cause trouble)
> >
> > I agree, please feel free to audit these to verify they are all correct.
> > But that's not what you did here, so that's not a valid justification
> > for these patches to be accepted.
>
> Understood. Assuming I've found some of these cases, shall I use devm
> oder just add the missing release ?
If it actually makes the code "simpler" or "more obvious", sure, that's
fine. But churn for churns sake is not ok.
> >> By the way: do you have some public branch where you're collecting
> >> accepted patches, which I could base mine on ? (tty.git/tty-next ?)
> >
> > Yes, that is the tree and branch, but remember that none of my trees can
> > open up until after -rc1 is out.
>
> So, within a merge window, you put everything else on hold ?
I put the review of new patch submissions on hold, yes. Almost all
maintainers do that as we can not add new patches to our trees at that
point in time.
And I do have other things I do during that period so it's not like I'm
just sitting around doing nothing :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 10/45] drivers: tty: serial: zs: use devm_* functions
From: Enrico Weigelt, metux IT consult @ 2019-03-16 9:17 UTC (permalink / raw)
To: Greg KH
Cc: linux-arm-msm, yamada.masahiro, macro, jacmet, festevam,
stefan.wahren, f.fainelli, bcm-kernel-feedback-list, linux-imx,
linux-serial, slemieux.tyco, andy.gross, tklauser, david.brown,
rjui, s.hauer, u.kleine-koenig, linuxppc-dev, vz, matthias.bgg,
andriy.shevchenko, baohua, sbranden, eric, richard.genoud,
Enrico Weigelt, metux IT consult, linux-kernel, kernel, shawnguo
In-Reply-To: <20190316032630.GB2499@kroah.com>
On 16.03.19 04:26, Greg KH wrote:
> No, it's just that those systems do not allow those devices to be
> removed because they are probably not on a removable bus.
Ok, devices (hw) might not be removable - that also the case for uarts
builtin some SoCs, or the good old PC w/ 8250. But does that also mean
that the driver should not be removable ?
IMHO, even if that's the case, it's still inconsistent. The driver then
shouldn't support a remove at all (or even builtin only), not just
incomplete remove.
>> Okay, I was on a wrong track here - I had the silly idea that it would
>> make things easier if we'd do it the same way everywhere.
>
> "Consistent" is good, and valid, but touching old drivers that have few
> users is always risky, and you need a solid reason to do so.
Understood.
By the way: do we have some people who have those old hw and could test?
Should we (try to) create some ? Perhaps some "tester" entry in
MAINTAINERS file ? (I could ask around several people who might have
lots of old / rare hardware.)
>> Understood. Assuming I've found some of these cases, shall I use devm
>> oder just add the missing release ?
>
> If it actually makes the code "simpler" or "more obvious", sure, that's
> fine. But churn for churns sake is not ok.
Ok.
> I put the review of new patch submissions on hold, yes. Almost all
> maintainers do that as we can not add new patches to our trees at that
> point in time.
hmm, looks like a pipeline stall ;-)
why not collecting in a separate branch, which later gets rebased to
mainline when rc is out ?
> And I do have other things I do during that period so it's not like I'm
> just sitting around doing nothing :)
So it's also a fixed schedule for your other work. Understood.
It seems that this workflow can confuse people. Few days ago, somebody
became nervous about missing reactions on patches. Your autoresponder
worked for me, but maybe not for everybody.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
^ permalink raw reply
* [GIT PULL] Please pull powerpc/linux.git powerpc-5.1-2 tag
From: Michael Ellerman @ 2019-03-16 11:28 UTC (permalink / raw)
To: Linus Torvalds
Cc: yanaijie, aik, aneesh.kumar, linux-kernel, malat, joel,
andrew.donnellan, mahesh, linuxppc-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Linus,
Please pull a few small powerpc updates for 5.1:
The following changes since commit 9580b71b5a7863c24a9bd18bcd2ad759b86b1eff:
powerpc/32: Clear on-stack exception marker upon exception return (2019-03-04 00:37:23 +1100)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.1-2
for you to fetch changes up to de3c83c2fd2b87cf68214eda76dfa66989d78cb6:
powerpc/64s: Include <asm/nmi.h> header file to fix a warning (2019-03-13 15:03:13 +1100)
- ------------------------------------------------------------------
powerpc fixes for 5.1 #2
One fix to prevent runtime allocation of 16GB pages when running in a VM (as
opposed to bare metal), because it doesn't work.
A small fix to our recently added KCOV support to exempt some more code from
being instrumented.
Plus a few minor build fixes, a small dead code removal and a defconfig update.
Thanks to:
Alexey Kardashevskiy, Aneesh Kumar K.V, Christophe Leroy, Jason Yan, Joel
Stanley, Mahesh Salgaonkar, Mathieu Malaterre.
- ------------------------------------------------------------------
Alexey Kardashevskiy (1):
powerpc/powernv: Fix compile without CONFIG_TRACEPOINTS
Aneesh Kumar K.V (1):
powerpc/hugetlb: Don't do runtime allocation of 16G pages in LPAR configuration
Jason Yan (1):
powerpc: remove dead code in head_fsl_booke.S
Joel Stanley (1):
powerpc/configs: Sync skiroot defconfig
Mahesh Salgaonkar (1):
powerpc/mm: Disable kcov for SLB routines
Mathieu Malaterre (1):
powerpc/64s: Include <asm/nmi.h> header file to fix a warning
arch/powerpc/configs/skiroot_defconfig | 12 +++++++++---
arch/powerpc/include/asm/book3s/64/hugetlb.h | 8 ++++++++
arch/powerpc/kernel/head_fsl_booke.S | 7 -------
arch/powerpc/kernel/traps.c | 1 +
arch/powerpc/mm/Makefile | 3 +++
arch/powerpc/platforms/powernv/opal-call.c | 1 +
6 files changed, 22 insertions(+), 10 deletions(-)
-----BEGIN PGP SIGNATURE-----
iQIcBAEBAgAGBQJcjN2tAAoJEFHr6jzI4aWA/jIQAK4J2VQD8Sw+2kSm3h7wW18U
+BDyc7fbbigQyBHFkMAdybRKsXMSCbco7jK12yUbh5xqYlo8Hc40DbKI32f0D3WE
7rRotjalxR9tF+u0+m8Pdge42bPmEyt6p/7w5Ys+wVj/KXqlwTJinqSvp5Qmrilk
19qOTaTCXEMJ7dFTXqlFNpBW+0kaahCZ6f767dPPKkiYSm/qMZjKG/KCejLDAGQL
x5ouTpPos8sOjts7dwJuBGCxTfU7usKpy1EbguIklzYjedk1MSh5sg6STTQsH8Y4
kAgd8T12Wo4cQPaBmjwTkD7BrCdWbjNcK5U61kKAByshM3ZyPo+xARyQMdIWVZJQ
pX51tjmKwzGk3nf1UiMP/jdx55Cj6rhr3EsfQepjocMa9t6IWNVpasAvFRPlw8ca
Xmhbqsjwy9wKroAYgITq1L+VfeDe+dXBgK7yrChpqSdU89iOYgjoUbnwI+OeSCbk
Hm8w1p5+7CNxRxNzBieqBCtYUIlEwjP3rOwuNEpb0dJ4USD4jEr/8Mk0YXWJj4yg
mplyFwUXBrWVQHlKRI2tabO8rY7KN8H+SC/EczvERxpLRc3m7dH3DIlMi8A4a9Lk
QyvoQY7n9fZw1lm+/6ORMCNSc8lkIrsDu44rgn7WpaZDbN1woia0q5AtsNDU9jr2
HwUoI/HIHq5FWRu4m6LN
=TNMo
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH v2 4/7] dt-bindings: counter: ftm-quaddec
From: Jonathan Cameron @ 2019-03-16 14:21 UTC (permalink / raw)
To: Rob Herring
Cc: Mark Rutland, devicetree, linuxppc-dev, linux-kernel, linux-pwm,
linux-iio, Patrick Havelange, Daniel Lezcano,
William Breathitt Gray, Li Yang, Thierry Reding, linux-arm-kernel,
Thomas Gleixner, Shawn Guo, Esben Haabendal
In-Reply-To: <20190312190952.GA18547@bogus>
On Tue, 12 Mar 2019 14:09:52 -0500
Rob Herring <robh@kernel.org> wrote:
> On Wed, Mar 06, 2019 at 12:12:05PM +0100, Patrick Havelange wrote:
> > FlexTimer quadrature decoder driver.
> >
> > Signed-off-by: Patrick Havelange <patrick.havelange@essensium.com>
> > Reviewed-by: Esben Haabendal <esben@haabendal.dk>
> > ---
> > Changes v2
> > - None
> > ---
> > .../bindings/counter/ftm-quaddec.txt | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/counter/ftm-quaddec.txt
> >
> > diff --git a/Documentation/devicetree/bindings/counter/ftm-quaddec.txt b/Documentation/devicetree/bindings/counter/ftm-quaddec.txt
> > new file mode 100644
> > index 000000000000..4d18cd722074
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/counter/ftm-quaddec.txt
> > @@ -0,0 +1,18 @@
> > +FlexTimer Quadrature decoder counter
> > +
> > +This driver exposes a simple counter for the quadrature decoder mode.
>
> Seems like this is more a mode of a h/w block than describing a h/w
> block. Bindings should do the latter.
The snag is that we need to dig ourselves out of the hole set by:
fsl,vf610-ftm-pwm etc.
Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt
Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
(I'm assuming these are the same IP block).
Can probably be sorted out though. One core driver binds against the
ftm and deals with instantiating the others depending on the configuration
(note that this mode for instance does make sense in DT as it's
really reflecting the fact there is a quadrature encoder
connected to the ftm).
Fiddly though :)
J
>
> > +
> > +Required properties:
> > +- compatible: Must be "fsl,ftm-quaddec".
> > +- reg: Must be set to the memory region of the flextimer.
> > +
> > +Optional property:
> > +- big-endian: Access the device registers in big-endian mode.
> > +
> > +Example:
> > + counter0: counter@29d0000 {
> > + compatible = "fsl,ftm-quaddec";
> > + reg = <0x0 0x29d0000 0x0 0x10000>;
> > + big-endian;
> > + status = "disabled";
> > + };
> > --
> > 2.19.1
> >
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.1-2 tag
From: pr-tracker-bot @ 2019-03-16 17:50 UTC (permalink / raw)
To: Michael Ellerman
Cc: yanaijie, aik, aneesh.kumar, linuxppc-dev, linux-kernel, malat,
joel, andrew.donnellan, mahesh, Linus Torvalds
In-Reply-To: <87y35f6osv.fsf@concordia.ellerman.id.au>
The pull request you sent on Sat, 16 Mar 2019 22:28:48 +1100:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.1-2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a9c55d58bc36b5a0ef7021772fc2508e693ed534
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* [PATCH] hotplug/drc-info: ininitialize fndit to zero
From: Colin King @ 2019-03-16 21:40 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Tyrel Datwyler, Bjorn Helgaas, linuxppc-dev, linux-pci
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Currently variable fndit is not initialized and contains a
garbage value, later it is set to 1 if a drc entry is found.
Ensure fndit is not containing garbage by initializing it to
zero. Also remove an extraneous space at the end of an
sprintf call.
Detected by static analysis with cppcheck.
Fixes: 2fcf3ae508c2 ("hotplug/drc-info: Add code to search ibm,drc-info property")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/pci/hotplug/rpaphp_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/hotplug/rpaphp_core.c b/drivers/pci/hotplug/rpaphp_core.c
index bcd5d357ca23..28213f44f64a 100644
--- a/drivers/pci/hotplug/rpaphp_core.c
+++ b/drivers/pci/hotplug/rpaphp_core.c
@@ -230,7 +230,7 @@ static int rpaphp_check_drc_props_v2(struct device_node *dn, char *drc_name,
struct of_drc_info drc;
const __be32 *value;
char cell_drc_name[MAX_DRC_NAME_LEN];
- int j, fndit;
+ int j, fndit = 0;
info = of_find_property(dn->parent, "ibm,drc-info", NULL);
if (info == NULL)
@@ -254,7 +254,7 @@ static int rpaphp_check_drc_props_v2(struct device_node *dn, char *drc_name,
/* Found it */
if (fndit)
- sprintf(cell_drc_name, "%s%d", drc.drc_name_prefix,
+ sprintf(cell_drc_name, "%s%d", drc.drc_name_prefix,
my_index);
if (((drc_name == NULL) ||
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] powerpc/6xx: fix setup and use of SPRN_PGDIR for hash32
From: Guenter Roeck @ 2019-03-16 22:47 UTC (permalink / raw)
To: Christophe Leroy, Michael Ellerman
Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <72bac00c-d2e3-515e-3ab1-99f20c058ea1@c-s.fr>
On 3/15/19 6:20 AM, Christophe Leroy wrote:
> Michael,
>
> Are you able to get this merged before 5.1-rc1 comes out ?
>
Looks like this patch got lost. I don't see it in Michael's most recent
pull request, the one that got merged today.
Guenter
> Thanks
> Christophe
>
> Le 08/03/2019 à 17:06, Christophe Leroy a écrit :
>>
>>
>> Le 08/03/2019 à 17:03, Segher Boessenkool a écrit :
>>> On Fri, Mar 08, 2019 at 07:05:22AM +0000, Christophe Leroy wrote:
>>>> Not only the 603 but all 6xx need SPRN_PGDIR to be initialised at
>>>> startup. This patch move it from __setup_cpu_603() to start_here()
>>>> and __secondary_start(), close to the initialisation of SPRN_THREAD.
>>>
>>> I thought you meant an SPR I did not know about. But you just misspelled
>>> SPRN_SPRG_PGDIR :-)
>>>
>>
>> Oops.
>>
>> Michael, can you fix the commit text (and subject) when applying ?
>>
>
>
>
^ permalink raw reply
* [PATCH] powerpc/mm: Only define MAX_PHYSMEM_BITS in SPARSEMEM configurations
From: Ben Hutchings @ 2019-03-17 1:17 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman; +Cc: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]
MAX_PHYSMEM_BITS only needs to be defined if CONFIG_SPARSEMEM is
enabled, and that was the case before commit 4ffe713b7587
("powerpc/mm: Increase the max addressable memory to 2PB").
On 32-bit systems, where CONFIG_SPARSEMEM is not enabled, we now
define it as 46. That is larger than the real number of physical
address bits, and breaks calculations in zsmalloc:
mm/zsmalloc.c:130:49: warning: right shift count is negative [-Wshift-count-negative]
MAX(32, (ZS_MAX_PAGES_PER_ZSPAGE << PAGE_SHIFT >> OBJ_INDEX_BITS))
^~
...
mm/zsmalloc.c:253:21: error: variably modified 'size_class' at file scope
struct size_class *size_class[ZS_SIZE_CLASSES];
^~~~~~~~~~
Fixes: 4ffe713b7587 ("powerpc/mm: Increase the max addressable memory to 2PB")
Cc: stable@vger.kernel.org
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
arch/powerpc/include/asm/mmu.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/mmu.h b/arch/powerpc/include/asm/mmu.h
index 25607604a7a5..2bc8c3f04f8a 100644
--- a/arch/powerpc/include/asm/mmu.h
+++ b/arch/powerpc/include/asm/mmu.h
@@ -341,7 +341,7 @@ static inline u16 get_mm_addr_key(struct mm_struct *mm, unsigned long address)
#if defined(CONFIG_SPARSEMEM_VMEMMAP) && defined(CONFIG_SPARSEMEM_EXTREME) && \
defined (CONFIG_PPC_64K_PAGES)
#define MAX_PHYSMEM_BITS 51
-#else
+#elif defined(CONFIG_SPARSEMEM)
#define MAX_PHYSMEM_BITS 46
#endif
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply related
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.1-2 tag
From: christophe leroy @ 2019-03-17 9:49 UTC (permalink / raw)
To: Michael Ellerman, Linus Torvalds
Cc: yanaijie, aik, aneesh.kumar, linux-kernel, malat, joel,
andrew.donnellan, mahesh, linuxppc-dev, Guenter Roeck
In-Reply-To: <87y35f6osv.fsf@concordia.ellerman.id.au>
Hi Michael,
Le 16/03/2019 à 12:28, Michael Ellerman a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Linus,
>
> Please pull a few small powerpc updates for 5.1:
>
> The following changes since commit 9580b71b5a7863c24a9bd18bcd2ad759b86b1eff:
>
> powerpc/32: Clear on-stack exception marker upon exception return (2019-03-04 00:37:23 +1100)
>
> are available in the git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.1-2
>
> for you to fetch changes up to de3c83c2fd2b87cf68214eda76dfa66989d78cb6:
>
> powerpc/64s: Include <asm/nmi.h> header file to fix a warning (2019-03-13 15:03:13 +1100)
>
> - ------------------------------------------------------------------
> powerpc fixes for 5.1 #2
>
> One fix to prevent runtime allocation of 16GB pages when running in a VM (as
> opposed to bare metal), because it doesn't work.
>
> A small fix to our recently added KCOV support to exempt some more code from
> being instrumented.
>
> Plus a few minor build fixes, a small dead code removal and a defconfig update.
>
> Thanks to:
> Alexey Kardashevskiy, Aneesh Kumar K.V, Christophe Leroy, Jason Yan, Joel
> Stanley, Mahesh Salgaonkar, Mathieu Malaterre.
Looks like the fix for 6xx/hash use of SPRN_SPRG_PGDIR is not there.
Patch at https://patchwork.ozlabs.org/patch/1053385/
(Or at https://patchwork.ozlabs.org/patch/1054213/ with better commit text)
Without that patch, 6xx with hash table silently loop forever in
pagefault handler while trying to start init, as reported from
linux-next by Guenter Roeck (see
https://patchwork.ozlabs.org/patch/1046041/)
Thanks
Christophe
>
> - ------------------------------------------------------------------
> Alexey Kardashevskiy (1):
> powerpc/powernv: Fix compile without CONFIG_TRACEPOINTS
>
> Aneesh Kumar K.V (1):
> powerpc/hugetlb: Don't do runtime allocation of 16G pages in LPAR configuration
>
> Jason Yan (1):
> powerpc: remove dead code in head_fsl_booke.S
>
> Joel Stanley (1):
> powerpc/configs: Sync skiroot defconfig
>
> Mahesh Salgaonkar (1):
> powerpc/mm: Disable kcov for SLB routines
>
> Mathieu Malaterre (1):
> powerpc/64s: Include <asm/nmi.h> header file to fix a warning
>
>
> arch/powerpc/configs/skiroot_defconfig | 12 +++++++++---
> arch/powerpc/include/asm/book3s/64/hugetlb.h | 8 ++++++++
> arch/powerpc/kernel/head_fsl_booke.S | 7 -------
> arch/powerpc/kernel/traps.c | 1 +
> arch/powerpc/mm/Makefile | 3 +++
> arch/powerpc/platforms/powernv/opal-call.c | 1 +
> 6 files changed, 22 insertions(+), 10 deletions(-)
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBAgAGBQJcjN2tAAoJEFHr6jzI4aWA/jIQAK4J2VQD8Sw+2kSm3h7wW18U
> +BDyc7fbbigQyBHFkMAdybRKsXMSCbco7jK12yUbh5xqYlo8Hc40DbKI32f0D3WE
> 7rRotjalxR9tF+u0+m8Pdge42bPmEyt6p/7w5Ys+wVj/KXqlwTJinqSvp5Qmrilk
> 19qOTaTCXEMJ7dFTXqlFNpBW+0kaahCZ6f767dPPKkiYSm/qMZjKG/KCejLDAGQL
> x5ouTpPos8sOjts7dwJuBGCxTfU7usKpy1EbguIklzYjedk1MSh5sg6STTQsH8Y4
> kAgd8T12Wo4cQPaBmjwTkD7BrCdWbjNcK5U61kKAByshM3ZyPo+xARyQMdIWVZJQ
> pX51tjmKwzGk3nf1UiMP/jdx55Cj6rhr3EsfQepjocMa9t6IWNVpasAvFRPlw8ca
> Xmhbqsjwy9wKroAYgITq1L+VfeDe+dXBgK7yrChpqSdU89iOYgjoUbnwI+OeSCbk
> Hm8w1p5+7CNxRxNzBieqBCtYUIlEwjP3rOwuNEpb0dJ4USD4jEr/8Mk0YXWJj4yg
> mplyFwUXBrWVQHlKRI2tabO8rY7KN8H+SC/EczvERxpLRc3m7dH3DIlMi8A4a9Lk
> QyvoQY7n9fZw1lm+/6ORMCNSc8lkIrsDu44rgn7WpaZDbN1woia0q5AtsNDU9jr2
> HwUoI/HIHq5FWRu4m6LN
> =TNMo
> -----END PGP SIGNATURE-----
>
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH v2 10/45] drivers: tty: serial: zs: use devm_* functions
From: Greg KH @ 2019-03-17 9:54 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: linux-arm-msm, yamada.masahiro, macro, jacmet, festevam,
stefan.wahren, f.fainelli, bcm-kernel-feedback-list, linux-imx,
linux-serial, slemieux.tyco, andy.gross, tklauser, david.brown,
rjui, s.hauer, u.kleine-koenig, linuxppc-dev, vz, matthias.bgg,
andriy.shevchenko, baohua, sbranden, eric, richard.genoud,
Enrico Weigelt, metux IT consult, linux-kernel, kernel, shawnguo
In-Reply-To: <fd8d6a9b-3e85-9904-2195-1f1bbc42bd2d@metux.net>
On Sat, Mar 16, 2019 at 10:17:11AM +0100, Enrico Weigelt, metux IT consult wrote:
> On 16.03.19 04:26, Greg KH wrote:
>
> > No, it's just that those systems do not allow those devices to be
> > removed because they are probably not on a removable bus.
>
> Ok, devices (hw) might not be removable - that also the case for uarts
> builtin some SoCs, or the good old PC w/ 8250. But does that also mean
> that the driver should not be removable ?
No, but 'rmmod' is not a normal operation that anyone ever does in a
working system. It is only for developer's ease-of-use.
> IMHO, even if that's the case, it's still inconsistent. The driver then
> shouldn't support a remove at all (or even builtin only), not just
> incomplete remove.
Cleaning up properly when the module is unloaded is a good idea, but so
far the patches you submitted did not change anything from a logic point
of view. They all just cleaned up memory the same way it was cleaned up
before, so I really do not understand what you are trying to do here.
> >> Okay, I was on a wrong track here - I had the silly idea that it would
> >> make things easier if we'd do it the same way everywhere.
> >
> > "Consistent" is good, and valid, but touching old drivers that have few
> > users is always risky, and you need a solid reason to do so.
>
> Understood.
>
> By the way: do we have some people who have those old hw and could test?
> Should we (try to) create some ? Perhaps some "tester" entry in
> MAINTAINERS file ? (I could ask around several people who might have
> lots of old / rare hardware.)
Let's not clutter up MAINTAINERS with anything else please.
> >> Understood. Assuming I've found some of these cases, shall I use devm
> >> oder just add the missing release ?
> >
> > If it actually makes the code "simpler" or "more obvious", sure, that's
> > fine. But churn for churns sake is not ok.
>
> Ok.
>
> > I put the review of new patch submissions on hold, yes. Almost all
> > maintainers do that as we can not add new patches to our trees at that
> > point in time.
>
> hmm, looks like a pipeline stall ;-)
> why not collecting in a separate branch, which later gets rebased to
> mainline when rc is out ?
I do do that for subsystems that actually have a high patch rate. The
tty/serial subsystem is not such a thing, and it can handle 2 weeks of
delay just fine.
> > And I do have other things I do during that period so it's not like I'm
> > just sitting around doing nothing :)
>
> So it's also a fixed schedule for your other work. Understood.
>
> It seems that this workflow can confuse people. Few days ago, somebody
> became nervous about missing reactions on patches. Your autoresponder
> worked for me, but maybe not for everybody.
Why would it not work for everybody? Kernel development has been done
in this manner for over a decade. Having a 2 week window like this is
good for the maintainers, remember they are the most limited resource we
have, not developers.
thanks,
greg k-h
^ permalink raw reply
* Re: Mac Mini G4 hang on boot with git master
From: Mark Cave-Ayland @ 2019-03-17 14:15 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In-Reply-To: <cf3327d8-3e04-2f37-4734-5525a5b638b2@ilande.co.uk>
On 15/03/2019 13:37, Mark Cave-Ayland wrote:
> Hi all,
>
> I've just done a git pull and rebuilt master on my Mac Mini G4 in order to test
> Michael's merge of my KVM PR fix, and unfortunately my kernel now hangs on boot :(
>
> My last working git checkout was somewhere around the 5.0-rc stage, so I suspect it's
> something that's been merged for 5.1.
>
> The hang occurs just after the boot console is disabled which makes me wonder if
> something is going wrong during PCI bus enumeration. Does anyone have an idea as to
> what may be causing this? I can obviously bisect it down, but on slow hardware it can
> take some time...
This was a weird one: bisecting directly from git master gave a nonsense result,
however by manually rebasing Michael's PR onto my last known good commit from master
I was able to finally pin it down to this commit:
7a0d6955f3f7a4250da63d528bfff7a9c91b5725 is the first bad commit
commit 7a0d6955f3f7a4250da63d528bfff7a9c91b5725
Author: Christophe Leroy <christophe.leroy@c-s.fr>
Date: Thu Feb 21 10:37:55 2019 +0000
powerpc/6xx: Store PGDIR physical address in a SPRG
Use SPRN_SPRG2 to store the current thread PGDIR and
avoid reading thread_struct.pgdir at every TLB miss.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
ATB,
Mark.
^ permalink raw reply
* [PATCH v2 0/5] Update hash MMU kernel mapping to be in sync with radix.
From: Aneesh Kumar K.V @ 2019-03-17 15:48 UTC (permalink / raw)
To: npiggin, benh, paulus, mpe; +Cc: Aneesh Kumar K.V, linuxppc-dev
This patch series map all the kernel regions (vmalloc, IO and vmemmap) using
0xc top nibble address. This brings hash translation kernel mapping in sync with radix.
Each of these regions can now map 512TB. We use one context to map these
regions and hence the 512TB limit. We also update radix to use the same limit even though
we don't have context related restrictions there.
Aneesh Kumar K.V (5):
powerpc/mm/hash64: Add a variable to track the end of IO mapping
powerpc/mm/hash64: Map all the kernel regions in the same 0xc range
powerpc/mm: Validate address values against different region limits
powerpc/mm: Drop the unnecessary region check
powerpc/mm/hash: Simplify the region id calculation.
arch/powerpc/include/asm/book3s/64/hash-4k.h | 15 +++
arch/powerpc/include/asm/book3s/64/hash-64k.h | 12 +++
arch/powerpc/include/asm/book3s/64/hash.h | 97 ++++++++++++-------
arch/powerpc/include/asm/book3s/64/mmu-hash.h | 31 +++---
arch/powerpc/include/asm/book3s/64/pgtable.h | 9 +-
arch/powerpc/include/asm/book3s/64/radix.h | 40 ++++----
arch/powerpc/include/asm/page.h | 11 ---
arch/powerpc/kvm/book3s_hv_rm_xics.c | 2 +-
arch/powerpc/mm/copro_fault.c | 14 ++-
arch/powerpc/mm/hash_utils_64.c | 45 ++++++---
arch/powerpc/mm/pgtable-hash64.c | 13 ++-
arch/powerpc/mm/pgtable-radix.c | 20 +++-
arch/powerpc/mm/pgtable_64.c | 9 +-
arch/powerpc/mm/ptdump/hashpagetable.c | 2 +-
arch/powerpc/mm/ptdump/ptdump.c | 3 +-
arch/powerpc/mm/slb.c | 22 +++--
arch/powerpc/platforms/cell/spu_base.c | 4 +-
drivers/misc/cxl/fault.c | 2 +-
drivers/misc/ocxl/link.c | 2 +-
19 files changed, 227 insertions(+), 126 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH v2 1/5] powerpc/mm/hash64: Add a variable to track the end of IO mapping
From: Aneesh Kumar K.V @ 2019-03-17 15:48 UTC (permalink / raw)
To: npiggin, benh, paulus, mpe; +Cc: Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <20190317154827.9188-1-aneesh.kumar@linux.ibm.com>
This makes it easy to update the region mapping in the later patch
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/include/asm/book3s/64/hash.h | 3 ++-
arch/powerpc/include/asm/book3s/64/pgtable.h | 8 +++++---
arch/powerpc/include/asm/book3s/64/radix.h | 1 +
arch/powerpc/mm/hash_utils_64.c | 1 +
arch/powerpc/mm/pgtable-radix.c | 1 +
arch/powerpc/mm/pgtable_64.c | 2 ++
6 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/hash.h b/arch/powerpc/include/asm/book3s/64/hash.h
index 54b7af6cd27f..8cbc4106d449 100644
--- a/arch/powerpc/include/asm/book3s/64/hash.h
+++ b/arch/powerpc/include/asm/book3s/64/hash.h
@@ -69,7 +69,8 @@
#define H_VMALLOC_SIZE (H_KERN_VIRT_SIZE - H_KERN_IO_SIZE)
#define H_VMALLOC_END (H_VMALLOC_START + H_VMALLOC_SIZE)
-#define H_KERN_IO_START H_VMALLOC_END
+#define H_KERN_IO_START H_VMALLOC_END
+#define H_KERN_IO_END (H_KERN_VIRT_START + H_KERN_VIRT_SIZE)
/*
* Region IDs
diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h
index 581f91be9dd4..51190a6d1c8a 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -277,9 +277,12 @@ extern unsigned long __vmalloc_end;
extern unsigned long __kernel_virt_start;
extern unsigned long __kernel_virt_size;
extern unsigned long __kernel_io_start;
+extern unsigned long __kernel_io_end;
#define KERN_VIRT_START __kernel_virt_start
#define KERN_VIRT_SIZE __kernel_virt_size
#define KERN_IO_START __kernel_io_start
+#define KERN_IO_END __kernel_io_end
+
extern struct page *vmemmap;
extern unsigned long ioremap_bot;
extern unsigned long pci_io_base;
@@ -296,8 +299,7 @@ extern unsigned long pci_io_base;
#include <asm/barrier.h>
/*
- * The second half of the kernel virtual space is used for IO mappings,
- * it's itself carved into the PIO region (ISA and PHB IO space) and
+ * IO space itself carved into the PIO region (ISA and PHB IO space) and
* the ioremap space
*
* ISA_IO_BASE = KERN_IO_START, 64K reserved area
@@ -310,7 +312,7 @@ extern unsigned long pci_io_base;
#define PHB_IO_BASE (ISA_IO_END)
#define PHB_IO_END (KERN_IO_START + FULL_IO_SIZE)
#define IOREMAP_BASE (PHB_IO_END)
-#define IOREMAP_END (KERN_VIRT_START + KERN_VIRT_SIZE)
+#define IOREMAP_END (KERN_IO_END)
/* Advertise special mapping type for AGP */
#define HAVE_PAGE_AGP
diff --git a/arch/powerpc/include/asm/book3s/64/radix.h b/arch/powerpc/include/asm/book3s/64/radix.h
index 5ab134eeed20..6d760a083d62 100644
--- a/arch/powerpc/include/asm/book3s/64/radix.h
+++ b/arch/powerpc/include/asm/book3s/64/radix.h
@@ -111,6 +111,7 @@
#define RADIX_VMEMMAP_BASE (RADIX_VMALLOC_END)
#define RADIX_KERN_IO_START (RADIX_KERN_VIRT_START + (RADIX_KERN_VIRT_SIZE >> 1))
+#define RADIX_KERN_IO_END (RADIX_KERN_VIRT_START + RADIX_KERN_VIRT_SIZE)
#ifndef __ASSEMBLY__
#define RADIX_PTE_TABLE_SIZE (sizeof(pte_t) << RADIX_PTE_INDEX_SIZE)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 0a4f939a8161..394dd969002f 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -1017,6 +1017,7 @@ void __init hash__early_init_mmu(void)
__vmalloc_start = H_VMALLOC_START;
__vmalloc_end = H_VMALLOC_END;
__kernel_io_start = H_KERN_IO_START;
+ __kernel_io_end = H_KERN_IO_END;
vmemmap = (struct page *)H_VMEMMAP_BASE;
ioremap_bot = IOREMAP_BASE;
diff --git a/arch/powerpc/mm/pgtable-radix.c b/arch/powerpc/mm/pgtable-radix.c
index 154472a28c77..bca1bf66c56e 100644
--- a/arch/powerpc/mm/pgtable-radix.c
+++ b/arch/powerpc/mm/pgtable-radix.c
@@ -578,6 +578,7 @@ void __init radix__early_init_mmu(void)
__vmalloc_start = RADIX_VMALLOC_START;
__vmalloc_end = RADIX_VMALLOC_END;
__kernel_io_start = RADIX_KERN_IO_START;
+ __kernel_io_end = RADIX_KERN_IO_END;
vmemmap = (struct page *)RADIX_VMEMMAP_BASE;
ioremap_bot = IOREMAP_BASE;
diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
index fb1375c07e8c..7cea39bdf05f 100644
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -98,6 +98,8 @@ unsigned long __vmalloc_end;
EXPORT_SYMBOL(__vmalloc_end);
unsigned long __kernel_io_start;
EXPORT_SYMBOL(__kernel_io_start);
+unsigned long __kernel_io_end;
+EXPORT_SYMBOL(__kernel_io_end);
struct page *vmemmap;
EXPORT_SYMBOL(vmemmap);
unsigned long __pte_frag_nr;
--
2.20.1
^ permalink raw reply related
* [PATCH v2 2/5] powerpc/mm/hash64: Map all the kernel regions in the same 0xc range
From: Aneesh Kumar K.V @ 2019-03-17 15:48 UTC (permalink / raw)
To: npiggin, benh, paulus, mpe; +Cc: Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <20190317154827.9188-1-aneesh.kumar@linux.ibm.com>
This patch maps vmap, IO and vmemap regions in the 0xc address range
instead of the current 0xd and 0xf range. This brings the mapping closer
to radix translation mode.
With hash 64K page size each of this region is 512TB whereas with 4K config
we are limited by the max page table range of 64TB and hence there regions
are of 16TB size.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/include/asm/book3s/64/hash-4k.h | 13 +++
arch/powerpc/include/asm/book3s/64/hash-64k.h | 11 +++
arch/powerpc/include/asm/book3s/64/hash.h | 95 ++++++++++++-------
arch/powerpc/include/asm/book3s/64/mmu-hash.h | 31 +++---
arch/powerpc/include/asm/book3s/64/pgtable.h | 1 -
arch/powerpc/include/asm/book3s/64/radix.h | 41 ++++----
arch/powerpc/include/asm/page.h | 3 +-
arch/powerpc/kvm/book3s_hv_rm_xics.c | 2 +-
arch/powerpc/mm/copro_fault.c | 14 ++-
arch/powerpc/mm/hash_utils_64.c | 26 ++---
arch/powerpc/mm/pgtable-radix.c | 3 +-
arch/powerpc/mm/pgtable_64.c | 2 -
arch/powerpc/mm/ptdump/hashpagetable.c | 2 +-
arch/powerpc/mm/ptdump/ptdump.c | 3 +-
arch/powerpc/mm/slb.c | 22 +++--
arch/powerpc/platforms/cell/spu_base.c | 4 +-
drivers/misc/cxl/fault.c | 2 +-
drivers/misc/ocxl/link.c | 2 +-
18 files changed, 170 insertions(+), 107 deletions(-)
diff --git a/arch/powerpc/include/asm/book3s/64/hash-4k.h b/arch/powerpc/include/asm/book3s/64/hash-4k.h
index cf5ba5254299..0dd62287f56c 100644
--- a/arch/powerpc/include/asm/book3s/64/hash-4k.h
+++ b/arch/powerpc/include/asm/book3s/64/hash-4k.h
@@ -13,6 +13,19 @@
*/
#define MAX_EA_BITS_PER_CONTEXT 46
+/*
+ * Our page table limit us to 64TB. Hence for the kernel mapping,
+ * each MAP area is limited to 16 TB.
+ * The four map areas are: linear mapping, vmap, IO and vmemmap
+ */
+#define H_KERN_MAP_SIZE (ASM_CONST(1) << (MAX_EA_BITS_PER_CONTEXT - 2))
+
+/*
+ * Define the address range of the kernel non-linear virtual area
+ * 16TB
+ */
+#define H_KERN_VIRT_START ASM_CONST(0xc000100000000000)
+
#ifndef __ASSEMBLY__
#define H_PTE_TABLE_SIZE (sizeof(pte_t) << H_PTE_INDEX_SIZE)
#define H_PMD_TABLE_SIZE (sizeof(pmd_t) << H_PMD_INDEX_SIZE)
diff --git a/arch/powerpc/include/asm/book3s/64/hash-64k.h b/arch/powerpc/include/asm/book3s/64/hash-64k.h
index f82ee8a3b561..e392cf17b457 100644
--- a/arch/powerpc/include/asm/book3s/64/hash-64k.h
+++ b/arch/powerpc/include/asm/book3s/64/hash-64k.h
@@ -13,6 +13,17 @@
*/
#define MAX_EA_BITS_PER_CONTEXT 49
+/*
+ * We use one context for each MAP area.
+ */
+#define H_KERN_MAP_SIZE (1UL << MAX_EA_BITS_PER_CONTEXT)
+
+/*
+ * Define the address range of the kernel non-linear virtual area
+ * 2PB
+ */
+#define H_KERN_VIRT_START ASM_CONST(0xc008000000000000)
+
/*
* 64k aligned address free up few of the lower bits of RPN for us
* We steal that here. For more deatils look at pte_pfn/pfn_pte()
diff --git a/arch/powerpc/include/asm/book3s/64/hash.h b/arch/powerpc/include/asm/book3s/64/hash.h
index 8cbc4106d449..523b9191a1e2 100644
--- a/arch/powerpc/include/asm/book3s/64/hash.h
+++ b/arch/powerpc/include/asm/book3s/64/hash.h
@@ -29,6 +29,10 @@
#define H_PGTABLE_EADDR_SIZE (H_PTE_INDEX_SIZE + H_PMD_INDEX_SIZE + \
H_PUD_INDEX_SIZE + H_PGD_INDEX_SIZE + PAGE_SHIFT)
#define H_PGTABLE_RANGE (ASM_CONST(1) << H_PGTABLE_EADDR_SIZE)
+/*
+ * Top 2 bits are ignored in page table walk.
+ */
+#define EA_MASK (~(0xcUL << 60))
/*
* We store the slot details in the second half of page table.
@@ -42,53 +46,60 @@
#endif
/*
- * Define the address range of the kernel non-linear virtual area. In contrast
- * to the linear mapping, this is managed using the kernel page tables and then
- * inserted into the hash page table to actually take effect, similarly to user
- * mappings.
+ * One context each will be used for vmap, IO and vmemmap
*/
-#define H_KERN_VIRT_START ASM_CONST(0xD000000000000000)
-
+#define H_KERN_VIRT_SIZE (H_KERN_MAP_SIZE * 3)
/*
- * Allow virtual mapping of one context size.
- * 512TB for 64K page size
- * 64TB for 4K page size
+ * +------------------------------+
+ * | |
+ * | |
+ * | |
+ * +------------------------------+ Kernel virtual map end (0xc00e000000000000)
+ * | |
+ * | |
+ * | 512TB/16TB of vmemmap |
+ * | |
+ * | |
+ * +------------------------------+ Kernel vmemmap start
+ * | |
+ * | 512TB/16TB of IO map |
+ * | |
+ * +------------------------------+ Kernel IO map start
+ * | |
+ * | 512TB/16TB of vmap |
+ * | |
+ * +------------------------------+ Kernel virt start (0xc008000000000000)
+ * | |
+ * | |
+ * | |
+ * +------------------------------+ Kernel linear (0xc.....)
*/
-#define H_KERN_VIRT_SIZE (1UL << MAX_EA_BITS_PER_CONTEXT)
-/*
- * 8TB IO mapping size
- */
-#define H_KERN_IO_SIZE ASM_CONST(0x80000000000) /* 8T */
+#define H_VMALLOC_START H_KERN_VIRT_START
+#define H_VMALLOC_SIZE H_KERN_MAP_SIZE
+#define H_VMALLOC_END (H_VMALLOC_START + H_VMALLOC_SIZE)
-/*
- * The vmalloc space starts at the beginning of the kernel non-linear virtual
- * region, and occupies 504T (64K) or 56T (4K)
- */
-#define H_VMALLOC_START H_KERN_VIRT_START
-#define H_VMALLOC_SIZE (H_KERN_VIRT_SIZE - H_KERN_IO_SIZE)
-#define H_VMALLOC_END (H_VMALLOC_START + H_VMALLOC_SIZE)
+#define H_KERN_IO_START H_VMALLOC_END
+#define H_KERN_IO_SIZE H_KERN_MAP_SIZE
+#define H_KERN_IO_END (H_KERN_IO_START + H_KERN_IO_SIZE)
-#define H_KERN_IO_START H_VMALLOC_END
-#define H_KERN_IO_END (H_KERN_VIRT_START + H_KERN_VIRT_SIZE)
+#define H_VMEMMAP_START H_KERN_IO_END
+#define H_VMEMMAP_SIZE H_KERN_MAP_SIZE
+#define H_VMEMMAP_END (H_VMEMMAP_START + H_VMEMMAP_SIZE)
/*
* Region IDs
*/
-#define REGION_SHIFT 60UL
-#define REGION_MASK (0xfUL << REGION_SHIFT)
-#define REGION_ID(ea) (((unsigned long)(ea)) >> REGION_SHIFT)
-
-#define VMALLOC_REGION_ID (REGION_ID(H_VMALLOC_START))
-#define KERNEL_REGION_ID (REGION_ID(PAGE_OFFSET))
-#define VMEMMAP_REGION_ID (0xfUL) /* Server only */
-#define USER_REGION_ID (0UL)
+#define USER_REGION_ID 1
+#define KERNEL_REGION_ID 2
+#define VMALLOC_REGION_ID 3
+#define IO_REGION_ID 4
+#define VMEMMAP_REGION_ID 5
/*
* Defines the address of the vmemap area, in its own region on
* hash table CPUs.
*/
-#define H_VMEMMAP_BASE (VMEMMAP_REGION_ID << REGION_SHIFT)
#ifdef CONFIG_PPC_MM_SLICES
#define HAVE_ARCH_UNMAPPED_AREA
@@ -104,6 +115,26 @@
#define H_PUD_BAD_BITS (PMD_TABLE_SIZE-1)
#ifndef __ASSEMBLY__
+static inline int get_region_id(unsigned long ea)
+{
+ int id = (ea >> 60UL);
+
+ if (id == 0)
+ return USER_REGION_ID;
+
+ VM_BUG_ON(id != 0xc);
+ VM_BUG_ON(ea >= H_VMEMMAP_END);
+
+ if (ea >= H_VMEMMAP_START)
+ return VMEMMAP_REGION_ID;
+ else if (ea >= H_KERN_IO_START)
+ return IO_REGION_ID;
+ else if (ea >= H_VMALLOC_START)
+ return VMALLOC_REGION_ID;
+
+ return KERNEL_REGION_ID;
+}
+
#define hash__pmd_bad(pmd) (pmd_val(pmd) & H_PMD_BAD_BITS)
#define hash__pud_bad(pud) (pud_val(pud) & H_PUD_BAD_BITS)
static inline int hash__pgd_bad(pgd_t pgd)
diff --git a/arch/powerpc/include/asm/book3s/64/mmu-hash.h b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
index a28a28079edb..b3f256c042aa 100644
--- a/arch/powerpc/include/asm/book3s/64/mmu-hash.h
+++ b/arch/powerpc/include/asm/book3s/64/mmu-hash.h
@@ -588,7 +588,8 @@ extern void slb_set_size(u16 size);
#endif
#define MAX_VMALLOC_CTX_CNT 1
-#define MAX_MEMMAP_CTX_CNT 1
+#define MAX_IO_CTX_CNT 1
+#define MAX_VMEMMAP_CTX_CNT 1
/*
* 256MB segment
@@ -601,13 +602,10 @@ extern void slb_set_size(u16 size);
* would give a protovsid of 0x1fffffffff. That will result in a VSID 0
* because of the modulo operation in vsid scramble.
*
- * We add one extra context to MIN_USER_CONTEXT so that we can map kernel
- * context easily. The +1 is to map the unused 0xe region mapping.
*/
#define MAX_USER_CONTEXT ((ASM_CONST(1) << CONTEXT_BITS) - 2)
#define MIN_USER_CONTEXT (MAX_KERNEL_CTX_CNT + MAX_VMALLOC_CTX_CNT + \
- MAX_MEMMAP_CTX_CNT + 2)
-
+ MAX_IO_CTX_CNT + MAX_VMEMMAP_CTX_CNT)
/*
* For platforms that support on 65bit VA we limit the context bits
*/
@@ -747,7 +745,7 @@ static inline unsigned long get_vsid(unsigned long context, unsigned long ea,
/*
* Bad address. We return VSID 0 for that
*/
- if ((ea & ~REGION_MASK) >= H_PGTABLE_RANGE)
+ if ((ea & EA_MASK) >= H_PGTABLE_RANGE)
return 0;
if (!mmu_has_feature(MMU_FTR_68_BIT_VA))
@@ -774,28 +772,29 @@ static inline unsigned long get_vsid(unsigned long context, unsigned long ea,
* 0x00002 - [ 0xc002000000000000 - 0xc003ffffffffffff]
* 0x00003 - [ 0xc004000000000000 - 0xc005ffffffffffff]
* 0x00004 - [ 0xc006000000000000 - 0xc007ffffffffffff]
-
- * 0x00005 - [ 0xd000000000000000 - 0xd001ffffffffffff ]
- * 0x00006 - Not used - Can map 0xe000000000000000 range.
- * 0x00007 - [ 0xf000000000000000 - 0xf001ffffffffffff ]
*
- * So we can compute the context from the region (top nibble) by
- * subtracting 11, or 0xc - 1.
+ * vmap, IO, vmemap
+ *
+ * 0x00005 - [ 0xc008000000000000 - 0xc009ffffffffffff]
+ * 0x00006 - [ 0xc00a000000000000 - 0xc00bffffffffffff]
+ * 0x00007 - [ 0xc00c000000000000 - 0xc00dffffffffffff]
+ *
*/
static inline unsigned long get_kernel_context(unsigned long ea)
{
- unsigned long region_id = REGION_ID(ea);
+ unsigned long region_id = get_region_id(ea);
unsigned long ctx;
/*
- * For linear mapping we do support multiple context
+ * Depending on Kernel config, kernel region can have one context
+ * or more.
*/
if (region_id == KERNEL_REGION_ID) {
/*
* We already verified ea to be not beyond the addr limit.
*/
- ctx = 1 + ((ea & ~REGION_MASK) >> MAX_EA_BITS_PER_CONTEXT);
+ ctx = 1 + ((ea & EA_MASK) >> MAX_EA_BITS_PER_CONTEXT);
} else
- ctx = (region_id - 0xc) + MAX_KERNEL_CTX_CNT;
+ ctx = region_id + MAX_KERNEL_CTX_CNT - 2;
return ctx;
}
diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h
index 51190a6d1c8a..8c156c5b4cd5 100644
--- a/arch/powerpc/include/asm/book3s/64/pgtable.h
+++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
@@ -279,7 +279,6 @@ extern unsigned long __kernel_virt_size;
extern unsigned long __kernel_io_start;
extern unsigned long __kernel_io_end;
#define KERN_VIRT_START __kernel_virt_start
-#define KERN_VIRT_SIZE __kernel_virt_size
#define KERN_IO_START __kernel_io_start
#define KERN_IO_END __kernel_io_end
diff --git a/arch/powerpc/include/asm/book3s/64/radix.h b/arch/powerpc/include/asm/book3s/64/radix.h
index 6d760a083d62..b43e12457fea 100644
--- a/arch/powerpc/include/asm/book3s/64/radix.h
+++ b/arch/powerpc/include/asm/book3s/64/radix.h
@@ -72,19 +72,17 @@
* | |
* | |
* | |
- * +------------------------------+ Kernel IO map end (0xc010000000000000)
+ * +------------------------------+ Kernel vmemmap end (0xc010000000000000)
* | |
+ * | 512TB |
* | |
- * | 1/2 of virtual map |
+ * +------------------------------+ Kernel IO map end/vmemap start
* | |
+ * | 512TB |
* | |
- * +------------------------------+ Kernel IO map start
+ * +------------------------------+ Kernel vmap end/ IO map start
* | |
- * | 1/4 of virtual map |
- * | |
- * +------------------------------+ Kernel vmemap start
- * | |
- * | 1/4 of virtual map |
+ * | 512TB |
* | |
* +------------------------------+ Kernel virt start (0xc008000000000000)
* | |
@@ -93,25 +91,24 @@
* +------------------------------+ Kernel linear (0xc.....)
*/
-#define RADIX_KERN_VIRT_START ASM_CONST(0xc008000000000000)
-#define RADIX_KERN_VIRT_SIZE ASM_CONST(0x0008000000000000)
-
+#define RADIX_KERN_VIRT_START ASM_CONST(0xc008000000000000)
/*
- * The vmalloc space starts at the beginning of that region, and
- * occupies a quarter of it on radix config.
- * (we keep a quarter for the virtual memmap)
+ * We use MAX_EA_BITS_PER_CONTEXT(hash specific) here just to make sure we pick
+ * the same value as hash.
*/
+#define RADIX_KERN_MAP_SIZE (1UL << MAX_EA_BITS_PER_CONTEXT)
+
#define RADIX_VMALLOC_START RADIX_KERN_VIRT_START
-#define RADIX_VMALLOC_SIZE (RADIX_KERN_VIRT_SIZE >> 2)
+#define RADIX_VMALLOC_SIZE RADIX_KERN_MAP_SIZE
#define RADIX_VMALLOC_END (RADIX_VMALLOC_START + RADIX_VMALLOC_SIZE)
-/*
- * Defines the address of the vmemap area, in its own region on
- * hash table CPUs.
- */
-#define RADIX_VMEMMAP_BASE (RADIX_VMALLOC_END)
-#define RADIX_KERN_IO_START (RADIX_KERN_VIRT_START + (RADIX_KERN_VIRT_SIZE >> 1))
-#define RADIX_KERN_IO_END (RADIX_KERN_VIRT_START + RADIX_KERN_VIRT_SIZE)
+#define RADIX_KERN_IO_START RADIX_VMALLOC_END
+#define RADIX_KERN_IO_SIZE RADIX_KERN_MAP_SIZE
+#define RADIX_KERN_IO_END (RADIX_KERN_IO_START + RADIX_KERN_IO_SIZE)
+
+#define RADIX_VMEMMAP_START RADIX_KERN_IO_END
+#define RADIX_VMEMMAP_SIZE RADIX_KERN_MAP_SIZE
+#define RADIX_VMEMMAP_END (RADIX_VMEMMAP_START + RADIX_VMEMMAP_SIZE)
#ifndef __ASSEMBLY__
#define RADIX_PTE_TABLE_SIZE (sizeof(pte_t) << RADIX_PTE_INDEX_SIZE)
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index ed870468ef6f..918228f2205b 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -139,7 +139,8 @@ static inline bool pfn_valid(unsigned long pfn)
* return true for some vmalloc addresses, which is incorrect. So explicitly
* check that the address is in the kernel region.
*/
-#define virt_addr_valid(kaddr) (REGION_ID(kaddr) == KERNEL_REGION_ID && \
+/* may be can drop get_region_id */
+#define virt_addr_valid(kaddr) (get_region_id((unsigned long)kaddr) == KERNEL_REGION_ID && \
pfn_valid(virt_to_pfn(kaddr)))
#else
#define virt_addr_valid(kaddr) pfn_valid(virt_to_pfn(kaddr))
diff --git a/arch/powerpc/kvm/book3s_hv_rm_xics.c b/arch/powerpc/kvm/book3s_hv_rm_xics.c
index 3b9662a4207e..085509148d95 100644
--- a/arch/powerpc/kvm/book3s_hv_rm_xics.c
+++ b/arch/powerpc/kvm/book3s_hv_rm_xics.c
@@ -822,7 +822,7 @@ static inline void this_cpu_inc_rm(unsigned int __percpu *addr)
raddr = per_cpu_ptr(addr, cpu);
l = (unsigned long)raddr;
- if (REGION_ID(l) == VMALLOC_REGION_ID) {
+ if (get_region_id(l) == VMALLOC_REGION_ID) {
l = vmalloc_to_phys(raddr);
raddr = (unsigned int *)l;
}
diff --git a/arch/powerpc/mm/copro_fault.c b/arch/powerpc/mm/copro_fault.c
index c8da352e8686..0da84a03388c 100644
--- a/arch/powerpc/mm/copro_fault.c
+++ b/arch/powerpc/mm/copro_fault.c
@@ -105,7 +105,7 @@ int copro_calculate_slb(struct mm_struct *mm, u64 ea, struct copro_slb *slb)
u64 vsid, vsidkey;
int psize, ssize;
- switch (REGION_ID(ea)) {
+ switch (get_region_id(ea)) {
case USER_REGION_ID:
pr_devel("%s: 0x%llx -- USER_REGION_ID\n", __func__, ea);
if (mm == NULL)
@@ -117,14 +117,18 @@ int copro_calculate_slb(struct mm_struct *mm, u64 ea, struct copro_slb *slb)
break;
case VMALLOC_REGION_ID:
pr_devel("%s: 0x%llx -- VMALLOC_REGION_ID\n", __func__, ea);
- if (ea < VMALLOC_END)
- psize = mmu_vmalloc_psize;
- else
- psize = mmu_io_psize;
+ psize = mmu_vmalloc_psize;
ssize = mmu_kernel_ssize;
vsid = get_kernel_vsid(ea, mmu_kernel_ssize);
vsidkey = SLB_VSID_KERNEL;
break;
+
+ case IO_REGION_ID:
+ pr_devel("%s: 0x%llx -- IO_REGION_ID\n", __func__, ea);
+ psize = mmu_io_psize;
+ ssize = mmu_kernel_ssize;
+ vsid = get_kernel_vsid(ea, mmu_kernel_ssize);
+ vsidkey = SLB_VSID_KERNEL;
case KERNEL_REGION_ID:
pr_devel("%s: 0x%llx -- KERNEL_REGION_ID\n", __func__, ea);
psize = mmu_linear_psize;
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index 394dd969002f..c6b39e7694ba 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -1013,12 +1013,11 @@ void __init hash__early_init_mmu(void)
__pgd_val_bits = HASH_PGD_VAL_BITS;
__kernel_virt_start = H_KERN_VIRT_START;
- __kernel_virt_size = H_KERN_VIRT_SIZE;
__vmalloc_start = H_VMALLOC_START;
__vmalloc_end = H_VMALLOC_END;
__kernel_io_start = H_KERN_IO_START;
__kernel_io_end = H_KERN_IO_END;
- vmemmap = (struct page *)H_VMEMMAP_BASE;
+ vmemmap = (struct page *)H_VMEMMAP_START;
ioremap_bot = IOREMAP_BASE;
#ifdef CONFIG_PCI
@@ -1239,7 +1238,7 @@ int hash_page_mm(struct mm_struct *mm, unsigned long ea,
trace_hash_fault(ea, access, trap);
/* Get region & vsid */
- switch (REGION_ID(ea)) {
+ switch (get_region_id(ea)) {
case USER_REGION_ID:
user_region = 1;
if (! mm) {
@@ -1253,10 +1252,13 @@ int hash_page_mm(struct mm_struct *mm, unsigned long ea,
break;
case VMALLOC_REGION_ID:
vsid = get_kernel_vsid(ea, mmu_kernel_ssize);
- if (ea < VMALLOC_END)
- psize = mmu_vmalloc_psize;
- else
- psize = mmu_io_psize;
+ psize = mmu_vmalloc_psize;
+ ssize = mmu_kernel_ssize;
+ break;
+
+ case IO_REGION_ID:
+ vsid = get_kernel_vsid(ea, mmu_kernel_ssize);
+ psize = mmu_io_psize;
ssize = mmu_kernel_ssize;
break;
default:
@@ -1422,7 +1424,8 @@ int hash_page(unsigned long ea, unsigned long access, unsigned long trap,
unsigned long flags = 0;
struct mm_struct *mm = current->mm;
- if (REGION_ID(ea) == VMALLOC_REGION_ID)
+ if ((get_region_id(ea) == VMALLOC_REGION_ID) ||
+ (get_region_id(ea) == IO_REGION_ID))
mm = &init_mm;
if (dsisr & DSISR_NOHPTE)
@@ -1438,8 +1441,9 @@ int __hash_page(unsigned long ea, unsigned long msr, unsigned long trap,
unsigned long access = _PAGE_PRESENT | _PAGE_READ;
unsigned long flags = 0;
struct mm_struct *mm = current->mm;
+ unsigned int region_id = get_region_id(ea);
- if (REGION_ID(ea) == VMALLOC_REGION_ID)
+ if ((region_id == VMALLOC_REGION_ID) || (region_id == IO_REGION_ID))
mm = &init_mm;
if (dsisr & DSISR_NOHPTE)
@@ -1456,7 +1460,7 @@ int __hash_page(unsigned long ea, unsigned long msr, unsigned long trap,
* 2) user space access kernel space.
*/
access |= _PAGE_PRIVILEGED;
- if ((msr & MSR_PR) || (REGION_ID(ea) == USER_REGION_ID))
+ if ((msr & MSR_PR) || (region_id == USER_REGION_ID))
access &= ~_PAGE_PRIVILEGED;
if (trap == 0x400)
@@ -1500,7 +1504,7 @@ void hash_preload(struct mm_struct *mm, unsigned long ea,
int rc, ssize, update_flags = 0;
unsigned long access = _PAGE_PRESENT | _PAGE_READ | (is_exec ? _PAGE_EXEC : 0);
- BUG_ON(REGION_ID(ea) != USER_REGION_ID);
+ BUG_ON(get_region_id(ea) != USER_REGION_ID);
if (!should_hash_preload(mm, ea))
return;
diff --git a/arch/powerpc/mm/pgtable-radix.c b/arch/powerpc/mm/pgtable-radix.c
index bca1bf66c56e..ba485fbd81f1 100644
--- a/arch/powerpc/mm/pgtable-radix.c
+++ b/arch/powerpc/mm/pgtable-radix.c
@@ -574,12 +574,11 @@ void __init radix__early_init_mmu(void)
__pgd_val_bits = RADIX_PGD_VAL_BITS;
__kernel_virt_start = RADIX_KERN_VIRT_START;
- __kernel_virt_size = RADIX_KERN_VIRT_SIZE;
__vmalloc_start = RADIX_VMALLOC_START;
__vmalloc_end = RADIX_VMALLOC_END;
__kernel_io_start = RADIX_KERN_IO_START;
__kernel_io_end = RADIX_KERN_IO_END;
- vmemmap = (struct page *)RADIX_VMEMMAP_BASE;
+ vmemmap = (struct page *)RADIX_VMEMMAP_START;
ioremap_bot = IOREMAP_BASE;
#ifdef CONFIG_PCI
diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
index 7cea39bdf05f..56068cac2a3c 100644
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -90,8 +90,6 @@ unsigned long __pgd_val_bits;
EXPORT_SYMBOL(__pgd_val_bits);
unsigned long __kernel_virt_start;
EXPORT_SYMBOL(__kernel_virt_start);
-unsigned long __kernel_virt_size;
-EXPORT_SYMBOL(__kernel_virt_size);
unsigned long __vmalloc_start;
EXPORT_SYMBOL(__vmalloc_start);
unsigned long __vmalloc_end;
diff --git a/arch/powerpc/mm/ptdump/hashpagetable.c b/arch/powerpc/mm/ptdump/hashpagetable.c
index b430e4e08af6..b9bda0105841 100644
--- a/arch/powerpc/mm/ptdump/hashpagetable.c
+++ b/arch/powerpc/mm/ptdump/hashpagetable.c
@@ -500,7 +500,7 @@ static void populate_markers(void)
address_markers[7].start_address = IOREMAP_BASE;
address_markers[8].start_address = IOREMAP_END;
#ifdef CONFIG_PPC_BOOK3S_64
- address_markers[9].start_address = H_VMEMMAP_BASE;
+ address_markers[9].start_address = H_VMEMMAP_START;
#else
address_markers[9].start_address = VMEMMAP_BASE;
#endif
diff --git a/arch/powerpc/mm/ptdump/ptdump.c b/arch/powerpc/mm/ptdump/ptdump.c
index 37138428ab55..63fc56feea15 100644
--- a/arch/powerpc/mm/ptdump/ptdump.c
+++ b/arch/powerpc/mm/ptdump/ptdump.c
@@ -303,8 +303,9 @@ static void populate_markers(void)
address_markers[i++].start_address = PHB_IO_END;
address_markers[i++].start_address = IOREMAP_BASE;
address_markers[i++].start_address = IOREMAP_END;
+ /* What is the ifdef about? */
#ifdef CONFIG_PPC_BOOK3S_64
- address_markers[i++].start_address = H_VMEMMAP_BASE;
+ address_markers[i++].start_address = H_VMEMMAP_START;
#else
address_markers[i++].start_address = VMEMMAP_BASE;
#endif
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index 5986df48359b..a0c37f428d60 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -694,7 +694,7 @@ static long slb_allocate_kernel(unsigned long ea, unsigned long id)
if (id == KERNEL_REGION_ID) {
/* We only support upto MAX_PHYSMEM_BITS */
- if ((ea & ~REGION_MASK) > (1UL << MAX_PHYSMEM_BITS))
+ if ((ea & EA_MASK) > (1UL << MAX_PHYSMEM_BITS))
return -EFAULT;
flags = SLB_VSID_KERNEL | mmu_psize_defs[mmu_linear_psize].sllp;
@@ -702,20 +702,25 @@ static long slb_allocate_kernel(unsigned long ea, unsigned long id)
#ifdef CONFIG_SPARSEMEM_VMEMMAP
} else if (id == VMEMMAP_REGION_ID) {
- if ((ea & ~REGION_MASK) >= (1ULL << MAX_EA_BITS_PER_CONTEXT))
+ if (ea >= H_VMEMMAP_END)
return -EFAULT;
flags = SLB_VSID_KERNEL | mmu_psize_defs[mmu_vmemmap_psize].sllp;
#endif
} else if (id == VMALLOC_REGION_ID) {
- if ((ea & ~REGION_MASK) >= (1ULL << MAX_EA_BITS_PER_CONTEXT))
+ if (ea >= H_VMALLOC_END)
return -EFAULT;
- if (ea < H_VMALLOC_END)
- flags = local_paca->vmalloc_sllp;
- else
- flags = SLB_VSID_KERNEL | mmu_psize_defs[mmu_io_psize].sllp;
+ flags = local_paca->vmalloc_sllp;
+
+ } else if (id == IO_REGION_ID) {
+
+ if (ea >= H_KERN_IO_END)
+ return -EFAULT;
+
+ flags = SLB_VSID_KERNEL | mmu_psize_defs[mmu_io_psize].sllp;
+
} else {
return -EFAULT;
}
@@ -725,6 +730,7 @@ static long slb_allocate_kernel(unsigned long ea, unsigned long id)
ssize = MMU_SEGSIZE_256M;
context = get_kernel_context(ea);
+
return slb_insert_entry(ea, context, flags, ssize, true);
}
@@ -761,7 +767,7 @@ static long slb_allocate_user(struct mm_struct *mm, unsigned long ea)
long do_slb_fault(struct pt_regs *regs, unsigned long ea)
{
- unsigned long id = REGION_ID(ea);
+ unsigned long id = get_region_id(ea);
/* IRQs are not reconciled here, so can't check irqs_disabled */
VM_WARN_ON(mfmsr() & MSR_EE);
diff --git a/arch/powerpc/platforms/cell/spu_base.c b/arch/powerpc/platforms/cell/spu_base.c
index 7f12c7b78c0f..4770cce1bfe2 100644
--- a/arch/powerpc/platforms/cell/spu_base.c
+++ b/arch/powerpc/platforms/cell/spu_base.c
@@ -194,7 +194,7 @@ static int __spu_trap_data_map(struct spu *spu, unsigned long ea, u64 dsisr)
* faults need to be deferred to process context.
*/
if ((dsisr & MFC_DSISR_PTE_NOT_FOUND) &&
- (REGION_ID(ea) != USER_REGION_ID)) {
+ (get_region_id(ea) != USER_REGION_ID)) {
spin_unlock(&spu->register_lock);
ret = hash_page(ea,
@@ -224,7 +224,7 @@ static void __spu_kernel_slb(void *addr, struct copro_slb *slb)
unsigned long ea = (unsigned long)addr;
u64 llp;
- if (REGION_ID(ea) == KERNEL_REGION_ID)
+ if (get_region_id(ea) == KERNEL_REGION_ID)
llp = mmu_psize_defs[mmu_linear_psize].sllp;
else
llp = mmu_psize_defs[mmu_virtual_psize].sllp;
diff --git a/drivers/misc/cxl/fault.c b/drivers/misc/cxl/fault.c
index dc7b34174f85..a4d17a5a9763 100644
--- a/drivers/misc/cxl/fault.c
+++ b/drivers/misc/cxl/fault.c
@@ -168,7 +168,7 @@ int cxl_handle_mm_fault(struct mm_struct *mm, u64 dsisr, u64 dar)
if (dsisr & CXL_PSL_DSISR_An_S)
access |= _PAGE_WRITE;
- if (!mm && (REGION_ID(dar) != USER_REGION_ID))
+ if (!mm && (get_region_id(dar) != USER_REGION_ID))
access |= _PAGE_PRIVILEGED;
if (dsisr & DSISR_NOHPTE)
diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c
index d50b861d7e57..04ec3d74f828 100644
--- a/drivers/misc/ocxl/link.c
+++ b/drivers/misc/ocxl/link.c
@@ -163,7 +163,7 @@ static void xsl_fault_handler_bh(struct work_struct *fault_work)
if (fault->dsisr & SPA_XSL_S)
access |= _PAGE_WRITE;
- if (REGION_ID(fault->dar) != USER_REGION_ID)
+ if (get_region_id(fault->dar) != USER_REGION_ID)
access |= _PAGE_PRIVILEGED;
local_irq_save(flags);
--
2.20.1
^ permalink raw reply related
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